ECMAScript 6 會重蹈 ECMAScript 4 的覆轍嗎？

01-12

都說ES4是步子跨得太大，結果瀏覽器廠商不願支持。而ES6現在幾乎引進了ES4當時爭議的每一個組件：模塊，類及其繼承。ES6會重蹈ES4的繼承么？還是說由於業界的變化，這些組件又變得可以接受了？如果是這樣，那麼業界心態的分歧點是哪裡？
註：原提問者不是前端從業人員，上面有些問題可能存在用語不當或者揣摩不當，歡迎修改這些地方，但請保留問題的主體。

ES4 的故事相當複雜... 我一時八卦心起整理了一下：

當年的 TC39 還叫 TC39-TG1
2005 年開始弄 ES4 的主要是 Brendan Eich 和開發了 AS3 的 macromedia（後來是收購 macromedia 的 Adobe）
M$ 和 Yahoo（主要是 Douglas Crockford）一開始是表示合作的
2007 年，BE 和 Adobe 已經在 ES4 上花了兩年時間，但 M$ 和 DC 突然表示覺得 ES4 太過龐大，並添加了太多他們不想要的東西。這裡具體的理由我們無從得知，只能做一些揣測：DC 的龜毛大家都知道的，從 JavaScript: The Good Parts 就可以看出他的偏好和 ES4 出入很大。M$ 在 ES4 的制定過程中並沒有積极參与，可能是因為與會的 Pratap Lakshman 和上層的溝通不足，然後某天跟上層一彙報，上層覺得 ES4 和 ES3 差別過大，實現起來難度大，而且會導致他們喪失對規範的控制權，所以突然就決定抵制 ES4 了。
2007 年 4月，DC 和 M$ 開始平行起草另一個提案，一開始叫 ES3.1，也就是後來的 ES5，整體上是一個更為保守、漸進的提案。當時 TG-1 內部對 3.1 的定位有疑問，但允許了其存在。
BE 對 ES4 的前景感到擔憂，2007 年 10 月發布了 ES4 提案預覽。M$ 和 DC 認為 BE 操之過急，發表了一些負面評論，雙方鬧翻。BE 對 M$ 的行為非常光火，並且認為 M$ 在背地裡運作引導業界輿論反對 ES4。
ES4 難產，與此同時，隨著 ajax 概念的提出，業界開始冒出各種 js 庫，對 js 工程化開始進行初步的探索。
2009 年，各方最終同意將 ES3.1 改為 ES5 並正式發布。同時，開始進行下一個版本的規範 Harmony/ES6 的起草。

--- 歷史的分割線 ---

時至今天，我們會發現 ES6 的業界環境和 ES4 有很多不同：

當年反對 ES4 的 M$/Yahoo 話語權已今不如昔，而且本身的態度也已經改變。IE 的市場份額持續下跌，在實現上也已長期處於追趕而非當年引領的地位。Yahoo 在互聯網界的地位一落千丈，DC 在 TC39 也不像當年那麼活躍。
Google 伴隨著 Chrome 飆升的佔有率，以及靠著 web 發家的背景強勢加入 TC39，現在可能是最有話語權也是最積極的玩家，因為推動 web 這個平台和 Google 本身的市場空間直接相關。
整體上 web 前端應用化、工程化的趨勢不可逆轉，對於支持工程化的語言特性需求也確實比當年高。隨著 Node.js 的爆發，JS 在後端的需求增長的同時也開始暴露出語言本身對大型工程的不足。根本上來講，就是 ES4 的時候業界對 js 工程化的需求沒有那麼高，所以 ES4 那些考量受眾不足。
當年 ES4 未能發布的一個原因是步子過大的同時，沒有有效的對新特性進行實踐考驗的方法。這一點在今天藉助各類 transpiler 得以實現。比如 CoffeeScript 的一些特性大家用了都說好，那麼 TC39 就可以放心地採用到 ES6 當中。TypeScript 的 class 大家用著覺得不錯，那麼也可以採用。同理，業界對模塊化的探索比如 AMD 和 CommonJS 也對 ES6 module 的最終定稿有著巨大的影響。簡言之就是沒有實踐的檢驗你很難光靠嘴巴說服所有人。

