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

是的。当然，如果我们有一个时间机器，回顾并确保许多 Javascript 特性的设计是不同的将是一个主要的消遣(这，并确保人谁设计的 IE 的 CSS 引擎从来没有进入 IT)。但这是不可能的，我们现在只能这样了。

我怀疑，随着时间的推移，它将成为网络的“机器语言”，其他设计得更好的语言和 API 也将编译成它(并迎合不同的运行时引擎缺陷)。

然而，我不认为这些“设计得更好的语言”是 Java、 Python 或 Ruby。尽管 Javascript 可以在其他地方使用，但它是一个 Web 应用程序的脚本语言。考虑到这个用例，我们可以比任何一种语言做得更好。

也许吧，但要做到这一点，我们需要得到主流浏览器的支持。IE 支持将是最难获得的。使用 JavaScript 是因为它是您唯一可以依赖的东西。

JavaScript 是唯一可用的原生标准选项。如果你想要更强大的功能，可以使用 jQuery，但是如果你需要做更多的事情，可以考虑为 Firefox 写一个插件吗？或类似的工业工程等。

我想这是 没那么容易的问题。我们可以说我们在使用 JS，但是使用 jQuery、 Prototype、 scriptacous、 MooTools 和所有出色的库真的有那么糟糕吗？

记住，JS 是 轻量级的，在 V8、 TraceMonkey、 SquirrelFish 中更是如此——这是现代浏览器中使用的新的 Javascript 引擎。

它也是 证明了-是的，我们知道它有问题，但我们有很多这些解决了，像早期的安全问题。允许浏览器运行 Ruby 代码或其他任何东西的成像。安全沙盒将不得不做，为了从头开始。你知道吗？Python 的人已经用过两次 失败了了。

我认为随着时间的推移，Javascript 将成为 修改和改进，就像 HTML 和 CSS 一样。这个过程可能很漫长，但并不是世界上的一切都是可能的。

如果你觉得你的手脏了，那么你要么是被洗脑了，要么是仍然感觉到“ DHTML 时代”的后遗症。JavaScript 非常强大，非常适合用于脚本交互性客户端。这就是为什么 JavaScript 2.0名声不佳的原因。我的意思是，为什么包、接口、类等等，这些显然都是服务器端语言的方面。JavaScript 作为一种基于原型的语言，并没有成熟的面向对象的特点，这一点很好。

如果您的应用程序缺乏无缝性，因为服务器端和客户端通信不畅，那么您可能需要重新考虑如何构建应用程序。我曾经处理过非常健壮的 Web 站点和 Web 应用程序，我从来没有说过，“嗯，我真的希望 JavaScript 可以做(xyz)。”如果它可以做到这一点，那么它就不会是 JavaScript ——它会是 ActionScript、 AIR 或 Silverlight。我不需要，大多数开发人员也不需要。这些都是很好的技术，但他们试图用一种技术来解决问题，而不是用一种..。.一个解决办法。

实际上，Javascript 是任何浏览器都将长期使用的唯一语言，所以尽管使用其他语言会很好，但我不认为它会发生。

你所说的“标准化虚拟机”非常大，需要被所有主流浏览器采用，而且大多数网站还是会继续使用 Javascript，因为它比其他浏览器更适合网站。

您必须在这个 VM 中对每种编程语言进行沙箱处理，并减少每种语言对系统的访问量，这需要对语言进行大量更改，并删除或重新实现许多特性。而 Javascript 已经考虑到了这一点，并且已经做了很长时间。

虽然 Javascript 是唯一支持良好的脚本语言，你可以直接从中控制页面，但是 Flash 对于大型程序有一些非常好的特性。最近它有了一个 JIT，还可以动态地生成字节码(参考 运行时表达式计算的一个例子，它使用 flash 将用户输入的数学表达式编译成本机二进制)。Hax 语言提供了带有推理和字节码生成能力的静态类型，您可以实现几乎任何您选择的运行时系统。

那你要怎么处理浏览器里的 Python 和 Ruby 呢！

1)仍然在编写脚本化的客户端应用程序吗。

2)使用套接字编写客户端-服务器应用程序? 为什么不直接在不使用浏览器的情况下编写呢？

3)编写独立的应用程序? 就像你现在做的那样。

