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

为了阐明建议，网页将包含字节码，而不是JavaScript之类的任何高级语言。

我了解务实的现实，由于进化的原因，JavaScript就是我们现在必须使用的，但是我正在考虑更多的长期性。关于向后兼容性，没有理由在一段时间内不能同时支持嵌入式JavaScript，当然，JavaScript可能是浏览器虚拟机支持的语言之一。

解决方案

回答

嗯，是。当然，如果我们有一台时间机器，那么回去并确保以不同的方式设计许多Javascript功能将是一个主要的消遣(那是要确保设计IE的CSS引擎的人员永远不会进入IT领域)。但这不会发生，我们现在坚持下去。

我怀疑，随着时间的流逝，它将成为Web的"机器语言"，其他更好设计的语言和API会被编译成它(并迎合不同的运行时引擎的缺点)。

但是，我认为这些"设计更好的语言"中的任何一种都不会是Java，Python或者Ruby。尽管可以在其他地方使用Javascript，但Javascript是Web应用程序脚本语言。在这种用例的情况下，我们可以比任何一种语言做得更好。

回答

可能是，但是要这样做，我们需要使用主要的浏览器来支持它们。 IE支持将是最难获得的。使用JavaScript是因为它是唯一可以依靠的。

回答

JavaScript是我们唯一可用的本地标准选项。如果我们需要强大的功能，请使用jQuery，但是如果需要更多功能，请考虑为Firefox编写插件吗？或者类似的IE等

回答

我认为这不是一件容易的事。可以说我们被JS束缚了，但是使用jQuery，Prototype，scriptaculous，MooTools和所有出色的库真的那么糟糕吗？

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

也被证明是的，我们知道它有问题，但是我们有很多类似的问题，例如早期的安全问题。允许浏览器运行Ruby代码或者其他任何东西的映像。必须先完成安全沙箱的检查。你知道吗？ Python专家已经两次失败了。

我认为Javascript将随着时间的流逝而进行修订和改进，就像HTML和CSS一样。这个过程可能会很长，但是在这个世界上并非一切皆有可能。

回答

如果我们觉得自己手脏了，那么我们或者被洗脑，或者仍然感觉到" DHTML年"的后遗症。 JavaScript非常强大，并且非常适合其目的，即编写交互性客户端脚本。这就是JavaScript 2.0这么糟糕的说唱原因。我的意思是，为什么软件包，接口，类等显然是服务器端语言的方面。 JavaScript可以很好地用作基于原型的语言，而无需全面的面向对象。

如果由于服务器端和客户端之间的通信不畅而导致应用程序缺乏无缝性，那么我们可能需要重新考虑如何构造应用程序。我曾经使用过非常强大的网站和Web应用程序，但我从未说过："嗯，我真的希望JavaScript可以做到(xyz)。"如果可以做到，那就不是JavaScript了，而是ActionScript或者AIR或者Silverlight。我不需要，大多数开发人员也不需要。那些是不错的技术，但是他们试图用技术而不是解决方案来解决问题。

回答

实际上，JavaScript是所有浏览器都将长期使用的唯一语言，因此虽然使用其他语言会非常好，但我看不到它的发生。

我们所说的"标准化VM"将非常大，并且需要所有主要浏览器采用，并且大多数站点仍然会继续使用Javascript，因为它比许多其他浏览器更适合于网站。

我们将不得不在此VM中沙箱化每种编程语言，并减少每种语言对系统的访问量，这需要对语言进行大量更改以及删除或者重新实现许多功能。 Javascript已经考虑了这一点，并且已经做了很长时间了。

回答

尽管Javascript是唯一可以直接从其控制页面的受支持脚本语言，但Flash对于较大的程序具有一些非常好的功能。最近，它具有JIT，还可以即时生成字节码(请查看运行时表达式评估，以获取示例，其中他们使用Flash来编译用户输入的数学表达式，一直到本地二进制。 Haxe语言为我们提供带推断的静态类型以及字节码生成功能，我们可以实现几乎所有选择的运行时系统。

回答

那么，我们在浏览器中对所有这些Python和Ruby所做的事情呢？

1)。还在编写脚本化的客户端应用程序吗？很好，这可以通过JavaScript很好地完成。

2)。使用套接字编写客户端服务器应用程序？为什么不没有浏览器就不编写它们？

3)。编写独立的应用程序？就像现在一样操作。

回答

我们如何定义最佳？最适合浏览器，还是最适合开发人员？ (加上ECMAScript与Javascript不同，但这是一个技术性问题。)

我发现JavaScript可以同时强大而优雅。不幸的是，我遇到的大多数开发人员都将其视为一种必要的邪恶，而不是一种真正的编程语言。

我喜欢的一些功能包括：

• 将职能视为头等公民
• 能够随时向任何对象添加和删除功能(虽然没什么用，但在使用时却让人大跌眼镜)
• 它是一种动态语言。

建立起来很有趣。随时随地享受它，因为尽管它可能不是客户端脚本的"最佳"方法，但它肯定是令人愉快的。

