原作鏈接：The Making of Fastbook: An HTML5 Love Story
當我們開始這個現在被稱爲Sencha的東西時，我們對WEB打了一個賭：我們賭當今的應用程序開發僅僅需要瀏覽器、一組優秀的框架和一套出色的工具。有了這三樣武器，我們知道開發者們能夠開發出用戶喜歡的應用程序。HTML5的問世讓這一切變得更加有趣，它讓開發者們擁有更多的工具來把瀏覽器當作應用開發的平臺，而不僅是頁面渲染引擎。面對這一機遇，開發者們激流勇進，應用程序如雨後春筍般涌現出來——包括桌面和移動端——充分發揮了HTML5使用WEB標準創建讓人驚歎的應用程序的能力。
所以，當馬克·扎克伯格說“HTML5還沒有準備好”時，我們對此是不敢苟同的。
我們認爲：Facebook的移動應用反應遲鈍並不能歸咎於HTML5。我們清楚智能手機上的瀏覽器有多強大，以及HTML5向我們展現了多麼豐富的能力。我們看到了最新一代的移動設備——至少運行着iOS 5 和 Android 4.1 ——正推動HTML5不斷實現更加出色的表現。但是最重要的是，我們已經看到我們的用戶使用HTML5創造出了多麼不可思議的應用。
“So, when Mark Zuckerberg said HTML5 wasn’t ready, we took a little offense to the comment.”
對於爲什麼Facebook的移動團隊遇到了問題，我們有着各自的疑慮，因爲這印證了一種常見的模式。在Sencha，我們開發框架和工具供應用程序開發者們使用，所以我們對使用HTML5開發應用程序的團隊有很深入的瞭解。當一個團隊在使用HTML5開發遭遇問題時，通常是因爲他們用開發“網站”的方法來開發應用程序，而且經常沒有使用正確的工具和架構。我們懷疑這正是Facebook的HTML5應用遭遇問題的原因所在。應用程序表現出了它的常見症狀——緩慢的加載、新鮮事（原文：News Feed）中不連續的用戶體驗、低幀率。
在任何情況下，我們都認爲HTML5實際上已經準備好了，而且我們想證明這個事實。所以我們決定以在業餘時間重新建設Facebook移動應用中具有挑戰性的部分爲己任。今天，我們向你介紹Sencha Fastbook，用技術證明HTML5可以有多快，並且對於應對最棘手的應用程序挑戰，它已經迫不及待了。
接下來這段四分鐘的視頻帶你快速領略Sencha Fastbook，並且將我們的HTML5應用和iOS以及Android上的本地Facebook應用（5.2版本和1.9.12版本是我們製作此視頻時（12月10日）的最新版本）面對面地一決高下。本文的剩餘部分我們將深入探討Fastbook的技術細節。
（本譯文中的“本地”二字即原文中的“native”，似乎也譯作“原生”，譯者知識淺薄，暫時分不清楚，在此且用“本地”）
（譯者：視頻在vimeo上，所以……可能需要一些功夫才能看到……地址：http://player.vimeo.com/video/55486684?title=0&byline=0&badge=0）
近距離觀察“本地”Facebook 應用程序
扎克伯格稱HTML5“尚未準備好（原文：just wasn’t there）”，於是我們決定深入地研究一下iOS上的最新版Facebook 本地應用，以儘量準確地理解扎克伯格的“尚未準備好”，並以此作爲我們的工程的開始。我們把一部iPhone手機連接到了電腦上的WEB調試程序，以觀察Facebook應用程序所產生的HTTP流量。最讓我們感到震驚的是：這個應用程序的很大一部分都是由原始的HTML頁面構成的。新鮮事（原文：News Feed）和資料頁面已經轉換爲本地程序，但是程序的許多其他用戶界面只是簡單地向 m.facebook.com 發送了HTTP GET請求。目前的“本地”Facebook應用實際是一個混合的WEB/本地應用：由 m.facebook.com 渲染、由UIWebView呈現的內容，和本地的 Objective C 組件混合在一起。
重新實現新鮮事板塊
在我們看到了本地Facebook應用是怎樣工作的之後，我們清楚地認識到，用戶體驗中最難實現的部分是新鮮事（原文：News Feed，下同）。因爲這需要處理由十億用戶以完全無法預料的方式上傳的無窮無盡的內容，這對於最老練的開發者們都是一個棘手的問題，無論他們使用何種技術來實現。
當我們使用HTML5重新實現新鮮事時，我們真心希望我們能夠確保它應有的流暢體驗。爲此我們進一步擴充和增強了Sencha Touch框架的核心。
首先我們通過實現一個無窮列表組件來處理未知大小的內容。僅僅很小的一組DOM節點就構成了實際可見的屏幕區域。在加載需要加載之前/之後的內容時，這組節點將不斷反覆地被使用。因此，不管存儲器中的數據有多少，內存的使用都被降到了最小。實現這一點並不難。要在處理新鮮事這樣複雜和多種多樣的數據時保持快速纔是真正的挑戰。瓶頸在於瀏覽器需要運行的核心進程：佈局和整合。
開發框架的經驗告訴我們，即便一個小模塊自身能夠很好的運行，但是當你把它放到一個比它本身大得多的應用中時，它的性能往往會捉襟見肘。隨着應用程序的逐漸龐大，DOM（文檔對象模型）樹也在不斷長大；隨着DOM樹越來越大，瀏覽器計算佈局所需的時間也就越來越長，程序性能就會下降。而且，隨着可見內容的增多，瀏覽器整合每個佈局（譯者：可能是指上一段所說的用來構成可視區域而重複使用一組DOM節點）時的性能也會明顯地下降。我們需要能夠讓應用在龐大的DOM樹下更加強健有力。
將本地Facebook應用和我們的Sencha Fastbook應用做面對面的比較
Fastbook是第一個使用全新的“沙盒容器”（原文：Sandbox Container）來分離複雜的視圖，將其放到自己的內嵌框架（iframe）中渲染，從而分割整個DOM樹的。這種特殊的容器不需要任何其他的應用程序層的處理，從而實現了與開發者的無縫對接（即所有添加到這個容器中的組件都將自動“沙盒化”（原文：sandboxed））。但是這也是有代價的：事件、定位、樣式和JavaScript代碼不得不作爲主窗口（原文：parent window）和沙盒（原文：child sandboxes）之間的代理。這是很複雜的，所以如果沒有一個強勁且架構合理的框架，這是很難實現的。沙盒允許佈局以分離的方式呈現，這樣可以讓主體的DOM樹儘可能的輕便。想要取得平衡以使其發揮最大功力，使用沙盒容器必須聰明得當。
就Fastbook而言，新鮮事、時間軸（原文：Timeline）和故事（原文：Story）的界面是單獨在各自的沙盒中呈現的。由於在渲染內容時所有的DOM元素都以很高的頻率重複利用，大量的reflow（譯者：瀏覽器渲染樣式時改變佈局的一種行爲。譯者google了reflow的相關資料，暫且如此理解。歡迎指正！）是不可避免的。關鍵在於讓這個進程儘可能少的佔用資源。使用沙盒容器的方法讓新鮮事表現得彷彿是單獨運行的，而實際上它仍然只是一個比它大的多的DOM樹的一部分。
“Sandboxing enables the News Feed to perform as if it is standalone, while actually is still a part of the much bigger DOM tree.”
接下來，我們將更深層的部分集成到了我們的TaskQueue（譯者：任務隊列），即Sencha Touch最近引入的一個特性。TaskQueue防止了對DOM樹的交叉反覆的讀寫請求，消除了任何不必要的呈現。結合新的沙盒技術，這一特性顯著地減少了呈現複雜視圖如時間軸、新鮮事時的性能代價。
緊接着我們添加了AnimationQueue（譯者：動畫隊列），這是一個全新的類，能夠對所有的動畫和事件做出響應，同時能夠將較繁重的任務安排在之後CPU較空閒的時候執行。它角色就像是框架的交通警察，權衡着不同操作的優先級，確保應用程序保持響應。當應用在執行動畫時，會暫停較低優先級的功能。當程序空閒時，AnimationQueue再執行那些較低優先級的任務。比如，當用戶在快速地滑動新鮮事頁面時，圖片的加載和渲染會被暫停，直至程序空閒，以此提升滑動頁面時的體驗。並且，一個高速的計時器會把較繁重的任務以無間隔的方式漸次地釋放執行。這樣保證了觸屏事件一直都可以儘快地得到響應。
另一方面，你不想禁止一些功能性的類，比如獲取更多數據來顯示在列表中。爲了確保這樣不減慢屏幕的滑動，我們使用了Web Workers（HTML5的新特性，是運行在後臺的JavaScript，獨立於其他腳本，不會影響頁面的性能）。這樣就把XHR/RPC通信和UI線程分離開來。使用Web Workers節省網絡請求成本和JSON編碼/解碼在現如今的多核設備上有着廣泛的應用。
以上就是我們在創造Fastbook時的技術要點，正是它們讓我們能夠使用純淨的開放標準的WEB技術造就Fastbook的出色表現。藉此我們向你展示瞭如何使用HTML5的各種特性來實現一個像Fastbook一樣驚人的應用，這也讓我們興奮異常。
福利
（原文：Bonus Points）
一個有趣的事情是，在我們研究iOS上的本地Facebook應用的網絡性能時，我們發現API調用返回了大量的原始數據給客戶端。爲了呈現新鮮事中的條目而向https://graph.facebook.com/graphql/ 發起的API調用，就是一個典型的例子。平均每10個條目就要傳送15KB到20KB的用gzip壓縮過的JSON數據，其中大多數並沒有真的被顯示出來。
爲了演示怎樣能夠優化網絡傳輸，我們設立了一個代理服務器，用來清理和解析從Facebook FQL API返回的原始數據。於是，在呈現相同的內容時，Fastbook傳輸的數據量遠小於本地應用程序：在顯示新鮮事時，最少僅傳送了相當於本地應用10%的數據。代理服務器允許我們卸載一些更加普通的任務，例如內容格式化，並將其篩選到服務器端。
同時，你可能注意到了本地iOS應用和Fastbook在滾動持續時間（原文：scrolling declaration time）上的差別。在本地應用中，滾動持續了大約3秒。我們決定增加摩擦力來將動畫持續時間減少至1.4秒。這樣不僅使得頁面內容可以更快地加載就緒，而且爲程序騰出了更多的空閒時間，以在用戶閱讀現有內容時緩存更多的條目供稍後閱讀。
親身體驗一下吧
（原文：Try It Yourself）
Fastbook不是Facebook應用的替代品。它是一個技術示例，向世人展示，只要使用正確的方法，輔以合適的框架和工具，開發者們能夠用HTML5來做什麼。如果你一直都想知道，HTML5已經準備好了嗎？把Fastbook下載到智能手機（我們推薦至少爲iOS 5或Android 4.1）上試試吧。你會發現，當你把瀏覽器當作一個應用程序開發平臺來看待，並且充分利用HTML5的強大特性時，即使是最複雜的應用程序也可以使用HTML5來實現。
快快動手敲起來！
（原文：Shut Up and Code）
如果你被激勵了，想要和我們一起向世人展示HTML5能做什麼，我們邀請你參與我們今天發起的“HTML5已準備好”應用程序辯論會（HTML5 Is Ready App Contest）。我們提供超過$20,000的經費和先進設備，讓那些有志於使用HTML5輔以強大工具向人們展示讓人歎爲觀止的應用的開發者大展拳腳。完整的規則和獎勵在這裏。
（譯者：哈哈。鬍子
菜鳥譯製，差錯難免，歡迎指正！
）
（轉載請註明出處：http://blog.hudidit.com/?p=270）
（滿懷敬意地再次附上原作鏈接）