chrome是否了解已编译的javascript？

Question

不是让V8动态编译JavaScript而是然后执行它，是不是可以事先编译JavaScript然后将机器代码嵌入页面而不是嵌入JavaScript网页？

Answer 1

网络上的运输机器代码存在两个主要问题：

1. 可移植性。没有服务器能够为所有可能的系统架构（现在和将来）提供适当的机器代码。例如，V8已经支持10种不同的CPU架构。
2. 安全的。没有客户能够在他们的机器上运行随机机器代码，而不知道它是否可以信任。

为了解决（1）您通常需要交叉编译机器代码，这比从高级语言编译更困难和更昂贵。为了解决（2）问题，您需要验证收到的机器代码，这比编译高级语言更加困难和昂贵。

机器代码也往往比高级代码大得多，因此也存在带宽问题。

现在，JavaScript可能不是高级语言的特别好选择。但这正是我们所坚持的网络语言。

Answer 2

  

我理解它的方式，V8 JavaScript引擎无论如何编译成机器代码，为什么不事先做呢？

根据W3C HTML5 Scripting specification，没有基于标准的原因，因为浏览器无法支持具有特殊type属性的机器代码（如Chrome使用Dart语言）：

  

以下列出了用户代理必须识别的MIME类型字符串，以及它们引用的语言：

"application/ecmascript"
"application/javascript"
...

     

用户代理可能支持其他语言的其他MIME类型...

目前，没有浏览器实现过这样的功能。

我怀疑这种方法的主要缺点是每个芯片架构都需要专门为其编译的脚本的机器代码版本。这意味着为了支持三种体系结构，页面需要包含三次编译脚本。 （它应该是第四次，包括普通的JavaScript，作为你没有包含的架构的后备，或者是不能支持编译代码的浏览器。）这可以使用大多数无用的数据显着增加页面的大小。无论你在编译时节省多少时间，加载时间的增加似乎都会显着抵消或完全超过。

像字节码这样的独立于体系结构的折衷解决方案似乎很差：你仍然需要包括两次脚本（一次用于字节码，一次通常用于不支持脚本的脚本），你需要做一些对字节码进行运行时处理，将其转换为机器码。

多包含后备问题正是其他脚本语言没有进入Web环境的原因：他们需要协调的跨供应商支持才能发挥作用。谷歌正试图与Dart合作，但他们看到的成功程度仍有待观察。

请注意Chrome does cache compiled versions of scripts所以脚本只需要编译一次，然后在用户重新访问页面时缓存已编译的代码以便重复使用。