为什么在通过网络发送JavaScript之前未将其编译为字节码？

#1 楼

为什么在通过网络发送JavaScript之前不将JavaScript编译为字节码？引擎。

让我从面对“为什么不呢？”时总是说的话开始。问题：不需要语言设计师给出充分的理由说明为什么他们没有花费数亿美元的他人来购买某人喜欢的功能。相反，要求该功能的开发人员给出充分的理由说明为什么这是花费时间，精力和金钱的最佳方式。您已经提出了一个没有附加任何数字的参数，即就带宽而言，字节码可以节省成本。我鼓励您计算一些实际数字，并将其与创建另一种语言的成本进行比较；这些费用是巨大的。请记住，在您的分析中，“实施”是最小的成本之一。在您的分析中还包括谁省钱与谁花钱，您会发现花钱的人不是省钱的人。奖励很重要。

，这是更合理的“为什么不呢？”之一提出质疑，因为它是我们出于考虑而拒绝使用的功能。

我们在Microsoft内部和TC级别都考虑了这种方案；由于JScript已被实现为编译为设计良好的，原则上的字节码语言，因此对于我们来说，将其提议为标准是很简单的，因此我们考虑这样做。各种原因包括：



天哪，很难对JavaScript进行标准化。每个人和他们的狗都会对字节码语言的理想特征有什么看法，这将是很多年的经验。没有人真的想去那里。
这是一个昂贵的解决方案，没有相关的昂贵问题。没有理由认为字节码语言在大小或速度上都会更有效率。 JavaScript已经很好地实现了最小化并且具有高度可压缩性。
它会为浏览器提供商创建大量的工作，而这些浏览器提供商已经因制作高效，兼容的JS实现而感到烦恼。
创建一个安全的JS实现以抵抗不良行为者的攻击已经足够困难了；我们应该将可攻击的表面积增加一倍吗？可能不是。

标准是创新的障碍。如果我们发现对字节码语言的微小更改会在某些以前无法预见或不重要的用户场景中产生很大的不同，那么我们可以自由地进行更改。如果这是一个标准，我们将不能自由创造用户利益。有趣的是，出于1990年代动机考虑使用此功能的客户要求主要与性能无关。

为什么不呢？对于JS而言，1990年代与今天截然不同。脚本大多很小。关于某天将有成千上万条线的框架的想法甚至还没有接近我们的视野。下载和解析JS只是下载和解析HTML所花费的时间的很小一部分。同样，它使用了非常相似的字节码语言。 （由同一个团队开发，并使用相同的资源和全部内容进行编译。）

相反，在浏览器中激发字节码的主要客户场景是使代码更难以阅读，理解，反编译，反向工程和篡改。对于拥有合理资源的任何攻击者而言，字节码语言几乎都不是要理解的任何其他工作，这是进行此工作的主要重点。我们不想造成一种虚假的安全感。

基本上有很多开支，却只有很少的好处，因此没有完成。在1998年至2015年之间必须进行一些更改，以使WebAssembly具有合理的价格收益；这些因素是什么，我不知道。您必须向WebAssembly咨询专家。

#2 楼

View Source
“ View Source”最初只是在某种程度上仍被认为是网络的重要功能。 Web开发人员正是通过这种方式学习Web开发的，相关的标准机构（ECMA TC39，W3C，WHATWG）仍然非常重视它。这包括删除所有注释，所有空格，并尽可能短地重命名所有标识符，以及一些更高级别的优化，例如删除无效代码。自HTTP / 1.0（1996年初）开始。 ECMAScript是文本，并且文本压缩非常好。实际上，ECMAScript是具有很多冗余的文本（出现很多;，{，}，(，)，,，.，function，var，if，for等）和算法。因此，传输的数据量比您实际确定的要少得多。作为实验，尝试使用网络上使用的一种典型压缩算法（例如gzip或deflate）压缩ECMAScript源文件，并将其与同一文件的已编译字节码的大小进行比较。
结果压缩后的源代码实际上很小，通常比典型的字节代码文件小得多。Zopfli是一种与deflate / zlib兼容的Web文本的改进编码算法。这意味着它可以由任何兼容delate / zlib的解码器解码，换句话说，每个浏览器都可以对其进行解压缩而无需更改。压缩所需时间比放气要长80倍，与“裸”放气相比，输出大小可提高3％–8％。对于动态创建的内容而言，即时执行此操作可能没有任何意义，但预压缩诸如JQuery之类的方法可能有意义。
Brotli是一种基于LZ77，Huffman，上下文建模以及其他一些新的压缩算法。技巧，例如从大量的网站，文本，ECMAScript源文件，CSS文件等中提取的频繁文本块的预定义词典。与deflate / zlib相比，压缩效果可提高25％。它旨在在低端便携式设备上进行有效解码。
字节码格式
这使我们面临下一个问题：ECMAscript没有标准化的字节码格式。实际上，某些实现甚至可能根本不使用字节码！例如，在最初的几年中，V8直接将ECMAScript编译为本地机器代码，而中间没有字节码。 Chakra，SquirrelFish Extreme和SpiderMonkey都使用字节码，但是它们使用不同的字节码。 dyn.js，TruffleJS，Nashorn和Rhine不使用ECMAScript特定的字节码，它们会编译为JVML字节码。同样，IronJS编译为CLI CIL字节码。
现在，您可能会说：为什么不为ECMAScript定义标准化的字节码格式？这个问题有两个方面：



