通过浏览器中托管的标准化虚拟机来支持一组语言(Java,Python,Ruby等)是否有意义,而不是要求使用一种专门的语言(实际上是一种专门的范例)仅用于客户端脚本?
为了澄清建议,网页将包含字节码,而不是JavaScript等任何高级语言。
我了解务实的现实,由于进化的原因,JavaScript就是我们现在必须使用的,但是我正在考虑更多的长期性。关于向后兼容性,没有理由在一段时间内不能同时支持嵌入式JavaScript,当然JavaScript可能是浏览器虚拟机支持的语言之一。
通过浏览器中托管的标准化虚拟机来支持一组语言(Java,Python,Ruby等)是否有意义,而不是要求使用一种专门的语言(实际上是一种专门的范例)仅用于客户端脚本?
为了澄清建议,网页将包含字节码,而不是JavaScript等任何高级语言。
我了解务实的现实,由于进化的原因,JavaScript就是我们现在必须使用的,但是我正在考虑更多的长期性。关于向后兼容性,没有理由在一段时间内不能同时支持嵌入式JavaScript,当然JavaScript可能是浏览器虚拟机支持的语言之一。
Answers:
嗯,是。当然,如果我们有一台时间机器,那么回头并确保以不同的方式设计许多Javascript功能将是一个主要的消遣(那是要确保设计IE的CSS引擎的人员永远不会进入IT领域)。但这是不会发生的,我们现在仍然坚持下去。
我怀疑,随着时间的流逝,它将成为Web的“机器语言”,而其他更好设计的语言和API会编译成它(并迎合不同的运行时引擎的缺点)。
但是,我不认为这些“设计更好的语言”中的任何一种都是Java,Python或Ruby。尽管可以在其他地方使用Javascript,但它还是Web应用程序脚本语言。在这种使用情况下,我们可以比任何一种语言做得更好。
我认为JavaScript是一门好语言,但是在开发客户端Web应用程序时,我希望可以选择。由于遗留原因,我们只能使用JavaScript,但是有些项目和想法正在寻求改变这种情况:
我认为我们将长期使用JavaScript,但是迟早会有所改变。有很多开发人员愿意在浏览器中使用其他语言。
回答问题 -不,这没有道理。
当前,与多语言VM最接近的是JVM和CLR。这些并不是完全轻巧的野兽,尝试在浏览器中嵌入这种大小和复杂性的东西是没有意义的。
让我们研究一下您可以编写一个比现有解决方案更好的新的多语言VM的想法。
所以,不,这没有道理。
请记住,为了支持这些语言,您将不得不精简其API,将所有在浏览器脚本上下文中没有意义的部分切掉。这里有大量的设计决策,而且有很大的出错机会。
在功能方面,无论如何,我们可能仅是真正在使用DOM,因此这确实是语法和语言问题,在这一点上,有必要问“这真的值得吗?”。
请记住,我们谈论的唯一的事情就是客户端脚本,因为服务器端脚本已经可以使用您喜欢的任何语言。这是一个相对较小的编程领域,因此引入多种语言的好处值得怀疑。
引入什么语言才有意义?(警告,主观材料如下)
引入C之类的语言是没有意义的,因为它是为与Metal配合使用而设计的,并且在浏览器中实际上没有多少金属可用。
引入Java之类的语言是没有意义的,因为关于它的最好的事情还是API。
引入像Ruby或Lisp这样的语言没有任何意义,因为JavaScript是一种非常强大的动态语言,非常接近Scheme。
最后,什么浏览器制造商真正想要支持多种语言的DOM集成?每个实现都有自己的特定错误。我们已经解决了MS Javascript和Mozilla Javascript之间的差异,并希望将这种痛苦增加五到六倍?
这没有道理。
在Windows上,可以向脚本宿主注册其他语言,并将其提供给IE使用。例如,开箱即用地支持VBScript(尽管它从未获得太多普及,因为在大多数情况下它甚至比JavaScript还要糟糕)。
Python win32扩展允许人们很容易地向IE这样添加Python,但这并不是一个好主意,因为Python很难沙箱化:许多语言功能都暴露了足够多的实现挂钩,以允许可能受到限制的应用程序崩溃。
通常,一个问题是,您向诸如浏览器之类的面向网络的应用程序添加的复杂性越高,出现安全问题的可能性就越大。一堆新的语言肯定会适合这种描述,而这些新语言仍在快速发展。
JavaScript是一种丑陋的语言,但是通过谨慎使用功能的选择性子集以及适当对象库的支持,通常可以使JavaScript具有相当的容忍性。似乎对JavaScript进行了渐进的,实用的添加,这是Web脚本可能继续发展的唯一方法。
如果您觉得自己手脏了,那么您要么被洗脑,要么仍在感受“ DHTML年”的后遗症。JavaScript非常强大,并且非常适合其目的,即编写交互性客户端脚本。这就是为什么JavaScript 2.0说唱不好的原因。我的意思是,为什么软件包,接口,类等显然是服务器端语言的方面。JavaScript可以很好地用作基于原型的语言,而无需全面的面向对象。
如果由于服务器端和客户端之间的通信不畅而导致应用程序缺乏无缝性,那么您可能需要重新考虑如何构造应用程序。我曾经使用过非常强大的网站和Web应用程序,但是我从未说过:“嗯,我真的希望JavaScript可以做到(xyz)。” 如果能够做到这一点,那就不是JavaScript了,而是ActionScript或AIR或Silverlight。我不需要,大多数开发人员也不需要。那些是很好的技术,但是他们试图用技术而不是解决方案来解决问题。
我认为标准的Web VM并非不可想象。只要您确保所使用的任何VM字节码格式都可以快速反编译为javascript,并且产生的输出将相当有效,您可以通过多种方式优雅地引入新的Web VM标准并提供完整的传统支持。我什至可以猜测一个聪明的反编译器可能会生成比人类自己生成的任何JavaScript更好的javascript。
借助此属性,可以轻松地在服务器上(快速),在客户端上(很慢,但在服务器控制范围有限的情况下)可以轻松地反编译任何Web VM格式,也可以通过以下方式预先生成并动态加载:本身不支持新标准的浏览器的客户端或服务器(最快)。
那些确实支持该新标准的浏览器将从基于Web虚拟机的应用程序的运行时速度提高中受益。最重要的是,如果浏览器将其旧版JavaScript引擎基于Web vm标准(即将javascript解析为Web vm标准然后运行),则它们不必管理两个运行时,但这取决于浏览器供应商。
快速更新这个老问题。
确认“网页将包含字节码而不是JavaScript等任何高级语言的每个人”“不会发生”。
2015年6月的W3C宣布WebAssembly即
一种新的可移植,节省大小和加载时间的格式,适合编译到Web。
这仍然是实验性的,但是Firefox每晚和Chrome Canary中已经有一些原型实现,并且已经有一些演示工作。
当前,WebAssembly主要设计为使用C / C ++生成,但是
我让您仔细查看该项目的官方页面,这确实令人兴奋!
这个问题经常浮出水面。我对此的立场是:
A)不会发生,B)已经在这里。
对不起,什么?让我解释:
VM不仅仅是某种通用的神奇设备。大多数VM已针对特定语言和特定语言功能进行了优化。以JRE / Java(或LLVM)为例:针对静态类型进行了优化,当实现动态类型或Java首先不支持的其他功能时,肯定存在问题和不利之处。
因此,支持许多语言功能(尾部调用优化,静态和动态键入,foo bar boo等)的“通用多用途VM”将是巨大的,难以实现的,并且可能更难于优化以从中获得良好的性能。它。但是我既不是语言设计师,也不是虚拟机专家,也许我错了:这实际上很容易,只有一个人知道吗?嗯,嗯。
已经在这里:可能没有字节码编译器/ vm,但实际上并不需要。afaik javascript即将完成,因此应该可以:
什么?首先没有C点!因为还没有。谷歌NACL。如果有人能做到,那就是谷歌。google正常运行后,您的问题就解决了。只,嗯,它可能永远都行不通,我不知道。上一次我读到它时,确实遇到了一些棘手的安全问题。
除此之外:
javascript的出现始于〜1995 = 15年。仍然,今天的浏览器实现有所不同(尽管至少现在不再受此限制)。因此,如果您重新开始,可能会在2035年左右使用跨浏览器的版本。至少是一个有效的子集。只是微妙的不同。并且需要兼容性库和层。但是没有努力去改善事情没有意义。
另外,可读的源代码又如何呢?我知道许多公司宁愿不将其代码作为“某种”开放源代码提供。就个人而言,如果我怀疑有腥或想从中学习,我很高兴能够阅读该资源。万岁源代码!
您的推理中有一些错误。
标准浏览器中的标准虚拟机将不再是标准的。我们有4个浏览器,并且IE在“标准”方面有不同的利益。其他三个正在快速发展,但是新技术的采用速度很慢。手机,小型设备上的浏览器呢...
JS在不同浏览器中的集成及其过去的历史使您低估了JS的功能。您承诺使用标准,但是不赞成JS,因为标准在早期没有奏效。
就像其他人所说的那样,JS与AIR / .NET / ...和其他不一样。JS的当前版本完全符合其目标。
从长远来看,Perl和Ruby可以很好地替代javascript。但是这些语言的采用速度很慢,并且众所周知它们永远不会取代JS。
您如何定义最佳?最适合浏览器,还是最适合开发人员?(加上ECMAScript与Javascript不同,但这是一个技术性问题。)
我发现JavaScript可以同时强大而优雅。不幸的是,我遇到的大多数开发人员都将其视为一种必要的邪恶,而不是一种真正的编程语言。
我喜欢的一些功能包括:
建立起来很有趣。随时随地享受它,因为尽管它可能不是客户端脚本的“最佳”方法,但它肯定是令人愉快的。
我确实同意,由于浏览器不兼容,在制作动态页面时令人沮丧,但是可以通过UI库来缓解。那应该不再针对JavaScript本身,而应该反对Swing。
这是一个好主意。为什么不更进一步呢?
然后,我们可以向浏览器添加功能,而不必将新的浏览器推出到每个客户端-相关的新位将从网络上动态加载。我们还可以发布新版本的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-浏览器内/
仍处于试验阶段,仍在进行中,但看起来很有希望。
对于.Net,我刚刚发现:http : //www.silverlight.net/learn/dynamic-languages/刚刚找到了该网站,但看上去也很有趣。即使在我的Apple Mac上也可以使用。
不知道上面的方法在为Javascript提供替代方法方面有多好,但是乍一看看起来很酷。潜在地,这将允许人们从浏览器本地使用任何Java或.Net框架-在浏览器的沙箱中。
关于安全性,如果该语言在JVM(或.Net引擎)中运行,则VM将负责安全性,因此我们不必担心这一点-至少,对于运行的任何内容,我们都不应担心在浏览器中。
我与之交谈过的关于ECMAScript等的绝大多数开发人员。等 最后承认问题不是脚本语言,而是它暴露的荒谬HTML DOM。混淆DOM和脚本语言是导致ECMAScript痛苦和沮丧的常见原因。另外,不要忘记,IIS可以使用JScript进行服务器端脚本编写,并且Rhino之类的东西使您可以在ECMAScript中构建独立的应用程序。尝试在其中一种环境中使用ECMAScript一段时间,然后查看您的意见是否有所改变。
这种绝望已经持续了一段时间。建议您对其进行编辑,以包括或重新发布特定问题。您可能会对获得的一些救济感到惊喜。
一个古老的站点,但仍然是一个不错的起点:Douglas Crockford的站点。
好吧,我们已经有了VBScript,不是吗?等一下,只有IE支持它!
对于您的VM不错的想法也是如此。如果我使用Lua编写页面脚本,而您的浏览器没有解析器将其转换为字节码怎么办?当然,我们可以想象一个脚本标签接受一个字节码文件,这甚至会非常有效。
但是经验表明,很难将新的东西带到Web:采用这种根本的新变化需要花费数年的时间。多少浏览器支持SVG或CSS3?
另外,我看不到您在JS中发现“脏”的东西。如果由业余爱好者编写代码,传播在其他地方复制的不良做法,可能会很丑陋,但大师们表明,它也是一种优雅的语言。有点像Perl:通常看起来像一种混淆的语言,但是可以使其变得完全可读。
请访问http://www.visitmix.com/Labs/Gestalt/进行检查-只要用户安装了Silverlight,就可以使用python或ruby。
这个问题问得好。
这不仅是JS的问题,还因为缺少用于在JS中开发大型程序的良好的免费IDE。我知道只有一个免费的:Eclipse。另一个不错的是Microsoft的Visual Studio,但不是免费的。
为什么会免费?如果网络浏览器供应商想要用在线应用程序代替台式机应用程序(并且他们想要),那么他们必须给我们程序员,优秀的开发人员工具。使用简单的文本编辑器,JSLint和内置的Google Chrome调试器,您无法制作50,000行JavaScript。除非你是个马哥教徒。
当Borland在1987年为Turbo Pascal 4.0开发IDE时,这是编程的一次革命。此后已经过去了24年。可惜的是,在2011年,许多程序员仍然没有使用代码完成,语法检查和适当的调试器。可能是因为好的IDE很少。
如果浏览器供应商希望我们构建能够与Windows,Linux,MacOS,iOS,Symbian等对抗的应用程序,则它们为程序员提供适当的(FREE)工具是符合Web浏览器供应商的利益的。
也许您正在寻找Google的Native Client。
我认为这不是一件容易的事。我们可以说我们一直坚持使用JS,但是使用jQuery,Prototype,scriptaculous,MooTools和所有出色的库真的那么糟糕吗?
记住,JS是轻量级的,在V8,TraceMonkey,SquirrelFish(现代浏览器中使用的新Javascript引擎)中更是如此。
这也被证明了 -是的,我们知道它有问题,但是我们已经解决了许多问题,例如早期的安全问题。允许您的浏览器运行Ruby代码或其他任何东西的映像。必须先完成安全沙箱的检查。你知道吗?Python专家已经两次失败了。
我认为Javascript会随着时间的流逝进行修订和改进,就像HTML和CSS一样。这个过程可能会很长,但是在这个世界上并非一切皆有可能。
我不认为您“了解实用的问题,即JavaScript就是我们现在必须使用的东西”。实际上,这是一种非常强大的语言。您在浏览器中使用Java小程序已有多年了,现在在哪里?
无论如何,您无需“变脏”即可在客户端上工作。例如,尝试使用GWT。
... 你的意思是...
Java和Java applet Flash和Adobe AIR等。
通常,任何RIA框架都可以满足您的需求;但对于每个使用它来说,都需要付出一定的代价(例如,运行时在浏览器或/和专有或/和仅与纯桌面相比可用的选项较少) http://en.wikipedia.org/wiki/List_of_rich_internet_application_frameworks
要使用任何非Web语言开发Web,您需要使用GWT:开发Java,编译为Javascript
好吧,考虑到所有浏览器已经在使用VM,我认为为Web制作VM语言并不难。
我认为这将有很大帮助,原因如下:
1.由于服务器编译代码,因此发送的数据量较小,并且客户端没有时间编译代码。
2.由于服务器可以在准备过程中编译代码并将其存储,与客户端试图花很少的时间快速编译JS的客户端不同,它可以进行更好的代码优化。
3.将语言编译为字节码比将其编译为JS更容易。
作为最后的注释(正如某人在另一条评论中已经说过的那样),HTML和CSS可以编译成一种更简单的语言,不确定是否将其视为字节码,但是您也可以将已编译的html和css从服务器发送到客户端,这会减少解析和获取时间
IMO,JavaScript,语言不是问题。JavaScript实际上是一种表达力很强的语言。我认为它代表不好,因为它没有经典的面向对象功能,但是对我来说,我越喜欢原型凹槽,我就越喜欢它。
我所看到的问题是我们被迫在网络上支持的许多浏览器的不稳定和不一致的实现。像jQuery这样的JavaScript库在减轻这种肮脏感觉方面大有帮助。