传统的答案，“为什么不是本机代码的JavaScript慢？”是：“因为这是解释”。与这种说法的问题在于解释不是语言本身的质量。作为事实上，时下最Javascript代码正在JIT编译的，不过，这是不是甚至接近原生速度。
如果我们从公式中删除的解释因素来启动JavaScript编译AOT？然后它将匹配的原生代码的性能？如果是的话，为什么不这样广泛在网上做*？如果没有，哪里是性能瓶颈呢？
如果新的瓶颈是DOM，如果我们排除是什么呢？将一个DOM少，编译的JavaScript是本机代码的效率？如果是的话，为什么不这样广泛在网上做**？如果没有，哪里是性能瓶颈呢？
剥离DOM部分和解释部分后，只有大的区别，我可以Javascript和C / C之间看到++在于前者具有动态类型的事实。假设我们消除过，并用DOM少，静态类型的结束，名列前茅的时间编译javascipt的。怎么会是比较本地代码？如果这将是高效的，为什么不这样广泛使用？如果不是这样，瓶颈在哪里呢？在这种状态下，JavaScript是几乎相同的C.
*也许有人会说，JIT更快加载，但这无法解释为什么没有被用于资源密集型的Web应用程序如3D视频游戏，其中AOT性能优势是非常值得的初始AOT编译延迟AOT。 （和显著“游戏加载”延迟是本反正）
**一个DOM-更少的JavaScript将使用的WebGL /画布与所述用户接口。目前这需要极少的DOM，它定义了最初的HTML5画布，但是这在理论上可以通过修改该技术是否值得的性能优势被淘汰。假设回答时DOM少的WebGL /画布是可能的。
编辑：我说的客户端编译。
重要： 你似乎主张JS的剥离，静态类型的编译版本。显示的第一件事是，你有没有线索，JS是什么：一个多范式编程语言，支持基于原型的OO，命令和函数式编程范式。关键是功能性的范式。除了哈斯克尔，它可以是你定义自己的缀运营商后，强类型排序的，功能性的语言不能静态类型AFAIK。想象一下，类似C的函数定义返回关闭：
function a = (function (Object g)
{
char[] closureChar = g.location.href;
Object foo = {};
Function foo.bar = char* function()
{//This is a right mess
return &closureChar;
};
}(this));
函数是第一类对象，太。利用吨返回对象的λ-功能，即参考函数可能返回自身，其他功能，对象或原语...如何在地球上，你会写所有的问题？ JS功能尽可能多的创建范围，构建你的代码，控制你的程序的流程，因为他们是你的变量赋值的东西的一种方式。
提前与编译JS的问题很简单：您编译代码，这将有不同的平台这样一个庞大的阵列上运行：运行Windows，OSX，Linux的台式机/笔记本电脑，UNIX以及平板电脑和智能手机与他们的不同移动浏览器... 即使你曾经试图写和编译JS，可以在所有平台上运行，JS的速度仍仅限于它是单线程的，并在JS引擎上运行（如Java运行在VM）。
编译代码客户端已经在这样做。诚然，这需要一些时间，但不是非常多。这是相当耗费资源，因此大部分现代浏览器会以这样的方式，很多预处理的已经做了缓存的代码。这将永远是可以通过编译的，都将在他们的编译状态缓存，太。 V8是一个开源的，快速的，JS引擎。如果你愿意，你可以检查它是如何确定被编译什么JS代码方面，哪些不是源。 即便如此，这就是V8仅是如何工作的...的JS引擎有更多的事情要做有多快你的代码运行：有些是非常快的，有些则没有。有些人在一两件事，在别人跑赢上的另一个区域的所有竞争对手更快。 More details can be read here
剥DOM的一部分，不剥从语言的任何东西。该DOM API，是不是JS本身的一部分。 JS是一个很传神，但在核心，小语种，就像C.两人都没有得到IO能力，留给自己的设备，也不能解析DOM。对于这一点，JS的浏览器实现有权访问的DOMParser对象。 您能否提供一个最小的DOM ...哎，大家有任何意义是所有改组后的DOM API。这是远约网的最好的事情。但你必须认识到，DOM和JS是独立的实体。的DOM（和DOM API）由W3管理，而ECMA是RESPONSABLE为JS。无论有任何与对方。这就是为什么DOM不能从JS“掠夺”：这是从来没有它的一部分开始。
既然你比较JS给C ++：你可以写，可以在Windows和Linux机器编译C ++代码，但是这并不像听起来那么容易。但既然你提到的C ++自己，我想你可能知道这一点。 说到这，如果你的C ++和JS之间看到的唯一真正的区别是静态类型vs动态类型，你真的应该花更多的时间来学习JS。
虽然它的语法类似C，语言本身共享很多相似之处，更和Lisp（即函数式编程）。它不知道的类本身，而是使用原型...动态类型真的不是什么大不了的事的，是诚实的。
因此，底线： 编译JS到每个机器上运行会导致类似MS的.NET框架。背后的理念是：“编写一次，到处运行” ...这并没有被证明是真实的。 Java是X平台，但这只是因为它没有编译为本地代码，但运行在虚拟机上。 最后，ECMAScript标准（JS是其最常见的实现），是不是所有的好，是该领域的所有大竞争对手共同努力的结果：Mozilla中，谷歌，微软和一些无关痛痒的瑞士公司。这是一个巨大的妥协。试想一下，这三个大牌同意作出JS编译器一起。微软将只提出了JScript compiler为最好，谷歌都会有自己的想法和Mozilla将可能有3级不同的编译器准备好，根据不同的社会所需要的。
编辑： 你做了编辑，澄清你在谈论客户端JS。因为你觉得有必要来指定，我感觉好像你不完全知道从哪里JS结束，并在浏览器接管。 JS被设计成一个非常便携的语言：它没有得到IO能力，支持多种发展模式，和（最初）是一个完全解释语言。诚然，这是充分考虑了网络开发的，但你可以，有的根本，用这种语言来查询数据库（MongoDB的），作为替代批量脚本语言（JScript中），或一个服务器端脚本语言（骨干， Node.js的，...）。有些使用的ECMAScript（用于JS的基本标准），以使自己的编程语言（是的，我说的是关于Flash的ActionScript）。
根据不同的使用情况，JS会（分别document，[Object http].createServer，[Object file].readFileSync对DOM的访问，Web服务器功能，以及IO）允许访问对象/ API的不是天然的语言。那些经常形成瓶颈，而不是语言本身。
当我暗示广告JS最初是一种解释型语言。正如这几天的样子，编译和解释语言之间的分工钟声已经淡出在过去的十年，是诚实的。 使用C / C ++进行严格编译语言，但在某些情况下（.NET）C ++代码不用再被编译成机器代码... 与此同时，脚本语言如Python，使用这么多的用途他们一般被看作是一种编程语言，如该术语的脚本语言在某种程度上意味着一个“较小的语言”。 几年前，随着PHP5的发布，ZendEngine2被释放了。从那时起，PHP编译成字节码和运行在虚拟机上。您可以使用APC缓存字节码。该字节码编译，可以生成从PHP代码独立的可执行文件一样，Facebook的HPHPc（不建议使用）用于编译PHP到C ++，再到本地代码。现在，Facebook的使用HHVM，这是一个自定义的虚拟机。 Find out more here。
同样的演变可以在JavaScript解释器（即所谓的发动机现在）可以看出。他们不是你的日常语法分析和执行的旧线程，你似乎仍然认为他们是。有很多巫术的内存管理，JITCompilation（tail stack optimizing even），优化和你有什么方面的事情... 所有伟大的事情，但这些使它比较硬，以确定实际的瓶颈。每个引擎优化的方式不同，甚至比IE6从IE10差异越大越，那么它的旁边，不可能一劳永逸地查明瓶颈。如果一个浏览器需要10秒的DOM密集型任务，另一个可能只需要1〜2秒。但是，如果在那里相互对立相同的浏览器来检查RegExp对象的性能，开机可能是在另一只脚。 让我们不要忘了，你写你的博客，一篇关于你的发现后，你必须检查，如果没有的浏览器发布了一个新版本/更新，声称加速某些任务。
其实，要回答你的问题，是的。排序或。既然当然你也可以给予相应的编译器编译提前时间的事情。
这是事实的Javascript AOT编译是一个有点离奇的概念。 AOT编译和“一次编写，到处运行”是一对矛盾，因为通过编译它，你都这么说，“我希望它这个特定的CPU上运行”。
但也有一些尝试这个。看看asm.js.你写你的C程序，然后通过几个铁圈可以将其转换成一个Javascript模块。然后，这个模块被加载的Firefox和中，因为它被标记以某种方式（AMS =“true”或东西），浏览器会尝试提前编译。结果几乎是原生速度。但是，有什么代码可以尝试这么多的限制（几乎所有那些你在上面举），我不能看到很多使用情况，除非是算法。
说了这么多，我觉得其他捐助者在他们的答案是过于严厉，因为你接触的东西的人实际上是试图做的。
我倾向于认为，这将是由显著保证金更快，但同时也限制了你有什么可以很容易，因为DOM实际工作真的很好某些事情要做。
DOM是专为文件;它是不是真的设计时考虑到用户界面。这就是说，与DOM与自DOM模型使其保持同步的最困难的问题之一是静态上下的性质，即使是最小的变化可能会造成回流（这可能会很慢）。反应和其他虚拟DOM框架，试图通过一次更换整个DOM，并使用虚拟域的diff，以尽量减少变化量来回避这个问题。使用帆布，另一方面，使得它非常琐碎保持屏幕同步与模型，因为你可以重画用新的数据画布，继续前进。
移动呈现在画布削减了中间人，让你做你自己的渲染，布局和造型。代价是显而易见的，但。现在，您可以管理所有的事件处理和手动滚动，加上嵌入实际的文件将是一场噩梦。如果一些框架是制定一个解决方案，这一点，它可能是没有DOM克鲁夫特一个可行的，高性能的选择，但是这可能不会是有道理的新闻网站，博客，社交媒体，还是真的大部分文字为主的网站。这种事情很可能带来巨大的性能提升到一个绘图应用程序，游戏，甚至可能是一个聊天应用程序，但不是很多其他领域都将受益。还是会？我很乐意被证明是错误的。
在DOM非常一直认为我们已经成功地融入各种古怪形状的孔方钉。这不是最好的一切工具，但是当你只有一把锤子，一切看起来都像钉子。
一切是不是性能，性能仍然来自次要的能力。你第一次在地方一些语言（RE：JavaScript的），使网站的可能，进而提高语言。如果你从JS剔除DOM操作，使其编译为本地代码，那么什么将我们使用的网站的？其中一个原因是JavaScript是四周，我们没有使用C / C ++的网络是因为它做的DOM操作的能力，它不需要被编译成机器特定的格式，因此是普遍执行。
除了我有一个已经剥离DOM操作的JavaScript的名称，静态类型，时间提前编译：这是Java的:)
你提的问题确实是我们为什么不使用Java的网站，因为它是如此美好的表演 - 想想吧。有一天，我们会在那里，但不是现在。