ES5, ES2015 和 TypeScript 的區別

ES5，ES2015（原名 ES6 ）和 TypeScript 之間有什麼不同？我們應該學習和使用哪一個？

首先，讓我們為討論這些建立一個基礎。TypeScript 是 JavaScript 的超集。ES2015 是 ES5 的改進。知道關係可以讓我們更容易學習他們。

我們想要理解他們之間的差異，首先我們就必須理解他們為什麼存在。 我們從 ES5 開始。

ES5

我們大多數人已經用了 ES5 好多年了。函數語言程式設計在它這兒最棒，或者說最糟糕，這要取決於你如何看待它了。我個人喜愛用ES5程式設計。所有的現代瀏覽器都對它進行了支援。它極其靈活，但這也會產生很多能將應用推到坑裡的因素。作用於、閉包、IIFE以及良好的防禦式邏輯，這些對於確保我們的ES5程式碼不翻船都是必要的。儘管如此，其靈活性還是我們要依靠的一份力量。

這份圖表展示了當前瀏覽器對於ES5的相容程度。

 也許ES5給我們帶來的最大的問題就是在開發時定位問題的困難。ES5 因其複雜性而缺少工具，充其量就是有工具能解析如何檢查ES5的某些關鍵點。我們想要知道的是在另外一個檔案中的物件包含了哪些屬性, 一個函式中的一個無效引數可能是什麼, 或者讓我們知道在什麼時候我們在一個不正常的作用域裡面使用了一個變數。ES5 讓這些事情對於開發者和工具而言都困難了起來。

ES6/E2015 飛躍前進

ES2015 是從 ES5的一個巨大飛躍。它給JavaScript增加了大量的功能特性。這些功能特性解決一些問題，這些問題曾使得ES5程式設計成為一項挑戰。它們是可選的，因此我們可以在ES2015中繼續有效的使用 ES5 (包括函式)。

這裡所見是 Luke Hoban 提供的 ES2015的一些功能特性的參考。完整的列表可以在這份文件中檢視。 - arrows - classes -增強的物件文字 - 模板字串 - 析構 - default + rest + spread - let + const - 迭代器 + for..of - generators - unicode - 模組 - 模組載入器 - map + set + weakmap + weakset - 代理 - 符號 - 內建外掛式的可子類化 - 承諾 - math + number + string + array + 物件 API - 二進位制和八進位制文字 - 反射api - 尾呼叫

這是對於ES5的一個巨大飛躍，而現代的瀏覽器都在爭先實現所有的這些功能特性。這份圖表展示了瀏覽器當前對於ES2015的相容程度。

Node.js 是針對V8引擎的現代版本而構建的。根據其文件來看，Node 已經對 ES2015的許多東西進行了實現。

Node 4.x 給自己打上了 LTS 標籤，定位於長期支援的版本。 LTS 標籤顯示了他們的產品釋出規律。所有偶數的主版本專注於穩定性和安全性。所有奇數的主版本 (例如 5.x) 則歸入短期支援  (STS) 的版本, 專注於積極地擴充和更高頻率的更新。簡言之，我的建議是仍將node4用於生產環境的開發中，而將node5用於研究可能會在未來的LTS版本中存在的功能特性。你可以讀一讀這裡的《node版本官方指南》。

回到 ES2015, 現在我們已經擁有了數量驚人的功能可以選擇用來編寫程式碼。

開發者如何看待 ES2015?

我們也許想要知道誰可能會對ES2015感興趣，還有誰並不感興趣。許多的ES5都深諳這門語言的利弊。在JavaScript領域混跡了十多年以後，我們可能會感覺ES5用起來非常舒適。如果沒有明白其中的價值，一旦我們已經掌握了一門語言，要找個理由跳轉到一個新的版本就可能有點困難了。我們會得到什麼？我們要解決什麼問題呢? 這就是我們自然而然會生出的想法。一旦我們認定遷移到ES2015有利可圖, 那麼就會做出遷移的決定。

