理解 ES5, ES2015（ES6） 和 TypeScript

理解 ES5, ES2015（ES6） 和 TypeScript

本文轉載自：衆成翻譯
譯者：kayson
鏈接：http://www.zcfy.cc/article/1332
原文：https://johnpapa.net/es5-es2015-typescript/

ES5, ES2015 (以前叫做 ES6)和 TypeScript 之間的區別是什麼？我們應該學習和使用哪一個？

首先，讓我們爲討論這些語言建立一個基礎。TypeScript 是 JavaScript 的超集。 ES2015 是 ES5 的演進。這種關係讓逐步學習它們變得容易些。

我們想理解它們之間的區別，但首先我們得知道它們是什麼以及爲什麼存在。我們從 ES5 開始。

ES5

ES5 是我們大部分人用了很多年的語言。它的函數式編程特性非常好，或者說非常糟糕，取決於你怎麼看它。 我個人喜歡用 ES5 編程。所有現代瀏覽器都支持它。它極度靈活，卻也有着許多會導致應用程序崩潰的因素。爲了保證我們的程序在IE5下不偏離正軌，我們需要作用域、閉包、立即執行的函數以及良好的邏輯。 儘管如此，它的靈活性也是我們大多數人依賴的一個優勢。

這個 圖顯示了當前瀏覽器對 ES5 的兼容性。.

或許 ES5 帶給我們的最困難的問題是如何在開發階段發現問題。ES5 工具很缺乏，因爲對工具來說檢查 ES5 太複雜了。我們想知道另一個文件裏的對象包含哪些屬性，函數的無效參數可能是什麼，或者讓我們知道是否在錯誤的作用域裏使用了變量。ES5 讓開發人員和工具做這些事變得困難。

ES6/ES2015 的飛躍

ES2015 是 ES5 的巨大飛躍。它給 JavaScript 增加了非常多的特性。這些特性解決了 ES5 編程的一些挑戰性問題。它們是可選的，因爲我們依然可以在 ES2015 裏使用 ES5 （包括函數）。

這裏是 ES2015 的一些特性，見諸 Luke Hoban 的參考文檔。完整的列表可以在spec 裏找到。 - 箭頭函數 - 類型 - 增強的對象字面量 - 模板字符串 - 解構 - 默認參數 + 剩餘參數 + 展開 - let + const - iterators + for..of - generators - unicode - modules - module loaders - map + set + weakmap + weakset - proxies - symbols - subclassable built-ins - promises - math + number + string + array + object APIs - binary and octal literals - reflect api - tail calls

這是 ES5 戲劇性的飛躍，現代瀏覽器也競相實現所有的特性。這張 圖展示了當前瀏覽器對 ES2015 的兼容性。

Node.js 是基於現代版本的 V8 引擎構建的。Node 已經實現了 ES2015 的很多特性，根據它的文檔。

Node 4.x 給自己打上了長期支持 (LTS) 的標籤。LTS 標籤表明了他們的發佈線路。所有的偶數主版本號集中於穩定性和安全性。所有的奇數主版本號（例如 5.x）是短期支持（STS）， 主要集中於活躍的開發和更頻繁的更新。簡言之， 我建議你產品開發用 node 4， 而未來的特性研究使用 node 5。你可以查看官方的 node 版本指南.

回到 ES2015， 我們現在擁有了難以置信的大量的特性可以在代碼裏使用。

開發者怎麼看 ES2015？

我們可能想知道誰對 ES2015 感興趣，誰不感興趣。有很多 ES5 開發者已經很清楚這門語言的利弊了。使用 JavaScript 超過十年了， 我們可能對 ES5 感覺良好了。 一旦我們掌握了一門語言，就很難接受跳躍到新的版本，如果我們看不到價值所在的話。我們獲得了什麼？我們解決了什麼問題？這是很自然的思路。一旦我們確定轉向 ES2015 是有價值的，那我們就會決定走這一步。

也有很多 ES5 開發者迫不及待地想用 ES2015 了。關鍵在於很多用過 ES5 的人已經在用 ES2015 了，而更多的人仍然在考慮是否遷移。

