基本概念
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轉換為Ajax請求。優(yōu)點顯而易見，首先減少了不必要的HTML傳輸，只請求和渲染頁面需要更新的部分，這就相應減少了所需傳輸?shù)膬热菁涌炝藘热菟瓦_至用戶的時間。并且也減少了服務端對HTML的不必要的渲染。Facebook也提到了可以減少session的重復load/unload。
使用Ajax也許不是什么新鮮的新聞，大家拒絕這項技術的原因可能很大程度基于SEO的需求。解決方案也很簡單，將Ajax只是作為提高用戶體驗的手段，而不是瀏覽網(wǎng)站必須的方法，即可解決SEO的問題（P.S. Facebook不需要SEO）。
一些實現(xiàn)細節(jié)：
整套方案包括：Link Controller, HistoryManager, BootLoader, Busy Indicator, CSS Unloading, Permanent link support, Resetting timer functions。這些方案本身沒有什么特殊的，大部分都可以顧名思義，需要解釋一下的可能是link controller，其含義是將標準的HTML LINK請求轉換為Ajax請求（通過綁定click事件）。Facebook的可貴之處是提供了這一整套完整的解決方案，最大程度上保證了網(wǎng)站的可用性。
效果：
提高了10%-30% 的網(wǎng)站傳輸時間，并提高了20%-30%的服務端頁面渲染速度。
使用范圍：
45%的Facebook頁面使用了此項技術。
PageCache
簡單的說，就是將訪問過的頁面緩存在客戶端。但我們知道，作為Facebook這樣交互性很強的網(wǎng)站，需要保障用戶能盡早的獲得更新后的信息，而不是給用戶展示一個毫無意義的過期頁面。
Facebook設計了一個框架來識別一個頁面是否來自于緩存（猜測：頁面首次加載完畢后將所有Ajax的Callback和Result緩存在本地。Facebook頁面是基于Ajax獲取頁面內容，參見BigPipe），若來自于緩存，通過Ajax來更新所需更新的模塊（猜測：通過JS預先定義本頁面所需更新的div Id及對應的callback handler，并在頁面下載時同時下載下來）。
其提到了三種更新類型：增量更新，用戶復寫（例如用戶在頁面上回復了一則評論）及跨頁更新（例如在消息詳細頁面將一則消息標識為已讀，需將首頁的未讀消息數(shù)進行更新。）。核心思路還是依據(jù)Ajax進行更新。具體思路為：
增量更新：只要頁面來自于緩存，即更新所有預定義的需增量更新的模塊。
用戶復寫：通過HistoryManager記錄用戶操作并在cache頁面讀取后重放所有被標記為“replayable”的操作。
跨頁更新：通過服務端Database API發(fā)送信號至客戶端將過期緩存標識為invalid（不清楚如何實現(xiàn)。也許是DB端提供一個開放的webservice，客戶端通過Ajax持續(xù)訪問此API來獲得此信息）。獲得了緩存過期信號后，通過Ajax更新需要更新的信息。
Facebook順帶提到了一個更新Ajax內容避免頁面變化/閃爍的小技巧，就是先將需更新的地方設置為blank，而非直接更新其內容。
效果：
加速了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等屬性及相應內容，收到后會通過預定義好的JS function來進行渲染。
Pagelet提供的高級功能：Pagelet的繼承，Phased Rendering（猜測：依據(jù)規(guī)則渲染，也就是依據(jù)Pagelet的Response進行渲染），跨Pagelet依賴（數(shù)據(jù)依賴，顯示依賴，JS依賴）。
BigPipe的三種模式：
一次渲染模式：即普通模式，支持搜索引擎，用來支持那些不支持JS的客戶端。
管線模式：即并行模式，并行請求，并即時渲染。
并行模式：并行請求，但在獲得所有請求的結果后再渲染。
效果：
提高了2倍的頁面響應時間。
YouTube面臨的問題
每天2Billion的訪問。每分鐘上傳35小時的內容�？蒠ouTube需要即時播放視頻！越快越好。
YouTube解決方案
1. 將JS引用位置從頁首移至頁尾。
2. 直接嵌入Flash Player（YouTube之前使用JS來加載Flash Player）。通過頁尾的JS來判斷客戶端的Flash版本（或不支持Flash），來替換預先嵌入的Flash Player或內容（如果需要的話），用來支持特定的客戶群。
效果：頁面渲染時間從～400ms降低為～200ms。Flash播放時間從～1200ms降低為～1100ms。
3. 預加載視頻連接： 通過使用JS創(chuàng)建Image引用視頻內容來與解析DNS并預開啟一個connection供之后使用。
效果：建立視頻連接的總時間從～260ms降低為～180ms。
4. 提供簡化版： 這個很無聊，就是提供一個簡版。
效果：頁面加載時間從～1750ms降低為～1100ms。
5. UIX Widget系統(tǒng)：延遲加載非關鍵內容。其實整段沒什么新意，大部分省略，無非是通過Ajax在頁面渲染完后再來動態(tài)加載非關鍵內容。比較特別的是利用JS的事件冒泡，在最上層用一個handler來處理各種事件（優(yōu)點不詳。。也許只是代碼比較簡潔集中吧），通過CSS來標識和識別對應的handler。
Yahoo Mail
Yahoo如何構建下一代的Mail系統(tǒng)？答案就是通過YUI3。Yahoo的技術絕對是最優(yōu)的，其已經(jīng)將web前端技術發(fā)展到一個非常成熟的地步，照顧到web的方方面面（數(shù)據(jù)壓縮，模塊化，高效CSS，非阻礙式JS加載，靜態(tài)內容提供，利用瀏覽器cache等等），所以也鮮有創(chuàng)新了。某種程度上來說，F(xiàn)acebook的一些所謂創(chuàng)新也不過是后知后覺，Yahoo早已考慮并實現(xiàn)了這些方案，只是也許不是那么有針對性而已。
Baidu
感覺整體傾向于組織結構介紹及一些比較過時的內容。如有興趣可移駕至http://v.youku.com/v_show/id_XMjE5OTM0NTA4.html 自行觀賞。
Taobao
還在討論一些何時使用Ajax，何時不使用的問題。略過不提。有興趣的可以移駕http://ued.taobao.com/blog/2007/12/20/d2-2/ 自行觀賞。
相反的，淘寶的精益測試倒是引起了我的興趣，出自微軟的淘寶員工鶴云講述了淘寶是如何進行CI（持續(xù)集成）的。有一些經(jīng)驗例如代碼覆蓋率測試也給人一些啟發(fā)。感興趣的同學可移駕至http://www.infoq.com/cn/presentations/hy-tabao-lean-test 觀賞。
新浪博客
也是一些組織架構，開發(fā)方式的內容。介紹了一下新浪自己的JS框架。并無太多亮點。有興趣的移駕http://v.youku.com/v_show/id_XMjE5OTYzMTI4.html 自行觀賞。
大概就總結了這么多吧，感覺還是國外在主導。國內也在越來越重視這個方向，一些有實力的企業(yè)也做出了一些成績，但還是與國際潮流有差距，也許是重視程度的區(qū)別吧。
歡迎大家補充討論。
喜歡 
頂
難過
囧
圍觀
無聊
