中间表示（例如字节码或 .net IL）仍然是一个优势吗？
Is intermediate representation (such as bytecodes or .net IL) still an advantage?
中间表示--IR--如Javabytecodes or .net CIL，还是优势？我们不能只在源代码中部署软件组件吗？
支持 IR 的论点之一是软件组件的可移植性，它避免了为每个目标体系结构编译源代码的需要（关于是否存在该体系结构的虚拟机）。 IR 提供了对每个体系结构特性的抽象。同样，它与 metadata 一起在启用安全保证方面带来了其他优势；检查安全通道；等等
今天，Node.js（使用V8引擎）等一些技术在源代码中引入了可部署组件的思想，在Node.js中调用了packages（我不确定这是否是 Node.js 中的开创性想法）。源代码包含 IR + 元数据 的相同信息。此外，在源代码中使用组件，并不会阻止运行时引擎使用现代虚拟机的相同原理，例如 just-in-time 编译和后期绑定数据类型，这允许自适应优化，因此理论上可以产生更快的执行速度。
那么，与源代码中的组件相比，在 IR 中部署软件组件有什么优势吗？
在某些情况下，区别开始变得模糊，我将在下面指出。但总的来说：
IR 字节码的一个优点是混淆了您创建的逻辑。然而，缩小 javascript 也是如此，并且在某些情况下达到相似的程度。
另一个优点是体积变小了，但缩小后的javascript也很小，或许也差不多。
第三个优势是更快的 JIT 编译，因为字节码更接近于源代码的实际机器指令。虽然您可以使用源代码执行 JIT，但需要更多指令 and/or 内存才能完成。所以在其他条件相同的情况下，您应该通过字节码部署获得更好的性能。需要注意的是，很少有其他情况是相同的，因此您可能不会总是观察到这种性能优势，或者它可能相对较小，具体取决于您的性能需求。
第四个优势是，与以一种语言为目标相比，您可以更轻松地让其他语言以字节码 IR 为目标。虽然可以创建一种编译为 javascript 的语言，但编译成字节码通常更容易，并且您将更好地控制结果的性能和正确性，因为您正在编译成某种东西更接近机器码。
最后，有可能，甚至在某些情况下，通过这个网站，手动调整字节码以提高性能，就像人们有时使用汇编程序所做的那样。
现在区别可能变得模糊了。人们可以想象一种相当重量级的字节码格式，这可能是由于需要支持大量的硬件，或者可能是由于设计不佳，与机器代码相比，它可能比解释的 ANSI C 更远。但是，如果我们假设字节码是一种合理的尝试来近似机器指令，并假设 "Source code" 表示像 C 或更高级别的东西，那么上述优势应该成立。
根据一些意见，我认为没有优势，只是设计选择的问题。而且，这就是我要对我自己的问题给出的答案，接下来我将证实这一点。
事实上，JavaScript 中缺少可部署的 IR 格式的主要原因可能是（如 中指出的）：
Javascript was just done backwards.
我很喜欢这句话。但是，当@HansPassant 声明时，我不确定第二部分：
WebAssembly is likely to be JS' bytecode.
关于 WebAssembly 模块的文档指出：
While WebAssembly modules are designed to interoperate with ES6 modules in a Web environment, WebAssembly modules are defined independently of JavaScript and do not require the host environment to include a JavaScript VM.
这强化了我的想法，即选择可部署的 IR 格式只是一个设计选项。事实上，在源代码中维护组件没有任何明显的缺点。因此，例如，我不确定现有的 Node.js 生态系统是否会采用 WebAssembly 模块。
最后在中，他对IR的可能优势进行了清晰的分析，但最后他考虑：
the distinction can get blurry.
我完全同意，在这里我列举了为什么所有 IR 优势都可以通过源代码方法进行反驳：
逻辑混淆 – 同样可以在源代码级别完成。
缩小尺寸 – 并非总是如此。在某些情况下，源代码中的组件甚至可能比其编译版本更小。
更快的 JIT 编译 – 仅在第一次方法调用时。后续调用将受益于相同的优化，无论方法体是在 IR 还是源代码中。
编译优于转译 – 只是两种不同的方法达到同一目的 – 支持其他高级编程语言。今天至少有一个 Javascript 转译器适用于最常用的编程语言。
低级手调 – 这是优点吗？我相信自动化工具可以比手动调整做得更好。此外，在某些情况下，手动调整可能会破坏模式并避免优化。
中间表示--IR--如Javabytecodes or .net CIL，还是优势？我们不能只在源代码中部署软件组件吗？
支持 IR 的论点之一是软件组件的可移植性，它避免了为每个目标体系结构编译源代码的需要（关于是否存在该体系结构的虚拟机）。 IR 提供了对每个体系结构特性的抽象。同样，它与 metadata 一起在启用安全保证方面带来了其他优势；检查安全通道；等等
今天，Node.js（使用V8引擎）等一些技术在源代码中引入了可部署组件的思想，在Node.js中调用了packages（我不确定这是否是 Node.js 中的开创性想法）。源代码包含 IR + 元数据 的相同信息。此外，在源代码中使用组件，并不会阻止运行时引擎使用现代虚拟机的相同原理，例如 just-in-time 编译和后期绑定数据类型，这允许自适应优化，因此理论上可以产生更快的执行速度。
那么，与源代码中的组件相比，在 IR 中部署软件组件有什么优势吗？
在某些情况下，区别开始变得模糊，我将在下面指出。但总的来说：
IR 字节码的一个优点是混淆了您创建的逻辑。然而，缩小 javascript 也是如此，并且在某些情况下达到相似的程度。
另一个优点是体积变小了，但缩小后的javascript也很小，或许也差不多。
第三个优势是更快的 JIT 编译，因为字节码更接近于源代码的实际机器指令。虽然您可以使用源代码执行 JIT，但需要更多指令 and/or 内存才能完成。所以在其他条件相同的情况下，您应该通过字节码部署获得更好的性能。需要注意的是，很少有其他情况是相同的，因此您可能不会总是观察到这种性能优势，或者它可能相对较小，具体取决于您的性能需求。
第四个优势是，与以一种语言为目标相比，您可以更轻松地让其他语言以字节码 IR 为目标。虽然可以创建一种编译为 javascript 的语言，但编译成字节码通常更容易，并且您将更好地控制结果的性能和正确性，因为您正在编译成某种东西更接近机器码。
最后，有可能，甚至在某些情况下，通过这个网站，手动调整字节码以提高性能，就像人们有时使用汇编程序所做的那样。
现在区别可能变得模糊了。人们可以想象一种相当重量级的字节码格式，这可能是由于需要支持大量的硬件，或者可能是由于设计不佳，与机器代码相比，它可能比解释的 ANSI C 更远。但是，如果我们假设字节码是一种合理的尝试来近似机器指令，并假设 "Source code" 表示像 C 或更高级别的东西，那么上述优势应该成立。
根据一些意见，我认为没有优势，只是设计选择的问题。而且，这就是我要对我自己的问题给出的答案，接下来我将证实这一点。
事实上，JavaScript 中缺少可部署的 IR 格式的主要原因可能是（如
Javascript was just done backwards.
我很喜欢这句话。但是，当@HansPassant 声明时，我不确定第二部分：
WebAssembly is likely to be JS' bytecode.
关于 WebAssembly 模块的文档指出：
While WebAssembly modules are designed to interoperate with ES6 modules in a Web environment, WebAssembly modules are defined independently of JavaScript and do not require the host environment to include a JavaScript VM.
这强化了我的想法，即选择可部署的 IR 格式只是一个设计选项。事实上，在源代码中维护组件没有任何明显的缺点。因此，例如，我不确定现有的 Node.js 生态系统是否会采用 WebAssembly 模块。
最后在
the distinction can get blurry.
我完全同意，在这里我列举了为什么所有 IR 优势都可以通过源代码方法进行反驳：
逻辑混淆 – 同样可以在源代码级别完成。
缩小尺寸 – 并非总是如此。在某些情况下，源代码中的组件甚至可能比其编译版本更小。
更快的 JIT 编译 – 仅在第一次方法调用时。后续调用将受益于相同的优化，无论方法体是在 IR 还是源代码中。
编译优于转译 – 只是两种不同的方法达到同一目的 – 支持其他高级编程语言。今天至少有一个 Javascript 转译器适用于最常用的编程语言。
低级手调 – 这是优点吗？我相信自动化工具可以比手动调整做得更好。此外，在某些情况下，手动调整可能会破坏模式并避免优化。