現在已經有很多 JavaScript 開發者了，但將來會更多。我相信現在正考慮學習 JavaScript 的人比正在使用 JavaScript 的人更多。JavaScript 在成長，並不是每個人都有堅實的的 ES5 背景。有些人是從 Java 和 C# 以及其他流行的語言和框架轉過來的。他們當中的很多人已經接觸過 ES2015 最近引入的特性了，而且接觸了好幾年了。這讓他們轉換到 ES2015 比 ES 更容易。並且這個時間點也很好，因爲很多現代瀏覽器和 Node 都支持 ES2015.

所以我們當中的很多人，看法各異，但都在向 ES2015（或更高）遷移。

支持 ES5 瀏覽器

我們怎樣在還不支持 ES2015 的瀏覽器上運行 ES2015？ 我們可以使用 ES2015， 然後用Babel 之類的工具轉換成 ES5。Babel 讓書寫 ES2015（還有未來的 ES2016 或更高）變得容易，仍然會編譯成更舊版本的 JavaScript。非常酷！

TypeScript

什麼地方該用 TypeScript ？ 我們到底需不需要它？

首先，我認爲它的名字就把人們嚇跑了。TypeScript 中的 Type 一詞表明我們現在有類型了。這些類型是可選的，因此我們不是必須用它們。不相信？試着粘貼你的 ES5 代碼到 TypeScript playground。媽咪快看！不需要類型耶！那麼我們是不是可以叫它 Type?Script_ 或者 [Type]Script ？ 玩笑歸玩笑，類型只是 TypeScript 的一小部分。或許更好的名字是 ES+。

讓我們回頭看看我之前提到的很多開發者在寫 JavaScript 代碼碰到的問題：難以在開發階段發現錯誤。

如果我們可以在輸入的時候發現作用域問題會怎樣？如果我們可以在工具裏用紅色下劃線標出不匹配的參數會怎樣？ 如果我們的編輯器和 IDE 可以在我們不正確地使用別人或自己的代碼時告訴我們，又會怎樣？這就是我們通常依賴工具的地方。

儘早發現問題

不管我們在用 Atom, VS Code, Visual Studio, Web Storm, 或者 Sublime Text，我們享受着工具的自帶功能或擴展程序，幫助我們更快地寫出更好的代碼。這寫工具應該（也能夠）幫助我們儘早地發現問題。

在寫代碼的時候立即發現問題，我們就可當即解決它，這樣不是更好玩嗎？或者因爲我們的 app 流量增加觸發了隱藏的bug導致產品崩潰，早上5點被打電話通知？我更喜歡在5點的時候在家陪家人 :)

今天這些工具在盡全力幫助我們發現問題，並且它們在這方面做得非常不錯。但是如果我們給它們更多點的幫助會怎樣？如果我們給它們提供像其他語言比如 C# 和 Java 同樣類型的幫助會怎樣？那麼這些工具確實可以更早、更多地幫助我們發現問題。

這就是 TypeScript 閃光的地方。

TypeScript 的價值不在於寫更少的代碼。TypeScript 的價值在於寫更安全的代碼。長遠地看，它幫助我們更高效地編碼，因爲我們利用了工具來發現問題，以及自動填充參數、屬性、函數和更多（通常被稱爲自動完成和智能感知）。

你可以 在這嘗試 TypeScript.

ES+

我開玩笑說 TypeScript 應該被叫做 ES+，但當我們更進一步探究它時，還真是這麼回事。

那麼 TypeScript 比 ES2015 更好的地方在哪？我會集中在我覺得增加了最多價值的三個主要方面：

1. 類型
2. 接口
3. 未來的 ES2016+ 特性 (比如 Annotations/Decorators and async/await)

_TypeScript 是 ES 加上如下的特性：

類型和接口幫助提供它需要的工具，以便在我們輸入的時候發現問題。有了這些特性，我們的編輯器就不必要猜測我們是否正確地使用了某個函數。工具有了這個信息，就很容易顯示一個紅旗，我們就可以馬上解決問題。在有些情況下，這些工具也可以給我們推薦，幫我們重構！

