[Localization] Translations of files in locale\zh-cn\docs

locale/zh-cn/docs/es6.md

@@ -0,0 +1,45 @@
+---
+title: ECMAScript 2015 (ES6) 以及未来展望
+layout: docs.hbs
+---
+# ECMAScript 2015 (ES6) 以及未来展望
+
+Node.js 不是为 [V8](https://developers.google.com/v8/) 引擎构建的。为了与此引擎保持实时更新，我们确保来源于 [JavaScript ECMA-262 specification](http://www.ecma-international.org/publications/standards/Ecma-262.htm) 的新功将被及时地给予 Node.js 开发者们，同时继续包含性能以及稳定性上的更新。
+
+所有的 ECMAScript 2015 (ES6) 功能将被分为三个部分 **shipping**，**staged** 和 **in progress**：
+
+* 所有 **shipping**：在 V8 引擎中认为是稳定的，转变成 **Node.js 默认**，并且 **不会** 需要任何运行时标记。
+* **Staged**：这些是将要完成的特性，并且在 V8 团队看来并不一定稳定，需要一个 `--harmony` 标记。
+* **In progress**：这些特性可以通过各自单独的 harmony 标记被激活使用。除非为了测试用途，否则绝不鼓励这样做。值得注意的是这些标记是借由 V8 引擎公开，将来或许会有潜在的变化而不会有任何免责声明或者协议。
+
+## 默认情况下什么特性随着 Node.js一起发布？
+
+[node.green](http://node.green) 提供了非常完整、几乎涵盖了不同版本的 Node.js 中所支持的 ECMAScript 特性。它基于 kangax 的兼容性对照表构建。
+
+## 有哪些特性在开发中？
+
+新特性源源不断地被加入 V8 引擎。一般说来，虽然具体的时间未知，但我们总希望他们将来在 Node.js 中有所体现。
+
+在每个 Node.js 发布版中，你可以通过 greeping 配上 `--v8-options` 参数罗列出全部处于 *in progress* 状态的特性功能。请注意：他们尚未完成，可能因为 V8 引擎自带的功能而夭折。所以使用这些特性时会冒风险。
+
+```bash
+node --v8-options | grep "in progress"
+```
+
+## 对于一个特定的功能，它的特性又如何呢？
+
+V8 团队现正在努力持续工作，他们借助 EcmaScript 5 或是更早时代的语言规范，利用转译或是本地相当的技术以提高新语言的功能特性，使之达到平衡。目前研发进度记录可以在 [six-speed](https://fhinkel.github.io/six-speed) 查询到，它会告诉你 ES2015 和 ESNext 的性能究竟如何（和本地的 ES5 同等技术相比）。
+
+特性优化的工作也随着 ES2015 到来，以上计划是通过 [执行计划](https://docs.google.com/document/d/1EA9EbfnydAmmU_lM8R_uEMQ-U_v4l9zulePSBkeYWmY)，有一个 V8 团队在那儿收集整理相关信息，并协调需要提高性能、设计追踪问题的文稿等部门。
+
+## 我有我自己的基本框架，可以利用 --harmony，所以我可以移除这个标记吗？
+
+目前来说，`--harmony` 在 Node.js 的作用是让 **staged** 特性起作用。它本质上等同于 `--es_staging`。如上所述，有些特性尚未完全确认是稳定的，所以如果你希望一个安全的环境（尤其是在发布环境），你应该考虑移除这个运行时的环境标记，直到它在 V8 中以默认形式发布，或者在 Node.js 中落地。如果你开启了这个开关，你应该有对未来 Node.js 升级而造成代码破坏（无法正常工作）的准备，比如 V8 引擎做了更改，它的语法变得更接近标准。
+
+## 我怎么知道某个特定版本的 Node.js 发布是随着哪个版本的 V8 引擎呢？
+
+Node.js 提供了一个简单的方法以列出所有依赖项，以及通过 `process` 全局对象，借助特定的二进制包发布的不同版本。由于是 V8 引擎，在你的终端输入以下命令就可以获取相关版本号：
+
+```bash
+node -p process.versions.v8
+```

locale/zh-cn/docs/guides/blocking-vs-non-blocking.md

@@ -0,0 +1,106 @@
+---
+title: 阻塞对比非阻塞一览
+layout: docs.hbs
+---
+
+# 阻塞对比非阻塞一览
+
+本概论涵盖了在 Node.js 中 **阻塞** and **非阻塞** 的区别，同时也会牵涉到时间轮询和 libuv 方面，不需要先行了解这些方面的知识也可以继续阅读。我们假定读者对于 JavaScript 语言和 Node.js 的回调机制有一个基本的了解。
+
+> "I/O" 指的是系统磁盘和由 [libuv](http://libuv.org/) 支持的网络之间的交互。
+
+## 阻塞
+
+**阻塞** 是说 Node.js 中其它的 JavaScript 命令必须等到一个非 JavaScript 操作完成之后才可以执行。这是因为当 **阻塞** 发生时，事件机制无法继续运行JavaScript。
+
+在 Node.js 中，JavaScript由于 CPU 密集操作而表现不佳。而不是等待非 JavaScript操作 （例如I/O）。这被称为 **阻塞**。在 Node.js 基本类库中，使用 libuv 的同步方法大多数都是 **阻塞** 的。原生方法也可能是 **阻塞** 的。
+
+所有在 Node.js 中提供的 I/O 方法也包括异步版本，它们都是 **非阻塞** 的，接受回调函数。一些方法同时也具备 **阻塞** 功能，它们的名字结尾都以 `Sync` 结尾。
+
+
+## 代码比较
+
+**阻塞** 方法执行起来是 **同步地**，但是 **非阻塞** 方法执行起来是 **异步地**。
+如果你使用文件系统模块读取一个文件，同步方法看上去如下：
+
+```js
+const fs = require('fs');
+const data = fs.readFileSync('/file.md'); // blocks here until file is read
+```
+
+这是一个与之功能等同的 **异步** 版本示例：
+
+```js
+const fs = require('fs');
+fs.readFile('/file.md', (err, data) => {
+  if (err) throw err;
+});
+```
+
+第一个示例看上去比第二个似乎简单些，但是有一个缺陷：第二行语句会 **阻塞** 其它 JavaScript 语句的执行直到整个文件全部读取完毕。注意在同步版本的代码中，任何异常都会抛出，会导致整个程序崩溃。在异步版本示例代码中，它由作者来决定是否抛出异常。
+
+让我们扩展一点我们的同步代码：
+
+```js
+const fs = require('fs');
+const data = fs.readFileSync('/file.md'); // blocks here until file is read
+console.log(data);
+// moreWork(); will run after console.log
+```
+
+这是一个类似的，但是功能上不等同的异步代码示例版本：
+
+```js
+const fs = require('fs');
+fs.readFile('/file.md', (err, data) => {
+  if (err) throw err;
+  console.log(data);
+});
+// moreWork(); will run before console.log
+```
+
+第一个示例代码中， `console.log` 将在 `moreWork()` 之前被调用。在第二个例子中， `fs.readFile()` 因为是 **非阻塞** 的，所以 JavaScript 会继续执行， `moreWork()` 将被首先调用。`moreWork()` 无需等待文件读完而先行执行完毕，这对于高效吞吐来说是一个绝佳的设计。
+
+
+## 并行和吞吐
+
+在 Node.js 中 JavaScript 的执行是单线程的，所以并行与事件轮询能力（即在完成其它任务之后处理 JavaScript 回调函数的能力）有关。任何一个企图以并行的方式运行的代码必须让事件轮询机制以非 JavaScript 操作来运行，像 I/O 操作。
+
+举个例子，让我们思考一个案例：案例中每个对服务器的请求消耗 50 毫秒完成，其中的 45 毫秒又是可以通过异步操作而完成的数据库操作。选择 **非阻塞** 操作可以释放那 45 毫秒用以处理其它的请求操作。这是在选择 **阻塞** 和 **非阻塞** 方法上的重大区别。
+
+Node.js 中的事件轮询机制和其它语言相比而言有区别，其它语言需要创建线程来处理并行任务。
+
+
+## 把阻塞和非阻塞代码混在一起写的危险
+
+在处理 I/O 问题时，有些东西必须避免。下面让我们看一个例子：
+
+```js
+const fs = require('fs');
+fs.readFile('/file.md', (err, data) => {
+  if (err) throw err;
+  console.log(data);
+});
+fs.unlinkSync('/file.md');
+```
+
+在以上的例子中， `fs.unlinkSync()` 极有可能在 `fs.readFile()` 之前执行，所以在真正准备开始读取文件前此文件就已经被删除了。一个更好的处理方法就是彻底让使它变得 **非阻塞化**，并且保证按照正确顺序执行：
+
+```js
+const fs = require('fs');
+fs.readFile('/file.md', (readFileErr, data) => {
+  if (readFileErr) throw readFileErr;
+  console.log(data);
+  fs.unlink('/file.md', (unlinkErr) => {
+    if (unlinkErr) throw unlinkErr;
+  });
+});
+```
+
+以上代码在 `fs.readFile()` 用异步方式调用 `fs.unlink()`，这就保证了执行顺序的正确。
+
+
+## 其它资料
+
+- [libuv](http://libuv.org/)
+- [关于 Node.js](https://nodejs.org/en/about/)