编写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一套开发库，非常类似我在这篇文章里描述的思想。笔者还没有在任何深度研究，但名称是伟大的:)
使用一套类似的框架吗？有你最喜欢的？觉得笔者缺少一个重要的框架吗？让笔者知道！