2013 前端技術盤點

　　本文曾發表於2013年12月《程式設計師》，個人收集和一些拙見，難免有錯誤和疏漏，請各位補充。文中加粗的關鍵字不少，沒有一一新增連結，Google一下即可找到相關資料

　　2013年，儘管前端技術在無線領域受到了挫折，但這無法減緩其發展勢頭。在基礎技術方面，規範和標準的發展、瀏覽器的快速演進為將來的Web應用打好了根基；隨著網站規模的進一步變大，互動變得更復雜，大家更關注用新的開發模式來解決問題；更重要的是，經過多年積累，在前端工程實踐上我們有了豐富的成果。本文將從多個角度介紹今年前端技術的發展，其中會穿插若干對前端發展的思考。

　方興未艾的規範和標準

　　自從HTML5推出後，W3C和各大瀏覽器廠商都在加緊推動規範發展和實現，尤其是手機瀏覽器對規範的支援程度，已成為國內瀏覽器宣傳的賣點。對於W3C的正式規範，大多數都已經被現代瀏覽器實現，而我們更應關注快速發展中的Working Draft規範。它們不僅對實際開發有幫助，更重要的是它們代表了Web未來的發展方向。

　　Web Components規範定義了未來的HTML元件，其中最重要的部分是Shadow DOM和Custom Element，除此之外還包括HTML模板、HTML imports和Decorators。Shadow DOM能將元件的程式碼和使用者的程式碼徹底分離，通過在文件渲染時插入一顆DOM子樹，但這子樹並不在主DOM樹中，因而外部的CSS無法直接影響Shadow DOM中的元素；當然，Shadow DOM能提供事件API、Javascript API、CSS API供外部控制。Custom Element則允許開發者自定義HTML標籤，讓頁面更語義化的同時，還能為元素加入屬性和方法，以提供特定的功能供外部呼叫。

　　WebDriver規範和 Selenium 2 WebDriver 自動化測試框架 API 十分類似，它取代了嵌入到被測Web應用中的Javascript，由瀏覽器直接支援的WebDriver，避免了Javascript安全模型的限制，還能利用作業系統級的呼叫來模擬使用者輸入。Firefox、IE、Opera 和 Chrome 都對其有一定支援，也能通過 WebDriver 完成 Android 和 iPhone 的移動web應用測試。

　　Webapp Working Group今年很活躍，前文提到的 Web Components 規範就是來自這個小組。它們今年的進展還包括 Push API、Streams API、UI Events 等規範。

　　W3C去年還成立了System Applications Working Group，目標是定義執行環境、安全模型和相關的API用來構建能與原生應用匹敵的web應用。他們在今年提出了一系列規範，其中比較重要的有：用來定義和引用Webapp的App URI規範；能定期喚醒應用的Web Alarms API；和系統簡訊服務通訊的Messaging API。

　　W3C所有規範都會公開發布，在 http://w3.org 上可以找到各個工作組的當前進展，你也可以訂閱他們的郵件組。

　　除了W3C規範，另一個重點是 ECMAScript 6 的規範草案。今年草案更新了9個版本，按計劃，正式版本將在年底釋出，我們每天都在編寫的Javascript程式碼即將發生巨大的變化。ECMAScript 6 在保證向下相容的前提下，提供大量新特性，使 JavaScript 能用來編寫更復雜的應用，今年重大的更新包括箭頭函式、物件代理、Symbol物件，還對之前提出的Class、Modules等特性做了一些調整。部分特性在Firefox和Chrome的較新版本中都獲得了支援，Google也推出了一個traceur-compiler，能將ECMAScript 6的程式碼編譯成ECMAScript 5在普通瀏覽器中執行，你可以自行嘗試。

　瀏覽器與協議

　　SPDY，這個四年前Google提出的協議，希望能讓網路傳輸更加快速，迄今已經獲得了Chrome、Opera(>=12)、Firefox(>=11)、IE(>=11)的支援，當前正在制定的Http/2草案也採用了SPDY協議做為其規範的基礎，SPDY通過壓縮、多路複用和優先順序來縮短載入時間，只需要建立一個TCP連線即可傳送網頁內容及圖片等資源，SPDY的網頁伺服器還可以主動推送內容。根據Google的測試，SPDY協議比傳統的Https協議快30%-40%。

　　PNaCl(Portable Native Client) 這個開源專案允許開發者在瀏覽器內編譯C或者C++程式碼，一次編譯就能在各種桌面 Chrome 或 Chrome OS 中執行，無需使用者安裝，效能和本地原生程式碼相近。從今年的Chrome 25開始，PNaCl 做到了架構獨立，一次編譯就能在不同的平臺上執行，包括ARM平臺。這讓web應用程式擁有更多發揮空間。

　　Blink已經取代Webkit成為Chromium的新渲染引擎，這是一個Webkit的獨立分支。Chromium之前是使用 Webkit 做為其渲染引擎，但由於Chromium在最初就實現了沙盒技術，而Webkit 2之後又開發了一套與Chromium不同的沙盒技術，這樣導致了兩者的程式碼複雜度上升，Blink分支可以讓 Google 不再顧及對 Webkit 2 的相容，加快改進速度。與此同時，Google 希望在核心效能上有更大突破，以及快速實現一些W3C的草案，獨立的分支會帶來更多自由度。對開發者來說，這並不是什麼壞事，在 HTML5 規範下，以及標準化組織的推動，兩個瀏覽器不會分裂，只會互相促進。

　　各家瀏覽器都在快速推進草案規範的實現。你可以去 http://caniuse.com/ 詳細查詢瀏覽器對各種規範的支援情況。

　語言能力增強仍在繼續

　　除了規範和標準組織對基礎技術的推進，我們還能經由預處理手段對語言能力進行增強。這些增強無需瀏覽器支援，因而開發者能快速使用這些新特性，更新速度也夠快。不過，相對去年來看，今年的勢頭弱了很多。

　　現在流行的CSS預處理語言包括LESS、SASS和Stylus。Less基於Javascript實現，安裝和使用都很簡單，從去年開始流行，著名的Bootstrap也是基於Less語法構建的；而SASS最初的設計比較難以理解和使用，直到它的語法升級成SCSS後才逐步被廣泛接受，它相對Less能力稍強，如迴圈、變數等，但這也可能帶來濫用，基於SASS的CSS框架有 Compass 和 Bourbon；Stylus和LESS很像，但語法更簡潔。由於CSS語法的能力限制，這些前處理器能讓開發CSS程式碼變得更簡單，而基於它們的CSS框架更是讓開發者低成本地搭建頁面。

　　CoffeeScript和TypeScript這類去年被熱捧的 Javascript 預處理語言，今年變得比較冷卻，前者的最近更新是六月份的1.6.3版本，相對年初發布的1.5進展不大；後者也遲遲沒有推出1.0版。在我看來，這些語言在簡化 Javascript 語言的同時，並沒有帶來更多的便利性，反而他掩蓋了語言內部的某些實現，增加了學習和排錯成本。

　　反倒是Dart在默默地成長。這個以取代 Javascript 為目標，也支援編譯成 Javascript 使用的語言，最近剛釋出了其1.0版的SDK，這標誌著它已具備投入生產的條件。Dart SDK中，除了程式語言，還包括很多工具和核心資源庫，以及一個Dart Editor。在最近的壓力測試中，不僅是Dart本身的效能高出 Javascript 許多，就連通過它編譯成的 Javascript 程式碼的效能都略微超過原生 Javascript 程式碼。

　　語言的改進並非短短數年就能完成的工作，我們要留有足夠的耐心。