2010 Web前端技術趨勢及總結

通過這段時間國內（百度，淘寶，新浪）及國外（Facebook，Youtube，Yahoo）各大公司的集中自曝，咱們能夠從中總結出2010 Web前端技術的一些趨勢。總的來講，隨着後端技術（存儲，併發，分佈式）的成熟，各大公司已經把重點從後端架構調整/建設轉移至前端（TTI時間，快速 發佈，帶寬利用率）。但做爲明星技術的HTML5/CSS3，都未正式成爲各公司的考慮重心，雖有所嘗試，但在關鍵功能上，均未成爲主力。這也W3C對當 前HTML5/CSS3標準現狀的表述：「不適宜用做生產環境」一致。

基本概念

Web前端技術的範圍

1. 編程語言/技術（HTML，JavaScript，CSS等）

2. 跨瀏覽器兼容性/支持（JS Framework，CSS Library）

3. 網絡傳輸性能（並行下載，帶寬利用率）

4. 瀏覽器渲染時間/性能（TTI即用戶可交互前等待時間，JS執行性能）

 

今年就我我的的感受，Facebook無疑又成爲了技術上的明星，在你們還在感慨其對於PHP的重大改進HipHop(Blocked inside China mainland)的時候，今年Facebook又在前端技術方面給你們帶來了驚喜。

Facebook面臨的問題

500M（Million）註冊用戶，50%天天至少訪問一次，用戶平均每日在線時間爲5小時25分鐘。帶寬及服務器壓力均很大。

Facebook的解決方案

Quickling

Facebook 提出了一個新名詞Ajaxify，顧名思義，就是將傳統的POST/GET轉換爲Ajax請求。優勢顯而易見，首先減小了沒必要要的HTML傳輸，只請求和 渲染頁面須要更新的部分，這就相應減小了所需傳輸的內容加快了內容送達至用戶的時間。而且也減小了服務端對HTML的沒必要要的渲染。Facebook也提 到了能夠減小session的重複load/unload。

使用Ajax也許不是什麼新鮮的新聞，你們拒絕這項技術的緣由可能很大程度基於SEO的需求。解決方案也很簡單，將Ajax只是做爲提升用戶體驗的手段，而不是瀏覽網站必須的方法，便可解決SEO的問題（P.S. Facebook不須要SEO）。

一些實現細節：

整 套方案包括：Link Controller, HistoryManager, BootLoader, Busy Indicator, CSS Unloading, Permanent link support, Resetting timer functions。這些方案自己沒有什麼特殊的，大部分均可以顧名思義，須要解釋一下的多是link controller，其含義是將標準的HTML LINK請求轉換爲Ajax請求（經過綁定click事件）。Facebook的難得之處是提供了這一整套完整的解決方案，最大程度上保證了網站的可用 性。

效果：

提升了10%-30% 的網站傳輸時間，並提升了20%-30%的服務端頁面渲染速度。

使用範圍：

45%的Facebook頁面使用了此項技術。

PageCache

簡單的說，就是將訪問過的頁面緩存在客戶端。但咱們知道，做爲Facebook這樣交互性很強的網站，須要保障用戶能儘早的得到更新後的信息，而不是給用戶展現一個毫無心義的過時頁面。

Facebook 設計了一個框架來識別一個頁面是否來自於緩存（猜想：頁面首次加載完畢後將全部Ajax的Callback和Result緩存在本地。Facebook頁 面是基於Ajax獲取頁面內容，參見BigPipe），若來自於緩存，經過Ajax來更新所需更新的模塊（猜想：經過JS預先定義本頁面所需更新的div Id及對應的callback handler，並在頁面下載時同時下載下來）。

其提到了三種更新類型：增量更新，用戶複寫（例如用戶在頁面上回復了一則評論）及跨頁更新（例如在消息詳細頁面將一則消息標識爲已讀，需將首頁的未讀消息數進行更新。）。核心思路仍是依據Ajax進行更新。具體思路爲：

增量更新：只要頁面來自於緩存，即更新全部預約義的需增量更新的模塊。

用戶複寫：經過HistoryManager記錄用戶操做並在cache頁面讀取後重放全部被標記爲「replayable」的操做。

跨 頁更新：經過服務端Database API發送信號至客戶端將過時緩存標識爲invalid（不清楚如何實現。也許是DB端提供一個開放的webservice，客戶端經過Ajax持續訪問 此API來得到此信息）。得到了緩存過時信號後，經過Ajax更新須要更新的信息。