你如何定义最好？对浏览器最好，还是对开发者最好？(另外 ECMAScript 与 Javascript 不同，但这是一个技术问题。)

我发现 JavaScript 既强大又优雅。不幸的是，我遇到的大多数开发人员都把它当作一种必要的罪恶，而不是一种真正的编程语言。

我喜欢的特色有:

• 把职能作为一等公民对待
• 能够在任何时候向任何对象添加和删除函数(没有多大用处，但当它是令人兴奋的)
• 它是一种动态的语言。

处理起来很有趣，而且已经建立起来了。尽情享受它吧，因为尽管它可能不是客户端脚本的“最佳”，但它的确令人愉快。

由于浏览器的不兼容性，制作动态页面确实令人沮丧，但 UI 库可以缓解这种情况。它不应该再针对 JavaScript 本身，就像 Swing 不应该针对 Java 一样。

在 Windows 上，您可以向 Scripting Host 注册其他语言，并将它们提供给 IE。例如，VBScript 支持开箱即用(尽管它从来没有获得多少流行，因为它在大多数情况下甚至比 JavaScript 更糟糕)。

Python win32扩展允许人们像这样轻松地将 Python 添加到 IE 中，但是这并不是一个好主意，因为 Python 很难被沙箱覆盖: 许多语言特性暴露了足够多的实现挂钩，允许一个被认为受限制的应用程序突破。

一般来说，面向网络的应用程序(如浏览器)的复杂性越高，出现安全问题的可能性就越大。一大堆新语言肯定符合这种描述，而且这些新语言也仍在快速发展。

JavaScript 是一种丑陋的语言，但是通过谨慎地使用特性的一个选择性子集，以及来自合适的对象库的支持，它通常可以变得相当可以忍受。对 JavaScript 进行渐进式的、实际的添加似乎是 Web 脚本继续发展的唯一途径。

绝大多数的开发人员我已经谈到了 ECMAScript 等。人们最终承认，问题不在于脚本语言，而在于它暴露出来的可笑的 HTML DOM。混淆 DOM 和脚本语言是 ECmascript 常见的痛苦和挫折来源。另外，不要忘记，IIS 可以使用 JScript 编写服务器端脚本，而且像 Rhino 这样的软件允许您在 ECMAScript 中构建独立的应用程序。尝试在这些环境中使用 ECMAScript 工作一段时间，看看您的观点是否有所改变。

这种绝望已经存在一段时间了。我建议你编辑这篇文章，以包含或转发特定的问题。你可能会因为得到的一些安慰而感到喜欢·一个人。

一个老网站，但仍然是一个伟大的地方开始: 道格拉斯·克罗克福特的网站。

问题不在于 JavaScript 这种语言。JavaScript 实际上是一种非常具有表现力和强大功能的语言。我认为它的名声不好，因为它没有经典的 OO 功能，但对我来说，我越是与原型槽，我越喜欢它。

在我看来，问题在于我们被迫在网络上支持的许多浏览器的实现都是不稳定和不一致的。像 jQuery 这样的 JavaScript 库对于减轻这种不愉快的感觉大有帮助。

嗯，我们已经有 VBScript 了，不是吗? 等等，只有 IE 支持它！
你对虚拟机的好想法也一样。如果我使用 Lua 编写页面脚本，而您的浏览器没有解析器将其转换为字节码，该怎么办？当然，我们可以想象一个脚本标记接受一个字节码文件，这甚至是相当有效的。
但是经验告诉我们很难给互联网带来新的东西: 采用这样一个彻底的新变化需要很多年的时间。有多少浏览器支持 SVG 或 CSS3？

再说了，我不觉得你觉得 JS 有什么“肮脏”的。如果由业余人士编写代码，传播其他地方复制的不良实践，那么它可能很丑陋，但大师们表明，它也可以是一种优雅的语言。有点像 Perl: 通常看起来像是一种模糊的语言，但是可以使其具有完美的可读性。

我不认为你“理解 JavaScript 只是我们现在必须处理的实际问题”。实际上，它是一种非常强大的语言。您在浏览器中使用 Javaapplet 已经很多年了，现在它在哪里呢？

无论如何，在客户机上工作不需要“弄脏”。

