構建移動Web應用程序的技術堆棧
編寫web應用程序時，有很多的技術決策。筆者最近回來編寫現代Web應用程序，并希望總結一些曾經在開發周期過程中做了記錄零散的想法。這篇文章是關于一套對筆者最近開發的項目有幫助的框架。筆者重溫了一些最重要的框架類型，其中每一個可以展開來寫一篇文章。這并不是一個廣泛的現有產品相比，只是一個筆者最近使用的部分技術。
雖然筆者的重點是移動優先， 筆者認為，這套技術可以應用在一般的web應用程序。 筆者的決定和數據支持考慮了幾個要求：
基于JavaScript(CoffeeScript，Dart，絕對值得認真看看，但我想避免引起激進選擇)
必須在現代瀏覽器工作良好(IOS ***ndroid 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模板已經逐步形成一個奇怪的約定，嵌入模板的內容到腳本標記內：。使用所有的模板引擎的基本做法是作為一個字符串來加載模板，構建模板參數，然后通過模板引擎模板和參數運行。
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一套開發庫，非常類似我在這篇文章里描述的思想。筆者還沒有在任何深度研究，但名稱是偉大的:)
使用一套類似的框架嗎?有你最喜歡的?覺得筆者缺少一個重要的框架嗎?讓筆者知道!
