中间代表 - IR - 例如Java bytecodes或.net CIL，还有优势吗？我们不能只在源代码中部署软件组件吗？
支持IR的一个论点是软件组件的可移植性，这避免了为每个目标体系结构编译源代码的需要（关于虚拟机的存在）建筑）。 IR提供了对每个体系结构特性的抽象。以同样的方式并与元数据一起，它在实现安全保障方面带来了其他优势;检查安全通道;等
今天，Node.js（带V8引擎）等一些技术在Node.js中引入了源代码中可部署组件的概念，称为 packages （我不确定它是否是开创性的Node.js中的想法）。源代码包含 IR +元数据的相同信息。此外，使用源代码中的组件并不妨碍运行时引擎使用现代虚拟机的相同原理，例如即时编译和后期绑定数据类型，这允许自适应优化因此理论上可以更快地执行。
那么，在IR中使用源代码中的组件部署软件组件是否有任何优势？
答案 0 :(得分：6)
在某些情况下，区别开始模糊，我将在下面说明。但总的来说：
IR字节码的一个优点是混淆了您创建的逻辑。然而，缩小的javascript也是如此，在某些情况下也是如此。
另一个优点是缩小了尺寸，但缩小的javascript也很小，也许同样如此。
第三个优点是更快的JIT编译，因为字节码更接近源代码的实际机器指令。虽然您可以使用源代码执行JIT，但执行此操作需要更多指令和/或内存。所以其他条件相同，你应该通过字节码部署获得更好的性能。应该注意的是，其他情况很少相同，因此您可能无法始终观察到这种性能优势，或者根据您的性能需求可能会相对较小。
第四个优点是，您可以更轻松地让其他语言以字节码IR为目标，而不是以语言为目标。虽然可以创建一个编译为javascript的语言，但通常可以更容易地编译为字节码，并且您可以更好地控制结果的性能和正确性，因为您正在编译成更靠近机器代码的东西。 。
最后，有可能，甚至在某些情况下，通过这个网站完成，手动调整字节码的性能，就像人们有时使用汇编程序一样。
现在区别可能变得模糊。人们可以想象一个相当重量级的字节码格式，可能是由于需要支持大量硬件，或者可能是由于设计不佳，这可能比机器代码更远，而不是解释ANSI C。但是，如果我们假设字节码是接近机器指令的合理尝试，并假设“源代码”表示高于C或更高级别的东西，则上述优点应该成立。
答案 1 :(得分：1)
根据一些观点，我认为没有优势，只是设计选择的问题。而且，这就是我对自己的问题给出的答案，我将在接下来证实这一点。
事实上，在JavaScript中缺少可部署的IR格式的主要原因可能是（如HansPassant's comment所示）：
Javascript刚刚倒退。
我真的很喜欢这句话。但是，当@HansPassant声明时，我不确定第二部分：
WebAssembly很可能是JS＆＃39;字节码。
有关WebAssembly模块的文档声明：
虽然WebAssembly模块旨在与Web环境中的ES6模块进行互操作，但WebAssembly模块是独立于JavaScript定义的，不需要主机环境包含JavaScript VM。
这强化了我的想法，即可部署IR格式的选择只是一种设计选择。事实上，在源代码中维护组件没有任何明显的缺点。因此，例如，我不确定现有的Node.js生态系统是否会采用WebAssembly模块。
最后在jackmott's answer中，他对IR的可能优势进行了清晰的分析，但最后他考虑：
区别可能变得模糊。
我完全同意，在此我列举了为什么所有IR优势都可以通过源代码方法进行反驳：
逻辑混淆 - 可以在源代码级别完成相同的操作。
缩小尺寸 - 并非总是如此。在某些情况下，源代码中的组件甚至可以比其编译版本更小。
更快的JIT编译 - 仅在第一次方法调用时。无论方法体是IR还是源代码，后续调用都将受益于相同的优化。
通过Transpiling进行编译 - 只是针对同一端的两种不同方法 - 支持其他高级编程语言。今天至少有一个Javascript转换器用于最常用的编程语言。
低级别的手势 - 这是一个优势吗？我相信自动化工具可以比手工调整做得更好。此外，在某些情况下，手动调整可能会破坏模式并避免优化。