TypeScript 承諾了前瞻思維。它把未來 ECMAScript 規範商定的特性在今天帶給我們。例如 decorators ( Angular 2 中用到了) 和 async/await (C# 中讓異步編程變得更容易的一項流行技術)這樣的特性。Decorators 在 TypeScript 中已經有了，而 async/await 很快會出現在 2.0 版本里，據 TypeScript 路線圖。

TypeScript 偏離了 JavaScript 了嗎？

在 TypeScript 網站的首頁的頂部，我們發現了這樣的聲明：

TypeScript 是類型化的 JavaScript 超集，可以編譯成普通的 JavaScript。

這個非常重要。TypeScript 不是快捷方式語言。它並沒有偏離 JavaScript。它沒有把我們帶到另外的方向去。它的目的是允許我們現在使用將來版本的 JavaScript 特性，並提供更好、更安全的體驗。

爲什麼不直接用 ES2015 呢？

那是個不錯的選擇！學習 ES2015 是 ES5 的巨大飛躍。一旦你掌握了 ES2015，我保證再學 TypeScript就是小菜一碟。所以我再次建議，一旦你學了 ES2015，嘗試下 TypeScript 並利用好它的工具。

就業力怎麼樣？

學習 ES2015 或者 TypeScript 會損害我的就業力嗎？ 絕對不會。但這並不意味着你不該理解 ES5。如今 ES5 無處不在。這種情況最終會減緩，但已經存在很多 ES5 代碼，而且理解這門語言也有利於做技術支持和理解 ES2015 和 TypeScript 解決了什麼問題。另外我們可以利用 ES5 知識幫助我們在瀏覽器裏藉助 sourcemap 調試問題。

跟上新興技術的腳步

很長一段時間我們不需要轉換器。Web 使用 JavaScript，很多寫 ES3 和 ES5 的人使用 jQuery 處理跨瀏覽器問題。ES5 出現的時候，並沒有多大改觀。很多年來，在 Web 開發領域我們有大部分瀏覽器都理解的一套穩定的 JavaScript 特性。在有問題的地方，我們利用 es5-shim.js 之類的東西和 jQuery 做變通處理。一切都變了。

Web 在快速發展。新的 Web 標準在浮現。Angular 2, Rx.js, React 和 Aurelia 之類的庫在推進 Web。更多的開發者通過 web 和 Node.js 轉向 JavaScript。

ECMAScript 團隊現在採用年份作爲標識來命名語言版本。不再叫 ES6，現在我們叫它 ES2015。下個版本會定爲 ES2016。這麼做的目的是爲了更頻繁地增加 JavaScript 新特性。桌面和移動設備的所有瀏覽器採納標準尚需時日。

這一切意味着什麼？ 就是當我們的瀏覽器支持 ES2015 的時候，ES2016 又出來了。沒有幫助的話，如果我們要支持無所不在的瀏覽器使用新特性，將會變得很糟糕。除非我們有一種方式去使用新特性並支持我們需要的瀏覽器。

這就是爲什麼在當今的 Web 轉換器的出現變得如此重要的原因。TypeScript 和 Babel (主要的轉換器) 都在瀏覽器之前支持 ES2015。它們都計劃支持（在一些案例下已經實現）ES2016 特性。這些工具回答了我們如何在前進的同時不丟下客戶的問題。

我們如何轉換？

我們可以利用 Gulp、Grunt、WebPack 和帶 JSPM 的 SystemJS 使用 Babel 或 TypeScript 來轉換。很多編輯器可以直接連接到這些任務，在我們編碼的時候轉換。現在很多 IDE 支持一鍵自動轉換。我們甚至可以通過命令行使用 TypeScript 監聽文件變化，實時轉換。

無論我們如何寫代碼、在哪寫代碼，都有很多方式轉換。

這一切的意義是什麼

我們選擇的職業的一個事實是：技術在變化。技術在發展。有時候技術的發展速度超過了我們吸收的速度。這就是爲什麼要利用 TypeScript 和 ES2015（以及更高） 版 Babel之類的工具幫助我們吸收和適應這些變化的原因。這裏我們是利用技術趕上技術。看上去像悖論，但本質上只是更有效地利用時間趕上技術的腳步。