09 年之前，JavaScript 還處於對自身語言的完善過程中，而到了 09年，JavaScript 類庫已經頗爲成熟，jQuery/Prototype//Dojo等都已經發布了好幾個stable版本，各大類庫也是相互吸收優點，不斷完善並提高自身性能，然而功能上已經沒有太多增加的勢頭。部分框架開始了思想上的轉變，更加註重前端開發的組織和結構，條理性強了很多，如YUI 等。
從 ECMAScript 規範的爭執，開啓了瀏覽器引擎大戰，各大廠商也趁機瓜分 IE 份額，Chrome和Firefox在這場戰役中取得大勝，V8 也敲響了前端的大門。爲了迎合市場的激烈競爭，IE 開始了升級之旅，09 年初發布 IE8，全面兼容 CSS2.1。
而此時，Node.js 和 3G Mobile 這兩隻巨獸開始浮出水面，Web 標準也開始向 HTML5、ECMAScript5.0 靠攏。
10 年，看齊標準，關注 Web 性能
毫無疑問，這一年，各大巨頭都看清了 HTML5 是 web 發展的未來，在保留原來前端技術的狀態下，都簇擁着拉扯 HTML5的裙襬。富客戶端應用也在這一年蓬勃生長，ExtJS/Dojo 搖身變爲企業級框架，各類組件化概念和產品如約而至。
延續着 09 年的變化，10 年的前端顯得頗爲沉寂，然而在標準的運用和推動上，各大廠商也是十分賣力。IE 9 出來了預覽第三版，iPhone 的 Safari 已經能夠支持衆多 HTML5 內容：Canvas/Video/Audio/Geolocation/Storage/Application Cache/Web SQL Database 等。
W3C 宣佈成立 Web 性能工作組，Google 和 Mozilla紛紛推出應用商店，瀏覽器調試工具也豐富了起來，人們開始更多地關注開發體驗和性能問題。
11 年，HTML5 扛大旗，Flash 堪憂
2011 年 HTML5 的技術發展和推廣都向前邁進了一大步，語義明確的標籤體系、簡潔明瞭的富媒體支持、本地數據的儲存技術、canvas等等各類技術被廣泛應用。這一年，很多 web 開發者也面臨一項技術的抉擇，HTML5 or Flash？從 Flash Player 11.1 開始，Adobe不再繼續開發面向移動設備瀏覽器的 Flash 插件，積極投身於 HTML5，這意味着 Flash 技術的凋零。
這一年，HTML5 遊戲火爆到了一個高潮，移動端開發工具和調試工具也日益成熟。jQuery 已經成爲大小公司日常開發的標配，成千上萬的 JQ 插件讓網頁開發變得尤爲輕鬆，而隨之而來的也是頁面的臃腫和性能調優的深入探索。
Node.js 已經悄然崛起，在 github 上的訪問量已經超過了 Rails，國內的雲應用開始嘗試使用 Node.js，Node.js相關工具也紛紛出來。
12 年，響應式開發，工程化推進
隨着硬件技術的發展，各手機廠商又開始騷動起來，爲了佔有更多的市場，不斷提高產品的性價比，體驗也得到了不斷的優化。藉着先前兩年HTML5颳起的東風，移動端上的 web 開發也顫抖了起來。移動端的開發挑戰不亞於 PC 上對多個瀏覽器的支持，這一年，萌生了衆多移動端框架，如Sencha Touch/Zepto.js/JQ Mobile等，相對 PC 端框架，它們更加輕便。
而移動端的崛起，帶來了許多終端開發難題：多終端適配，多分辨率適配，遠程調試等等，而隨着這些難題一個個被解決，移動端生長的勢頭變得更加強盛。此時Twitter也推出了 Bootstrap， 這個前端開發工具包不僅方便了前端，也方便了後端同學，它的出現讓快速建站更加簡單。
編程思想的切換，迎來了 CoffeeScript 和 TypeScript，這兩個預處理語言的出現又爲 JavaScript引來了不少其他方向轉型過來的開發者。JavaScript的兄弟 Node.js，也在命令行領域開拓了一片不小的疆域，甚至有動搖 Perl和Ruby地位的趨勢。
在前端工程化上，幾個派系相互爭鬥，產出了 AMD、CMD、UMD 等規範，也衍生了 SeaJS、RequireJS等模塊化工具。前端在這一年很有跳躍感。
13 年，爆發式增長，百花齊放
規範和標準上有不少產出。Web Components的出現給前端開發開闢了新思路；WebDriver規範的出來推動了自動化測試的進程，ECMAScript 6的規範草案落地，Webapp 工作小組在這一年也是相當活躍。
Chrome 瀏覽器在這一年也有了很大的突破，開始支持 SPDY，使用 Blink 取代 webkit 作爲 Chromium的新渲染引擎，Chrome DevTools 的調試體驗大幅度提升。這一年中，Chrome 連同其他瀏覽器廠商快速推動了各項草案規範的實現。
語言能力上依舊在增強，並且從 JS 開始擴散到 CSS，LESS、SASS 和 Stylus 等 CSS 預處理語言開始走俏，Web開發變得更加緊湊。
而在無線端，應用不再侷限於 Webapp，由於流暢度、性能等方面不能滿足用戶體驗的需求，各大公司開始轉向 Native 方向的研究，進而出現了Hybrid 和 PhoneGap 的繁榮，它們爲 JS 調用了提供更多的設備 API。
Node.js 大放異彩，很多公司在生產環境中使用 Node.js，同時也出現了諸如 Express、Meteor等小巧的快速搭建 Node.js Server 的應用框架。
各瀏覽器的調試也是種類繁多、功能豐富，PhantomJS 在自動化測試上開始取代Selenium，出現了衆多的遠程調試方案和工具。
前端工程化開始普及，各公司開始推出自己的前端集成開發解決方案。
14 年，移動端的崛起，HTML5 和 ES6 落地
HTML5 正式定稿，這意味着，web page 正式演變爲 web application。ES6 華麗麗走進前端，走的很穩重，它的Module/Class 等特性已經完全讓這門語言具備了開發大型應用的能力。
大而厚的基礎庫難以滿足靈活場景，Mobile 要求極致體驗，MV* 庫鋪卷而來，如vue/angular/knockout等。
Web Components 跨終端組件快速發展，移動端開發迎來一次昇華。Node.js 前後端分離的流行，中間層的出現改變了前後端的合作模式。2014 是顛覆式的一年，前端發展在這一年開始形成了一個短暫的穩定格局。
15 年，觀念的轉變，步入前端工業化生產
今年格外引人注目的框架是，類 React。Facebook 在 React.js Conf 2015 大會上推出了基於 JavaScript的開源框架 React Native，它結合了 Web 應用和 Native 應用的優勢，可以使用 JavaScript 來開發 iOS 和 Android原生應用。在 JavaScript 中用 React 抽象操作系統原生的 UI 組件，代替 DOM元素來渲染等。敲一次代碼，能夠運行在多個平臺上，其優勢可見一斑。除了 React ，還有手機淘寶推出的 Weex 框架，它吸收了 vue.js的編程精華，編程風格更加簡約。
在衆多構建工具中，如今瀟灑存活的並不多。體驗完 grunt 和 browserify 後，gulp 順勢而至，爾後又出現了 webpack、jspm等。而包管理工具，經歷了 components、bower、spm 後，npm 開始主導整個市場。
Node.js 的應用已經鋪天蓋地，各大公司前端都把 Node.js作爲分離前後端的主要手段，並且在測試、監控等方面沉澱了大量內容。不過，這個市場是很苛刻的，Node.js 的性能難以達到 C/C++的水平，那麼接下來要做的就是要提升性能，至少得接近 C/C++。
@法海 師兄批註：對時間點的總結是，其實很多技術方案很早就出現了，只不過沒有大規模應用，因此，對於上文中時間點的謬誤，你可以將語句從「xxx出現了」改成「xxx得到廣泛應用」。其實我發現，問題在於，一個技術領域的新起和發展並不是一年內能完成的，一個技術方案的出現和廣泛應用也不是一年內能落地的，所以執着於以「年」爲時間點來編史，會畫地爲牢。
Web 規範和標準
最開始，我們看到的 JavaScript 還只是一個簡單的腳本語言，配合着AJAX，在網頁上翻騰了好幾個年頭。隨着互聯網趨勢越來越明顯，互聯網業務量和業務複雜度不斷增加，很多網頁變得相當複雜，如讓我們震驚了好一會兒的Gmail，交互複雜，體驗優良。爲了更好的多人協作，代碼中的 Utils 庫越來越大，在這些庫中，基礎部分更多的是對 JavaScript語言本身的拓展，比如給 String 加一個 repeat 函數，再加一個 trim 函數，再加一個 endWith 函數等等。
複雜的業務中會經常看到一層又一層的回調處理，回調的嵌套讓代碼的可讀性變的很差，而且很難將多個異步並行處理。爲了改變這種編程範式，我們做了很多的思考，使用事件監聽，使用各種手段拉直回調，平坦地調用。
慢慢的，如果你在關注 W3C 小組的動向，會發現，那些被認可的，並且被廣泛重複定義的東西，都被納入了標準。最開始的 jQuery/prototype，前者主要是對瀏覽器做兼容處理，讓開發者不再把精力放到瀏覽器的差異上；後者是對語言本身的拓展，對 JavaScript各種類型做拓展，並且提供了一套拓展任何對象的功能集。而現在的開發，我們很大程度上不再依託這些類庫。規範和標準已經把這些差異都統一了，String 中自帶了includes/startsWith/endsWith/repeat/padStart/padEnd 等函數，Array 自帶了 from/forEach/of/keys/values/find/findIndex 函數…
規範的標準是爲了讓開發者得到更好的編程體驗，編程不是目標，目標是將編程生產力轉化成實際效益，越少的阻礙對開發者越有利。各瀏覽器廠商當然也認識到了這一點，他們不斷地提升自己產品的體驗，將標準中的新特性都融合進去，比如 ES6 中的 Promise/Generator/Class/Module 等等。在這些內容普及之前，我們不需要加入 jQuery/prototype這些「不純粹」的東西，而是添加兩個 shim 和 polyfill，如 es5-shim，html5shiv等等。待到山花爛漫時，再輕鬆刪掉這些補丁程序。
這兩年工程化很熱，W3C 小組也看到了，這就是市場的需求，爲了完成一個大型應用的編程，就必須模塊化、組件化，於是在規範中也出現了 Module& Module Loader；Node.js的到來，讓很多前端工程師開始接觸數據庫操作，面對巨量的異步，我們忍氣吞聲寫了無數的回調地獄，儘管使用了很多Promise相關的操作，程序結構依然鬆散難以閱讀，於是規範中也開始出現了 async/await 等對 Generator 的上層封裝。文字已經不能滿足當代人的溝通需求，音視頻等富媒體傳輸走進了我們的生活，於是規範中也出來了 WebRTC/WebAudio 等規範。
只要規範出來了，後續市面上就會根據規範來實現一套 shiv，這些shiv提供了同樣的 API，提供了同樣的編程體驗。當瀏覽器自我進化完成之後，這些shiv也將成爲歷史，被開發者遺棄在代碼的註釋之中。這些都是規範和標準的魅力，它的存在，就是讓開發者把精力投入到自己的業務之中，編程和範式的工作交給它。
在 這裏 可以看到，W3C各個小組最近都在幹啥。標準不能囊括一切。
生態的自我完善和自我拓展
技術的更迭過於頻繁，我們能夠清晰地看到，很多人還在用更迭前一波甚至是前好幾波的產品。
當年的 IE6，在戰場上鏖戰了 10多個年頭，依然屹立不到，而現在它在市面上依然有百分之一左右的佔有率，這種小強精神不得不讓人肅然起敬。“只要用戶在，我們就得追隨”，這可能是很多公司的服務理念，因爲用戶就是潛在的利潤。正是因爲這種服務理念，成就了IE6 一個又一個的 5 年！然而低本版的 IE 已經不僅僅是被前端從業人員抵制和排斥了，網絡安全、網絡運維、QA等等，各個技術崗位的人員都開始對他不屑，它的存在對工作效率、對安全、對很多方面產生了極爲不良的影響，甚至影響到一些核心內容的推廣，所以 2016 將是低版本IE 消亡的一年，我也呼籲業界所有的朋友舉起義旗反抗起來！
慶幸的是，也有人開始吃螃蟹了。從支付寶到天貓到淘寶，阿里巴巴在很多業務上已經主（bèi）動（bī）地放棄了對 IE6 和 IE7的支持，甚至在統一接入層直接做了 302 跳轉，提示用戶更新瀏覽器或者引導流量到無線端。這是一個好的開始，我們期望這也是業界達成共識的開始！
HTTP 協議，從 1.0 快速過度到了 1.1，整個互聯網的上層建築變的十分穩固。當然，我也瞭解到依然有很多產品還是保持了 1.0的狀態，據說電信公司的很多產品就是使用 HTTP/1.0 進行通訊，這無疑讓人驚愕。爲了追求更高的效率，減少網絡傳輸中的無效流量，W3C 工作組對 HTTP協議也做了重新的定義，SPDY 就是 13 年比較火熱的一個話題，Firefox 和 Chrome 都陸續開始支持 SPDY，後來在SPDY的基礎上做了升級，正式定義爲 HTTP/2.0，它的一個很大特點就是多路複用，這個小小的特點改變了我們前端編程的很多優化模式，比如
域名不是越多越好，爲了能夠充分利用瀏覽器的連接數，我們給 JS 和 CSS 開一個域名，給 img開好幾個域名，網頁打開的時候，恰到好處的利用瀏覽器的連接數上限限制。HTTP/2.0 的多路複用，就是可以在一個 HTTP請求中進行多個資源的傳輸，如果域名散列，反而不能利用這個特性
資源合並沒有任何優勢，以前的資源合併是爲了減少請求數以節約建立 TCP 鏈接的網絡開銷和頭部傳輸的流量開銷，而在 HTTP/2.0 中，一個 HTTP請求上完全可以把所有的資源全部推送過來，如果合併了資源，反而不能良好運用瀏覽器對資源的緩存。
當然，除了多路複用，還有很多其他的優化，比如傳輸的數據爲二進制流，HEAD頭會被壓縮處理，服務器可以向客戶端推送內容等。在這個技術水平指數式增長的年代，我相信以後的革新不會比消滅 IE6 痛苦。
模塊加載上，經過了各派系的爭論之後，流傳下來幾個不錯的產品 SeaJS、RequireJS等，那麼那個模塊加載器將成爲工具平臺中短暫的終點呢？似乎這些都不是。當我們按照規範中的方式進行模塊定義，按照規範中的方式加載定義的模塊時，加載這個流程就顯得不那麼重要了，因爲這些事情最後都會變成shiv/polyfill 的事情，最終會變成瀏覽器的固有屬性。
當一個東西在社區中被暴力追捧的時候，會有很多衍生的產品出來，當這些衍生物根深蒂固時，可能又會出現一個更加原生更加符合開發習慣的東西出來。就像jQuery，我們爲它編寫的插件不計其數，而在工程化的需求衝擊下，它卻顯得那麼的弱不禁風，因爲它關注的點和當前的發展態勢不太吻合，僅此而已。
Mobile 的發展驅動着戰場的轉移
記得當年拿着 Nokia5230 學完了 HTML 和 JavaScript的入門，那屏幕尺寸也就是三個手指的寬度，緊緊攥在手裏看着頁面混排效果極差的網頁文檔。
現如今，iPhone 都出到 6s 了，一個版本一個尺寸，而且尺寸越來越大，還有各種寬高不一的 Android機器，種類繁多。以前的觸屏是電阻式，只支持單點觸碰；而現在電容式的觸屏精度更高，還支持多指觸控，這如絲般順滑的體驗在三四年前是完全體會不到的。曾經手機開一個程序久了就會卡，動不動還會自動重啓；而現在的手機開一堆程序，完全無感知，這就是硬件發展前後的差異。
手機已經成爲了人們生活中不可或缺的一部分，甚至成爲了一些人身體的一部分，淘寶今年雙十一的數據顯示，國內移動端的消費比例已經遠遠超過了 PC 端，佔比68%。面對龐大的用戶，我們的技術是否做好了充足的準備，這裏還得打一個問號。
PC 上那一套經驗不是直接搬到移動端就可以使用了，在移動端還需要解決更多的問題：
多分辨率問題，這裏涉及到了響應式設計和前端響應式技術
不同網絡環境的網頁加載優化問題，2g/3g/4g/wifi
手指交互帶來的一系列體驗問題
爲了提升用戶體驗，將 Web Native 化 —— 類 React 技術帶來的一系列問題
遠程調試問題
移動安全問題等等
上面提到的問題很多已經有了優秀的解決方案，當然也有很多未提及的。WebApp的性能、流暢度和穩定性遠遠不如原生應用，同時它也無法良好地運用設備提供的原生功能，這些都是大家轉投 Native 的原因。
端的融合
不同分辨率的手機，不同物理尺寸的終端，爲了保持良好的視覺體驗和用戶體驗，我們不得不爲每一個尺寸寫一份 Media Query代碼，那麼對應的，設計師也需要設計多套版式供前端使用，這給設計師、前端和測試帶來了無盡的麻煩。爲此，我們通過前端技術重塑屏幕，重新定義像素尺寸，使用流式佈局，通過百分比來響應不同的終端尺寸。這是端的融合。
後續的 Mobile 的技術發展方向上，應該是相當明確的。很多公司都是三套人馬維護三端的程序，iOS、Android 和Web，而這三端做的事情都是一樣的，一樣的界面，一樣的後端接口，一樣的交互方式。爲了能夠快速響應業務的變更，我們不得不將三端合併爲一端對待，用一套程序編程成三端代碼，然後發佈到三個平臺上。這也是端的融合。React系列技術發展到此，絕對不是終點，它只是一個探路燈，給我們照明瞭方向。
技術需要爲業務做保障，而好的技術是能夠及時響應業務的變化，我們不可能投入大量的人力在 Web的修補工作上，通過開發統一工具，屏蔽端和端之間的差異，統一開發模式和開發體驗，這纔是 Mobile 的未來。
當然，回到我們之前說的規範和標準，我們目前所做的「屏蔽差異」工作，今後，也會有統一的標準來規範，目前手機廠商沒有這個共識，是因爲還處於當年Chrome、Firefox 搶佔 IE6 市場份額的階段。端的最終融合在於一個統一的標準，以及強有力的執行。
棧的融合
我剛接觸前端的時候，還沒有聽說「全棧」，Web技術棧往小裏說，包含了從前端設計、交互、前端實現、網絡數據傳輸、後端實現、後端運維和數據庫等幾個方面，能短時間內從無到有實現這麼一套系統，並且能夠抗得住一定流量衝擊的人，我們可以稱之爲全棧工程師。能夠有架構有條理地實現這套系統，並且抗得住大流量、有集成測試、有監控的，這種我們可以稱之爲資深全棧工程師。現在不乏這種人才，也不乏自吹爲這種人。
棧的融合得益於 Node.js 的出現，作爲前後端分離的橋樑，它拉近了前端工程師與後端的距離，有的人在這座橋樑上賣力行走，漸漸的也從前端走進了後端，甚至走進了後端的運維。至此，前端也擁有了部署和發佈整個應用的能力，這是一個質的突破。
使用 Node.js，簡單幾行程序便能實現一個 web 服務器、便能搭建一個多人聊天的網頁，它的便捷性可見一斑。NPM社區的發展，沉澱了成千上萬的組件包，一行命令即可獲取，這種組件拼湊式的開發，任何功能的實現都不會顯得太複雜，而這裏的「不復雜」也蘊含了無數的坑坑窪窪，在這一層的融合上也會遇上不少阻礙：
冗餘的龐大的包內容，爲了使用一個小功能，我們從網絡上拉取下來一個巨大的包，而且這裏的「巨大」對很多人來說都是無感知的，很少會有人進入node_modules 去查看依賴的第三方包是如何實現的，實際情況可能會相當震撼，第三方包還引用了一堆第三方包，這些包都會在 Node.js執行的時候被收納進去，放在內存中。
猛烈的迭代，今年的 Node.js 被人嫌棄迭代太慢了（當然，這是表面原因），走出了一個分支 io.js，發展了一會兒，進度趕超了 Node.js，後來覺得一家人不幹兩家活，又合並回去了。雖說上層 API 幾乎沒有變化，但是底層卻被翻了一個天。
偶爾的巨大漏洞，每隔一端時間就會暴露 Node.js 存在漏洞，這些漏洞的補救措施就是立即升級版本號，比較讓人擔心受怕。
後端意識不強烈，前端佔領了中間層的開發，有的時候還幹這後端的活兒，然而卻沒有後端沉澱多年固有的意識，測試和監控做的相當潦草。
JavaScript 從客戶端的腳本語言縱身躍進進入了後端行列，而今也開始深入到移動端 Native 領域，確實是無孔不入，這可能就是語言的特性，也可能是技術本身就在尋求融合點，把有差異的地方全部躺平，然後用統一的方式去關注業務，關注用戶。端和棧也在融合。
後端服務化，雲數據，雲安全
用戶體驗變得越來越重要，響應式技術的發展也是後續網頁應用的一大特點，端和端之間的差異只是在表現上，數據這一層差異不是特別大，很多應用 PC 和Mobile 共用一套接口，或者 Mobile 的接口在 PC接口的基礎上做了一層包裝，對接口字段做了些許刪減。後端爲了響應各個端之間的數據需求，也需要關注數據的可利用性，接口包裝的拓展性等，這是後端服務化的一個表現。移動端的開發上，前後端間隙十分明顯，越來越多移動端應用的發佈已經脫離了後端，前端完全通過異步方式獲取數據。
業務變化很快很快快，今天這個產品被併購，明天那個業務被砍掉，每個人負責的業務線可能冷不丁地就變了。很多大公司的決策是由上往下的，上面微動，下面可能就是大動，可能某個部門就不存在了，也可能被劃分成幾個產品部門。
所以「大後臺，小前臺」的趨勢必然形成。前端，毫無疑問，在這個前臺之中。前臺的特點是靈活的，多變的，可快速重組的。對後臺而言，爲了響應前臺的變化，需要提供更細粒化的API，將數據打散，打得更加零碎，零碎的數據易於重組，這是在考驗後端的架構能力。如今，很多前端也都是半棧工程師，盤踞在前後端中間層上，然而如何迎接這種後端服務化的模式，似乎這個準備還是不夠充足的。
GraphQL 的出現場景跟 React 類似，React 是前端應對不同場景的一種強有力手段，而GraphQL則是後端應對不同需求場景的一次嘗試，Web APIs 將會成爲 Web App 和 Mobile App 的一箇中心點，前端基於後端的 RESTful服務構建應用，這裏面存在太多未知的問題需要探索，這是一個大數據下探索的新起點，也給前端開發者創造了無數的可能。
這幾年各類網盤，各個雲服務商都在搶佔市場，有提供圖片儲存的，有提供 CDN靜態資源緩存的，有提供大文件儲存的，也有賣數據庫服務的。種類繁多，而歸根到底都是，你付錢給我，我提供儲存和安全，還提供方便的 SDK讓你獲取自己的數據。雲服務賣的是一套服務，它是把所有人的數據風險集於一身，用強硬的技術做安全防禦。雲，賦予了我們無窮的想象空間。
三輛馬車，我們還差一輛
開發功能對很多人來說是輕鬆活兒，基本的前端語言加些複雜的特效，實現成本不會很高；即便是搭建一個網站，使用 Node.js社區中的框架也能夠輕鬆實現。然後極少人會去關注每個功能點的測試，一個項目下來基本看不到測試用例，更不用說會去做監控相關的事情。結果就是，踏過了無數的坑窪之後終於上線了，而後續加功能的時候發現，加了東西就跑不通，新內容影響了之前的邏輯，只好去修復之前的邏輯，修好之後發現更早之前的邏輯又不通了，整個修復過程就像玩多米諾骨牌。
程序開發三板斧：功能、測試和監控。在 github上可以看到很多程序都加入了持續集成，這是一個好兆頭，意味着我們寫的程序也越來越健壯，至少貢獻給世人使用的程序是健壯的。很多程序的代碼覆蓋率也達到了90%+，這些數據都是重視測試的證據。
然而，三輛馬車，我們最後一輛依然沒有開動起來。很多公司都會有自己的 log平臺，每個用戶訪問頁面中的任何一個鏈接都會將用戶信息和訪問信息以 log日誌形式收集到 log平臺上，然後通過監控平臺或者離線分析的方式，獲取業務數據或者技術數據，進行分析和二次開發。這些東西在大公司見的很多，而這方面的東西在前端，尤其是使用Node.js 做程序開發的前端身上，看到的並不多。