UPDATE:
当 JavaScript 在 1995-96 年首次出现时，Brendan Eich 创建了第一个 JS 引擎，称为 Spider-Monkey（至今仍在 Mozilla Firefox 中使用）。此时，JavaScript 的创建就考虑到了浏览器的需求。这样来自服务器的任何文件都会被浏览器快速解释和显示。
Interpreter 是这样做的最佳选择，因为 Interpreters
逐行执行代码并立即显示结果。
但随着时间的推移，性能成为一个问题，它变得越来越慢。解释器的问题在于，当您在像这样的循环中一遍又一遍地运行相同的代码时：
const someCalculation = (num1, num2) => {
return num1 + num2;
};
for (let i = 0; i < 10000; i++) {
someCalculation(5, 6); // 11
}
它可能会变得非常非常慢。
所以最好的选择是引入编译器，
这实际上对我们有帮助。启动需要多一点时间，因为它必须在开始时经历编译步骤 - 浏览我们的代码，理解它并将其吐出为另一种语言。但编译器足够聪明。当它看到像上面这样的代码时（我们循环它并且它具有相同的输入，返回相同的输出），它实际上可以简化这段代码，而不是多次调用这个函数，它可以用输出替换这个函数功能。像这样的东西。
const someCalculation = (num1, num2) => {
return num1 + num2;
};
for (let i = 0; i < 10000; i++) {
11; // And it will not call someCalculation again and again.
}
由于编译器不会为该循环中的每次传递重复翻译，因此生成的代码实际上更快。
编译器所做的这些编辑称为优化
因此，Javascript 将解释器和编译器结合起来，以充分利用两者的优势。因此，浏览器开始混合称为 JIT 编译器的编译器进行即时编译，以使引擎更快。
在图像中你可以看到Profiler它会监视重复的代码并将其传递给编译器进行代码优化。
这意味着我们输入的Javascript代码的执行速度
进入发动机将会
逐渐完善，因为Profiler和Compiler不断
对我们的字节代码进行更新和更改，以便
尽可能高效。所以解释器可以让我们正确运行代码
而 Profiler 和 Compiler 允许我们优化此代码：
我们正在跑步。
现在让我们得出一些结论：
现在我们知道了 JS-Engine 的工作原理，作为程序员，我们可以编写更多优化代码 - 编译器可以比我们的常规 Javascript 更快地获取和运行代码。However,
我们需要确保我们不会混淆这个编译器 - 因为编译器并不完美，它可能会犯错误，并且它可能会尝试优化恰恰相反的代码。如果它犯了一个错误并且做了一些意想不到的事情，它就会做一些叫做去优化这需要更长的时间才能将其返回给口译员。
现在的大问题是： Javascript 是解释性语言吗？
ANSWER：是的，最初当 Javascript 首次出现时，您有一个 Javascript 引擎，例如 Brenden Eich 创建的 Spider-Monkey，它将 javascript 解释为字节码，并且该 Javascript 引擎能够在我们的浏览器内部运行，告诉我们的计算机要做什么。
但现在事情已经发生了变化，我们不仅有解释器，我们还使用编译器来优化我们的代码。所以，这是一个常见的误解。
当有人说 Javascript 是一种解释语言时，是的，确实如此
这有一定道理，但这取决于实施情况。你可以做一个
可能只能编译的 Javascript 引擎的实现。
从技术上讲，这一切都取决于实施。
