@@ -0,0 +1,34 @@
+# ES6 特性
+
+ECMAScript 6 (以下简称 ES6)是 JavaScript 语言的下一代标准，已经在 2015 年 6 月正式发布了。Mozilla 公司将在这个标准的基础上，推出 JavaScript 2.0。ES6 的目标，是使得 JavaScript 语言可以用来编写大型的复杂的应用程序，成为企业级开发语言。标准的制定者有计划，以后每年发布一次标准，使用年份作为标准的版本。因为当前版本的 ES6 是在 2015 年发布的，所以又称 ECMAScript 2015。
+
+# **Module & Module Loader**
+
+ES2015 中加入的原生模块机制支持可谓是意义最重大的 feature 了，且不说目前市面上五花八门的 module/loader 库，各种不同实现机制
+
+互不兼容也就罢了 ( 其实这也是非常大的问题 )，关键是那些模块定义 / 装载语法都丑到爆炸，但是这也是无奈之举，在没有语言级别的支持下，js 只能做到这一
+
+步，正所谓巧妇难为无米之炊。ES2016 中的 Module 机制借鉴自
+
+CommonJS，同时又提供了更优雅的关键字及语法 ( 虽然也存在一些问题 )。遗憾的是同样有重大价值的 Module
+
+Loader 在 2014 年底从 ES2015 草案中移除了，我猜测可能是对于浏览器而言 Module
+
+Loader 的支持遭遇了一些技术上的难点，从而暂时性的舍弃了这一 feature。但是一个原生支持的模块加载器是非常有意义的，相信它不久后还是会回
+
+归到 ES 规范中 ( 目前由 WHATWG 组织在单独维护 )。
+
+2.  **Class**
+
+    准确来说 class 关键字只是一个 js 里构造函数的语法糖而已，跟直接 function 写法无本质区别。只不过有了 Class 的原生支持后，js 的面向对象机制有了更多的可能性，比如衍生的 extends 关键字 ( 虽然也只是语法糖 )。
+
+3.  **Promise & Reflect API**
+
+    Promise 的诞生其实已经有几十年了，它被纳入 ES 规范最大意义在于，它将市面上各种异步实现库的最佳实践都标准化了。至于 Reflect API，它让 js 历史上第一次具备了元编程能力，这一特性足以让开发者们脑洞大开。
+
+除此之外，ES2016 的相关草案也已经确定了一大部分其他 new features。这里提两个我比较感兴趣的 new feature：
+
+1.  async/await ：协程。ES2016 中 async/await 实际是对 Generator&Promise 的上层封装，几乎同步的写法写异步比 Promise 更优雅更简单，非常值得期待。
+2.  decorator ：装饰器，其实等同于 Java 里面的注解。注解机制对于大型应用的开发的作用想必不用我过多赘述了。用过的同学都说好。
+
+而关于纯 ES6 语法在各大浏览器上的支持情况，可以查看[这里](http://kangax.github.io/compat-table/es6/)。另外推荐一个可以将 ES5 代码转化为可读的 ES6 代码的转化器：[lebab](https://github.com/mohebifar/lebab)
@@ -6,4 +6,31 @@
 
 JavaScript 的设计与语法一直为人所诟病，不过正如 Zeit 的 CEO Guillermo Rauch 所言：JavaScript 虽然生于泥沼，但是在这么多年不断地迭代中，它也慢慢被开发者与市场所认可，最终化茧成蝶，被广泛地应用在从客户端到服务端，从应用开发、系统构建到数据分析的各个领域。JavaScript 最薄弱的一点在于其是解释性的无类型的语言，这一点让其在大型项目或者系统开发中充满了很多的性能瓶颈或者不稳定性；譬如在 JavaScript 中某个函数可以接受任意数目、任意类型的参数，而 Java 则会在编译时即检测参数类型是否符合预期。早期的 JavaScript 仅被用于为网页添加简单的用户交互，譬如按钮响应事件或者发送 Ajax 请求；不过随着 Webpack 等现代构建工具的发展，开发者可以更加工程化地进行高效的前端项目开发，并且整个网页的加载性能也大大提高，譬如 PWA 等现代 Web 技术能够使 Web 应用拥有与原生应用相近的用户体验。
 
-我喜爱这门语言，所以我希望能够以绵薄之力让更多的人无痛地使用它。本系列中提及的很多代码实现与工具库可以参阅笔者的 [coding-snippets/js](https://github.com/wx-chevalier/coding-snippets) 以及 [js-swissgear](https://github.com/wx-chevalier/coding-snippets/tree/master/js)。
+我喜爱这门语言，所以我希望能够以绵薄之力让更多的人无痛地使用它，在返回主页后您可以看到更多有关 JavaScript 的代码实践。
+
+# ECMAScript
+
+ECMAScript 是 JavaScript 语言的国际标准，JavaScript 是 ECMAScript 的实现。要讲清楚这个问题，需要回顾历史。1996 年 11 月，JavaScript 的创造者 Netscape 公司，决定将 JavaScript 提交给国际标准化组织 ECMA，希望这种语言能够成为国际标准。次年，ECMA 发布 262 号标准文件(ECMA-262 )的第一版，规定了浏览器脚本语言的标准，并将这种语言称为 ECMAScript。这个版本就是 ECMAScript 1.0 版。
+
+之所以不叫 JavaScript，有两个原因。一是商标，Java 是 Sun 公司的商标，根据授权协议，只有 Netscape 公司可以合法地使用 JavaScript 这个名字，且 JavaScript 本身也已经被 Netscape 公司注册为商标。二是想体现这门语言的制定者是 ECMA，不是 Netscape，这样有利于保证这门语言的开放性和中立性。因此，ECMAScript 和 JavaScript 的关系是，前者是后者的规格，后者是前者的一种实现。在日常场合，这两个词是可以互换的。
+
+ECMAScript 定义了：
+
+- [语言语法](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Lexical_grammar) – 语法解析规则、关键字、语句、声明、运算符等。
+- [类型](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Data_structures) – 布尔型、数字、字符串、对象等。
+- [原型和继承](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain)
+- 内建对象和函数的[标准库](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects) – [JSON](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON)、[Math](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math)、[数组方法](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)、[对象自省方法](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object)等。
+
+ECMAScript 标准不定义 HTML 或 CSS 的相关功能，也不定义类似 DOM(文档对象模型)的[Web API](https://developer.mozilla.org/en-US/docs/Web/API)，这些都在独立的标准中进行定义。ECMAScript 涵盖了各种环境中 JS 的使用场景，无论是浏览器环境还是类似[node.js](http://nodejs.org/)的非浏览器环境。
+
+## 特性阶段
+
+- Stage 0 “strawman” — The starting point for all proposals. These can change significantly before advancing to the next stage. There is no acceptance criteria and anyone can make a new proposal for this stage. There doesn’t need to be any implementation and the spec isn’t held to any standard. This stage is intended to start a discussion about the feature. There are currently over twenty stage 0 proposals.
+
+- Stage 1 “proposal” — An actual formal proposal. These require a “champion”(i.e. a member of TC39 committee). At this stage the API should be well thought out and any potential implementation challenges should be outlined. At this stage, a polyfill is developed and demos produced. Major changes might happen after this stage, so use with caution. Proposals at this stage include the long-awaited Observables type and the Promise.try function.
+
+- Stage 2 “draft” — At this stage the syntax is precisely described using the formal TC39 spec language. Minor editorial changes might still happen after this stage, but the specification should be complete enough not to need major revisions. If a proposal makes it this far, it’s a good bet that the committee expects the feature to be included eventually.
+
+- Stage 3 “candidate” — The proposal has approved and further changes will only occur at the request of implementation authors. Here is where you can expect implementation to begin in JavaScript engines. Polyfills for proposals at this stage are safe to use without worry.
+
+- Stage 4 “finished” — Indicates that the proposal has been accepted and the specification has been merged with the main JavaScript spec. No further changes are expected. JavaScript engines are expected to ship their implementations. As of October 2017 there are nine finished proposals, most notably async functions.
@@ -1,3 +1,137 @@
 [![返回目录](https://i.postimg.cc/KvQbty96/image.png)](https://url.wx-coder.cn/lrKga)
 
 # 剖析 V8 引擎
+
+# 引擎与运行时：代码解析与执行
+
+JavaScript 是典型的解释型语言，其需要运行在某个容器内：该容器首先将 JavaScript 代码转化为可执行的命令(语法解析以及 JIT)，然后注入某些全局变量以允许 JavaScript 与外部进行交互。所谓的 JavaScript 引擎(Engine )就是负责解析与编译，将 JavaScript 脚本转化为机器理解的命令；而 JavaScript 运行时(Runtime )这是提供了程序运行期间能够访问的内建库。譬如在浏览器中运行的代码，能够访问 Window 对象或者 DOM API，其就是由浏览器的 JavaScript 运行时提供的。而 Node.js 提供的运行时则包含了不同的库，譬如 Cluster 或者文件系统接口等等。所有的运行时都会包含基础的数据类型以及常见的 Console 对象这样的工具库。我们可以认为 Chrome 与 Node.js 共用相同的 Google V8 引擎，而拥有不同的运行时。
+
+[这篇文章](https://parg.co/Uuv)对于 V8 的工作原理有非常不错的讲解
+
+![](https://cdn-images-1.medium.com/max/2000/0*bN9YVBLw_tT1Xvte.)
+
+![](https://s3.amazonaws.com/images.ponyfoo.com/uploads/addy-ad3b2ea8f9be48a18c4bdad5041a3237.png)
+
+```sh
+$ out/Debug/d8 --print-ast add.js
+…
+--- AST ---
+FUNC at 12
+. KIND 0
+. SUSPEND COUNT 0
+. NAME "add"
+. PARAMS
+. . VAR (0x7fbd5e818210) (mode = VAR) "x"
+. . VAR (0x7fbd5e818240) (mode = VAR) "y"
+. RETURN at 23
+. . ADD at 32
+. . . VAR PROXY parameter[0] (0x7fbd5e818210) (mode = VAR) "x"
+. . . VAR PROXY parameter[1] (0x7fbd5e818240) (mode = VAR) "y"
+```
+
+![](https://s3.amazonaws.com/images.ponyfoo.com/uploads/ast-602ed6f747124b0888c0a032eba50bb2.png)
+
+```sh
+$ out/Debug/d8 --print-bytecode add.js
+…
+[generated bytecode for function: add]
+Parameter count 3
+Frame size 0
+   12 E> 0x37738712a02a @    0 : 94                StackCheck
+   23 S> 0x37738712a02b @    1 : 1d 02             Ldar a1
+   32 E> 0x37738712a02d @    3 : 29 03 00          Add a0, [0]
+   36 S> 0x37738712a030 @    6 : 98                Return
+Constant pool (size = 0)
+Handler Table (size = 16)
+```
+
+![](https://parg.co/UOA)
+
+## JIT
+
+## 优化器
+
+作为解释型语言，JavaScript 的性能一直是其瓶颈之一。Google 在 2009 年在 V8 中引入了 JIT 技术 (Just in time compiling ) , JavaScript 瞬间提升了 20 － 40 倍的速度。JIT 基于运行期分析编译，而 Javascript 是一个没有类型的语言，于是， 大部分时间，JIT 编译器其实是在猜测 Javascript 中的类型，举个例子：
+
+```js
+function add (a, b) { return a+b}
+var c = add (1 + 2);
+
+// 编译为
+function add (int a, int b) { return a + b;} // a, b 被确定为 int 类型
+
+// 有的开发者会做
+var d = add ("hello", "world");
+```
+
+这种情况下，JIT 编译器只能推倒重来。JIT 带来的性能提升，有时候还没有这个重编的开销大， [Optimization killers · petkaantonov/bluebird Wiki · GitHub](https://github.com/petkaantonov/bluebird/wiki/Optimization-killers)。事实上，大部分时间 JIT 都不会生成优化代码，有字节码的，直接字节码，没有字节码的，粗粗编译下就结了，因为 JIT 自己也需要时间，除非是一个函数被使用过很多遍，否则不会被编译成机器码，因为编译花的时间可能比直接跑字节码还多。
+
+# 语法增强
+
+## 类型转换
+
+Webpack、Fuse 、 Rollup、Browserify
+
+## 静态类型
+
+# Modern JavaScript Development Glossary
+
+JavaScript was created in 1995 by Brendan Eich with the objective to be a language which designers could easily implement dynamic interfaces,
+in other words, it wasn’t built to be fast; it was created to add behavior layer on HTML pages comfortably and straightforwardly.
+
+Engine is a program that converts Javascript code into lower level or machine code that microprocessors can understand.
+
+# Engine & Runtime: Code Parse, Compile and Execution
+
+After loading, the source code will be transformed into a tree representation called Abstract Syntax Tree or AST. Then, depending on the engine/operational system/platform, either a baseline version of this code is compiled, or a bytecode is created to be interpreted.
+
+## JIT
+
+Initially, JavaScript was an interpreted language, making the startup phase faster because the interpreter only needs to read the first instruction, translate it into bytecode and run it right away. For the 90’s internet needs, JavaScript did its job very well. The problem lies when applications start to be more complex.
+
+In the decade of 2000, technologies like Ajax made web applications been more dynamic, Gmail in 2004 and Google Maps in 2005 was a trending on this use case of Ajax technology. This new “way” of building web applications end up with more logic written on the client side. In 2008 with the appearance of Google and it’s engine V8 which compiled all JavaScript code into bytecode right away.
+
+In computing, just-in-time (JIT) compilation, also known as dynamic translation, is a way of executing computer code that involves compilation during execution of a program – at run time – rather than prior to execution.
+
+Most often this consists of source code or more commonly bytecode translation to machine code, which is then executed directly. A system implementing a JIT compiler typically continuously analyses the code being executed and identifies parts of the code where the speedup gained from compilation or recompilation would outweigh the overhead of compiling that code.
+
+In summary, the phases of JIT compiler could be described as:
+
+- Parse
+
+- Compile
+
+- Optimize/deoptimize
+
+- Execution
+
+- Garbage Collector
+
+The following is great example of JIT phases on V8 by Addy Osmani:
+
+![](https://cdn-images-1.medium.com/max/1600/1*N6eUu1Wy0xyu7dR54Pn5bQ.png)
+
+### The Profiler
+
+The Profiler is another entity to be observed, which monitors and collect code execution data. I’ll describe it in summary how it works, taking into account that are differences among browsers engines.
+
+At the first time, everything passes through the interpreter; this process guarantees that the code runs faster after AST is generated. When a piece of code is executed multiple times, as our getNextState() function, the interpreter loses his performance since it needs to interpret the same piece of code over and over again, when this happens, the profiler marks this piece of code as warm and baseline compiler comes to action.
+
+We will use the following snippet to illustrate how JIT works:
+
+```js
+function sum(x, y) {
+  return x + y;
+}
+[1, 2, 3, 4, 5, '6', 7, 8, 9, 10].reduce((prev, curr) => sum(prev, curr), 0);
+```
+
+When profiler marks a piece of code as warm, the JIT sends this code to the baseline compiler, which creates a stub for this part of code while the profiler keeps collecting data regarding the frequency and types used on this code section (among other data). When this code section is executed (on our hypothetical example return x + y;), the JIT only needs to take this compiled piece again. When a warm code is called several times in the same manner (like same types), it’s marked as hot.
+
+## Optimizer Compiler
+
+JIT 本身并不能带来必然的性能优化
+
+The optimizer compiler generates an even faster version of this code, which is marked as hot. It is only possible based on some assumptions that the optimizer compiler makes like the type of the variables or the shape of objects used in this code. On our example, we can say that a hot code of return x + y; will assume that both x and y are typed as anumber.
+
+The problem is when this code has been hit with something not expected by this optimized compiler, in our case the sum(15, '6') call, since y is a string. When this happens, the Profiler assumes that its assumptions were wrong throwing everything out returning to the base compiled (or interpreted) version again. This phase is called deoptimization. Sometimes this happens so often that it makes the optimized version slower than using the base compiled code.