復(fù)雜的業(yè)務(wù)中會經(jīng)?？吹揭粚佑忠粚拥幕卣{(diào)處理，回調(diào)的嵌套讓代碼的可讀性變的很差，而且很難將多個異步并行處理。為了改變這種編程范式，我們做了很多的思考，使用事件監(jiān)聽，使用各種手段拉直回調(diào)，平坦地調(diào)用。
慢慢的，如果你在關(guān)注 W3C 小組的動向，會發(fā)現(xiàn)，那些被認可的，并且被廣泛重復(fù)定義的東西，都被納入了標準。最開始的 jQuery/prototype，前者主要是對瀏覽器做兼容處理，讓開發(fā)者不再把精力放到瀏覽器的差異上；后者是對語言本身的拓展，對 JavaScript 各種類型做拓展，并且提供了一套拓展任何對象的功能集。而現(xiàn)在的開發(fā)，我們很大程度上不再依托這些類庫。規(guī)范和標準已經(jīng)把這些差異都統(tǒng)一了，String 中自帶了 includes/startsWith/endsWith/repeat/padStart/padEnd 等函數(shù)，Array 自帶了 from/forEach/of/keys/values/find/findIndex 函數(shù)…
規(guī)范的標準是為了讓開發(fā)者得到更好的編程體驗，編程不是目標，目標是將編程生產(chǎn)力轉(zhuǎn)化成實際效益，越少的阻礙對開發(fā)者越有利。各瀏覽器廠商當然也認識到了這一點，他們不斷地提升自己產(chǎn)品的體驗，將標準中的新特性都融合進去，比如 ES6 中的 Promise/Generator/Class/Module 等等。在這些內(nèi)容普及之前，我們不需要加入 jQuery/prototype 這些「不純粹」的東西，而是添加兩個 shim 和 polyfill，如 es5-shim，html5shiv 等等。待到山花爛漫時，再輕松刪掉這些補丁程序。
這兩年工程化很熱，W3C 小組也看到了，這就是市場的需求，為了完成一個大型應(yīng)用的編程，就必須模塊化、組件化，于是在規(guī)范中也出現(xiàn)了 Module & Module Loader；Node.js 的到來，讓很多前端工程師開始接觸數(shù)據(jù)庫操作，面對巨量的異步，我們?nèi)虤馔搪晫懥藷o數(shù)的回調(diào)地獄，盡管使用了很多 Promise 相關(guān)的操作，程序結(jié)構(gòu)依然松散難以閱讀，于是規(guī)范中也開始出現(xiàn)了 async/await 等對 Generator 的上層封裝。文字已經(jīng)不能滿足當代人的溝通需求，音視頻等富媒體傳輸走進了我們的生活，于是規(guī)范中也出來了 WebRTC/WebAudio 等規(guī)范。
只要規(guī)范出來了，后續(xù)市面上就會根據(jù)規(guī)范來實現(xiàn)一套 shiv，這些 shiv 提供了同樣的 API，提供了同樣的編程體驗。當瀏覽器自我進化完成之后，這些 shiv 也將成為歷史，被開發(fā)者遺棄在代碼的注釋之中。這些都是規(guī)范和標準的魅力，它的存在，就是讓開發(fā)者把精力投入到自己的業(yè)務(wù)之中，編程和范式的工作交給它。
在這里可以看到，W3C 各個小組最近都在干啥。標準不能囊括一切。
