我一直有点恼火的是，javascript 项目有两个主要领域——Node 和“浏览器”——虽然大多数浏览器 JS 可以很容易地在 Node 中运行，如果需要的话，还有几个用于 DOM 东西的库，将 Node 内容移植到浏览器通常是事后才想到的。
对于开发者社区来说，这一切似乎是浪费了大量的精力，所有 JS 开发者都可以减轻这种情况，他们只是为“最小公分母”(浏览器)开发并使用各种垫片来使用仅在除了普通的旧浏览器之外的 Node 或其他 JS 环境。
这不仅会减少很多生态系统的障碍并使浏览器中的开发更加现实，还会使赋予浏览器超能力成为司空见惯的事情......查看示例 browserver ，它在浏览器内部设置了一个 http 服务器，但由于浏览器实际上不能接受 http 请求，因此使用 websockets 与可以接受的代理 Node 服务器通信。
所以我想问一下，与 Node 相比，网络浏览器的 javascript 环境的真正技术限制是什么？ 我认为 Node 只是“一个 javascript 环境，加上 http 服务器和本地文件系统，减去 DOM 和 chrome”。是否有技术原因导致开发人员无法采用我上面描述的方法，为浏览器 JS 环境开发(这有正式名称吗？)并为 Node 使用垫片？
最佳答案
在客户端上运行的代码通常与在服务器上运行的代码有非常不同的目标。然而，当有必要在两种环境中使用一些库的特性时，有很多特性是使用通用的 AMD 形式定义的，这使得它们与平台无关(例如 Q)。
这两种环境之间的主要区别在于，一种环境受严格的安全策略和限制(浏览器)约束，而另一种则不然。对于与安全相关的操作(例如强制执行安全权限)，浏览器也是一个不可信任的环境。
我还将在此处添加 @jfriend00 评论，因为我认为它也非常相关并暴露了其他差异:
The biggest practical difference is that you have to design a browser application to work in an installed base of existing browsers including older versions (lowest common denominator). When deploying a node application, you get to select the ONE version of node that you want to develop for and deploy with. This allows node developers to use the latest greatest features in node which won't be available across the general browser population for years. @jfriend00
browserver之类的项目很有意思，我都是为了实验开发，但是在实践中真的有用吗？图书馆应该为它们真正有用的环境而设计。让所有库在两种环境中都可用没有任何好处。这不仅通常会导致代码复杂性增加，而且某些功能有时无法进行 shimmable，从而导致平台之间的 API 不一致。
关于javascript - Node环境和浏览器javascript环境的区别，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/23959868/