Web前端技術趨勢：HTML5仍不宜用做生產

通過這段時間國內(百度，淘寶，新浪)及國外(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,onload等屬性及相應內容，收到後會經過預約義好的JS 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_... 自行觀賞。
　　Taobao
　　還在討論一些什麼時候使用Ajax，什麼時候不使用的問題。略過不提。有興趣的能夠移駕http://ued.taobao.com/blog/20... 自行觀賞。
　　相反的，淘寶的精益測試卻是引發了個人興趣，出自微軟的淘寶員工鶴雲講述了淘寶是如何進行CI(持續集成)的。有一些經驗例如代碼覆蓋率測試也給人一些啓發。感興趣的同窗可移駕至http://www.infoq.com/cn/prese... 觀賞。
原文來自：http://tech.it168.com/a2010/1...
轉載於猿2048:➮《Web前端技術趨勢：HTML5仍不宜用做生產》