几天前一个刚打仗 JavaScript 的朋侪问我 JavaScript 是编译型言语照样诠释型言语。从一个初学者那边听到如许的题目让我有些惊奇，因为一切初学者都晓得 JS 是一个诠释型言语；特别是像她如许之前运用过 Java 这类言语的初学者。

当一些人深切 JavaScript 而且最先研讨 V8 引擎、SpiderMonkey、JIT 之类东西的时刻，他们最先关于诠释型照样编译型有更多的疑问。很愉快看到她已在这个阶段了。

令人疑心的是什么？

最最先的时刻，JavaScript 的圣经 —— MDN 明白地说 JavaScript 是一个诠释型言语（同时还说到了 JIT 实时编译，后文会说起）。然则下面几点依然会让 JavaScript 是不是真的是一个诠释型言语发生疑问：

• 假如 JS 是诠释型言语那为何会有变量提拔（hoisting）？
• JIT（实时编译）会做代码优化(同时建立代码的编译版本)；诠释型言语没法做到这些。

有什么疾速的回复吗？

因为 JavaScript 范例没有对这一点做明白申明，疑心和疑问是都是存在的，不能单方面地回复。让我们基于理论定义和 JavaScript 事变流程来弄清楚 JavaScript 究竟是什么言语。

编译型言语 VS 诠释型言语

主要题目是没有整体或许构造划定这些；比方：编译型言语和诠释型言语的定义以及怎样分别。 而这两个都是观点。

所以依据观点，编译型言语是代码在运转前编译器将人类可以明白的言语（编程言语）转换成机械可以明白的言语。

诠释型言语也是人类可以明白的言语（编程言语），也须要转换成机械可以明白的言语才实行，然则是在运转时转换的。所以实行前须要环境中装置了诠释器；然则编译型言语编写的应用在编译后能直接运转。

很多人以为诠释型言语意味着当碰到顺序中行号为xyz时直接将其传给CPU就可以运转；然则现实不是如许。一切的编程言语都是为人类建立的。他们是人类可以明白的。必须将编程言语转换为机械言语才运转。编译器猎取全部代码，转换它，做适宜的优化而且建立一个可以运转的输出文件。编译器依据上下文来转换语句。

那末变量提拔呢？

我以为你应当已晓得了 JavaScript 的变量提拔。在函数作用域内的任何变量的声明都邑被提拔到顶部而且值为undeinfed。

所以 JavaScript 引擎彷佛诠释了同一个剧本文件两次？第一次完成一切的声明提拔然后第二次才实行代码？照样先编译全部代码然后运转它？这两种都不对。

下面是 JavaScript 处置惩罚声明语句的历程：

• 一旦 V8 引擎进入一个实行详细代码的实行上下文（函数），它就对代码举行词法剖析或许分词。这意味着代码将被支解成像foo = 10如许的原子标记（atomic token）。
• 在对当前的全部作用域剖析完成后，引擎将 token 剖析翻译成一个AST（笼统语法树）。
• 引擎每次碰到声明语句，就会把声明传到作用域（scope）中建立一个绑定。每次声明都邑为变量分派内存。只是分派内存，并不会修正源代码将变量声明语句提拔。正如你所晓得的，在JS中分派内存意味着将变量默许设为undefined。
• 在这以后，引擎每一次碰到赋值或许取值，都邑经由过程作用域（scope）查找绑定。假如在当前作用域中没有查找到就接着向上级作用域查找直到找到为止。
• 接着引擎天生 CPU 可以实行的机械码。
• 末了， 代码实行终了。

所以变量提拔不过是实行上下文的小把戏，而不是很多网站形貌的源代码修正。在实行任何语句之前，诠释器就要从建立实行上下文后已存在的作用域（scope）中找到变量的值。

诠释 JavaScript 中的立即编译（JIT）

JIT 或 实时编译 编译器不是 JavaScript 所特有的。其他言语比方 Java 也有一些在实行前编译代码的机制。

当代 JavaScript 引擎一样有 JIT。是的，它们有编译器。让我来为你诠释一下为何它们须要 JIT 以及 JIT 在 JavaScript 的实行中是怎样事变的。

编译型和诠释型言语最主要的区别是编译型言语须要很长的时候来预备实行。因为它须要对全部代码举行词法剖析、做一些极致的优化等事变。另一方面诠释型言语几乎在实行后一瞬间就最先，然则没有任何代码优化。所以每一条语句都是离开转换（编译）的，斟酌下面这一段代码。

for(i=0; i < 1000; i++){
    sum += i;
}

在编译型言语中sum += i部分在轮回运转时已编译成了机械码，机械码将直接运转一千次。

然则在诠释型言语中，实行时会将sum += i转换（编译）一千次。对雷同的代码举行一千次转换会形成非常大的机能消耗。

这就是 Google 和 Mozilla 的开发人员将 JIT 到场 JavaScript 的缘由。

编译

在 JavaScript 中假如一段代码运转凌驾一次，那末就称为 warm。假如一个函数最先变得 warmer（译者注：即运转更屡次），JIT 将把这段代码送到编译器中编译而且保留一个编译后的版本。下一次一样代码实行的时刻，引擎会跳过翻译历程直接运用编译后的版本。

这将优化机能。在真正的编译器中，因为编译器能接见全部代码所以做了除此之外更多的事变。

优化

假如一段 warm 的代码变得 hot 或许 hotter（译者注：指运转更屡次以及比更多还要多的次数）JIT 会尝试更多的优化而且保留优化后的版本。在编译器举行优化的历程当中会做一些关于变量范例和运转环境中值的假定，假如假定不建立就将这个优化的版本回退，假如假定建立的话，这将让代码机能更高。

想要相识更多 JIT 的学问可以浏览 Lin Clarks 关于JIT的课程。

总结

如今我们相识了 JavaScript 实行时究竟发生了什么，所以应当可以辨别 JavaScript 究竟是编译型照样诠释型言语了。下面是这篇文章的要点。

• JavaScript 代码须要在机械（node 或许浏览器）上装置一个东西（JS 引擎）才实行。这是诠释型言语须要的。编译型言语顺序可以自由地直接运转。
• 变量提拔不是代码修正。在这个历程当中没有天生中间代码。变量提拔只是 JS 诠释器处置惩罚事变的体式格局。
• JIT 是唯一一点我们可以对 JavaScript 是不是是一个诠释型言语提出疑问的来由。然则 JIT 不是完全的编译器，它在实行前举行编译。而且 JIT 只是 Mozilla 和 Google 的开发人员为了提拔浏览器机能才引入的。JavaScript 或 TC39 从来没有强迫请求运用 JIT。

因而，虽然 JavaScript 实行时像是在编译或许像是一种编译和诠释的夹杂，我依然以为 JavaScript 是一个诠释型言语或许是一个本日很多人说的夹杂型言语，而不是编译型言语。