我确实同意，由于浏览器不兼容，在制作动态页面时令人沮丧，但是可以通过UI库缓解这种情况。那应该不再针对JavaScript本身，而应该反对Swing。

回答

在Windows上，可以向脚本宿主注册其他语言，并将其提供给IE使用。例如，开箱即用地支持VBScript(尽管它从未获得太多普及，因为在大多数情况下它甚至比JavaScript还要糟糕)。

Python win32扩展允许人们很容易地将python这样添加到IE，但这并不是一个好主意，因为Python很难沙箱化：许多语言功能都暴露了足够多的实现钩子，以允许可能受到限制的应用程序崩溃。

通常，一个问题是，我们向诸如浏览器之类的面向网络的应用程序添加的复杂性越高，出现安全问题的可能性就越大。一堆新的语言肯定会适合这种描述，而这些新语言仍在快速发展。

JavaScript是一种丑陋的语言，但是通过谨慎使用功能的选择性子集以及适当对象库的支持，通常可以使JavaScript具有相当的容忍性。似乎对JavaScript进行了渐进的，实用的添加，这是Web脚本可能继续发展的唯一方法。

回答

我与之交谈过的关于ECMAScript等的绝大多数开发人员。 al。最终承认问题不是脚本语言，而是它暴露的荒谬的HTML DOM。混淆DOM和脚本语言是导致ECMAScript痛苦和沮丧的常见原因。另外，请不要忘记，IIS可以使用JScript进行服务器端脚本编写，并且Rhino之类的东西使我们可以在ECMAScript中构建独立的应用程序。尝试在其中一种环境中使用ECMAScript一段时间，然后查看意见是否有所改变。

这种绝望已经持续了一段时间。我建议我们对其进行编辑以包括或者转发特定问题。我们可能会为我们获得的一些缓解感到惊喜。

一个古老的网站，但仍然是一个不错的起点：Douglas Crockford的网站。

回答

IMO，JavaScript，语言不是问题。 JavaScript实际上是一种富有表现力且功能强大的语言。我认为它代表不好，因为它没有经典的OO功能，但是对我来说，我越喜欢原型凹槽，就越喜欢它。

我所看到的问题是我们被迫在网络上支持的许多浏览器中的不稳定且不一致的实现。像jQuery这样的JavaScript库在减轻这种肮脏的感觉上还有很长的路要走。

回答

好吧，我们已经有了VBScript，不是吗？等一下，只有IE支持它！
同样，我们对VM的好主意也是如此。如果我使用Lua编写页面脚本，而浏览器没有解析器将其转换为字节码怎么办？当然，我们可以想象一个脚本标签接受一个字节码文件，这甚至会非常有效。
但是经验表明，很难将新的东西带到Web：采用这种根本的新变化需要花费数年的时间。多少浏览器支持SVG或者CSS3？

另外，我看不到我们在JS中发现"脏"的东西。如果由业余人员编写代码，传播在其他地方复制的不良做法，可能会很丑陋，但大师们表明，这也是一种优雅的语言。有点像Perl：通常看起来像一种混淆的语言，但是可以使其变得完全可读。

回答

我不认为我们"了解实用的问题，即JavaScript就是我们现在必须使用的东西"。实际上，这是一种非常强大的语言。我们在浏览器中使用Java小程序已有多年了，现在在哪里？

无论如何，我们无需"变脏"即可在客户端上工作。例如，尝试使用GWT。

回答

也许我们正在寻找Google的Native Client。

回答

我绝对会欢迎浏览器中使用独立于语言的标准VM(我希望使用静态类型的语言进行编码)。

(从技术上来说)这是逐渐可行的：第一个主要的浏览器支持它，并且服务器有可能在当前请求来自兼容浏览器的情况下发送字节码，或者将代码转换为JavaScript并发送纯文本JavaScript。

已经存在一些可编译为JavaScript的实验语言，但是拥有(可能)定义的VM可以提高性能。

我承认，"标准"部分将非常棘手。同样，与库有关的语言功能(例如静态类型与动态类型)之间也会存在冲突(假设新事物将使用相同的库)。因此，我认为这不会很快发生。

回答

推理中有一些错误。

• 标准浏览器中的标准虚拟机将不再是标准的。我们有4个浏览器，并且IE在"标准"方面有不同的利益。其他三个正在快速发展，但是新技术的采用速度很慢。手机，小型设备上的浏览器呢...
• JS在不同浏览器中的集成及其过去的历史使我们低估了JS的功能。我们承诺使用标准，但是不赞成JS，因为标准在早期没有奏效。
• 就像其他人所说的那样，JS与AIR / .NET / ...和类似的东西并不相同。 JS的当前版本完全符合其目标。

从长远来看，Perl和Ruby可以很好地替代javascript。但是这些语言的采用速度很慢，并且众所周知它们永远不会取代JS。

回答

我认为JavaScript是一种不错的语言，但是在开发客户端Web应用程序时，我希望可以选择。由于遗留原因，我们只能使用JavaScript，但是有些项目和想法正在寻求改变这种情况的方法：