Facebook順帶提到了一個更新Ajax內容避免頁面變化/閃爍的小技巧，就是先將需更新的地方設置爲blank，而非直接更新其內容。

效果：

加速了10倍的網站響應時間並節約了20%的服務端頁面渲染成本。

BigPipe

此 項技術經過將頁面分割爲各個Pagelets的方式，將整張頁面的獲取/渲染變成了並行的方式（感受很是像iframe sets，但Facebook使用Ajax實現。）。此項技術是Quickling和PageCache的基石。此技術包含了服務端/客戶端兩方面，在前 後端均打破了以往頁面的渲染形式。

實現細節：

Pagelet的Response爲JSON格式，包括id,css,js,content, function來進行渲染。

Pagelet提供的高級功能：Pagelet的繼承，Phased Rendering（猜想：依據規則渲染，也就是依據Pagelet的Response進行渲染），跨Pagelet依賴（數據依賴，顯示依賴，JS依賴）。

BigPipe的三種模式：

一次渲染模式：即普通模式，支持搜索引擎，用來支持那些不支持JS的客戶端。

管線模式：即並行模式，並行請求，並即時渲染。

並行模式：並行請求，但在得到全部請求的結果後再渲染。

效果：

提升了2倍的頁面響應時間。

YouTube面臨的問題

天天2Billion的訪問。每分鐘上傳35小時的內容。可YouTube須要即時播放視頻！越快越好。

YouTube解決方案

1. 將JS引用位置從頁首移至頁尾。

2. 直接嵌入Flash Player（YouTube以前使用JS來加載Flash Player）。經過頁尾的JS來判斷客戶端的Flash版本（或不支持Flash），來替換預先嵌入的Flash Player或內容（若是須要的話），用來支持特定的客戶羣。

效果：頁面渲染時間從～400ms下降爲～200ms。Flash播放時間從～1200ms下降爲～1100ms。

3. 預加載視頻鏈接： 經過使用JS建立Image引用視頻內容來與解析DNS並預開啓一個connection供以後使用。

效果：創建視頻鏈接的總時間從～260ms下降爲～180ms。

4. 提供簡化版： 這個很無聊，就是提供一個簡版。

效果：頁面加載時間從～1750ms下降爲～1100ms。

5. UIX Widget系統：延遲加載非關鍵內容。其實整段沒什麼新意，大部分省略，無非是經過Ajax在頁面渲染完後再來動態加載非關鍵內容。比較特別的是利用 JS的事件冒泡，在最上層用一個handler來處理各類事件（優勢不詳。。也許只是代碼比較簡潔集中吧），經過CSS來標識和識別對應的 handler。

Yahoo Mail

Yahoo如何構建下一代的Mail系統？答案就是經過YUI3。Yahoo 的技術絕對是最優的，其已經將web前端技術發展到一個很是成熟的地步，照顧到web的方方面面（數據壓縮，模塊化，高效CSS，非阻礙式JS加載，靜態 內容提供，利用瀏覽器cache等等），因此也鮮有創新了。某種程度上來講，Facebook的一些所謂創新也不過是後知後覺，Yahoo早已考慮並實現 了這些方案，只是也許不是那麼有針對性而已。

Baidu

感受總體傾向於組織結構介紹及一些比較過期的內容。若有興趣可移駕至http://v.youku.com/v_show/id_XMjE5OTM0NTA4.html 自行觀賞。

Taobao

http://www.docin.com/p-54097869.html 沒有什麼特別值得一提的內容。須要的同窗可自行觀賞。

相反的，淘寶的精益測試卻是引發了個人興趣，出自微軟的淘寶員工鶴雲講述了淘寶是如何進行CI（持續集成）的。有一些經驗例如代碼覆蓋率測試也給人一些啓發。感興趣的同窗可移駕至http://www.infoq.com/cn/presentations/hy-tabao-lean-test 觀賞。

新浪博客

也是一些組織架構，開發方式的內容。介紹了一下新浪本身的JS框架。並沒有太多亮點。有興趣的移駕http://v.youku.com/v_show/id_XMjE5OTYzMTI4.html 自行觀賞。

 

大概就總結了這麼多吧，感受仍是國外在主導。國內也在愈來愈重視這個方向，一些有實力的企業也作出了一些成績，但仍是與國際潮流有差距，也許是重視程度的區別吧。

歡迎你們補充討論。