做移动嵌入的webapp, 有什么适合的技术?
项目是一个面向大众的 webapp , 会嵌入在多个 nativeapp 中. 我个人比较喜欢 AngularJS , 而 Leader 的观点是 AngularJS 太重(无论是包大小, 还是性能, 他写过 AngularJS , 也喜欢它), 绑定机制的性能在移动端可能是硬伤. 那么如果这样, 是否有一些更适合的移动前段框架, 可以的话给一些使用的成功案例并说说理由.另外, 我们是一个少数精英趋向的团队(对...目前还不是). 我个人之前一直在上海, 最近才到了广州. 在上海非常憧憬 Teambition 这家公司. 因此在某些管理和技术上都有下意识的想模仿他们. 据说这家公司有一个特点: 几乎全部使用 CoffeeScript. 于是我在想我们是不是也可以效仿, 但是目前这家公司接触过 CoffeeScript 的人只有我一个, 有没有什么办法说服 Leader 使用 CoffeeScript ? (或者说服我放弃这个玩意)==========# Update @
#===============================嗯。。 大家的回答都很有参考价值， 非常感谢。
但是“有什么适合的技术” 仍然没有人解答。 Leader 到处搜并实验了下（ Browser 和 PhoneGap ）， 貌似说 GMU + Zepto 是目前找下来比较靠谱的， 但是没有定论。怎么说呢。。我总之是被 GMU 首页那糟糕的设计给吓到了。。。
按投票排序
提到了我司，我也来说几句。首先是，喜欢 Teambition 为什么不来和我们一起工作？传送门：。目前版本的 AngularJS 确实不太适合做移动应用。如果项目比较简单，完全没有必要使用 AngularJS 这么重的框架；如果项目复杂，使用了 AngularJS 就得狗屁。Teambition 目前 AngularJS、Backbone 和 React 都在用。Backbone 本身比较轻量，适合不是很复杂的应用，当然也做得出复杂的应用，Teambiiton 就是基于 Backbone 的，但是比起 AngularJS ，Backbone 的功能太弱了，以至于为了实现 Teambition，包含了很多自己开发的组件来补充 Backbone，所以复杂的项目，Backbone 不会比 AngularJS 轻多少，而且还需要写很多重复的代码。不过现在有一点好处，Backbone 可以很细腻地控制应用的每一个角落，以至于 Teambition 没有太大的性能问题。我在用 AngularJS 做另外一个项目，有可能是我也不太了解 AngularJS，没多少功能，但是性能上就差了，而且我也没有明显优化的方向。React 的话，本身只是做了 View 层，但是 React 的代码已经和 AngularJS 一样多了……我们目前用到的地方就是使用 React 来做 Backbone 中 View 的渲染和绑定。我们的服务端基本上都是 Node.js 的，所以前后端全都 CoffeeScript。CoffeeScript 最大的好处就是语法糖，也就是可能写起来爽一些。但开发速度不会因此提高，因为敲代码只是开发的一小部分，很多时间都花在思考和调试。现在我慢慢不太喜欢 CoffeeScript了，如果用 CoffeeScript 的话，免不了在开发或者上线时有一个编译的过程，对于不同的开发方式，编译的方式虽然不一样，Teambition 原来是使用 Express 中间件来 serve，现在使用 Grunt 来 watch，但是只要有编译过程，总是会增加开发或者上线的过程的复杂度；最重要的一点就是，如果 CoffeeScript 没有自己的运行时，浏览器不原生支持 CoffeeScript 的话，CoffeeScript 永远没有翻身之日。毕竟是要编译成 JavaScript 的，首先会收到 JavaScript 的限制，其次是 CoffeeScript 中的某些语法糖，JavaScript 总有一天也会有的，看看 ES 6 新增的一些新特性，和 CoffeeScript 很像的。还有 CoffeeScript 永远只能做 JavaScript 的跟屁虫，比如在Node 0.11.x 版本中支持 yield 了，CoffeeScript 是不是也要支持？不然咱们这些使用者怎么办？所以 CoffeeScript 目前已经支持 yield 了，将在下一个版本发布出来。当然那些 TypeScript，Dart 什么的，如果没有自己的运行时，和 CoffeeScript 的命运也差不多。补充一点：如果会 JavaScript 的话，学习 CoffeeScript 的成本非常低，一两天吧？！对大多数人或者团队来说，接受成本或者说服成本更多一些，扯皮讨论是否使用 CoffeeScript 的时间，基本上可以学会 CoffeeScript 了。最后，能不能好好写 CoffeeScript，不是 coffee script 呀！
-先说背景：UC九游HybridApp， 原生WebView，自研Android，非phonegap采用Angular，非单页应用模式，Native和H5属于重交互类型。实践一年了。目前性能方面我们还在优化， 不只是angular的问题， 还涉及到Native等地方，所以现在请无视我们APP的性能效果。。。再说结论：Angular目前用在移动端，还比较重， 需综合考虑。缺点：Angular目前比较大， 100+K，内嵌还勉强，如果远端页面就有点大了。我们的应用场景比较特殊，和Native交互非常多， 架构模式也不是单页面应用，而是一个页面一个WebView，所以很多angular的特性用不到。很多页面，业务形态很简单，只是简单的展示，用angular的绑定大材小用。不支持服务端渲染。在某些奇葩机型上， #hash识别会出问题，导致WebView 404， 要hack。优点：在我接手之前，整个项目是无架构模式，没有任何复用性。接手后，迅速用angular架构起框架， 移植代码，把底层逻辑封装完成开发人员业务层的代码非常之简单，开发效率高在这过程中， 学习了angular的很多理念，让团队在AOP单元测试，组件化等方面的有不错的认知。未来：针对的理念，对整个项目进行前端工程化的改造， 进行中。由于angular本身良好的模块化和依赖机制，目前几乎无痛。业务逻辑目前正在逐步独立化，减少对angular的依赖。核心逻辑独立后，部分简单的页面， 可以不用angular实现，我称之为混合式前端框架。复杂页面，还是使用angular （谁叫目前也没有其他更好的框架了，vue，react感觉也还在发展中，不值得迁移）等待angular在mobile方面的优化（之前看过官方doc），等待angular 2.0。前后端分离中， angular不能支持服务端渲染， 是个痛。 SEO也是（当然我们是Hybrid无视，也别跟我提prerender.io,那是无奈之举)另外，以上的思路，会基于FIS/SCRAT做一个scrat-ng之类的工具（实践成熟后会开源出来回馈社区）。PS： 我忍不住要骂知乎， 本文多次编辑， 经常丢失我上一次的内容， 保存草稿和保存那里肯定有bug。-
vue.js怎么样呢？
既然你的leader用过Angular并且也喜欢他，你应该相信他的判断。关于coffeescript，优点缺点都比较明显。综合考虑，除了大多数成员都已经熟悉的团队（比如teambition），我个人不是非常推荐。对于绝大多数前端团队来说，成员熟悉JavaScript是没有问题的。所以如果要升级编程语言，优先考虑ES6。当然，目前ES6的工具链可能还不算最成熟（估计还要半年到1年）。如果是Windows平台可用VS的，可考虑用TypeScript。不过，通常情况下，编程体验是多项因素综合的。语言只是其中一环。
我们首先要看做 Mobile WebApp 有哪些限制，我大约列出一些:1. 连接限制，针对一个 server 只能有两个连接(iOS)。这个和 Angular关系不算很大，但是要注意其缺省载入 view template 的行为是发起一个新的请求。2. File Cache，iOS 下大于 20k 的文件都会进浏览器 cache。因此，有时你需要自己管理 cache 到 local Storage (Mobile Browser 不支持 manifest)。3. 计算能力: 移动浏览器受限于内存和CPU (ARM 真的要比 x86 弱很多)能力，因此复杂的 HTML 文档非常消耗资源，这一点 用 React 就会帮你很多（依赖于自己维护一个虚拟 DOM，然后仅在 RAF 期间批量传递 DOM 变化的差量给浏览器），其他所有基于直接操作 DOM 的 MVC 框架都有类似的问题。当然， React 仅仅是 MVC 中的 View，你需要另外考虑你的代码组织方式，是结合 Backbone 还是用 FRP 等。4. JS 执行没有 JIT (iOS下)，Apple 的 UIWebview 不支持 JS 执行的 JIT，因此 JS 的性能会弱一些，这方面虽然没有定性比较，但是 Angular 周期性的 Watch 应该是较大的开销。关于 Coffee: 我是 Coffee 的重度用户，事实上，我也在不断权衡什么时候用 Coffee， 什么时候不用，但是起码到现在为止(包括ES6)，编写、阅读和理解的好处要大于弊端。但是说服别人很难，因为只有坚持一段时间才能体会到其中的好处。或者如果对方是 ruby 或者 python 转过来的会更容易接受。最简单的说服方法是，我已经写了一个框架，带来的好处大家都看得到，那么自然就随着走了。
你们的leader说得有道理，虽然我做过一个基于 Angular 的 webapp ，在 mobile 端没什么问题，但我其实一直都挺担心这个问题，特别是低端一点的 android 机。我那时赶着交差，也没有详细测试。Angular的 touch 模块也有一些莫名其妙的问题，不知道是不是版本的问题，debug了之后发现，它为了算出 touch 的距离，使用了 clientX 和 clientY ，但像 iOS 7 的 safari 就会遇到问题。反正后来我自己重写了。我觉得 CoffeeScript 引入的语言便利程度完全不能抵消团队全员学习 CoffeeScript 的学习成本。
说说自己的技术吧，同上，我也觉得AngularJS在重，所以后面我就试着用Backbone + RequireJS + jQuery + MustacheBackbone 轻量级，支持jquery，自带路由，对象化视图，强大的sync机制减少页面大小从而加快页面显示。jQuery jQuery使用户能更方便地处理HTML（标准通用标记语言下的一个应用）、events、实现动画效果，并且方便地为网站提供AJAX交互。不过主要是jQuery能够使用户的html页面保持代码和html内容分离，只需定义id即可。Underscore是Backbone的依赖库 Underscore 是一个JavaScript实用库,提供了类似Prototype.js的一些功能,但是没有继承任何JavaScript内置对象。RequireJS 你可以顺序读取仅需要相关依赖模块。Mustache JS模板引擎自己用上面的技术写了一个简单的移动CMS—— 与AngularJS不同的是，用上面的技术的话，应该可以有选择也加入自己需要的框架和东西。我想在多数时候会比AngularJS快捷，而且RequireJS也支持Coffeescript
我们团队前段时间一直在用AngularJS开发一个传统网站。目前正准备做一个Hybrid App，虽然对AngularJS比较熟，但由于Angular太重，在手机上的性能比较让人担心，所以并没有选用它。关于coffee script，个人觉得如果前端项目的JS部分很大很复杂，用coffee没问题，这会减少前端的开发和维护工作量。如果JS并不算太复杂，考虑有限的收益，更多的学习成本，换技术就不太划算了。
对于项目来说，领导需要考虑的不是用什么，而是什么最合适。你领导现任对AngularJS 很了解，根据他的经验判断，觉得AngularJS 不适合当前这种项目。这是他需要对项目进行的掌控，避免项目在开发过程中出现意外或者出现致命性的问题导致项目卡壳。第二点，在团队中推广或者普及一项工具，是一个循序渐进的机制，我的团队是一个技术一般般的团队，我从普及代码规范、sass、jade这些就已经花了2年时间，才慢慢的把让整个团队心甘情愿做出转变。当然现在也在普及 coffee script，我希望整个过程是引导式的，而非强制式的。因为每个团队成员的技术能力，和学习能力，以及对新事物的看法都不一样。 保守派，激进派，还有无所谓派众口难调。基于这些基础情况，采用不同策略去推进团队的工具普及是一项长远的工作。 所以很多时候 不是你领导不愿意做，而是在他的计划里面，可能觉得目前推进 coffee script可能会出现太多的问题。不太适合，或者觉得目前项目 coffee script并不合适在目前团队里面用。希望你们团队成为你心目中的牛逼团队，但是这一些都不能着急。欲速则不达。
同对现阶段在移动端采用 Angular 持保留态度，主要的痛点同你们 Leader 的原因。期待针对移动端的 Angular、React 等框架的变种。至于 Coffee Script 的技术推广问题，个人认为不是说服不说服的事儿，如果你有时间有精力 cover 团队的学习和维护成本（比如在周会上长期给大家做 Coffee Script 的推广和分享，大家使用中遇到任何 Coffee Script 相关的问题你能及时响应解决），他们能看到使用后带来的收益，自然会采用；而如果你做不到，也就不要期望能通过说服增加大家的成本了。
已有帐号？
无法登录？
社交帐号登录