移动端开发：使用jQuery Mobile还是Zepto
jQuery Mobile和Zepto是移动端的js库。jQuery Mobile相当于PC端的jQuery UI，它提供了很多页面的UI库，能够很快的开发出漂亮的界面，适合公司没有UI设计师的前端开发人员来进行移动端的开发。Zepto相当于PC端的jQuery，它提供了很多方法和功能，能够很快的实现各种需求和功能，适合公司有UI设计师的前端开发人员来进行移动端的开发。
jQuery Mobile性能上没有zepto好。
zepto.js是一个专为mobile WebKit浏览器(如：Safari和Chrome)而开发的一个JavaScript框架。它标榜自己在其简约的开发理念，能够帮助开发人员简单、快速地完成开发交付任务。更重要的是这个JS框架，是超轻量级的，只有5KB。zepto.js的语法借鉴并且兼容 jQuery。
jQuery Mobile这个框架能够帮助你快速开发出支持多种移动设备的Mobile应用用户界面。
jQuery Mobile不仅会给主流移动平台带来jQuery核心库，而且会发布一个完整统一的jQuery移动UI框架。虽然jQuery Mobile相对较新，但开发人员可以用jQuery Mobile为许多移动设备（包括智能手机和平板电脑）开发网站应用程序，RSS阅读器等应用。
jQuery Mobile是目前最流行的一个移动开发的框架，文档丰富，社区活跃，有很多的UI控件供我们使用，并且提供对多页面的支持（通过Ajax方式读取内容，并提供页面切换的过渡动画）。我认为jQuery Mobile的最强大之处就在于其UI方面的支持，但这一部分恰恰不是我所需要的，它对UI的限制比较多。Sencha Touch是ExtJs的移动版，对于不熟悉ExtJs的人来说有一定的学习成本。
jQuery Mobile的缺点，主要有两点：一是重，二是UI限制太大。
我们选择了zepto.js作为底层库，使用sea.js进行模块的管理和发布，当然也可以使用requirejs来进行模块的管理和发布，requirejs比seajs的对应的工具多一些，因为requirejs是外国的，而其他相应的工具也是外国的，因此使用seajs，相对应的工具会少一些。但是开发起来容易一些，都是中文资料。此外，我们使用backbone.js为基础的MVC架构，用来剥离应用的数据部分；使用underscore.js做为前端模板引擎（backbone重度依赖）；使用iScroll.js为我们提供模拟滚动的功能（此库在低端移动设备上，反应慢）。这些都是一些专业的“小库”，很适合移动端的开发。当然，具体情况需要具体分析，没有万能的框架，只有万能的开发者。如果时间允许，也可以自己来定制一套满足自身需求的基础库。毕竟在移动端，一切以 “精简”为主。
对于单页应用来说，iScroll确实是一个非常优秀的解决方案，但是iScroll却有一个最大的缺陷——慢，滚动的性能与浏览器原生实现相比，在低端的移动设备上有明显卡顿。
不过要兼容低端的移动设备，原生的滚动还是有优势的。尝试放弃使用iScroll组件，使用原生的Scroll。因为较新的浏览器已支持{overflow: scroll; -webkit-overflow-scrolling: touch;}。
iScroll的诞生，主要是因为早期的webkit内核浏览器没有一种原生支持固定高度的容器。到目前为止，iScroll最大的问题就是慢，在千元以下Android设备上表现尤为突出。使用局部滚动来替代iScroll滚动是最好的一种方式，但很可惜，现在只有iOS5、6支持局部滚动，并且支持程度并不好，而Android压根就不打算支持。这样，我们就不得不使用iScroll。
问题来了，现在到底使用iScroll呢？还是不使用？使用的话，大部分Android设备在滚动时会很卡，如不使用，部分功能又实现不了。其实，这个问题也不必太纠结。
- 首先， 对于header、footer需要固定位置的页面，可以直接使用position:fixed实现。部分不支持fixed定位的浏览器问题也不大，这部分设备一般都是Android2.x的系统，配置也较低，相对交互而言，速度显然更加重要；
- 对于需要依赖固定高度实现切换动画效果的交互，应尽量保证滚动条在页面顶部时处理。必要时做出一些牺牲，舍弃部分影响用户使用流畅的交互；
- 尽量使用浏览器原生支持代替iScroll；
- 如果必须使用iScroll才能实现的功能，一定要控制在最小范围，不要在常用场景应用iScroll；
虽然iScroll在iOS下表现得非常出色，但是都应当尽量使用浏览器原生支持特性来实现功能，这样才能最大化保证交互操作的流畅性。
很长一段时间都有一个争论，有页面跳转是不是WebApp？我认为单独讨论single page webapp还是页面跳转是没有意义的，所有产品都是建立在用户需求之上。对于现有的single page webapp产品，浏览器没有准备好，硬件配置也没有准备好，函数运算效率、页面渲染都跟不上，尤其是Android设备。基于用户需求出发，一些意识形态的东西该抛弃就抛弃，放开的使用页面跳转，只要能让程序运行流畅的东西，就应该毫不犹豫的使用。
但凡事也没有绝对，在一定的功能范围之内，也可以使用炫一些的切换动画，在一个页面实现多个子功能。
基于以上对移动端浏览器混乱程度的理解，移动web产品要做到全平台适配，工作量无遗是巨大的，并且，由于HTML5的支持程度，也会导致大部分低端用户无法使用到一些高级特性，或表现效果不佳。而且，没必要为了适应低端Android用户让高端iOS用户也忍受着简陋无比的交互及界面。那么，将iOS、Android、Windows Phone分为不同的版本，做相应的功能适配还是很有必要的。
- 在iOS下，自由度比较高，能随意发挥，很多有创意的交互及设计，都能在Safari下表现得比较好；
- Android下由于设备硬件配置及浏览器版本差异比较大，就会选择相应保守的方式，舍弃部分影响用户使用流畅的交互，以及影响页面渲染的界面设计；
- 对于Windows Phone我们是从WP8起步，这样会更好做浏览器兼容。 做分版本适配的目的，是为了在保证功能交互的前提下让每个用户都能得到最流畅的操作体验。
用原生控件做外壳和交互，保证流畅的用户体验和完整的推广渠道；使用HTML5来展示内容，保证内容的迅速迭代更新，即时响应用户需求。于是就诞生了Hybrid App，这也是目前最流行最合适的一种App形式。
下面提出我个人的建议：
如果你的团队刚刚组建或者框架知识了解不深入，那么开发移动端，使用单一的库就行了。
比如：jQuery mobile或Zepto。
使用jQuery mobile可以省略很多UI设计或者说重构的一些工作，在公司团队中，如果没有这方面的成员时，可以使用此库。但是此库性能不好，兼容性一般，UI限制大，请慎重使用。
使用Zepto开发，性能上最好的，而兼容性比较好，跟jQuery有同样的API，只是需要自己设计UI，以及重构。touch功能上有一定的兼容性问题。推荐使用此库，这样你可以任意发挥你的想法。
如果你的团队具有一定的框架基础，像模块化开发的代表requirejs和seajs，那么，完全可以把这个项目进行模块化开发，把这两个库的任意一个加入到项目中，将对你项目的协同开发，以后的代码维护都将有很好的贡献。这两个库的学习成本不大，很容易上手。
如果你的团队，个个都是高手了，那么就可以进行mvc模式的开发了。在你的项目中，加入backbone+underscore，这是目前为止，最简单的mvc模式的开发组合。但是大家都知道，使用backbone，你就必须按照backbone的模式来进行项目的开发，具有一定的限制。也就是说，开发和维护，都需要了解backbone这个框架。
如果你的团队，个个是大牛的话，那么就可以使用angularjs或react了。这种模式的开发，现阶段是前端开发的最新研究成果了。此种框架，学习成本大，但是代表着公司的实力和创新。
当然，除了以上这些基础库和基础框架，我们可能还需要添加一些第三方库，比如iscroll，此库兼容性好，唯一缺点就是在低端设备上，会卡，所以项目不能全局使用iscroll实现滚动效果。我们需要添加原生的scroll来实现项目中的滚动效果，如果使用原生scroll不能实现的，那么才使用iscroll来实现。
比如：faskClick，它解决点击事件延迟的bug，当然zepto的touch模块也可以解决。
比如：模板引擎，像underscore，handlerbars等。
比如：HTML5的application cache本地缓存机制。
移动开发总结：
（1）jQuery mobile或者Zepto+自己设计UI
（2）seajs或requirejs+Zepto
（3）seajs或requirejs+Zepto+Backbone+underscore
（4）angularjs或react
我个人希望能够使用第三种，然后项目成熟了，再使用第四种。毕竟新技术的实践，还是很有想象空间的。
当然，如果对技术不需要深入，只要实现功能，那么使用第二种我觉得还是不错的。 至于第一种，我个人觉得模块化开发还是非常必要的，之前在公司里面看之前的前端负责人开发的一套系统，代码写的太混乱了，简直看不得，维护起来非常不方便，所以模块化开发，我个人觉得，必须使用。
关于移动端的UI组件，我推荐腾讯的frontUI。百度的gmu很久没更新了，也没人维护了，而且耦合性比frontUI大，不推荐。
关于移动端的调试工具，我暂时只用过weinre。由于公司网络不行，我使用的是低版本的weinre，只支持safari调试，而且反应比较慢。但是，还是能够解决问题的，只是效率不高。网上有很多教程，百度一下就知道怎么用了。