@bombless 记得有一次看 Rust 团队的人出来做 talk 提到过用 Rust 写 JS 引擎这个问题，目前的看法是没什么必要，因为 Rust 最重要的特性之一是 safety ，而给浏览器写一个 JS 引擎没有 JIT 根本不能投入生产，而要写 JIT 那基本上就是无穷无尽的 unsafe 了（本质上就是生成汇编然后塞进一个 executable memory ，如何安全的起来……）

@secondwtq

我的意思是，要看懂 JS 引擎，起码得具备基本的编译原理知识，否则光是编译器前端就已经看不下去了，更不要提后端的优化。但是具备了基本的编译原理知识，起码可以看懂 JIT 以外的大部分东西。目前各个 JavaScript 引擎都是解释器+ JIT 编译器的架构了，包括 V8 这个编译器忠实信徒都为资源有限的设备搞出了 ignition ， Chakra 做跨平台移植也是先不管 JIT ，将解释器移植起来再说。所以可以先看懂前端+解释器+GC 的部分，再去深入研究 JIT ，因为后者起码还得对汇编和计算机组成原理有足够的了解才能向下看，恐怕对于前端来说跑得更偏了……

不过和 layout engine 相比，显然 JavaScript 引擎更有趣吧（更像一个 big clean problem ，虽然跟其他语言比一点都不 clean ……）， layout engine 感觉就是在跟 W3C 和后面那成山成海的 spec 搏斗，搏斗的同时还要在一个庞大无比的代码山里做性能优化，看起来就枯燥的多……

JavaScript 引擎们反倒更像是普通的高级语言引擎，何况脱离浏览器的使用场景也不少了，能从其他语言的实现里借鉴的东西也很多，不少搞 JavaScript 引擎的人以前都是搞 Java 啊 C# 啊的实现出身的。如果有其他高级语言实现的经验，切换到 JavaScript 的次元相对来说要容易一些……（除了要适应一下各种反人类反优化的语言设计……）

还有我觉得楼主似乎应该搞清楚一个浏览器的架构先……比如不要把 V8 和 Chakra 归成 “浏览器内核”？要知道在 Google 啊 M$ 啊之类的地方，做 JavaScript 引擎的团队通常也是跟浏览器团队分开的，有不同的组织和 leader ，而且后者一般人多得多…… JavaScript 引擎团队更多的是需要对编程语言和高级语言虚拟机有深入了解的人，浏览器团队一般收的人会多元化一些，因为浏览器是个更加庞大、涉及更多领域的项目。而且通常 JavaScript 引擎不止为浏览器服务（ Node.js ， M$ 的 UWP 等），所以他们需要让这个引擎能够嵌入到非浏览器环境去，自然不能跟浏览器耦合太重。举个栗子来说，早期的 V8 团队都跑去搞 dart 了，而早期的 IE 团队在 M$ 高层不重视 IE 之后很多都跑去搞 WPF 了，大概就能体会到两者技能树的不同了吧……

有没有必要看个人吧，如果平时只是撸业务的，那恐怕没有太大必要，不过多了解实现并且（不可避免地）多翻标准对处理兼容性问题有一定好处。如果是做数据可视化或者做基础库 /框架的，会比较有用，因为优化的需求会比较多，而任何领域的优化都需要足够的底层知识作为基础。

至于专门学 C++ 是不是显得矫情……关键要看楼主计算机基础如何，这些东西说白了也就是大型软件项目而已，如果计算机基础不行（图形学、编译原理、计算机网络等），光看 C++ 是没有用的，还是会一头雾水，还不如先补基础。另外不能说不需要学 C++，因为这些引擎通常含有大量 C++ 技巧（自己实现的智能指针，元编程 etc.），即使你相应的基础知识很熟，要想真的读懂代码也还是要对 C++ 有足够了解。

另外渲染引擎和 JavaScript 引擎是两个次元的东西，前者代码量一般是后者十倍以上，而且对应的标准长度大概是后者的…………百倍以上？前者主要是绘制的计算和 DOM 的实现，大概对于普通前端来说比较上层的那些东西是可以直接开始看的（无非就是把标准里的要求实现出来而已，对着 W3C 和 WHATWG 的标准翻即可），但是里面一些细节（比如 HTML/CSS parser ）可以先跳过，具备了足够基础后再来看也无妨。另外最底层的绘制细节一般都交给了 Cairo 之类的图形库，所以没有图形学相关知识的话也可以先当成黑盒子跳过……

JavaScript 引擎的话，如果楼主有足够的编译原理基础又不想跑太偏的话，也是可以直接看的吧……（愿意跑偏一点的可以看看 Lua 的实现这种，相似之处不少，而且相对简单得多）。但是如果 lexer 啊递归下降的 parser 啊 SSA 啊 JIT 这些都不知道是啥的话，来看 V8 之类的引擎肯定会一头雾水的……最起码也得能看懂 ECMAScript 的标准里的文法吧？如果发现看不懂的话，可能还是先去学学编译原理合适些……

