适用于浏览器的可插入语言引擎。为什么不?

时间:2011-04-13 18:54:27

标签: javascript browser

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

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

另一方面,程序员在浏览器中渴望长时间使用他们喜欢的语言。所以,我们有像GWT(用于java),parenscript(用于常见的lisp),HJScript(用于haskell)等产品,并且我确信许多其他语言的许多其他库允许程序员使用他们喜欢的语言并生成客户端代码也是如此。

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

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

4 个答案:

答案 0 :(得分:10)

你真的不需要可插拔的引擎,只是一个商定的字节码格式。谷歌现在正在使用基于LLVM的NaCl和PNaCl。因此,任何编译成LLVM字节码安全子集的程序都可以在浏览器中运行。

答案 1 :(得分:1)

浏览器供应商甚至不能就常见的视频格式(请参阅html5 <video>辩论)或document DOM对象的外观如何达成一致,并希望他们就整体视图达成一致语言界面?

祝你好运。

答案 2 :(得分:1)

我猜你忘记了applets并嵌入了。两者都提供你想要的。两者都是出于同样的原因。

答案 3 :(得分:-1)

我们过去一直沿着这条路走下去。

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

结果是整个网站只能在IE中运行。

这不再是网络需要的。作为一名开发人员,我可能迫切希望使用我最喜欢的语言编写代码,但作为用户,我希望能够浏览网络上的所有网站,而不必担心我需要哪个插件来获取任何给定的网站,或者是否我首选的浏览器甚至可以使用这些插件。

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

现在,如果到达最终用户的代码是一致的,无论其编写的语言是什么,那么语言无关紧要。但这实际上意味着编译代码(或至少字节码),这是在浏览器中运行脚本语言的完全不同的鱼。