用于浏览器的可插入语言引擎。为什么不？答案

【问题标题】：Pluggable language engines for browsers. Why not?用于浏览器的可插入语言引擎。为什么不？
【发布时间】：2011-04-13 18:54:27
【问题描述】：

Firefox 有一个 SpiderMonkey javascript 引擎。 Chrome 有 V8 javascript 引擎。

显然，这些引擎是一个独立的产品，浏览器利用某种接口 API 与它们进行交互。

另一方面，程序员长期以来一直渴望在浏览器中使用他们最喜欢的语言。如此之多，以至于我们拥有诸如 GWT（用于 java）、parenscript（用于 common lisp）、HJScript（用于 haskell）之类的产品，而且我确信许多其他语言的许多其他库允许程序员使用他们最喜欢的语言并生成客户端代码也是如此。

这个想法是如此明显，以至于我很惊讶还没有实现它。为什么不将浏览器的接口 API 发布到语言引擎，并允许网站提供自定义语言引擎作为可下载的包。以目前 3-4 MB 的互联网速度，一次下载对于大多数应用程序来说不是问题，对于 Intranet 使用更是如此。

那么我们的可插拔引擎在哪里？

【问题讨论】：

SpiderMonkey 和 V8 不仅仅是语言，它们也是一个完整的虚拟机。为什么不将语言与 VM 分开，并允许第三方提供自己的语言，如 JVM 和 dotnet 呢？这也可以解决安全问题。
我看不到好处...你为什么要这个？

标签： javascript browser

【解决方案1】：

您真的不需要可插拔引擎，只需要约定的字节码格式。谷歌现在正在使用基于 LLVM 的 NaCl 和 PNaCl 走这条路。因此，任何编译为 LLVM 字节码安全子集的程序都可以在浏览器中运行。

【讨论】：

【解决方案2】：

浏览器供应商甚至无法就通用视频格式（参见 html5 <video> 辩论）或 document DOM 对象的外观达成一致，您希望他们就整个语言界面达成一致吗？

祝你好运。

【讨论】：

成功永远不会受到指责。 Macromedia 并没有等到每个人都同意一个标准。他们刚刚推出了自己的解决方案。现在闪存是事实上的互联网标准。 SpiderMonkey 和 V8 不仅仅是语言，它们还是一个完整的虚拟机。为什么不将语言与 VM 分开，并允许第三方提供自己的语言，如 JVM 和 dotnet 呢？这也可以解决安全问题。
但我的观点是，他们需要就通用接口达成一致，而这极不可能。再加上你有像 Internet Explorer 这样短视的团队（对不起，这只是事实，你不能比那些人更固执地自卑），即使他们同意一些复杂到可以允许优化的东西，也永远不会实现他们，所以你会回到原点。

【解决方案3】：

我猜你忘记了小程序和嵌入。两者都提供您想要的。出于同样的原因，两者都很糟糕。

【讨论】：

【解决方案4】：

我们过去一直走这条路。

旧版本的 IE 支持 VBScript 作为除 JScript 之外的脚本语言。

结果是一大堆只能在 IE 中运行的网站。

这不是网络再次需要的。作为开发人员，我可能非常想使用我最喜欢的语言编写代码，但作为用户，我希望能够浏览网络上的所有站点，而不必担心任何给定站点需要哪些插件，或者是否我喜欢的浏览器甚至可以使用这些插件。

这是微软 Silverlight 遇到的问题。这可能是一项了不起的技术，但对于最终用户来说，我为什么想要另一个插件？ Silverlight 已经设法获得了一些市场份额，这要归功于微软的强大力量，但实际上并没有那么多。

现在，如果到达最终用户的代码是一致的，不管它是用什么语言编写的，那么语言就无关紧要了。但这实际上意味着编译代码（或至少是字节码），这与在浏览器中运行脚本语言完全不同。

【讨论】：

这不是原始海报所建议的。这与可单独下载的语言运行时安装程序无关。
@Eddy。是的。这正是OP所建议的。他建议下载语言运行时并将其作为插件安装到浏览器中。引用：“允许网站提供自定义语言引擎作为可下载的包”。不，这仍然不是一个好主意。也就是说，自提出这个问题以来的五年里，整个浏览器生态系统已经发生了翻天覆地的变化。事实上，目前的趋势是标准化编译字节码，正如我在上一段中所建议的那样，尽管我们还没有实现。
嗯，也许吧。恕我直言，原始海报旨在捆绑并直接从网站下载的运行时插件；不像 Flash、Java 或 Silverlight 中的“可单独下载”且单独启动的安装程序，但更像是当今网页中包含 JS 库的方式。无论如何，这对我来说仍然是一个不错的主意......