綜上，個人認為 ES6 不太可能會重蹈 ES4 的覆轍（目前的計劃發布時間是 2015 年 6 月）

---

References:

The Story Behind ES4

A Short History of JavaScript

meetings:minutes_mar_21_2007 [ES Wiki]

meetings:minutes_sep_27_2007 [ES Wiki]

Brendan Eich

The Only Thing We Have To Fear Is Premature Standardization

完全贊同 @尤雨溪的答案。補充幾點：

1. ES3之後的JS語言進化的嘗試很早就開始了，同時有若干個方案，有具體實現的包括http://JScript.NET、ActionScript 3等。但作為ES4/JS2而為人所知的，是Mozilla的草案。草案本身不是BE寫的，而是Waldemar Horwat。對這個草案到現在我還留有深刻印象的一個有趣特性就是基於namespace的API version。

2. 2005年開始重啟ES4/JS2，實際上拋棄了Mozilla的草案，而轉而以ActionScript 3為基礎，當時Mozilla和Adobe走得很近，Adobe還開源了自己的VM送給Mozilla。這草案在某些方面比現在的ES6要走得更遠，比如有相當強大的類型系統，支持泛型、nullable、interface、union type等——當然從現在的趨勢看，ES7或ES8早晚會加入這些東西。這草案也繼承了老的Mozilla JS2草案中的一些特性。比如前面提到的namespace——這特性與C++/C#中的namespace不同，我理解更接近某種弱化的annotation，比如public/private是以內置namespace實現的。

3. ES4被幹掉我個人覺得很大程度上是「政治」原因而非技術原因。注意本段均為帶有強烈個人觀點的陰謀論敘述。事情發生變化就是起於Macromedia被Adobe收購。當時Flash平台如日中天，Adobe收購MM之後一下子成為了足以和微軟對抗的巨頭——既有壟斷性平台，又有極其完整的涵蓋從設計到開發所有工具的產品線。現在連Web唯一的開發語言都要以AS3為底本了！這個時候，攪屎棍DC出現了。他作為Yahoo!這個落後生產力的公司代表的個人代表，以其技術偏見為由，私下找到微軟密謀。微軟正愁如何對付Adobe，這下一拍即合，當即由DC為主炮製了ES 3.1出來跟ES4分庭抗禮，為此連自家的http://JScript.NET也做了炮灰。另一方面，自大的Adobe卻似乎在夢遊，除了傻兮兮的拿ES4作為廣告標籤來宣傳自己的AS3（當然後來被叫停，但也已造成社區對其的不滿），在ECMA TC39中卻聽不到它們的聲音——我一直都沒搞清在ECMA TC39中誰是Adobe的代表。在關鍵公司中，Google當時還沒有進入此領域（V8是2008年開始的），Apple還處在復興前夜（iPhone是2007年發布的，WebKit在2005年剛剛開源），Opera從來就沒有什麼話語權，Adobe在夢遊……網站方面，今天引領Web開發的Facebook和Twitter當時不知道在幹什麼，唯一代表Yahoo!就那個德行。在開發者社區這裡，當時Node還沒出現（2009年），JS語言社區主要都是缺乏語言設計和大型編程經驗的網頁開發者，水平低、容易忽悠。總之，能決定JS未來的，只有Mozilla和Microsoft，或者說只有微軟——因為此時Microsoft在瀏覽器相關領域仍然具有壟斷話語權。於是，DC狐假虎威，BE孤掌難鳴，後來發生的事情就像 @尤雨溪描述的那樣了。

4. 客觀的說，ES5除了從ES4中吸收的get/set之外，都只是小小的補丁，就這麼些東西，折騰了好幾年，實在是作死的節奏，極端讓人失望。要不是Node橫空出世和Web App大爆發，JavaScript的前景還真是一片灰暗。

