2010 Web前端技術趨勢及總結(jié) Facebook摘全明星MVP
經(jīng)過這段時間國內(nèi)（百度，淘寶，新浪等）及國外（Facebook，Youtube，Yahoo等）各大公司的集中自曝，我們可以從中總結(jié)出2010 Web前端技術的一些趨勢?？偟膩碚f，隨著后端技術（存儲，并發(fā)，分布式）的成熟，各大公司已經(jīng)把重點從后端架構(gòu)調(diào)整/建設轉(zhuǎn)移至前端（TTI時間，快速發(fā)布，帶寬利用率）。
作為明星技術的HTML 5/CSS 3，都未正式成為各公司的考慮重心，雖有所嘗試，但在關鍵功能上，均未成為主力。這也W3C對當前HTML 5/CSS 3標準現(xiàn)狀的表述：“不適宜用作生產(chǎn)環(huán)境”一致。
Web前端技術的范圍
1. 編程語言/技術（HTML，JavaScript，CSS等）
2. 跨瀏覽器兼容性/支持（JS Framework，CSS Library）
3. 網(wǎng)絡傳輸性能（并行下載，帶寬利用率）
4. 瀏覽器渲染時間/性能（TTI即用戶可交互前等待時間，JS執(zhí)行性能）
個人感覺，F(xiàn)acebook無疑又成為了技術上的明星，在大家還在感慨其對于PHP的重大改進HipHop(Blocked inside China mainland)的時候，今年Facebook又在前端技術方面給大家?guī)砹梭@喜。
Facebook面臨的問題
500M（Million）注冊用戶，50%每天至少訪問一次，用戶平均每日在線時間為5小時25分鐘。帶寬及服務器壓力均很大。
Facebook的解決方案
Quickling
Facebook提出了一個新名詞Ajaxify，顧名思義，就是將傳統(tǒng)的POST/GET轉(zhuǎn)換為Ajax請求。優(yōu)點顯而易見，首先減少了不必要的HTML傳輸，只請求和渲染頁面需要更新的部分，這就相應減少了所需傳輸?shù)膬?nèi)容加快了內(nèi)容送達至用戶的時間。并且也減少了服務端對HTML的不必要的渲染。Facebook也提到了可以減少session的重復load/unload。
使用Ajax也許不是什么新鮮的新聞，大家拒絕這項技術的原因可能很大程度基于SEO的需求。解決方案也很簡單，將Ajax只是作為提高用戶體驗的手段，而不是瀏覽網(wǎng)站必須的方法，即可解決SEO的問題（P.S. Facebook不需要SEO）。
整套方案包括：Link Controller, HistoryManager, BootLoader, Busy Indicator, CSS Unloading, Permanent link support, Resetting timer functions。這些方案本身沒有什么特殊的，大部分都可以顧名思義，需要解釋一下的可能是link controller，其含義是將標準的HTML LINK請求轉(zhuǎn)換為Ajax請求（通過綁定click事件）。Facebook的可貴之處是提供了這一整套完整的解決方案，***程度上保證了網(wǎng)站的可用性。
效果：
提高了10%-30%的網(wǎng)站傳輸時間，并提高了20%-30%的服務端頁面渲染速度。
使用范圍：
45%的Facebook頁面使用了此項技術。
PageCache
簡單的說，就是將訪問過的頁面緩存在客戶端。但我們知道，作為Facebook這樣交互性很強的網(wǎng)站，需要保障用戶能盡早的獲得更新后的信息，而不是給用戶展示一個毫無意義的過期頁面。
Facebook設計了一個框架來識別一個頁面是否來自于緩存（猜測：頁面***加載完畢后將所有Ajax的Callback和Result緩存在本地。Facebook頁面是基于Ajax獲取頁面內(nèi)容），若來自于緩存，通過Ajax來更新所需更新的模塊（猜測：通過JavaScript預先定義本頁面所需更新的div Id及對應的callback handler，并在頁面下載時同時下載下來）。
其提到了三種更新類型：增量更新，用戶復寫（例如用戶在頁面上回復了一則評論）及跨頁更新（例如在消息詳細頁面將一則消息標識為已讀，需將首頁的未讀消息數(shù)進行更新）。核心思路還是依據(jù)Ajax進行更新。具體思路為：
增量更新：只要頁面來自于緩存，即更新所有預定義的需增量更新的模塊。
用戶復寫：通過HistoryManager記錄用戶操作并在cache頁面讀取后重放所有被標記為“replayable”的操作。
跨頁更新：通過服務端Database API發(fā)送信號至客戶端將過期緩存標識為invalid（不清楚如何實現(xiàn)。也許是DB端提供一個開放的webservice，客戶端通過Ajax持續(xù)訪問此API來獲得此信息）。獲得了緩存過期信號后，通過Ajax更新需要更新的信息。
Facebook順帶提到了一個更新Ajax內(nèi)容避免頁面變化/閃爍的小技巧，就是先將需更新的地方設置為blank，而非直接更新其內(nèi)容。
效果：
加速了10倍的網(wǎng)站響應時間并節(jié)約了20%的服務端頁面渲染成本。
BigPipe
此項技術通過將頁面分割為各個Pagelets的方式，將整張頁面的獲取/渲染變成了并行的方式（感覺非常像iframe sets，但Facebook使用Ajax實現(xiàn)。）。此項技術是Quickling和PageCache的基石。此技術包含了服務端/客戶端兩方面，在前后端均打破了以往頁面的渲染形式。
實現(xiàn)細節(jié)：
Pagelet的Response為JSON格式，包括id,css,js,content,onload等屬性及相應內(nèi)容，收到后會通過預定義好的JS function來進行渲染。
Pagelet提供的高級功能：Pagelet的繼承，Phased Rendering（猜測：依據(jù)規(guī)則渲染，也就是依據(jù)Pagelet的Response進行渲染），跨Pagelet依賴（數(shù)據(jù)依賴，顯示依賴，JS依賴）。
BigPipe的三種模式：
◆一次渲染模式：即普通模式，支持搜索引擎，用來支持那些不支持JS的客戶端。
◆管線模式：即并行模式，并行請求，并即時渲染。
◆并行模式：并行請求，但在獲得所有請求的結(jié)果后再渲染。
效果：
提高了2倍的頁面響應時間。
擴展閱讀：世界***的PHP站點 Facebook后臺技術探秘
YouTube面臨的問題
每天2Billion的訪問。每分鐘上傳35小時的內(nèi)容?？蒠ouTube需要即時播放視頻！越快越好。
YouTube解決方案
1. 將JavaScript引用位置從頁首移至頁尾。
2. 直接嵌入Flash Player（YouTube之前使用JS來加載Flash Player）。通過頁尾的JS來判斷客戶端的Flash版本（或不支持Flash），來替換預先嵌入的Flash Player或內(nèi)容（如果需要的話），用來支持特定的客戶群。
效果：頁面渲染時間從～400ms降低為～200ms。Flash播放時間從～1200ms降低為～1100ms。
3. 預加載視頻連接： 通過使用JavaScript創(chuàng)建Image引用視頻內(nèi)容來與解析DNS并預開啟一個connection供之后使用。
效果：建立視頻連接的總時間從～260ms降低為～180ms。
4. 提供簡化版：這個很無聊，就是提供一個簡版。
效果：頁面加載時間從～1750ms降低為～1100ms。
5. UIX Widget系統(tǒng)：延遲加載非關鍵內(nèi)容。其實整段沒什么新意，大部分省略，無非是通過Ajax在頁面渲染完后再來動態(tài)加載非關鍵內(nèi)容。比較特別的是利用JS的事件冒泡，在最上層用一個handler來處理各種事件（優(yōu)點不詳。。也許只是代碼比較簡潔集中吧），通過CSS來標識和識別對應的handler。
Yahoo Mail
Yahoo如何構(gòu)建下一代的Mail系統(tǒng)？答案就是通過YUI3。Yahoo的技術絕對是***的，其已經(jīng)將Web前端技術發(fā)展到一個非常成熟的地步，照顧到Web的方方面面（數(shù)據(jù)壓縮，模塊化，高效CSS，非阻礙式JavaScript加載，靜態(tài)內(nèi)容提供，利用瀏覽器Cache等等），所以也鮮有創(chuàng)新了。某種程度上來說，F(xiàn)acebook的一些所謂創(chuàng)新也不過是后知后覺，Yahoo早已考慮并實現(xiàn)了這些方案，只是也許不是那么有針對性而已。
Baidu
感覺整體傾向于組織結(jié)構(gòu)介紹及一些比較過時的內(nèi)容。
Taobao
還在討論一些何時使用Ajax，何時不使用的問題。
相反的，淘寶的精益測試倒是引起了我的興趣，出自微軟的淘寶員工鶴云講述了淘寶是如何進行CI（持續(xù)集成）的。有一些經(jīng)驗例如代碼覆蓋率測試也給人一些啟發(fā)。
新浪博客
也是一些組織架構(gòu)，開發(fā)方式的內(nèi)容。介紹了一下新浪自己的JavaScript框架。并無太多亮點。
大概就總結(jié)了這么多吧，感覺還是國外在主導。國內(nèi)也在越來越重視這個方向，一些有實力的企業(yè)也做出了一些成績，但還是與國際潮流有差距，也許是重視程度的區(qū)別吧。歡迎大家補充討論。
【編輯推薦】
