为什么选择JavaScript而不是标准的浏览器虚拟机？

通过浏览器中托管的标准化虚拟机支持一组语言(Java,Python,Ruby等)是否有意义,而不是要求使用专门的语言 - 实际上,这是一种专门的范例 - 仅适用于客户端脚本？

为了澄清这个建议,网页将包含字节代码而不是像JavaScript这样的任何高级语言.

我理解实用的现实,即由于进化原因,JavaScript正是我们现在必须处理的事情,但我在考虑更长远的问题.关于向后兼容性,没有理由在一段时间内无法同时支持内联JavaScript,当然JavaScript可能是浏览器虚拟机支持的语言之一.

1> Adam Wright..：

---

嗯,是.当然,如果我们有一台时间机器,返回并确保许多Javascript功能的设计不同将是一个主要的消遣(这,并确保设计IE的CSS引擎的人从未进入IT).但它不会发生,我们现在仍然坚持下去.

我怀疑,它将成为网络的"机器语言",其他更好的设计语言和API编译到它(并迎合不同的运行时引擎缺点).

但是,我不认为这些"设计得更好的语言"中的任何一种都是Java,Python或Ruby.尽管能够在其他地方使用,Javascript仍然是一种Web应用程序脚本语言.鉴于该用例,我们可以比任何一种语言做得更好.

---

-1为IE CSS团队备注.IE6在发布时并不坏,它的主要竞争对手是曾经写过的最蹩脚的垃圾软件.人员攻击虽然很有趣,但并不能让世界变得更美好.

---

+1对IE的CSS团队的评论很好......;)

---

不能不同意您对JavaScript的评估"...... Web应用程序脚本语言......".它是一种优秀,灵活的语言,具有更多的适用性.

---

@TJ Crowder:ITYM"不能不同意[...]更多."？

---

@Jaroslaw Szpilewski无耻的JS狂热主义？你有没有对此误认为是另一篇帖子？此外,对于@erikkallen,IE CSS团队的评论是俗称的"笑话".

---

在这个答案中有一些"千里眼":我们现在有了CoffeeScript.

2> Manuel Ceron..：

---

我认为JavaScript是一种很好的语言,但我希望在开发客户端Web应用程序时有一个选择.由于遗留原因,我们一直坚持使用JavaScript,但有些项目和想法正在寻找改变这种情况:

Google Native Client:用于在浏览器中运行本机代码的技术.

Emscripten:LLVM字节码编译器到javascript.允许LLVM语言在浏览器中运行.

想法:浏览器中的.NET CLI,由Mono的创建者提供:http://tirania.org/blog/archive/2010/May-03.html

我想我们将长期使用JavaScript,但这迟早会改变.有很多开发人员愿意在浏览器中使用其他语言.

3> the happy mo..：

---

回答这个问题 - 不,这没有意义.

目前,我们与多语言VM最接近的是JVM和CLR.这些并不是轻量级的野兽,尝试在浏览器中嵌入这样大小和复杂的东西是没有意义的.

让我们来看一下你可以编写一个比现有解决方案更好的新的多语言VM的想法.

你的稳定性落后了.

你落后于复杂性(方式,方式,背后因为你试图推广多种语言)

在采用方面你落后了

所以,不,它没有意义.

请记住,为了支持这些语言,您将不得不删除一些非常激烈的API,删除在浏览器脚本环境中没有意义的任何部分.这里有大量的设计决策,错误的机会很大.

在功能方面,我们可能只是真正使用DOM,所以这实际上是一个语法和语言的问题,在这一点上,有问题的是,"这真的值得吗？"

请记住,我们唯一讨论的是客户端脚本,因为服务器端脚本已经可以使用您喜欢的任何语言.这是一个相对较小的编程领域,因此带来多种语言的好处值得怀疑.

引入哪些语言是有意义的？(警告,主观材料如下)

引入像C这样的语言是没有意义的,因为它是用金属制作的,而在浏览器中没有太多的金属可用.

引入像Java这样的语言是没有意义的,因为关于它的最好的事情是API无论如何.

引入像Ruby或Lisp这样的语言没有意义,因为JavaScript是一种非常接近Scheme的强大动态语言.

最后,什么浏览器制造商真的想支持多种语言的DOM集成？每个实现都有自己的特定错误.我们已经走过火来处理MS Javascript和Mozilla Javascript之间的差异,现在我们想要将这种痛苦乘以五六倍？

这没有意义.

---