也许你正在寻找谷歌的本地客户端。

我当然欢迎浏览器中独立于标准语言的 VM (我更喜欢用静态类型语言编写代码)。

(技术上)这是相当可行的逐步: 首先，一个主要的浏览器支持它和服务器有可能要么发送字节码，如果当前请求是从兼容的浏览器或转换代码到 JavaScript 和发送纯文本 JavaScript。

现在已经有一些实验性语言可以编译成 JavaScript，但是拥有一个已定义的 VM (也许)可以提供更好的性能。

不过，我承认，“标准”部分会相当棘手。此外，语言特性(例如静态与动态类型)之间也会有关于库的冲突(假设新事物将使用相同的库)。因此，我认为这不会(很快)发生。

你的推理有些错误。

1. 标准浏览器中的标准虚拟机永远不会是标准的。我们有4个浏览器，并且 IE 在“标准”方面存在利益冲突。其他三项技术发展迅速，但新技术的采用率较低。手机上的浏览器，小型设备..。

2. JS 在不同浏览器中的集成及其过去的历史导致您低估了 JS 的威力。你承诺建立一个标准，但是不赞成 JS，因为标准在早期的时候并没有发挥作用。

3. 正如其他人所说，JS 不同于 AIR/。NET/... 之类的。现在的 JS 完全符合它的目标。

从长远来看，Perl 和 Ruby 完全可以取代 javascript。然而，这些语言的采用是缓慢的，而且众所周知，它们永远不会取代 JS。

我认为 JavaScript 是一种很好的语言，但我希望在开发客户端 Web 应用程序时有一个选择。由于传统的原因，我们只能使用 JavaScript，但有一些项目和想法正在寻找改变这种情况的方法:

1. Google Native Client : 在浏览器中运行本地代码的技术。
2. Emscripten : LLVM 字节码编译器到 javascript。允许 LLVM 语言在浏览器中运行。
3. 创意: Mono: http://tirania.org/blog/archive/2010/May-03.html的创建者在浏览器中使用.NET CLI

我认为我们将在很长一段时间内使用 JavaScript，但这种情况迟早会改变。有很多开发人员愿意在浏览器中使用其他语言。

这个问题经常出现，我的立场是:

A)不会发生 和 < strong > B)已经在这里了。

什么? 听我解释:

公告 A

虚拟机不仅仅是某种通用的魔法装置。大多数虚拟机都针对某种语言和某些语言特性进行了优化。以 JRE/Java (或 LLVM)为例: 针对静态类型进行了优化，当实现动态类型或其他 Java 最初不支持的东西时，肯定存在一些问题和缺点。

因此，支持大量语言特性(尾部调用优化、静态和动态类型、 foo bar boo，...)的“通用多用途虚拟机”将是庞大的，难以实现，可能更难优化以获得良好的性能。但是我不是语言设计师或者虚拟机专家，也许我错了: 这其实很简单，只是还没有人有这个想法？嗯，嗯。

广告 B

这里已经有了: 可能没有字节码编译器/vm，但是您实际上并不需要它。Faik javascript 正在转向完成，所以应该可以:

1. 创建一个从语言 X 到 javascript 的翻译程序(例如 coffee escript)
2. 用 javascript 创建一个解释语言 X 的解释器(例如 脑残)。是的，表现会很糟糕，但是，嘿，不能什么都有。

公告 C

什么？根本就没有 C 点! ？因为还没有。谷歌 NACL。如果有人能做到，那就是谷歌。一旦谷歌让它工作，你的问题就解决了。只是，可能永远不会成功，我不知道。我最后一次读到它有一些未解决的安全问题的 真的棘手的类型。

除此之外:

• Javascript 从1995年到现在已经有15年了。尽管如此，浏览器的实现今天仍然有所不同(尽管至少它不再是令人难以忍受的了)。因此，如果你开始一些新的东西，你可能有一个版本工作跨浏览器大约2035年。至少是一个工作的子集。只有细微的差别。并且需要兼容的库和层。不过没必要不去努力改进。

• 还有，可读的源代码呢？我知道很多公司不愿意将他们的代码作为“某种”开源服务。就我个人而言，如果我怀疑有问题或者想从中学到什么，我很高兴我能读出来源。源代码万岁！

