構建移動Web應用程序的技術堆棧

　　編寫web應用程序時，有不少的技術決策。筆者最近回來編寫現代Web應用程序，並但願總結一些曾經在開發週期過程當中作了記錄零散的想法。這篇文章是關於一套對筆者最近開發的項目有幫助的框架。筆者重溫了一些最重要的框架類型，其中每個能夠展開來寫一篇文章。這並非一個普遍的現有產品相比，只是一個筆者最近使用的部分技術。

　　雖然筆者的重點是移動優先， 筆者認爲，這套技術能夠應用在通常的web應用程序。 筆者的決定和數據支持考慮了幾個要求：

• 基於JavaScript（CoffeeScript，Dart，絕對值得認真看看，但我想避免引發激進選擇）
• 必須在現代瀏覽器工做良好（IOS 5，Android 4）

　　挑選一個MVC框架

　　在本地UI的應用程序開發中模型視圖控制器模式已經使用了幾十年。其基本思路是分開表示層（用戶界面，動畫，輸入）和數據層（存儲，通信，數據）。有其餘相似的模式，如MVVM的（模型視圖的ViewModel），但主要的想法是在展示和數據層之間有定義良好的分離，爲了更乾淨的代碼和長期的維護：

　　有許多JavaScript模型視圖控制器框架的產品。有一些如Backbone.js和Spine.js是用純代碼編寫的，而其餘像Knockout.js和Angular依靠DOM數據屬性綁定。那些依賴HTML5數據DOM屬性的分離視圖和數據的MVC系統被認爲是不對的。這不包括Knockout.js和Angular框架。 spine.js比 CoffeeScript更容易，根據我最初的要求排除了CoffeeScript。

　　backbone.js比大多數框架更受歡迎（也許除JavaScriptMVC外，彷佛像一個死的項目），還設有一個成長的開源社區。對於筆者的應用程序棧，筆者選擇了Backbone.js。欲瞭解更多有關挑選一個MVC的信息，檢出TodoMVC，它使用不一樣的MVC框架實現相同的Todo應用程序。還能夠看到這個MVC框架的比較，它強烈同意Ember.js，一個出現相對較晚的框架。筆者還沒有有機會使用它，但它在個人清單上。

　　選擇一個模板引擎

　　要在網絡上創建一個嚴謹的應用程序，你不可避免地要創建大型的DOM樹。若是使用JavaScript API來操做DOM，不如使用基於字符串的模板編寫html來得更簡單高效。JS模板已經逐步造成一個奇怪的約定，嵌入模板的內容到腳本標記內：<script id="my-template" type="text/my-template-language">... </script>。使用全部的模板引擎的基本作法是做爲一個字符串來加載模板，構建模板參數，而後經過模板引擎模板和參數運行。

　　backbone.js依賴於Underscore.js，它有一個有些侷限的有詳細語法的模板引擎。有其餘可供選擇，包括jQuery模板，Handlebars.js，Mustache.js和許多其餘的。 jQuery模板已經被jQuery團隊準備廢棄了，因此我沒有考慮這個選項。Mustache是一個跨語言的模板系統，具備簡單和成熟的決定，以支持儘量少的邏輯。事實上，在Mustache最複雜的構造是遍歷一個對象數組的方式。 handlebars.js建於Mustache之上，加入一些不錯的功能，如預編譯模板和模板表達式。對於筆者而言，並不須要這些額外的功能，而後選擇了筆者的模板平臺Mustache.js。

　　在通常狀況下，筆者的印象是，現有的模板框架可比較的功能是不多的，所以決定在很大程度上是我的喜愛的問題。

　　選擇一個CSS框架

　　CSS框架是必不可少的工具，用來擴展CSS如變量等方便的功能集，建立分層的CSS選擇器的方式，以及一些更先進的功能。這實質上是建立了一個新的語言：CSS的加強版本（姑且稱之爲它的CSS++）。爲便於開發，一些框架在瀏覽器中實現了一個JavaScript的CSS+ +解釋器，而一些其餘框架讓你監控一個CSS+ +文件，並每當有更改就編譯它。全部的CSS框架應提供命令行工具來編譯CSS++成CSS給開發。

　　像模板語言同樣，也有不少選擇。筆者的選擇是出於我的的語法偏好，筆者更喜歡SCSS，由於它避免了像@怪異的語法。 SCSS的一個缺點是，它並無附帶一個JavaScript解釋器（有一個非官方的，筆者尚未試過），但可用命令行監視器。還有其餘相似的CSS框架，包括LESS和Stylus。

　　如何佈局視圖Views

　　HTML5提供了多種方式來佈局內容，MVC框架對這些佈局技術的使用無要求，留給開發者你一點困難。

