构建移动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瘾。