也有許多ES5開發者都等不及要使用 ES2015 了。關鍵是很多曾今使用ES5的人已經在用到ES2015了，而更多的人則仍然在決定中躑躅不前。

現如今 JavaScript 開發者有許許多多，而且還有更多人在進入這個領域。我認為現在正考慮學習JavaScript以及那些仍在在學習的人的數量，將會比目前正在使用它的人要少。 JavaScript 正處在發展之中，而並不是每個人都會有一個成熟的 ES5 開發背景。許多人都來自於Java和C#已經其它流行的語言和框架。這些的許多都已經擁有了 ES2015最近引入的功能特性，並且用了都好幾年了。這使得ES2015對於他們而言比起ES5來說更容易過渡。而現在也是個好時候，因為許多現代瀏覽器以及 Node 都在支援著ES2015。

因而我們有許多人，都擁有著不同的背景，卻都會走上 ES2015 (或者更高版本) 的遷移之路。

支援 ES5 的瀏覽器

我們如何才可以在還不支援ES2015的瀏覽器中執行ES2015? 我們可以使用像 Babel 這樣的工具，用 ES2015 編寫程式碼，然後將程式碼轉換成 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，我們所要享受的都是其多得有點過剩的固有功能或者可供我們選擇的工具擴充套件，是它們在幫助我們較快的寫出更好的程式碼。這些工具應該（而且能夠）對儘早識別出問題起到有所幫助。

當我們編寫程式碼時候，如果能馬上找到一個問題的話，就會更加有意思，於是我們就可以就地解決它 … 或者在早上5點鐘被叫醒，因為恰好在那時候觸發了我們隱藏的bug而導致業務中斷，生產環境爆出問題？5點那個時候我寧願跟我的家人待在一起 :)

今天的這些工具在試圖幫助我們識別問題，而它們的工作確實令人欽佩。不過如果我們可以給它們更多一點點的幫助會如何呢? 如果我們賦予它們跟今天其它像C#和Java這樣的語言相同的型別的幫助會如何呢? 那這些工具就確實能儘早而且頻繁的幫助我們識別出問題來。

這就是 TypeScript 的用武之地。

TypeScript 的價值並不在於編寫更少的程式碼，其價值在於編寫更加安全的程式碼。從長遠看來，它能幫助我們利用其工具識別問題並自動填充引數、屬性、函式以及更多東西（通常被成為自動補全和智慧感知），從而更有效率的編寫出程式碼。

你可以在其playground中體驗TypeScript。

ES+

我開玩笑說 TypeScript 應該被叫做 ES+, 而當我們更近一點觀察它的時候，還確實是這樣的。

那麼 TypeScript 在 ES2015 之外還提供了什麼呢? 我將專注於三個我所認為增加了最大價值的方面 :

1. 型別

2. 介面

3. 未來的 ES2016+ 特性 (比如註解/裝飾器以及非同步/等待)

TypeScript 就是 ES 機上像這樣的一些特性。

型別和介面對於提供那些需要在我們敲寫程式碼的時候就能識別出問題的功能有幫助。有了這些功能特性，編輯器就不需要去猜測我們是否在正常地使用一個函式。錯誤資訊對於工具而言足夠明確，足以讓它們向我們亮起紅燈，那樣我們就可以立即對問題進行修復。在某些情況下，這些工具也能在推薦和重構上幫助到我們！

