你不知道的JavaScript（ES6與之將來）

時間 2019-11-05

標籤不知道 javascript es6 與之將來欄目 JavaScript 简体版

原文原文鏈接

你不知道的JS（下卷）ES6與之將來

第一章：ES的今與明

在你想深刻這本書以前，你應該對（在讀此書時）JavaScript的最近標準掌握熟練，也就是ES5（專業來講是ES 5.1）。在此，咱們決定全方面地談論關於將近的 ES6，同時預見JS將會怎樣發展。git

若是你對JavaScript不夠自信，我極力推薦你先讀一讀本系列的其餘話題：es6

入門與進階：你是編程和JS的菜鳥嗎？這部分是在你開始學習征途是須要的線路圖。github
做用域與閉包：你知道JS的詞法做用域是基於編譯器（不是解釋器）語義的嗎？你能解釋閉包是如何成爲詞法做用域和函數做爲值的直接結果的嗎？編程
this與對象原型：你能列舉this綁定的四個簡單原則嗎？你可曾在JS中用僞造「類」，而不是採起更簡單的「行爲委託」設計模式？你聽過 連接到其餘對象的對象（結鏈對象） （OOLO）嗎？設計模式
類型與語法：你瞭解過JS中的內置類型嗎？更關鍵是，你知道如何在類型之間正確且不出錯地使用強制轉換嗎？你還對JS語法/句法的毫釐之差感到心安嗎？promise
異步與性能：你還在使用回調函數處理你的異步性？你能說明promise是什麼而且爲什麼/如何解決了「回調地獄」的嗎？你知道如何使用generator來提高異步代碼的易讀性嗎？究竟是什麼構成了成熟優異的JS程序和獨立操做？瀏覽器

若是你已經讀過了這些話題而且對它們涵蓋的內容瞭然於胸，那此刻就讓咱們深刻JS的進化過程來探索已初露端倪和更遠的變化。閉包

與ES5不一樣，ES6不只僅往JavaScript這門語言添加一套新API。它包含了大量的新的語法形式，其中的一些你可能會花上點時間才能適應。還有幾種新的組織形式以及爲各類數據類型添加的新API helper方法。app

對這門語言來講ES6十分激進。就算你自覺得懂得ES5，ES6也盡是 你還未知曉 新東西，那就準備好！這本書囊括了ES6中你須要當即掌握的重要主題，更有甚者是能預見你應該能意識到將來方向。異步

警告： 本書中的全部代碼都模擬在ES6及以上的環境中運行。此次編寫，不一樣的瀏覽器和JS環境（好比Node.js）對ES6的支持可能不一樣，由此你經歷可能會豐富多樣。

版本

JavaScript標準官方名爲「ECMAScript」（縮寫爲「ES」），而且直到最近才徹底採用序列數來表示版本（例如，「5」表明「第五版」）。

最先的版本，ES1和ES2，並不廣爲人知曉和使用。ES3是JavaScript第一次普遍傳播的開端，而且構成了像IE6-8和早前的Android 2.x移動瀏覽器的JavaScript標準。因爲一些超出咱們討論範圍的政治緣由，不幸的的ES4沒有出現。

在2009年，ES5正式定稿（以後是2011年的ES5.1），它在瀏覽器的現代革命和爆發性增加（好比Firefox，Chrome，Opera，Safari，和其餘許多瀏覽器）中普遍傳播，並做爲JS標準肯定下來。

展望下一個版本的JS（從2013年過渡到2014年和以後的2015年），在討論中顯而易見的是ES6。

然而，臨近ES6規範發佈時，有建議說起將來的版本號切換爲編年制，好比用ES2016（同ES7）來指代在2016年底前被定稿的全部版本。有些人對此否認，相對於後來的ES2015來講，ES6更可能繼續保持優點。然而，事實上ES2016可能預兆了新的編年制（將被使用）。

還能夠觀察出JS進化的頻率即便與一年一度爲定版相比都要快得多。只要一個想法開始標準化討論的進程，瀏覽器就開始爲這種特性構建原型，並且早期的採用者就開始在代碼中進行實驗。