事实上，Silverlight 实际上就是一个基于.Net 的虚拟机客户端。

你是说。

Java 和 Javaapplet Flash 和 Adobe AIR 等等。

一般来说，任何 RIA 框架都可以满足您的需求; 但是对于每一个框架，使用它都要付出代价(例如。可在浏览器或/和专有或/和较少的选项比纯桌面) Http://en.wikipedia.org/wiki/list_of_rich_internet_application_frameworks

对于使用任何非 Web 语言开发 Web，可以使用 GWT: developerJava，编译为 Javascript

JavaScript 是浏览器的标准虚拟机。例如，OCaml 和 Haskell 现在都有可以输出 JavaScript 的编译器。其局限性不在于 JavaScript 语言，而在于通过 JavaScript 访问的浏览器对象，以及用于确保您可以安全地运行 JavaScript 而不会损害您的计算机的访问控制模型。当前的访问控制非常糟糕，出于安全考虑，JavaScript 只允许非常有限的访问浏览器对象。和谐计划正在努力解决这个问题。

看看这个 http://www.visitmix.com/Labs/Gestalt/-允许你使用 python 或者 ruby，只要用户已经安装了 Silverlight。

因为它们都已经拥有带字节码解释器的虚拟机，而且字节码也各不相同。{ Chakra (IE) ，Firefox (SpiderMonkey) ，Safari (SquirrelFish) ，Opera (Carakan).

对不起，我认为 Chrome (V8)可以编译成 IA32机器码。

回答 有个问题-不，这是没有意义的。

目前，最接近于多语言 VM 的是 JVM 和 CLR。这些并不完全是轻量级的动物，并且尝试在浏览器中嵌入这种大小和复杂性的东西是没有意义的。

让我们研究一下这样一个想法，即您可以编写一个比现有解决方案更好的新的多语言 VM。

• 你在稳定性方面落后了。
• 您在复杂性方面落后了(方式、方式、落后是因为您试图将复杂性推广到多种语言)
• 你的领养手续还没办完

所以，不，这说不通。

记住，为了支持这些语言，你必须把它们的 API 去掉，把那些在浏览器脚本上下文中没有意义的部分去掉。这里有大量的设计决策需要制定，并且存在巨大的错误机会。

就功能而言，我们可能只使用 真的来处理 DOM，所以这确实是一个语法和语言习惯的问题，在这一点上，我们有必要问，“这真的值得吗?”

请记住，我们正在讨论的 只有是客户端脚本，因为服务器端脚本已经可用于任何您喜欢的语言。这是一个相对较小的编程领域，因此引入多种语言的好处值得怀疑。

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

引入像 C 这样的语言是没有意义的，因为它是用来处理金属的，而在浏览器中并没有太多的金属可用。

引入 Java 这样的语言毫无意义，因为它最好的地方就是 API。

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

最后，什么浏览器制造商真正想要支持多语言的 DOM 集成？每个实现都有自己特定的 bug。我们已经经历过 MS Javascript 和 Mozilla Javascript 之间的差异，现在我们想把这种痛苦乘以五到六倍？

这说不通啊。

从某种意义上说，在浏览器中使用像 Javascript 这样更具表现力的语言，而不是像 Java 字节码这样更通用的语言，意味着一个更加开放的网络。

这是个很酷的主意，为什么不更进一步呢？

• 用同一虚拟机语言编写 HTML 解析器和布局引擎(实际上是浏览器中的所有复杂部分)
• 把引擎发布到网上
• 为页面提供声明，说明要使用哪个布局引擎及其 URL

然后，我们就可以向浏览器添加功能，而不必将新浏览器推送到每个客户端——相关的新比特将从网络动态加载。我们也可以发布新版本的 HTML，而不必像在浏览器中那样复杂地保持向后兼容性——兼容性是页面作者的责任。我们还可以尝试使用 HTML 以外的标记语言。当然，我们可以在引擎中编写奇特的 JIT 编译器，这样您就可以用任何想要的语言编写网页脚本。

除了 javascript，我欢迎任何语言作为可能的脚本语言。

最酷的是使用其他语言，然后是 Javascript。Java 可能不太适合这个标签，但是像 Haskell、 Clojure、 Scala、 Ruby、 Groovy 这样的语言会很有用。

不久前我来了一个交叉 Rubyscript..。 Http://almaer.com/blog/running-ruby-in-the-browser-via-script-typetextruby http://code.google.com/p/ruby-in-browser/
还在试验中，但看起来很有希望。
我刚找到的网站: http://www.silverlight.net/learn/dynamic-languages/刚找到的网站，但看起来也很有趣。甚至从我的 苹果电脑工程。

不知道上面提供的 Javascript 替代方案有多好，但乍一看还是很酷的。潜在地，这将允许使用任何 Java 或。网络框架本地从浏览器-在浏览器的沙箱。

至于安全性，如果语言在 JVM 内部运行(或。因此，虚拟机将负责安全性，所以我们不必担心这个问题——至少不会比我们应该为浏览器内运行的任何东西担心的更多。

这是一个非常好的问题。

这不仅仅是 JS 中的问题，因为在 JS 中开发大型程序时缺乏好的免费 IDE。我知道只有一个是免费的: Eclipse。另一个好的是微软的 VisualStudio，但不是免费的。

为什么是免费的？如果浏览器厂商想用在线应用程序取代桌面应用程序(而且他们也想这么做) ，那么他们必须给我们这些程序员提供好的开发工具。你不能使用一个简单的文本编辑器，JSLint 和内置的 GoogleChrome 调试器来编写5万行 JavaScript 代码。除非你是个男性至上主义者。

当 Borland 在1987年为 Turbo Pascal 4.0开发 IDE 时，这是一场编程上的革命。24年过去了。遗憾的是，在2011年，许多程序员仍然不使用代码完成、语法检查和正确的调试器。可能是因为好的 IDE 太少了。

如果浏览器厂商希望我们为他们开发可以与 Windows、 Linux、 MacOS、 iOS、 Symbian 等对抗的应用程序，那么为程序员开发合适的(免费)工具是符合他们利益的。

我不认为一个标准的网络虚拟机是不可想象的。有很多方法可以让你优雅地引入一个新的 web VM 标准，并得到完全的遗留支持，只要你确保你使用的任何 VM 字节码格式都可以被快速反编译成 javascript，并且结果输出将是相当有效的(我甚至可以猜测，一个聪明的反编译器可能会生成比任何人类自己能生成的 javascript 更好的 javascript)。

有了这个属性，任何 web VM 格式都可以很容易地在服务器上(快速)、在客户机上(慢速，但在你对服务器控制有限的情况下是可能的)进行反编译，或者可以由客户机或服务器(最快)为不支持新标准的浏览器预先生成并动态加载。

那些原生支持新标准的浏览器将从基于 web vm 的应用程序运行速度的提高中受益。最重要的是，如果浏览器基于 web vm 标准(即将 javascript 解析为 web vm 标准并运行它) ，那么它们不必管理两个运行时，但这取决于浏览器供应商。

关于这个老问题的快速更新。

每个人都肯定“网页将包含字节码，而不是任何高级语言，如 JavaScript”“不会发生”。

2015年6月，W3C宣布 WebAssembly

一种新的便携式、大小和加载时间效率高的格式 网上汇编。

这还处于试验阶段，但是 Firefox 每晚版和 Chrome 金丝雀已经有了一些原型实现，而且已经有了 一些示范工作。

然而，目前 WebAssembly 主要是设计用于从 C/C + + 生成的

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

我让你有一个更近距离的看看 官方页面的项目，这是真正令人兴奋的！

好吧，考虑到所有的浏览器都已经使用了 VM，我不认为为 Web 开发一种 VM 语言有那么困难。
我认为这会有很大帮助，原因有以下几点:
1.由于服务器编译代码，所以发送的数据量较小，客户端编译代码的时间不会过长。
2.由于服务器可以在准备和存储代码时编译代码，不像客户机那样只需要很少的时间就可以快速编译 JS，因此它可以进行更好的代码优化。
3. 将语言编译成字节码比转换成 JS 要容易得多。

最后，HTML 和 CSS 编译成一种更简单的语言，不确定是否算作字节码，但是你也可以把编译好的 HTML 和 CSS 从服务器发送到客户端，这样可以减少解析和获取的时间