5. 我還是很敬佩BE的。雖然他被DC擺了一道，讓整個語言發展大開倒車，當時連我都覺得不能忍，但是他還是找到了妥協（Harmony）的道路。ES3.1改名為ES5其實有僭越（就這麼點東西好意思叫ES5？），但是也為ES6鋪平了道路。ES4草案中還是有相當數量的特性最終被ES6繼承了。包括 let、destructuring assign、generator 等。另一些特性則以更好的方式重生，如 ES6 module 之於 ES4 package，ES6 Symbol 之於 ES4 namespace 等。其他那些特性如 array comprehensions、運算符重載、decimal類型等，無論會不會在未來加入，自ES6開始的語言進化的道路已經確定，不再是攪屎棍或某個公司所能阻礙的了。

個人對ES4的狀況表示遺憾，惋惜。

在我看來，ES4可以算是一次較好的改進，能夠滿足較大規模的開發需要，但可惜的就是步子邁太大了，遭受的反對過多。

這一陣我也思考了這些問題，因為還是有很多人不支持ES6的改進，覺得把本來很簡單的JS搞複雜了，沒有必要。我覺得這個問題的分歧點在哪裡呢，在於雖然大家都是做Web前端開發，都是在瀏覽器里寫東西，但產品形態差距太大。

我能夠想到，是哪些人希望JS加上類、模塊、類型，又是哪些人覺得不改就挺好。前一種多半是做Web應用的，也就是在瀏覽器中開發「軟體」的，後一種多半是做「頁面」的。這兩種產品形態的差異，導致雙方對開發語言的需求大為不同，前者恨不得不要用JS，改用C#，後者連現在已有的JS都可能覺得啰嗦。

這兩種人其實是無法調和的，並且分歧會越來越大。Web應用開發者在ES4的時代相對弱勢，所以ES4就悲劇了，而現在，這類人佔比越來越高，話語權也越來越強，所以ES6就這樣了，再往後，頁面開發者更覺得難以忍受了。

所以有時候我真覺得，乾脆別搞ES6什麼的了，保留現有JS不變，像Google搞Dart那樣，重新標準化一門新語言，然後大家各取所需，搞頁面的就用現在的JS，搞應用的就用新語言，各自演進，大家都快樂，多好啊。

以目前這種狀況，搞應用的嫌ES6步子小，搞頁面的嫌大，再往後，多邁一步都是很困難的，因為反對的聲音將越來越大，難辦啊。

只看TC39 Stage 3的條件即可：『至少要有兩個符合規範的具體實現』。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

1. TC39

TC39（Technical Committee 39）是一個推動JavaScript發展的委員會。

它的成員由各個主流瀏覽器廠商的代表構成。

會議的每一項決議必須大部分人贊同，並且沒有人強烈反對才可以通過。

因為，對成員來說，同意就意味著有責任去實現它。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

2. Stage

每一項新特性，要最終納入ECMAScript規範中，TC39擬定了一個處理過程，稱為TC39 process。

其中共包含5個階段，Stage 0 ~ Stage 4。

Stage 0: strawman

一種推進ECMAScript發展的自由形式，任何TC39成員，或者註冊為TC39貢獻者的會員，都可以提交。

Stage 1: proposal

該階段產生一個正式的提案。

（1）確定一個帶頭人來負責該提案，帶頭人或者聯合帶頭人必須是TC39的成員。

（2）描述清楚要解決的問題，解決方案中必須包含例子，API以及關於相關的語義和演算法。

（3）潛在問題也應該指出來，例如與其他特性的關係，實現它所面臨的挑戰。

（4）polyfill和demo也是必要的。

Stage 2: draft

草案是規範的第一個版本，與最終標準中包含的特性不會有太大差別。

草案之後，原則上只接受增量修改。

（1）草案中包含新增特性語法和語義的，儘可能的完善的形式說明，允許包含一些待辦事項或者佔位符。

（2）必須包含2個實驗性的具體實現，其中一個可以是用轉譯器實現的，例如Babel。

Stage 3: candidate

候選階段，獲得具體實現和用戶的反饋。

此後，只有在實現和使用過程中出現了重大問題才會修改。

（1）規範文檔必須是完整的，評審人和ECMAScript的編輯要在規範上簽字。

（2）至少要有兩個符合規範的具體實現。

Stage 4: finished

已經準備就緒，該特性會出現在年度發布的規範之中。

