没有eval（），JavaScript可以编译成二进制文件吗？

Question

从我读过的所有内容来看，似乎唯一提到的就是阻止JavaScript被编译一次，运行到处（或至少每个浏览器运行）都是愚蠢的eval()语句。有什么关于JavaScript的东西使这成为一个不可能的壮举？

不是浪费所有这些时间，在每台计算机和每个浏览器上，JIT-ting和下载多个源代码文件，我希望看到浏览器使用更少的字节运行JavaScript，使用更少的连接，并且快速，优化代码。

如何做到这一点？

Answer 1

这个问题在几个层面上存在缺陷。

1. 如果你的意思是任何二进制格式（比方说，字节码），那么你需要所有 JS实现在那里进行操作，聚在一起并达成标准。不会发生。即使如此，也不能保证你会在缩小的JS上获得任何文件大小的重大改进，更不用说重大改进了。将一些.py源文件的大小与缓存的.pyc字节码文件的大小进行比较我手头上显示，至少CPython的字节码通常比源文件更大。并且源文件甚至没有缩小！
2. 如果您的意思是原生可执行文件......那么，很难将JS编译为本机代码AOT，特别是在没有构建整个实现的情况下，但这在理论上可能是可能的。它不会带来太多的性能提升，因为你无法消除动态性（至少不是静态的 - JIT编译器可以做得更好），所以你必须付出代价。它也有许多缺点，使它完全没有价值：
   1. 生成的二进制文件是特定于平台的。所以要么你必须发送所有可能的二进制组合（这是浪费的，并且需要浏览器进行额外的特殊处理），或者你必须做嗅探并发送你认为可能适合的任何二进制文件 - 这会使任何不愿意的人感到困惑免费提供相当多的私人信息（通过发送错误/完全无用的可执行文件）。
   2. 你可能会失去沙盒。原生代码在很大程度上是一个巨大的黑盒子。在浏览器中运行它也意味着浏览器会从一些不受信任的来源运行可执行代码 - 恶意软件的邀请。当然，除非您将整个顶级的反恶意软件套件集成到每个浏览器中。我真的需要进一步评论吗？
   3. 除非为所有允许编译的JS访问实现的所有内置函数等的实现创建标准，否则创建一些共享代码的方法，最终会产生大量冗余（静态链接整个JS实现）进入二进制）。结果可能比压缩JS更大。
   4. 您仍然需要一些标准界面（除非您希望从architectures * OSs转到architectures * OSs * browsers可执行文件）以进行DOM集成。
   5. 甚至没有提到所有浏览器都必须支持这一点。无论是以标准方式还是各自独立方式。很难（并且很长）足以说服所有人以源代码形式支持大多数HTML，CSS和JS 。或者你需要引入一些检测支持的标准方法。
   6. 另外（如已经指出的），对于动态语言，JIT可以执行与静态编译器一样好或更好。所以很可能（非常不可思议地，考虑到前面的一些观点）你可以节省下载的时间（使用缩小，gzipping，缓存等已经很小）和解析（这不是无论如何，这是一个重要的性能杀手。但实际运行时间也不会显着改善。

Answer 2

虽然这并没有真正浪费那么多时间。 JavaScript引擎花费的时间远远超过运行 JavaScript而不是解析它。理论上你可以将JavaScript编译成机器代码，这有点像嵌入JavaScript引擎和脚本本身，就像一个自解压的ZIP文件或其他东西。我不认为这有什么好处。