chrome是否了解已编译的javascript？

Question

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

Answer 1

网上发货机代码存在两个主要问题:

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

为了解决(1),您通常需要交叉编译机器代码,这比从高级语言编译更困难和更昂贵.要解决(2),您需要验证收到的机器代码,这比编译高级语言更困难,成本更高.

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

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

Answer 2

按照我的理解，V8 JavaScript 引擎无论如何都会编译成机器码，所以为什么不提前做呢？

根据W3C HTML5 脚本规范，浏览器不支持具有特殊type属性的机器代码（正如 Chrome 对 Dart 语言所做的那样）没有基于标准的原因：

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

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

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

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

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

像字节码这样的与体系结构无关的折衷解决方案似乎很糟糕：您仍然需要包含两次脚本（一次用于字节码，一次通常用于不支持它的脚本）并且您需要在将其转换为机器码的字节码。

多重包含和回退问题正是其他脚本语言没有进入 Web 环境的原因：它们需要协调的跨供应商支持才能发挥作用。谷歌正在尝试使用 Dart，但他们看到的成功程度还有待观察。

请注意，Chrome 会缓存脚本的编译版本，因此脚本只需要编译一次，然后编译后的代码会被缓存以供用户重新访问页面时重用。