（1）通過Test 262的驗收測試。

（2）有2個通過測試的實現，以獲取使用過程中的重要實踐經驗。

（3）ECMAScript的編輯必須規範上的簽字。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

原文在這：The TC39 process for ECMAScript features

ES4 大幅度修改了 ES3 的語義集，而 Harmony 的語義集更接近於 ES5 的補充（ES4 和 ES6 的 Class 語義並不相同），因此步子太大扯著蛋是不大會的。

當然我對 Harmony 也有些不滿，比如 Generator 明顯過於複雜，語義更強但是更簡單的 call/cc 是更好的選擇

我覺得隨著ECMAScript不斷的更新換代，JS大有追隨甚至趕超C++的趨勢，越來越複雜。但這也並不是什麼壞事，與其像 @徐飛說的那樣分化成兩種不同的語言，還不如就像C++那樣，什麼都有，各取所需，這樣也少了不少嘴仗。

跟硬體有關，以前是pc機，淘汰速度慢，現在還有很多ie6瀏覽器在用。現在移動佔上風，瀏覽器更新更簡單，es6即便只有移動應用，也足夠了。手機的更新速度一般是2年，2年後手機沒壞電池也差不多了。這個就是現在新技術更新快的根本原因，沒必要對被老的東西敷住手腳

我其實很喜歡ECMAScript 4的，因為我寫ActionScript

只能說ES4生不逢時， Adobe 死得憋屈！

快來使用ECMAScript 2015吧時過境遷，不可同日而語了，如果當時前端已邁入工程化的大門，ES4早就普及了

在使用ES6一段時間後，發現會增加js的複雜程度，所以基本上不用。我相信很多開發者都會不知不覺不使用ES6一些特性來抵制ES6。使用過ES4，和JAVA,C#特別像。我覺的傳統程序員反而會喜歡ES4。感覺ES6和ES4比較起來反而是開倒車，真是鬱悶。

看別人兩年前提出的問題以及眾多前輩的回答，心裡感觸頗多。ES6已經成了標配，Vue 2.0 發展的也如火如荼，更甚至Yahoo都要被賣了。

@尤雨溪已經說了。

簡單來說，不會。最主要的原因是現在TC-39裡面組成有各大瀏覽器廠商的人，當一個proposal被提出，大家估摸著都能知道實現起來的難度（stage 1），實在是實現不了的有些會被推掉。

一個proposal要最終進入標準，需要完成Test262，有兩個兼容的實現並通過Test262，並且要有實際的shipping，比如有兩個不同獨立的VM 實現並且ship了。

ES 6是Javascript的新開端，ES 3 before都是DOM Process Language（文檔對象操作語言），ES 5是Advance DOM Process Language，高度優化了DOM操作體驗，沒有ES 5就沒有jQuery，因為沒有人會願意花很多時間在3基礎上寫這麼複雜的東西，也不好產生要寫這種產品的思維。

我個人認為ES 6是另一個世界，而且跟目前人們對ES(JS)的渴望和需求是相符的，就像iPhone的出現跟當年人們對手機的需求是相符的，漂亮的iPhone，容器化的App，多任務簡潔的系統等等……

一個東西能不能流行，關鍵在於人們願不願意用，就是【市場】，有些還存在於商業條件，比如上面回答說的M$、Adobe和Google等紛爭。

上面已經有人貼出來兼容程度了，可見未來還是可行的，我看到評論有人說：IE殺出來怎麼辦？

你用IE，不代表：沒有人用Chrome，沒有人用Safari。。。

最近不是有「白酒賣不出去，然後很多零售店都癱瘓了」的新聞嗎，現在很多年輕人，都不喜歡喝酒，因為酒有傷身體，人們青睞的東西會發生改變。

現在還是有人喝白酒，還有人用IE，也有人用舊的相機。

但是，我們還是更積極響應的是人們尋求的未來，人們真實需要的東西，就算ES 6不受一部分人的歡迎，但是，還是有一部分的人（可能會增加）是支持的，所以不會有題主的情況。

應該不會了，畢竟現在主流桌面瀏覽器對 ES6 的原生支持都比 Babel 還要高。