Javascript 浏览器的可插拔语言引擎。为什么不呢？

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

显然，这些引擎是一个独立的产品，浏览器使用某种接口API与之交互

另一方面，程序员很长时间以来都渴望在浏览器中使用他们最喜欢的语言。如此之多，我们有像GWT（用于java）、parenscript（用于common lisp）、HJScript（用于haskell）这样的产品，我相信还有许多其他语言的库，允许程序员使用他们喜欢的语言并生成客户端代码

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

---

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

浏览器供应商甚至无法就通用视频格式（参见html5

辩论）或

文档

DOM对象的外观达成一致，而您希望他们在整个语言界面上达成一致

---

祝你好运。

你其实不需要可插拔的引擎，只需要一种商定的字节码格式。谷歌现在正沿着这条路走下去，推出了基于LLVM的NaCl和PNaCl。因此，任何编译成LLVM字节码的安全子集的程序都可以在浏览器中运行。

我想你忘了小程序和嵌入式程序了。两者都能提供你想要的。这两个都是因为同样的原因。我们过去一直走这条路

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

结果是大量的站点只在IE中工作

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

这就是微软的Silverlight所面临的问题。这可能是一项了不起的技术，但对于最终用户来说，为什么我需要另一个插件？Silverlight凭借微软的强大实力获得了一定的市场份额，但实际上并没有那么多

---

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

SpiderMonkey和V8不仅是语言，它们也是一个完整的虚拟机。为什么不将语言与VM分开，并允许第三方提供自己的语言，如JVM和dotnet呢？那也能保证安全。我看不出有什么好处。。。你为什么要这样？成功永远不会被指责。Macromedia没有等到每个人都同意一个标准。他们刚刚推出了自己的解决方案。现在flash实际上是互联网标准。SpiderMonkey和V8不仅是语言，它们也是一个完整的虚拟机。为什么不将语言与VM分开，并允许第三方提供自己的语言，如JVM和dotnet呢？这也会考虑到安全性。但我的观点是，他们需要就一个通用接口达成一致，这是不可能的。此外，你还有一些目光短浅的团队，比如Internet Explorer（很抱歉，这只是事实，你不能比那些家伙更顽固地自卑），他们即使同意一些足够复杂的事情来进行优化，也永远不会实施，所以你会回到原点。这不是最初的海报所建议的。它不是关于一个可单独下载的语言运行时安装程序。是的。这正是OP建议的。他建议下载语言运行库并将其作为插件安装到浏览器中。引用：“允许网站提供自定义语言引擎作为可下载包”。不，这仍然不是个好主意。也就是说，自从提出这个问题以来，整个浏览器生态系统在五年内发生了彻底的变化。事实上，目前的趋势是标准化编译字节码，正如我在上一段中所建议的，尽管我们还没有做到。嗯，也许吧。IMHO最初的海报旨在捆绑运行时插件并直接从网站下载；不像Flash、Java或Silverlight那样是一个“可单独下载”和单独启动的安装程序，更像是JS库如何包含在今天的网页中。不管怎样，对我来说这仍然是个不错的主意。。。