我认为你没有正确回答这个问题,你只是说明为什么你认为其他语言不适合此时浏览器中的javascript.适用于网络的通用字节码将是其他语言编译成的东西,如果该语言有用将取决于其创建者而不是web字节码,许多语言已经通过编译成javascript(即dart)来做到这一点.

---

我不认为浏览器中的VM是必要的.当然它已经作为Silverlight和Applets存在.后者未能获得普及,我认为主要是因为时机不好和技术愚蠢而且大部分已经解决.允许脚本标记之间的任何语言(有限制)都会非常酷,当然不是不可能也不是不切实际的.

---

沉重(MB)？可能没关系.沉重(复杂)？*方式*太重了.任何多语言VM你有,你将有语言实现坐在上面(如JRuby中/ IronRuby的,Clojure的是,Jython/IronPython的),等等.无论是JVM吃的复杂性或语言的实现做.

4> bobince..：

---

在Windows上,您可以使用脚本主机注册其他语言并将其提供给IE.例如,开箱即用支持VBScript(尽管它从未获得过多的普及,因为它对于大多数用途甚至比JavaScript更糟糕).

Python win32扩展允许人们很容易地将Python添加到IE中,但这并不是一个好主意,因为Python非常难以使用沙箱:许多语言功能暴露了足够的实现挂钩以允许一个受限制的应用程序突破.

一般来说,一个问题是,您添加到面向网络的应用程序(如浏览器)的复杂性越高,安全问题的可能性就越大.一堆新语言肯定符合这种描述,而这些新语言仍在快速发展.

JavaScript是一种丑陋的语言,但是通过仔细使用特定的特征子集以及来自合适的对象库的支持,它通常可以被认为是可以容忍的.似乎增量,实用的JavaScript添加是Web脚本可能继续发展的唯一方式.

5> Aivar..：

---

我肯定会欢迎浏览器中的标准语言独立VM(我更喜欢使用静态类型语言编写代码).

(技术上)逐渐可行:第一个主浏览器支持它,如果当前请求来自兼容浏览器或者将代码转换为JavaScript并发送纯文本JavaScript,则服务器可以发送字节码.

已经存在一些可以编译为JavaScript的实验语言,但是具有已定义的VM(可能)可以提供更好的性能.

不过我承认"标准"部分会非常棘手.此外,关于库的语言特征(例如,静态与动态类型)之间也会存在冲突(假设新事物将使用相同的库).因此,我认为不会发生(很快).

6> 小智..：

---

如果您觉得自己的手脏了,那么您可能已被洗脑,或者仍然感受到"DHTML年"的影响.JavaScript非常强大,非常适合其目的,即脚本交互客户端.这就是为什么JavaScript 2.0有这么糟糕的说唱.我的意思是,为什么包,接口,类等,当它们明显是服务器端语言的一部分时.JavaScript作为基于原型的语言很好,而不是面向对象的全面的.

如果由于服务器端和客户端之间的通信不良而导致应用程序缺乏可靠性,那么您可能需要重新考虑如何构建应用程序.我曾经使用过非常强大的网站和Web应用程序,我从来没有说过,"嗯,我真的希望JavaScript可以做(xyz)." 如果它可以做到这一点,那么它将不是JavaScript - 它将是ActionScript或AIR或Silverlight.我不需要那个,大多数开发人员也不需要.这些都是很好的技术,但他们试图用技术解决问题,而不是......好吧,解决方案.

---

1. Javascript完全是OOP.OOP是关于对象,而不是关于类.2.您可以在JavaScript中扩展对象,这是Prototypal面向对象编程的全部要点.你没有回答这个问题,问题不是攻击JS,只是要求选择.我认为JS是一种很棒的语言,但我希望在浏览器中编程时有其他选择.

---

怎么说,JavaScript不是面向对象的全面的？它肯定是我所知道的面向对象语言最多的语言之一.JavaScript中的所有东西都是一个对象 - 甚至是函数.只是JavaScript中的OOP在许多其他语言中看起来不像OOP.

---

你并没有错,我认为最好的方法就是JS不是基于类的OO,它是原型OO.

---

那个人错了."Protype"是一种设计模式(Gamma等人,第117-126页).正如您将回忆设计模式围绕面向对象编程中的常见设计.仅仅因为该语言与其他OOP语言不具有相同的功能并不意味着它不是OOP.

---

OOP不是JavaScript固有的.您没有内核中包含的包,接口,抽象类或方法重载,并且您无法扩展对象 - 只有对象的原型,这使得它在技术上基于原型,而不是基于OOP.

---