一般在一個特性被官方認可以前，這些早期的引擎/工具的原型已經被標準化了。由此也能夠認爲將來的JS版本將是一個特性一個特性的更新，而非一組主要特性的隨意集合的更新（就像如今這樣），也不是每一年更新（像可能將變成的那樣）。

總得來講就是版本號再也不那麼重要了，JavaScript開始變得更像一個萬古長青的活標準。對待它的最佳方法是再也不「基於ES6」來思考你的代碼，而是按它支持的特性考慮。

轉譯

特性的快速演變，給開發者們促使一個原本存在的問題惡化，他們熱衷於當即使用新特性，而同時被被現實打臉，他們的網站/app須要支持那些不支持這些特性的老版本瀏覽器。

在整個行業中ES5的方式彷佛已經無力迴天了，它典型的思惟模式是，代碼庫會等至幾乎全部的前ES5環境不能支持它們以後纔開始採用ES5。其結果，就是許多人最近（在本書寫做時）纔開始採用strict模式這樣的東西，而它早在五年前就在ES5中定稿了。

業界廣泛認爲，等待和落後於語言規範那麼多年，對JS生態系統是有害的。全部負責推進語言進化的人都期待這樣的事情；只要新的特性和模式以規範的形式穩定下來，而且瀏覽器有機會實現它們，開發者就開始基於這些新的特性和模式進行編碼。

那麼咱們如何解決這個看似矛盾的問題呢？答案是工具化，特別是一種稱爲 轉譯（transpiling） 的技術（轉換+編譯）。大體上，它的理念是使用一種特殊的工具將你的ES6代碼轉換爲能夠在ES5環境中運行的等價物（甚至更近似的！）。

舉個栗子TvT，想想簡寫屬性定義（見第二章的「對象字面量擴展」）。如下是ES6的形式：

var foo = [1,2,3];

var obj = {
    foo        // 意指 `foo: foo`
};

obj.foo;       // [1,2,3]

這（大體）是它如何轉譯的：

var foo = [1,2,3];

var obj = {
    foo: foo
};

obj.foo;    // [1,2,3]

這是一個小而愉悅的轉換，（由於）它讓咱們在一個對象字面量聲明中將foo: foo簡寫爲foo，若是名稱（屬性名和屬性值）相同的話。

轉譯器爲你執行這些轉換，這個過程一般是構建工做流的一個步驟，這和你使用linting（檢查代碼），壓縮等其餘相似操做一模一樣。

Shim庫/Polyfill庫

不是全部的ES6新特性都須要轉譯器。可行的話，Polyfill（也叫shims）是一種模板，它爲從一個新點的環境到舊點的環境中定義等效行爲。語法不能被填補，可是API每每能夠。

比方說，Object.is(..)是一個用來檢查兩個值嚴格等價性的新功能，它不包括===對於NaN和-0值的那種微小差別的例外。爲Object.is(..)使用Polyfill至關簡單：

if (!Object.is) {
    Object.is = function(v1, v2) {
        // 檢查 `-0`
        if (v1 === 0 && v2 === 0) {
            return 1 / v1 === 1 / v2;
        }
        // 檢查 `NaN`
        if (v1 !== v1) {
            return v2 !== v2;
        }
        // 其餘的全部狀況
        return v1 === v2;
    };
}

提示：注意外層的if語句包圍了填補（polyfill）的內容。這是一個重要的細節，它意味着這段代碼段僅僅爲了在考慮中的API還未被定義的老環境而定義的應變行爲；你想要重寫API的狀況少之又少。

這有一個被稱爲「ES6 Shim」（https://github.com/paulmillr/...）的很棒的ES6填補（ES6 shim庫）合集，你絕對會在全部新JS項目中把它做爲標準組成部分來採用！

看起來JS將會維持持續發展（狀態），同時瀏覽器也會持續地推出來支持新特性，而不是洪水般地更新。因此現代化的最佳策略就是在你的代碼庫中引入填補（polyfill庫），並在你的構建流程中引入轉譯步驟，如今就開始習慣新的現實。

若是你決定保持現狀，等到全部不支持新特性的瀏覽器都消失纔開始使用新特性，那麼你將一直落後於時代。你將遺憾地錯過爲使編寫JavaScript更有效，更高效，並且更健壯而設計的改革。