　　通常來講，對documents相對位置是合適的，但對apps除外。應避免絕對定位，像tables。許多Web開發人員已經轉向使用float屬性對準元素的，可是這只是第二理想的構建應用程序的觀點，由於它沒有相似應用程序的佈局，致使許多奇怪的問題和臭名昭著的clearfix hacks。

　　通過多年來的佈局與各類網絡技術的實驗，筆者認爲一個固定的定位和flex box的模型相結合是移動互聯網應用的理想選擇。筆者使用的是將屏幕上的界面元素（頁眉，側邊欄，頁腳等）固定定位。flex box 模型對在頁面上佈局堆疊視圖（Stacked views）是很棒的（水平或垂直的）。只有CSS盒模型明顯地對界面設計進行了優化，很是相似Android的LinearLayout 管理器。對於有關flex box模型的更多信息，請閱讀保羅的文章，並注意該規範正在由一個新的，非向後兼容的版本取代。

　　自適應Web應用程序

　　最後一節，在這個問題上：筆者大力提倡建立設備特定的用戶界面。這意味着爲不一樣的形式屏幕從新編寫視圖代碼部分。幸運的是，MVC模式，使得它比較容易爲多個視圖（如平板電腦和手機）重用業務邏輯model。

　　iOS Flipboard演示了這個想法很好，它爲平板電腦和手機用戶提供了爲每一個設備外形高度定製的體驗。手機用戶界面特別爲垂直點擊進行了優化，容許單手使用。平板的UI讓兩手反面持有設備工做良好。

　　輸入的考慮

　　移動用戶與您的應用程序進行交互的主要方式是經過用手指觸摸屏幕。這與基於鼠標的互動至關不一樣，由於有額外9點在跟蹤屏幕，這意味着開發人員編寫移動應用程序時，須要拋棄移動鼠標事件。此外，在移動鼠標事件有300ms延遲點擊的問題（有一個著名的觸摸式的解決方法）。在移動瀏覽器使用這些事件的詳細信息，請參閱個人觸摸事件的文章。

　　只有S /mousedown/ touchstart/全部的事件處理程序是不夠的。有 一套全新的用戶期待的觸摸設備手勢，如點擊、經過瀏覽圖像列表導航。雖然蘋果公司有一個不爲人知的手勢API，但沒有在網頁上作手勢檢測的開放規範。咱們真的須要一個JavaScript手勢檢測庫，去處理一些較常見的手勢。

　　如何使其離線工做

　　對於一個應用程序脫機工做，你須要確保兩件事情真實：

• Assets資產可用（經過AppCache，文件系統API等）
• 數據是可用的（經過LocalStorage，WebSQL，IndexedDB等）

　　實踐中，在網絡上創建離線應用是一個棘手的問題。通常來講脫機功能應從一開始就加入你的應用程序。讓現有Web應用程序沒有顯着的重寫代碼運行在離線狀態下是特別困難的。此外，脫機技術還有各類未知的存儲限制，並且未知超出限制時會發生什麼不肯定的行爲。最後，在離線的技術堆棧還有一些技術問題，最顯着的是AppCache，正如我在之前的文章提到。

　　寫真正的離線功能的應用程序是一個很是有趣的方法是「離線優先」。換句話說，若是沒有互聯網鏈接所有寫入本地，當存在互聯網鏈接，實現同步數據同步層。在Backbone.js MVC模型，這能夠很好地適應自定義Backbone.sync適配器。

　　單元測試

　　單元測試您的UI是有困難的。然而，由於你使用MVC的模型，它是徹底隔離的UI和數據結果，所以，可方便測試。QUnit是一個至關不錯的選擇，特別是由於它容許使用它的start（）和stop（）方法單元測試異步代碼。

　　總結

　　總之，筆者使用Backbone.js 做爲 MVC 框架，Mustache.js作爲模板，SCSS做爲CSS框架，CSS的Flex box展示界面views，自定義觸摸事件和QUnit單元測試工具，來寫筆者的移動Web應用程序。脫機支持，筆者仍然嘗試用各類技術，並但願將來繼續寫篇文章。雖然筆者強烈相信有必要在這裏列出每種工具（如MVC），筆者也相信，筆者在這裏描述的許多具體的技術是能夠互換的（如Handlebars 和 Mustache）。

　　還有一件事：2012年1月17日，Thorax宣佈發佈。這是一個基於Backbone一套開發庫，很是相似我在這篇文章裏描述的思想。筆者尚未在任何深度研究，但名稱是偉大的:)

　　使用一套相似的框架嗎？有你最喜歡的？以爲筆者缺乏一個重要的框架嗎？讓筆者知道！

　　來源：英文原文，中文編譯：IT癮。