这不会让我"完全错误",它只会打开严格的OOP定义来解释 - 例如 - 有多少JavaScript是基于OO的.我的回答是:"其中一些 - 其余的都是基于原型的."

---

@ hal1001:JavaScript,Java,Ruby,SmallTalk,ActionScript等都支持面向对象的编程范例.其中一些允许通过原型继承对象,而另一些则使用类(ActionScript支持两者)."Prototypal"和"基于类"只是语言可以为其对象提供的两个继承/实例化方案的名称.

7> Jeremy Bell..：

---

我不认为标准的Web VM是不可思议的.有许多方法可以优雅地引入新的Web VM标准并具有完整的遗留支持,只要您确保您使用的任何VM字节码格式都可以快速反编译为javascript,并且结果输出将相当有效(我甚至会猜测一个智能反编译器可能会产生比人类自己产生的任何javascript更好的javascript.

使用此属性,可以在服务器上(快速),在客户端上轻松地反编译任何Web VM格式(速度很慢,但在您对服务器的控制有限的情况下可能),或者可以通过动态预生成和加载对于本身不支持新标准的浏览器,客户端或服务器(最快).

那些原生支持新标准的浏览器将受益于基于web vm的应用程序的运行时速度的提高.最重要的是,如果浏览器将其传统的javascript引擎基于web vm标准(即将javascript解析为web vm标准然后运行它),那么他们就不必管理两个运行时,但这取决于浏览器供应商.

8> jjrv..：

---

虽然Javascript是唯一支持良好的脚本语言,您可以直接控制页面,但Flash为更大的程序提供了一些非常好的功能.最近它有一个JIT,并且还可以动态生成字节码(检查运行时表达式评估,例如,他们使用flash将用户输入的数学表达式一直编译为本机二进制).Haxe语言为您提供了带有推理的静态类型,并且您可以使用字节码生成功能实现您选择的几乎任何运行时系统.

9> stefs..：

---

这个问题经常浮出水面。我对此的立场是：

A）不会发生，B）已经在这里。

对不起，什么？让我解释：

广告A

VM不仅仅是某种通用的神奇设备。大多数VM已针对特定语言和特定语言功能进行了优化。以JRE / Java（或LLVM）为例：针对静态类型进行了优化，并且在实现动态类型或Java首先不支持的其他功能时肯定存在问题和不利之处。

因此，支持许多语言功能（尾部调用优化，静态和动态键入，foo bar boo等）的“通用多用途VM”将是巨大的，难以实现的，并且可能更难于进行优化以获得良好的性能。它。但是我既不是语言设计师，也不是虚拟机大师，也许我错了：这实际上很简单，只有一个人没有这个主意？嗯，嗯。

广告B

已经在这里：可能没有字节码编译器/ vm，但是您实际上不需要一个。afaik javascript即将完成，因此应该可以：

创建从语言X到javascript（例如coffeescript）的翻译器

在javascript中创建解释器以解释语言X（例如brainfuck）。是的，性能会很糟糕，但是，嘿，不可能拥有一切。

广告C

什么？首先没有C点！因为还没有。谷歌NACL。如果有人能做到，那就是谷歌。google正常运行后，您的问题就解决了。只，嗯，它可能永远都行不通，我不知道。上一次我读到它时，确实遇到了一些棘手的安全问题。

---

除此之外：

javascript的出现始于〜1995 = 15年。仍然，今天的浏览器实现有所不同（尽管至少现在不再受此限制）。因此，如果您重新开始，可能会在2035年左右使用跨浏览器的版本。至少是一个有效的子集。只是微妙的不同。并且需要兼容性库和层。但是没有努力去改善事情没有意义。

另外，可读的源代码又如何呢？我知道许多公司宁愿不将其代码作为“某种”开放源代码提供。就个人而言，如果我怀疑有腥或想从中学习，我很高兴能够阅读该资料。万岁源代码！

10> Quentin Roy..：

---

快速更新这个老问题.

每个肯定"网页都包含字节代码而不是像JavaScript这样的高级语言"的人都不会发生.

2015年6月的W3C宣布WebAssembly即

一种新的便携式,大小和加载时间有效的格式,适合编译到Web上.

这仍然是实验性的,但是Firefox夜间和Chrome Canary已经有一些原型实现,并且已经有一些示范工作.

目前,WebAssembly主要设计为使用C/C++生成

随着WebAssembly的发展,它将支持比C/C++更多的语言,我们希望其他编译器也支持它.

我让你仔细看看项目的官方页面,真是令人兴奋!