TypeScript 有望成為前瞻性的思維。它有助於我們提前商榷未來ECMAScript中出現的功能特性。例如像裝飾器 (在 Angular 2 中有被用到) 以及非同步/等待 (一種可以讓C#中的非同步程式設計更加輕鬆的流行技術)這樣的技術。裝飾器現在在TypeScript中已經可以使用了，而據 《TypeScript路線圖》 非同步/等待很快就會在 2.0 版本中推出。

TypeScript 是否會偏離 JavaScript 的方向?

在 TypeScript 網站的頭版頁面 頂部，我們找到了這樣一條宣告:

TypeScript 是JavaScript 型別化子集，它會被編譯成原生的JavaScript。

這是非常重要的。TypeScript 並不是一種捷徑語言。它不會偏離 JavaScript，不會將我們帶去另外一個方向。它的目的是讓我們可以在今天就能使用到將會在未來的JavaScript版本中出現的功能特性, 並提供一個更好且更加安全的體驗。

為什麼不就使用 ES2015 得了?

這是一個很棒的選擇 ! 學習 ES2015 是從 ES5 的一個很大的進步。一旦你掌握了 ES2015, 我敢說從此 TypeScript 就是隻是非常小的一步。因此回頭我會建議，一旦你學習了 ES2015, 要嘗試一下 TypeScript 並利用好它的工具。

就業情況怎麼樣?

學些 ES2015 或者 TypeScript 會對我的就業產生不良影響嗎? 當然不會。不過這也並不意味著你不去理解ES5。今天 ES5 無所不在。不過它終有沒落的一天，但還有那麼多 ES5 在那兒，而理解這門語言對於理解ES2015和TypeScript幫助我們解決了什麼畢竟是有好處的。另外我們也能夠利用ES5的知識來使用瀏覽器中的原始碼對映對問題進行除錯。

緊跟新興技術的腳步

很長一段時間裡我們都不需要什麼轉譯器（transpiler）。Web使用的是JavaScript，而大多數編寫ES3和ES5的傢伙都在用jQuery來處理跨瀏覽器問題。當ES5到來時，並沒有發生太多的變化。多年來從事著 Web開發，我們已經擁有了一套穩定的大多數瀏覽器都能理解的JavaScript功能特性。如果哪裡出了問題，我們會使用想 es5-shim.js 甚至jQuery來處理它們。但時代在變。

Web的步伐現在很快。新的標準不斷湧向。像Angular 2, Rx.js, React, 以及 Aurelia 這樣的庫在推動這 Web向前發展。更多的開發者正在通過 web和Node.js進入JavaScript這個領域。

ECMAScript 團隊現在採納了一種新的命名方式，以年份作為標識，區分語言的版本。不會有ES6了，現在我們叫它ES2015。而下一個版本則被指向 ES2016。其意圖就是讓新的功能特性更加頻繁地加入到JavaScript中去。對於所有的瀏覽器而言，從桌面到移動端都採納這一套標準，是需要花點時間的。

整個這些意味著什麼呢? 正當我們擁有了支援ES2015的瀏覽器的時候， ES2016 可能就出來了。 如果沒有其它幫助，而我們又想要在所有的瀏覽器上都用上新的功能特性，就可能會有點可怕了! 除非我們有辦法可以利用今天的新的功能特性，並支援我們需要支援的瀏覽器。

這就是為甚轉譯器的出現在今天的Web領域如此重要的原因。TypeScript 和 Babel (轉譯領域的主要玩家) 都在其出現在瀏覽器之前就已經支援ES2015了。它們都計劃要支援(並且已經在某些情況下這樣做了) ES2016 的功能特性。這些工具就是我們如何一邊繼續向前推進，又不會把我們的客戶落下，這個問題的答案。

我們是如何反編譯（Transpile）的?

我們可以使用類似 Gulp，Grunt，WebPack，SystemJS 和 JSPM 這些工具反編譯成 Babel 或者 TypeScript。很多編輯器直接連線到這些任務為我們的程式碼進行反編譯。現在，很多 IDE 都支援通過點選一個按鈕自動化反編譯。我們甚至可以在命令列中使用 TypeScript，並可以檢視我們的檔案並進行反編譯。

總之，我們的程式碼都有很多種方式可以進行反編譯。

這意味著什麼

實際上，在技術上的改變會改變我們在職業上的選擇。有時候，技術上發生的改變遠遠快於我們的吸收速度。這就是為什麼工具是重要的，因為它可以幫助我們吸收，就像 TypeScript 和 Babel 之於 ES2015（更高版本）。在這個例子中，我們使用技術來跟上技術。這看起來像是一個悖論，但是它的核心就是要我們有效使用時間。

原文地址：https://johnpapa.net/es5-es2015-typescript/