字节码格式限制了执行引擎的设计。例如，看一下JVM：JVM比ECMAScript引擎彼此更相似。我个人认为，如果不进行缺乏标准字节码格式的广泛试验，就不可能实现2000年代末/ 2010年代初的“性能竞赛”。


不仅很难使所有ECMAScript引擎供应商都同意一种通用的标准化字节码格式，而且要考虑这一点：将仅ECMAScript的字节码格式添加到浏览器是没有意义的。如果您使用通用的字节码格式，那么如果它也支持ActionScript，VBScript，Python，Ruby，Perl，Lua，PHP等，那就更好了。但是现在您遇到了与＃1中相同的问题，除了成倍增加：不仅所有ECMAScript引擎供应商都需要就通用字节码格式达成一致，而且还必须获得PHP，Perl，Ruby，Python，Lua等。社区也要达成共识！


缓存
在规范URI上托管着广为使用的知名库，可以在多个站点中引用它们。因此，它们只需要下载一次就可以在客户端缓存。
CDN
许多库都使用CDN，因此实际上是从靠近用户的位置提供它们的。 asm.js
WebAssembly（Wasm）是一种紧凑的二进制指令格式，目前已由W3C标准化，并且已经在Firefox，Chrome，Safari和Edge中提供。但是，它并不是ECMAScript的字节码格式，而是作为C，C ++和Rust等语言的低级便携式机器代码和编译目标。
在Wasm之前，已经有asm。 js，它具有相似的目标，但是它被设计为ECMAScript的语法和语义子集，因此您可以在不支持asm.js的引擎中不经修改地运行它，并且它的工作速度要慢得多。

#3 楼

JavaScript由Netscape于1995年发明，最初被定位为一种易于使用的嵌入式脚本语言，可以与HTML集成并控制用Java编写的更复杂的组件。请参阅初始新闻稿以了解预期的用例。
绝不打算将其用于大量代码（因为应该将客户端Java用于复杂的东西），因此注释和源文本的大小开销仅仅是
观众
JavaScript最初的设计师Brendan Eich曾说过：

我们的目标是为Web设计师和
兼职程序员，他们从图像，插件和Java小程序等组件构建Web内容。我们将Java视为价格较高的程序员所使用的“组件
语言”，胶水
程序员（网页设计者）将组装组件并使用[一种脚本语言自动实现其交互。 ]。

另外一个引号： />应该使用的专用编程语言：组件作者，他们使用C ++或（我们希望）Java编写；以及“业余”或“专业”的“脚本”，谁会直接将代码嵌入HTML中。编译语言（如C ++）适合专业开发人员使用，而脚本语言则可供非程序员使用。请注意，该新闻稿将JavaScript与Visual Basic进行了比较，后者用于Office宏和其他自动化工具。当时，网页作者不被视为软件开发人员，而更像图形设计师或DTP用户。
如今，脚本语言和编译语言之间的区别已经变得更加模糊，但是在当时，迎合非开发人员意味着脚本语言意味着没有单独的编译步骤。
易于开发
文本格式是对于临时开发人员而言，这非常容易，因为您不需要开发环境即可将其编译为字节码。您只需键入文本并重新加载浏览器即可查看它的运行情况。在引入JavaScript的时候，专用的HTML编辑器几乎不存在。人们在记事本中编写网页。没有用于Web页面的构建管道。
嵌入HTML
JavaScript被设计为直接嵌入HTML中，例如<input type="button" onclick="alert('hello world')">。如今，人们不赞成将JavaScript嵌入HTML中，但是在那时，这是连接事件处理程序的标准方法。在这种情况下，JavaScript基本上必须是基于文本的。有用。

#4 楼

数据使用实际上可能不是问题。

响应体内的假设（因为埃里克·利珀特（Eric Lippert）的精彩回答似乎已经充分涵盖了实际问题）：

无论您谈论的是数据上限还是带宽，我的Google-Fu都无法发掘任何表明Javascript实际上是在“浪费数TB的数据”的研究。至于其余的问题，在很多事情上，问“这将导致什么问题？”的用处不大。而不是首先问“这将带来什么好处？”。