Vue 我从 Vue.js 回到了 jQuery
之前用 Vue 做过一个纯前端的项目，与后端通过 api 交互数据，深深的感觉到了 Vue 的简约和强大。
最近做一个 rails 项目也尝试着用上了 Vue, 发现 jQuery + turbolinks + ujs + erb 足够简单了，性能也足够好，很多用 DOM 操作很简单的事情，要换个思路硬是分离出数据和视图反而变复杂了。
正好也不用担心客户端渲染引起的其他比如 SEO 的问题。
我是用了很多年的 jQuery 了，最近学习了 Vue.js 后，果断用上。心得是 jQuery 可以解决的问题，80% 以上的情况下，Vue.js 可以解决得更好。jQuery 能不用就不用了。
个人认为 vue 的定位很尴尬，高不成低不就。重型场景有 angular，轻重结合场景有 react，微型场景有 riot。vue 没有自己的理念，不明白为啥 vue2.0 出了以后，突然很多技术板块都出现了 vue 的帖子，是一种营销吗？
#8 楼 @hxh1246996371 你这种说法太肤浅了，按你的说法 jquery 也能解决 angular 和 react 能解决的事，简单和漂亮每个人的定义不同吧。
- 阿里的 weex 用 vue
- gitlab 用 vue
- laravel 用 vue
- .....
不知道他们的场景是轻是重，不知道他们为什么不选择 react 或者 angular。我相信他们都不是傻的
另外 自己看看 Gitlab 的这篇文章 why-we-chose-vue
你确定【jquery 也能解决 angular 和 react 能解决的事？】
至于简不简单，就拿 angular1 来说吧，我相信正常人都能一眼看出来 vue 比它简单易懂
说话得拿出证据，当你不了解一个东西的时候 不要妄下结论
不追 hype，明智选择。
我经常反思
- “到底有哪些公司是因为采用了 SPA 从而在竞争中胜过了传统 HTML 公司”
- “为什么豆瓣还不用 SPA”
- “为什么淘宝还不用 SPA”
- “为什么网易新闻还不用 SPA” (有什么其他大公司靠 SPA 取胜的吗？)
但是始终得不到答案。
常常见到各位朋友用 SPA 做 Ruby China 或者 V2EX 的网页客户端， 用过之后我的感受是“算了我还是用 Turbolinks 加持的 Ruby China”， 并没有见到太大的优势然而我知道他们付出的工作量和维护成本差多少。
常见的回复正如本帖中提到的 “你的需求用不上 vue 啊” “场景不同就应该选择不同的框架” “看场景，没有什么是银弹！”
但是各位高人又不教大家如何选择对应的框架
那么我在这里抛砖引玉：
个人认为 SPA 的唯一对应场景是 SaaS，而且要是把桌面软件搬到网上的那种
我用 vue 想实现的是一个比较常见且简单的场景： index 页面的列表，新增数据，刷新；
我用 vue 的思路：1.create 方法调用后，递归组件增加内容；2. 直接把列表数据用 vue model-view 分离循环，然后 create 后返回列表数据。2 应该是更符合 vue 理念的。
我开这个帖子也是想看看大家的讨论，@nong的观点我很赞赏，我也喜欢这种讨论问题的态度。楼上那些我的需求用不上 vue，什么场景不同的，我也想说的是这样的答案意义不大，有心的话也可以谈谈我这个场景为啥不适合 vue。
我这样的场景，我用 vue 也未尝不可。只是我后来反思自己的这个技术选型，有些盲目追求新技术了。turbolinks + ujs 的理念已经足够领先了，而且非常简单，其实大部分单页应用都是可以这样来实现的。只是 ujs 跟 jQuery 搭配使用更合口。
有很多做 rails 的兄弟一上来就把 turbolinks 禁掉了，又怎么能体会其精妙之处呢。
#17 楼 @i5ting 终于出现明白人，我个人认为过度推广就是一种营销，而 vue 作为一个开源框架，这么做实在让人有些反感，也许不是那么客观。
#13 楼 @hxh1246996371 你举的这些例子，难道我就没了解吗？当你没了解我是否了解的时候，也请不要妄下结论。不要上过 github 就像第一次进城一样。
#12 楼 @sefier vue 的出现就是对 angular 1.x 的模仿，无论是模版还是双向绑定。
ember 有个 cli 可以一键生成项目，vue 就出了个 vue-cli。
react 出了 jsx 之后，vue 也添加了对 jsx 的支持，react 的 vdom 号称性能牛逼，vue2.0 就也实现了 vdom。
react 有 reflux、redux 实现单项数据流，vue 就也实现了个 vuex。
react-native 和 weex 孰先孰后双方各执一词，但是 react-native 无论是立意还是正式发布都早于 weex。
借鉴本无可厚非，然而其它框架基本没有受到过 vue 的反哺。
我说的 vue 没有理念指的就是 vue 总是在借鉴、模仿别人，将别人的思想重新实现一遍。
然后再通过一些技术社交平台来进行推广，就连微信小程序面市，vue2.0 都要借势宣传一波，所以 js 社区才有娱乐圈这种雅称。
当然这只是我个人的喜好问题，我不喜欢 vue，是因为我认为框架最重要的是思想而不是实践。redux 的源码也不过几千行，我相信很多人理解 redux 思想之后，自己实现一个也不是太大的问题，甚至可以比 redux 实现得更优雅。
正如 rails 现在已不如前几年那么"coooool"，可是它的思想可谓被无数 web 框架借鉴乃至依然显得伟大。
angular 和 react/flux 也做到了这点，可是 vue 没有。
#13 楼 @hxh1246996371 另外你要我列举我所谓的场景，不妨我就稍微说说我的看法抛砖引玉
首先是 Angular2 引入了 ts，可以用作静态类型检查，更方便地写测试代码。引入了模块化，解决了 react 组件业务切分不明，组件粒度过细导致开发起来常常束手束脚的缺点。有 model 层可以实现前端管道过滤不规则 json，有指令可以实现自治组件，有 service 可以拆分逻辑代码。Angular2 的开发体验更接近后端项目，例如做一个业务极其复杂的企业系统（例如 erp、oa 等），或者是上千个页面的中大型网站，我很难想象用 react 或者 vue 开发如何能够做到多人协作组件复用化还能使项目不杂乱。
目前和 vue 使用人群重叠最大的就是 react，这二者都是细粒度木偶组件 + 自由组合智能组件 + 单向数据流的开发方式，而 react 当初被提出其实只是 fb 想要实现一个前端 view 层的复用，因此数据流动方式其实除了 redux 这类前端 flux 思想实现外，还有如 relay、graphql 以及第三方的 meteor 等后端框架来让开发者自由使用，此时的开发场景就不仅限于 spa 页面了。我说的轻重结合，实际上就是指组件拆分细化的话，无论何种场景都可以根据使用情况打包不同的组件来达到快速开发而打包的 js 文件也不会太大。
至于 weex，一个阿里的 kpi 项目，用脚趾头想也知道只能选个人项目 vue 了吧。
另外 riot 这类新兴的微型框架就是在这方面做到极致，比如你开发一个只有一个页面的 spa，引入一个 riot 就可以使用各种 mvvm 特性，打包的 js 文件还小，这就是我说的微型场景。
而 vue 的定位真的很尴尬，高不成低不就。如果你要强行说 vue 可以开发全部的场景，那也是可以牵强地成立的。不过同时我说 jQuery 也可以做到，你还要否认的话就是双重标准了。我两年前就用 jQuery 实现了一个组件化的 mvvm 框架，虽然那时候刚开始做前端写得不太漂亮。
#33 楼 @ch3rub1m 生不逢时？我不觉得，事实上很多现代 JS 框架的创新举动都是 Ember 开创或者首倡的，很多后起之秀都继承或学习了 Ember 对整个社区的贡献，在这个历史时期，Ember 的出现和繁荣恰到好处。准确的说并不是 Ember 生不逢时，而是它相对来讲更超前一些，它瞄准的目标是 Ambitious Web Apps，而这类的应用哪怕在目前的 web 届也都少数，能做好的更是凤毛麟角。相对而言，Ember 对于多数 web 开发者而言就显得“困难”一些罢了，因为它的开发者和社区的大多数人都是走在探索 web apps 的较前沿的，用户基数不大我倒觉得很正常。
我以前觉得 Ember 和 Rails 很像，但现在显然不是这样了。Rails 当年火起来离不开一个“快”字，在服务端渲染技术高度成熟的时代，Rails 汇集了几乎所有 web 开发的最佳实践，并且给出了最合理的应用程序架构，所以它生而逢时了。然而就应用程序形态来讲，Rails 也没有改变服务端渲染的本质，它只是把所有的菁华打包给你（主厨推荐）而已。
但 Ember（以及其他的 SPA 框架）却是要探索新的应用程序形态，为了能在 web 上开发和提供桌面级应用程序的体验，并且还能在此基础上提供 landing page 的服务端渲染，这是过去的应用程序框架没有成熟解决方案的事情。在这件事情上如果获得大票的用户基数而且评价还相当高的话，那就说明已经很成熟了，那时候我们应该能够看到很多很多非常棒的 web apps，而不是只是 content pages，今天的 React ／ Vue 等等算做到了吗？在我看来只是把热度炒高罢了，前路依然很远。
过去我也喜欢推广一下 Ember，但现在比较少了。一方面是我自己探索的更深入了，问题更多，需要研究的时间也就更多，没时间扯；另一方面则是绝大多数“应用”还是处于内容形态而不是应用形态，相应的多数开发者也就不需要 Ember，这是必然的，你没在 web 平台上做过桌面级的应用，你当然不会觉得 Ember 的好处在哪里。别的人再去推荐也没有什么用处的，因为需求的局限性就在那里摆着。
就在昨天看到一个老司机在 medium 上的文章，他大意是这是他第三次写文章评论 Ember，前两次都是喷，说他是多么多么 hate Ember，他以为如果还有第三次也一定还是喷，而且会喷的更厉害的，但自己都没想到第三次他想说的却只有：I Love Ember Totally！这种差别是因为前后几次评价是源自于使用 Ember 在不同的项目上所获得的体验，你要解决的问题不同，对工具的体验自然也就不同。
今天我们所见的一些人一直在喊着：“我不要 A 也不要 B，我就只用 X，它就是最好的，没有之一”，这不就等于拿着一个锤子，然后试图把所有的问题都当成钉子么？或许他们自打学会开发起，所面对的问题就只有钉子吧，所以你给他们去推荐电钻啊、焊机啊之类的东西也是白忙乎，他们用不着啊。
前面有人的评价就很准确，非要拿 SPA 框架去开发 Ruby China 的客户端，这就是用牛刀杀鸡，吃力不讨好的行为。当然，用做自己练习是无可厚非的，但如果做不出足够出色的体验就不要拿出来给“他们”看，因为他们会觉得你费这么大力气也不过就是 10 年前的技术能达到的水准罢了，有什么意义？
如果真想练手，去做做真正的应用程序，比如说 cform.io 这样的（原谅我打了个广告，因为我不知道还有什么更接地气的实例），只有做这样的东西你才能体会到 Ember 这样的框架究竟强大在哪里，久而久之你就会知道所谓“生不逢时”不过是一场误会罢了，那些逢时的人追捧的无非就是热度，然而解决的问题领域还是十年前的那一套，具体的技术都有一些进步，可是战场并没有变啊。
顺带说几句最近的感受，我加了一个 QQ 群，以 Ember 为主题的，群主也是一个身体力行在国内推动 Ember 的同行。在里面一个来月吧，做了一点微不足道的工作，很多人和我讨论问题或者闲聊期间，普遍都喜欢说：Ember 在国内环境好差啊，用户好少啊……
我个人其实很难理解这种想法，或许只是单纯的吐槽？然而对比一下 Slack 上的 Ember 社区，却从来没见过有人在上面喊 Ember 在 xxx 环境好差啊，用户好少啊……这算是中国特色吗？
如果我们一定要把某种情感付诸在用户基数、占有率等等数值指标上的话，那么我们难道不应该高兴才对吗？因为在各行各业，真正站在食物链顶层的都是少数派，Rails 这么牛，用户基数大得过 Java／php 吗？So what？我们能因此证明 Rails 不如它们？它们才是最优秀的，没有之一？
同样的道理怎么到了前端就完全颠倒过来了？我心中的解释就是：这个行业领域还很不成熟，大多数人看不到未来发展的方向究竟是怎么样的，也分辨不清到底什么才是重要的或者优秀的技术进展，理不清技术发展和需求领域变动趋势的关联关系，因此很容易被“煽动”，很容易被“同化”，同时也容易在用户基数处于劣势的时候产生很强烈的不安全感。
上述的阐述仅仅代表个人观点，很多词语打了引号不是为了强调，而是为了弱化这些词语本来的意思，看不懂语文的就不要来喷了。根本的意思就是这些现象并不是绝对错误的，而是现实发展阶段的必然性，就好像过度追求经济发展的速度就会产生一批性情粗劣的土豪富绅一样，并且热衷抱土豪大腿的也一定是多数人，然而这并不代表这个世界就没有清流存在了，而清流之所以清，还不就是因为少而精呗。所以不要因为身边用的人少就觉得自己吃亏了或者低人一等了，重要的是你心里明白究竟什么才是适合你的，什么才是你要追求的。
@nightire 想请教一下，我近期项目也要做一个编辑器，类似 cform 但编辑内容不同。这样需要大量操作 dom，用 vue，react，ember 合适吗？我想你指导下是怎么实现的。我熟悉 vuejs，但是没学过 ember
目前 JS framework 选择性很高很多自由，但也经常碰到各种配置问题 (Webpack 就很多小细节要注意) . 经典 jquery 至少还是个比较简单的工具。
比较 tools and frame 需要首先考虑 workflow, 团队规模，即成本。被撺掇着用新技术而导致的灾难很常见，家丑满满。
- ReactJS 让 html css js 三者的正交设计犹如白痴，近一步，Facebook 下一个计划是做基于双缓冲技术的浏览器了 (此浏览器用 PHP 代替 JS, dot.php vs node.js)
- 造 angular2 时间不短，估计花钱不少，越来越像微软的谷歌与微软联合作孽... 微软拉了滩 s, 谷歌动手把 s 抹到了发布会的墙上
- vue 资金来源是众筹平台，鉴于 building large and ambitious single page applications, 将来会越来越重，坐等内部上演分裂好戏，
- growth hack: 粉丝越多，撕 b 越快，脑残粉越多，撕 b 越血腥