@HentaiMew 不我的意思是。。即使没有 JIT ， V8 也是编译成机器码再执行的，你看过那个对谈就知道了，如今其他所有主流 JS 引擎确实都是解释器+JIT 编译器的架构，但 V8 还真不是，也毫无意愿加解释器。我纠结的点是，人家明明不需要解释器啊， ES 里啥都没规定，那些属于实现细节。。你真要做 AOT ，也不是不可以（不过 eval 和 with 需要 workaround )。。 JS 当然是脚本语言了，名字里都摆着。。

@fractal314 另外我不是男的，且我也没写 Node.js 多久啊……起码我刚学的时候就知道了 Koa 的存在，所以从来没觉得嵌套回调是什么问题，因为……干嘛要写嵌套回调啊？（除了某些逗比库只有嵌套的 API 需要你先自行封装一下）= =

@fractal314 Express 是基于 Connect 的，用的是类似 CPS 的方法解决回调的问题，属于在引擎没有太多特性支持的时候，编程上的 trick 。 Promise 也是类似的 trick ，所以不需要 JS 引擎的支持，用起来就能改变你代码的形状。

yield （或者说 generator ）这种涉及上下文切换的特性，则是需要引擎支持的，但是这个也是很早 V8 就支持的，虽然要打开 flag ，然后现在 ES2015 已经定稿了， Node.js 也和 io.js 合并紧跟最新的 V8 了，所以不开 flag 就能用……

而 async/await 可以直接基于 generator 做实现，虽然 V8 还没有，不过用 co 这样的库可以直接达到类似的目的，只是一点点语法糖不同。

所以总而言之， Node.js 里的回调嵌套问题，很早就有解决方案了啊…… Express 的继任者 Koa 是基于 generator+co 解决的嵌套问题，也是 2013 年就出现的，国外的不说，国内 Node.js 用得最广的阿里就是广泛使用 Koa 的，也有员工是 Koa 的 contributor 比如双十一天猫 Node.js 的负责人 dead-horse ……（ https://github.com/koajs/koa/graphs/contributors ）（他今年双十一的 Node.js 应用分享在： https://github.com/tmallfe/tmallfe.github.io/issues/28 ，你看嵌套回调这种已经根本不是个事儿了提都不提……）

@mzer0 yield 不是 Node.js 里的东西啊，是 JavaScript 里的，语言层面上的，在 ES2015 里被标准化，需要引擎支持，而 V8 已经支持了，然后基于 V8 的 Node.js 也自然就支持了（以前需要开 flag ，现在 Node.js 和 io.js 合并之后不需要开 flag 就能使用）。

@HentaiMew 另外编译和解释这种不都算实现细节么，和语言无关，除了 Java 这种自带 JVM Spec 的，没有什么本质之说……你要想解释， C/C++也是能直接解释执行的啊，大把人写 C/C++ 的解释器做 toy project 玩儿呢……那 C/C++ 就变成脚本语言了？

@HentaiMew “所有 JS 引擎全部都有“解释器”和“编译器””这种论调是哪里来的， V8 就没有解释器，真的没有，不信你看 https://channel9.msdn.com/Shows/Going+Deep/Lars-Bak-and-Steve-Lucco-Chakra-V8-JavaScript-Open-Source ， Lars Bak 还表示了对解释器的不屑…… V8 是开源的，你完全可以去看他的源代码，看过你就知道了，他只有编译器，区别只在于 baseline compiler 编译出的是没有优化的机器码， crankshaft 编译出的是优化过的机器码，从来没有解释执行一说……那照你这么说他非得编译成机器码才能执行 JS 引擎， V8 就不算 JS 运行时了么= =

@mzer0 复杂的不是 yield ，是如果想要用 generator 来做异步需要加多的那一个 scheduler ，也就是说，你需要 async/await ，或者在没有实现之前，得有 co 这样的垫脚石……然而只要有了这些基础设施写起来就跟写同步差不多了=___=（嵌套回调哪里简单了……“一层套一层，想想就发怵” 2333

@HentaiMew V8 没有解释器，只有编译器。没有解释执行，只有源代码->机器码->执行，而不是源代码->执行。即使不优化，也照样编译成机器码，然后执行机器码，也就是说跟 C/C++编译器是一个路子。

ECMAScript 完全没有要求过 JS 需要怎样被运行，所以并不存在什么 “ JS 无需编译成字节码即可被执行的本质”……那些都是“实现细节”……

@mzer0 楼上。

@fractal314 2015 年了还在用嵌套回调写 node ，说明知识范围太狭窄了，还是别再写的好……

@HentaiMew 说 JavaScript 是解释型脚本，你让 V8 这种只有编译器没有字节码的引擎情何以堪……

@zonghua 恰恰相反，有了基金会和新的版本机制对社区是好事啊，以后大家要上生产环境的和初学的只要盯着最近的那个 LTS 就行， LTS 的更新也能保证不会步子太大扯到蛋，喜欢折腾的又可以去玩稳定版，社区也能继续保持朝气

@luoway 保护你的颈椎腰椎各种关节………

@Orzpls +10086 ，当你身边充满了大牛的时候就好多了

单数稳定版，双数 LTS