Node环境和浏览器javascript环境之间的差异

Question

我一直有点恼火,有两个javascript项目的主要领域 - 节点和"浏览器" - 虽然大多数浏览器JS可以很容易地在Node内部运行,如果需要的话可以使用几个DOM库,移植Node浏览器的内容通常是事后的想法.

这一切似乎都是开发人员社区浪费的大量精力,所有JS开发人员只需针对"最小公分母"(浏览器)进行开发并使用各种填充程序来使用仅在Node或其他中提供的功能除了普通的旧浏览器之外的JS环境.

这不仅削减了大量的生态系统冗余代码,并开发功能于该浏览器更加逼真,这也使得它平常给浏览器的超级大国......在寻找例如browserver,其中规定了在浏览器中的http服务器,但因为浏览器实际上不能接受http请求,所以使用websockets与可以的代理节点服务器通信.

所以我想问一下,网络浏览器的javascript环境与Node相比,真正的技术限制是什么？ 我认为Node只是"一个javascript环境,加上http服务器和本地文件系统,减去DOM和chrome".是否存在技术原因导致开发人员无法转向我上面描述的方法,为浏览器JS环境开发(这有官方名称吗？)并使用节点的填充程序？

Answer 1

在客户端上运行的代码通常与在服务器上运行的代码具有非常不同的目标。然而，当在两种环境中使用某些库的功能有意义时，其中许多功能是使用通用 AMD 形式定义的，这使得它们独立于平台（例如Q）。

两种环境之间的主要区别在于，一种环境受到严格的安全策略和限制（浏览器）的约束，而另一种则不受。对于与安全相关的操作（例如强制执行安全权限）来说，浏览器也是一个不可信的环境。

我还将在这里添加 @jfriend00 评论，因为我相信它也非常相关并暴露了其他差异：

最大的实际区别是，您必须设计一个浏览器应用程序，以便在现有浏览器的安装基础上工作，包括旧版本（最低公分母）。部署节点应用程序时，您可以选择要开发和部署的节点的一个版本。这使得节点开发人员可以使用节点中最新的、最强大的功能，而这些功能多年来在一般浏览器中都无法使用。@jfriend00

像 browserver 这样的项目很有趣，我完全赞成实验性开发，但它们在实践中真的有用吗？图书馆应该针对其真正有用的环境进行设计。让所有库在两种环境中都可用并没有任何好处。它不仅通常会导致代码复杂性增加，而且某些功能有时无法调整，从而导致平台之间的 API 不一致。