• Google Native Client：在浏览器中运行本机代码的技术。
• Emscripten：将LLVM字节码编译器转换为javascript。允许LLVM语言在浏览器中运行。
• 想法：Mono的创建者在浏览器中使用.NET CLI：http://tirania.org/blog/archive/2010/May-03.html

我认为我们将长期使用JavaScript，但是迟早会有所改变。有很多开发人员愿意在浏览器中使用其他语言。

回答

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

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年左右使用跨浏览器的版本。至少是一个有效的子集。那只是微妙的不同。并且需要兼容性库和层。但是没有努力去改善事情没有意义。
• 另外，可读的源代码又如何呢？我知道许多公司宁愿不将其代码作为"某种"开放源代码提供。就个人而言，如果我怀疑有腥或者想从中学习，我很高兴能够阅读该资料。万岁的源代码！

回答

的确。 Silverlight实际上仅仅是基于客户端.Net的VM。

回答

... 你的意思是...

Java和Java小程序
Flash和Adobe AIR
等等..

通常，任何RIA框架都可以满足需求；但是每使用它，都需要付出一定的代价(例如，运行时在浏览器或者/和专有或者/和/或者纯台式机上可用的选项较少)
http://en.wikipedia.org/wiki/List_of_rich_internet_application_frameworks

要使用任何非Web语言开发Web，我们需要使用GWT：开发Java，编译为Javascript

回答

JavaScript是浏览器的标准虚拟机。例如，OCaml和Haskell现在都具有可以输出JavaScript的编译器。限制不是JavaScript语言，而是通过JavaScript可访问的浏览器对象，以及用于确保我们可以安全运行JavaScript而不会损害计算机的访问控制模型。当前的访问控制是如此糟糕，以至于出于安全原因，仅允许JavaScript对浏览器对象进行非常有限的访问。 Harmony项目正在寻求解决此问题。

回答

只要用户已经安装了Silverlight，就​​可以通过http://www.visitmix.com/Labs/Gestalt/进行检查，让我们使用python或者ruby。

回答

因为它们都已经具有带有字节码解释器的VM，并且字节码也完全不同。 {Chakra(IE)，Firefox(SpiderMonkey)，Safari(SquirrelFish)，Opera(Carakan)。

抱歉，我认为Chrome(V8)可以编译为IA32机器代码。

回答

回答问题不，这没有任何意义。

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

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

• 我们在稳定性方面落后。
• 我们落后于复杂性(之所以如此，是因为我们试图对多种语言进行概括)
• 我们在领养上落后

所以，不，这没有道理。

请记住，为了支持这些语言，我们将不得不精简其API，将所有在浏览器脚本上下文中没有意义的部分切掉。这里有大量的设计决策，而且有很大的出错机会。

在功能方面，无论如何，我们可能实际上只是在使用DOM，因此这确实是语法和语言问题，在这一点上，有必要问"这真的值得吗？"。

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

引入什么语言才有意义？ (警告，主观材料如下)

引入C之类的语言是没有意义的，因为它是为与Metal配合使用而设计的，并且在浏览器中实际上没有多少金属可用。

引入Java之类的语言是没有意义的，因为关于它的最好的东西还是API。

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

最后，什么浏览器制造商真正想要支持多种语言的DOM集成？每个实现都有自己的特定错误。我们已经解决了MS Javascript和Mozilla Javascript之间的差异，然后想将这种痛苦增加五到六倍吗？

这没有道理。

回答

从某种意义上说，在浏览器中使用更具表达能力的语言(例如Javascript)，而不是在Java字节码之类的更通用的语言中意味着更开放的网络。

回答

这是一个好主意。为什么不更进一步呢？

• 用相同的VM语言编写HTML解析器和布局引擎(实际上是浏览器中的所有复杂位)
• 将引擎发布到网络
• 为页面提供使用的布局引擎及其URL的声明

然后，我们可以向浏览器添加功能，而不必将新的浏览器推出到每个客户端，相关的新位将从Web动态加载。我们还可以发布HTML的新版本，而无需保持页面浏览器兼容性中一直保持向后兼容性的所有荒谬复杂性，这是页面作者的责任。我们还可以尝试使用HTML以外的标记语言。而且，当然，我们可以将精美的JIT编译器编写到引擎中，以便我们可以使用所需的任何语言编写网页脚本。

回答

我欢迎除javascript以外的任何语言作为脚本语言。

不错的是使用Java语言之外的其他语言。 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/
仍处于试验阶段，仍在进行中，但看起来很有希望。
对于.Net，我刚刚发现：http://www.silverlight.net/learn/dynamic-languages/刚刚找到了该网站，但看上去也很有趣。即使在我的Apple Mac上也可以使用。

不知道上面的方法在为Javascript提供替代方法方面有多好，但是乍一看看起来很酷。潜在地，这将使人们可以从浏览器的沙箱内的浏览器本地使用任何Java或者.Net框架。

为了安全起见，如果语言在JVM(或者.Net引擎)内部运行，则VM将负责安全性，因此我们不必担心，至少不必担心，那么我们应该在内部运行的任何事物都可以浏览器。