那些用 jQuery 已经在线上跑的好好的东西，谁没事找事换啊，钱谁出、风险谁担呢。

什么时候 @dhh 在 rails 里做像用 jQuery 替换 prototype 那件事，那就说明 jQuery 老矣 O(∩_∩)O 哈！

PostCSS and Rework 这块没有接触过，其他还是有所耳闻

看不懂他的问卷啊。jQuery heard of/read about: 1.7%，never heard of: 0%。这两个指标不应该是 mutual exclusive 么。

jQuery，万金油，也没那么不堪，发现在技术社区只要是易学易用的东西，评价都不高，特别是“易学”这个特点，最招黑

#3 楼 @billy 四个选项我是这样脑补：

1. 没听过
2. 略有耳闻
3. 用过
4. 经常使用

#6 楼 @luikore 你可以不用所谓“臃肿的框架”，但作为前端工程师你也不能离开了 jQuery 就不会做任何事情，这是对于前端工程师的要求而已。

我们对 jQuery 的结果感到沮丧，不是因为 jQuery 不好，也不是鄙视还在用 jQuery 做项目的团队／个人——这些都很正常，比方说使用 Angular 或 Ember 等“臃肿框架的”，当面对 DOM 操作的时候多数人还是会操起 jQuery／Zepto。

但是作为前端工程师的我们必须知道 jQuery 的来由，知道它曾经如此红火的原因，同时也应该知道现在生态环境的逐渐成熟，有多少事情其实是不必依赖 jQuery 的。太多太多的人用各种理由来为自己“离不开 jQuery”做辩护，太多太多的人用这些理由束缚自己的脚步和视野。

更多的我不想说了，叫不醒的人永远都叫不醒，他们永远都会有数不清的理由，随便吧。

只说一点：离不开 jQuery 的，将永远把 UI 编程弄成“以 DOM 为中心”的编程，如果你觉得 fine，那就 fine。

@billy 对用户的调查是按熟悉程度划分百分比的。比如 jQuery

四项加起来正好 100%

#7 楼 @nightire

react 很火，react-bootstrap, react-material-ui, 还有各种组件，但是 awesome-react 上面，看不到什么线上在运行着的开源 web 项目，像 peatio, ruby-china 这种。

论坛上看到你们提到 ember，对 ruby 工程师友好，有了兴趣。

我也不喜欢 jquery, jquery-ui，也觉得 react 很优雅，ember 不知。

但是采用前后端分离，不少带 viewer 的 gem，那些 helper 在 view 里用不了了。方便的表单验证，页面上的权限管理，等等许多问题不知道前端框架的场景下是怎么解决的。

如果有了多一些的 react，或 ember 开源项目，能迅速学习，我是肯定放弃 jquery 的。操作 dom。尼玛。写着都烦。

#9 楼 @seaify 你前后分离，还关带 viewer 的 gem 什么事？恕我愚钝看不明白你在说什么。

#9 楼 @seaify 另外，使用新技术的往往都是从内部项目或是非开放型项目开始的，所以公众平台上可能比较少也很正常。别的框架我不了解，Angular 的开源项目简直不要太多，问谷歌吧。Ember 的话可以看看这里：http://iheanyi.com/blog/a-list-of-open-source-emberjs-projects/ 都是质量很高的。

https://github.com/TryGhost/Ghost https://github.com/aptible/dashboard.aptible.com https://github.com/wordset/wordset-ui https://github.com/hummingbird-me/hummingbird https://github.com/discourse/discourse

这五个都是值得一看的，它们都符合你的要求：开源，Rails／Grape Backend API，大项目，有线上产品可以参考等等

https://github.com/kagemusha/crambear

#10 楼 @nightire

就当做是考量。有些舍不得这么多已有的 gem

#11 楼 @nightire

非常感谢你的这些推荐。特别是第 2 和 3 项开源项目。

我不懂前端。但是我以为，考量前端的功力不是应该是 JS 玩的多溜吗？框架这件事不要那么在乎吧，项目适合用哪个就用哪个啦。今天 Angular, Ember, 明天就出了个 Bngular, Fmber

#7 楼 @nightire

离开了 jQuery 就写不了 DOM 操作也没什么好羞耻的吧，毕竟 W3C 的 DOM API 设计得不好用啊... 离开 Angular/Ember/React 就不会操作 DOM 的人也有一大堆

功能和 jQuery/Zepto 不重合的小框架也有不少，它们可以一起用。有些框架干脆就实现了部分类似 jQuery 的 API

#15 楼 @luikore 咱们不说这个了好吗？我觉得你也是一个高手，我很不好意思和你争论这个话题。

这就好比我也懂一些 Rails，其实我写过的 Rails 项目虽然简单但自认为写得还是比很多后端工程师好的，然而我不会评价 Rails 哪里不好，或者还有什么更好的。因为我有自知之明，我知道以自己在后端开发上的见识还不足以对这个生态系统评头论足，先学会用好就是了。

所以你看看你说的话，懂行的人一眼就看出来和我说的不是一回事好吗？是否要用 jQuery 来操作 DOM，和是否以 DOM 为中心来进行客户端 UI 开发，这是一个性质的事情吗？如果用了 Angular／Ember／React，还成天净研究怎么操作 DOM 的那只能说明他白用了好吗？

实在没啥可说的，我就此打住了，如果觉得扫了大家的面子那我道歉，我只是想分享一个调查而已。我说 jQuery 和测试框架的现状让我沮丧这是事实，而且我自己沮丧不代表不让大家用啊，搞不懂怎么就触碰到一堆敏感的神经了？说句真心话，比起调查结果里的 jQuery，这里的一些回复才真的是更让我觉得沮丧呀……我一点都不觉得 jQuery 有什么不好的，真正不好的是它对很多人所产生的影响。

Someone said: jQuery is good, no judgement. But we do have more better way to do client side application development, we do need to think about some other way to get rid of the ugly DOM manipulation, we do need to move forward, to embrace the changes, to make UI development more and more better.

Then there always others responded: go away! jQuery is the best tool, don't try to ignore it, we like it.

OK, if you are back-end guy who do some font-end works, or if you are full-stack engineers who not require to do complex UI development, then you think jQuery is enough, that's fine to us, just go ahead. But we, as professional font-end developers, we deserve to move forward, to create better solutions. You don't need to join us, you can still stick to yesterdays, but plz do not drag on us, just sit back, we do respect to each others, don't we?

如果你觉得 fine，那就 fine。 你喜欢这样认为就认为吧，我无所谓 兄弟，还能不能好好讨论了？ 不知道是谁神经敏感了，好吧，不说了。

#18 楼 @yanguango 如果你觉得 fine 那就 fine，我不觉得我这句话有什么问题。作为前端工程师，我知道有比 jQuery 更好的方法和思想去做我的工作，但是非专业的前端工程师却要对我说：jQuery 没什么不好的，你不能指责用 jQuery 的人。问题是我有说 jQuery 不好吗？我有认为还在用 jQuery 的人羞耻吗？我只是觉得到了今时今日，还有这么多的前端工程师（请注意，这个调查的对象都是前端工程师，不是偶尔做一些前端的后端工程师）还如此依赖 jQuery，舍不得迈开探索的一步，这个现象让我觉得沮丧而已——这么多人看不懂吗？

既然你们觉得停留在 jQuery 的 comfort zone 就足够了，那我的确没什么好说的，觉得 fine 就觉得 fine，有错？

至于后面那句话，其实是我回错人了，所以我删了，向你道歉。

#12 楼 @seaify 当我们说到“前后端分离”的时候，我不知道诸位后端工程师是怎么理解的，但是在我们前端看来所谓“分离”就是所有和前端相关的代码：HTML＋CSS＋JavaScript，它们都是可以在完全没有后端的环境下进行开发的。我们不需要把源代码混合在一起，我们不需要把运行环境混合在一起，我们不需要把部署混合在一起，从开始敲下第一个字母直到最终上线，前端工程师都完全不需要知道后端到底用了什么，放在哪里，如何运行。唯一联系彼此的纽带就是 API 的通信和线下的设计、业务沟通等等。

我的确看到一些 Rails 项目使用了 Angular／Ember 等 SPA 框架，但是代码却是混合在 Rails 框架里的，如果你仔细审视他们的写法你会发现他们根本就没有分离，他们还是用着老一套的思想去做 UI 编程，唯一不同的是他们利用了那些 SPA 框架里的一些特性而已，比如说数据双向绑定，模版系统等等。然而这和我们前端所说的分离还相差很远。

如果在架构体系上做到了我所说的那种分离，也就意味着你之前所用到的任何 gems 都不再需要了，因为我们根本就不需要依赖 Ruby 环境好吗？所以你不用舍不得的，任何涉及到前端开发的 gems，前端的生态系统里（主要是 node＋npm）都一定会有一样的或类似的，只可能更好不可能更糟。从另外一个角度说，现有的项目并不建议彻底的分离，因为的确如你所说有很多东西需要替换。

#13 楼 @seaify 我给你加了一个新项目在原来的回复里，这个新项目不是很知名但是它很新，你可以看到基本上都在用最新的版本，而且代码更新也比较勤快（应该是正在开发中的项目）

#20 楼 @nightire

我明白你说的前后端分离，是仅通过 api 通信，写过一个很烂的 react 代码，就是通过 api 通信的，https://github.com/seaify/ipool/tree/master/proxy-frontend。

而 react-rails, angular-rails 这些 gem，如果使用了，也只能使用一部分特性，用不了 flux, 但是好处在于它能继续使用 asset pipeline, 能继续混着其它的 gem 带的 view 一起用。不过我是支持彻底分开的，这样的话，后端选型上范围更大，而且很多时候，前端值得单独彻底抽离出去。

前端的世界里，至少我知道通过 browserify，也能使用各种 npm 包，因为我关注的是 react.js, 然后 react-china 这个社区和 ruby-china 比起来还太弱，也没看到 react 很多出名线上的开源项目，所以还没大量时间投身 react。另外刚学会 browserify, gulp, grunt 这些东西，现在又有 webpack，变化太快了

jquery 反正在我看，思想是太古老了，可是现在前端框架又给人变化太快了，facebook 系列的 react, flux, relay, graphql，react 和 graphql 都给人眼前一亮的感觉，可是相应使用它们的开源项目太少，我只是想在等等。等到时间更合适些。

反正目前的前端代码和后端代码在一起，页面上通过 jquery，我是非常反感的，太弱了，一点简单的事情写 coffee 太蛋疼，目前正在想用什么样的解决方案来替换掉它，影响开发效率和心情

@dfguo

能不能推荐些 react 线上在运行着的开源 web 项目？SPA 的。要是界面更漂亮那就更好了。

要是再有 react vs ember。。O(∩_∩)O~，从周边来看，觉得使用 react 的人更多了。

awesome-react 的 app 节点下的推荐太少了，Khan Academy'的 perseus 也不好看。

前端的世界变化太快... ember 还没掌握好，react , webpack 什么的又火起来了..

#24 楼 @feitian124 前端变化快是不假，但是 ember 和 react 不是一个概念呀，一个是全功能的框架，一个只是视图层的库，不用都学啊。webpack 就只是一个模块加载打包器罢了，周边工具而已，学起来也没有什么负担。而且 ember 有 ember cli，webpack gulp 之类的都不需要用的，而 react 本身只是解决了视图层的问题，你要做大规模的应用还得解决其他环节，比如路由，数据映射，事件分派等等，最终你等于用各种库拼出一个 ember 来——当然还是有区别的。但是 react 的优势其他框架又不是没有，DDAU ember 也可以实现啊，virtual DOM ember 的 glimmer 引擎也毫不逊色啊。

#26 楼 @luikore 我有这么说么？我觉得你只是把你的怨念强加在我身上而已，你所说的一切，比如：

1. 你觉得 Vanilla JS 优于 jQuery
2. 觉得自己工具和理念比 jQuery 优越

我没有这样说过吧？我对“沮丧”的解释在前面已经说得很清楚了，不知道你为什么总是认为我们在排挤 jQuery？

另外，elm clojure 等等要用在浏览器里就不需要编译了？

只靠 React 就能写大型应用程序了？

没有哪一种工具是万能的，但偏偏很多人却觉得 jQuery 是万能的，别人连说它都不能说了？更何况也没有强求大家不要用它，只是希望能有更多人往前迈一步，有错？难道不用 jQuery 就只剩下 DOM 着一种选择？难道你用 React Ember Angular 的时候还要天天写 getElementById 这样的 API？

我和你的根本分歧就在于：

1. 我说不用 jQuery（其实也没说不用，只是少用，但偏偏都觉得我是说不用），不是不让用，而是鼓励去尝试更多的选择。
2. 你说不用 jQuery，然后就只剩下 DOM 这一个选择了……这样一对比你自然是稳居不败之地。

现在的趋势就是想推动前端继续进步的人却被一群自恃全栈工程师却死抱 jQuery 还不许人家撒手人拖着后腿

很讨厌像这样乱开地图炮，模仿一下而已，不会生气吧？

都没人提 Backbone 哼

#28 楼 @fresh_fish 支持 Backbone，一直放在我的后备箱中，它跟我的开发理念很匹配，不过一直没有复杂场景用得上。

#28 楼 @fresh_fish 我用，这东西正如他的名字一样，真心提供了她该做的（一样儿也不多）。

#29 楼 @rei 你感觉淘宝 UED 的 nodejs 做中途岛怎样？，好吗？我有一个小项目是做一个学校的门户网站，我用了 nodejs 来做中途岛大概框架就是参考的airbnb，我自己感觉很好，做到模板复用，解决了 seo 问题，同时也解决了 angularjs 等单页面第一次加载慢的问题，而且写复杂的前端交互也挺顺的，写起来也很自由没有前后台的界限。这是我自己的感觉。说实话，我们公司挺小的，我正打算以后都做成完全前后台分离的，前端可以用 nodejs 或单纯用 angular 等，后台可以是 soa 框架（按功能分块），当然了，我只是停留在想法上，没啥经验对这方面。

#27 楼 @nightire

而我"感到沮丧"段说的是调查者，不是你... 因为调查者说

I would expect this number to decrease over time as people’s knowledge of ES2015 increases and move back towards using native JavaScript and smaller libraries.

如果你没有觉得 Vanilla JS 优于 jQuery 的意思，我向你道歉，我把原作者和你合一起开地图炮了。

看到 jQuery 和测试工具的结果还是令人挺沮丧的啊，尽管这两年前端发展日新月异，可是总体水平提升还是有点赶不上。

潜台词是不是觉得用 jQuery 舒服，就是水平低？

就 SPA 来说 有纯 SPA（yaoman 创建项目，纯 html、js 开发，要使用带路由的框架 Ember 等），单单使用 jQuery 肯定不够

有混合 SPA（部分页面 SPA）（后端生成 html，使用 reach 这种纯渲染库、rivets 这种纯双向绑定库 等），对于这类来说，Angular、Ember 确实很臃肿

#32 楼 @wpzero 淘宝 UED 的方案在他们的场景有合理性，但不是适合所有人。我觉得 Martin Fowler 的 MonolithFirst 也适用于这个问题：

This pattern has led many of my colleagues to argue that you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile.

门户网站没必要，模版复用、SEO、首页加载这些都是前后端分离才引入的问题，用服务端渲染就好。如果是技术人员维护我还推荐静态网站。

#29 楼 @rei 的分析 非常棒！补充一点，创业公司很难招到那些熟悉和掌握理念上比较“超前”的 js 框架，更多时候 backbone+jquery 或许是更好的选择。

淘宝 UED 感觉最近收声了啊。midway 炒了个大新闻，不懂后来如何了

前后端还分离烦躁的事情还是有不少的，部分代码要写两遍, 比如前后端的 model 呀, 一些验证逻辑等, seo, session保持 等，单个看是小问题，堆积起来多了也郁闷。

#33 楼 @luikore

哈？难道你就是这么理解的？今天真心见识了！

总体水平提升还是有点赶不上，这句话哪里暗示了初始水平低这个条件了？

所谓总体水平提升，指的是从范围（前文的这两年是范围）开始到结束，在这个区间内的增长程度；我原话是拿这个程度与同时间段内前端业界总体的发展程度做对比，才得出“有点赶不上”的结论。这怎么就是暗示初始水平低了呢？

再说了，就算两年前你的 jQuery 用的出神入化，但是两年后你还只是 jQuery 出神入化，那说“水平提升跟不上”又有什么错误呢？

而且我也强调了，对于偏重后端的全栈型工程师，出于各种因素考虑必须还得和 jQuery 对付着的，这是可以理解的，我也没说不能用啊？！

但是这个调查面对的是纯前端工程师或偏重前端的全栈型工程师好吗？我针对这个前提说“总体水平提升有点赶不上”又有什么错？

如果你现在是一个只会做前端的工程师，你跟人家说我就会 jQuery，测试？不会！自动构建？不会！ES2015？没听说过！这样的，就算说你水平低，有异议？今年是 2015 年，不是 2005 年好吗？

我还能说什么？语死早吗？算了算了，我真不想和你就此问题争执下去了，我作为偏重前端的工程师一向都特别尊重后端工程师，但是在这篇帖子的众多回复里，我看到的却是众多后端工程师对前端这块发展所抱持的怀疑和否定，总觉得在你们眼里大家就停留在 jQuery 就好了，前端也不要瞎折腾了。

我不知道历史上是不是也有同行这样看待过力求进步的后端工程师们，如果你们觉得这没什么那就没什么吧。

我们他妈的求进步就等同于认定你们水平低？这什么逻辑！

顺便借回帖多说一句，前后分离并没有说要用在所有类型的项目上，什么需要什么不需要这是需要您们自己判断的，而且众多新技术也不只是为前后分离而诞生的。不想用也可以不用，没人逼你们，何必总是一副受迫害者的样子？

真累。

#38 楼 @feitian124

1. model 看起来是写两遍，但实际上是把一部分以前在后端的 model 逻辑移交给了前端，减少后端的代码量和处理负担。比如说数据库有 firstName lastName 俩字段，前端定义 model 不是为了单取这俩字段，而是为了合成另外一个 virtual attribute，fullname。这就是个例子，具体能怎么用要看大家的群策群力。现在的确还不算特别成熟，但是不努力就不会有未来，你也可以观望到成熟再用。

2. 验证逻辑也要重复那说明前后的职责不太明确，一般来说分离之后前端验证的是“有没有，全不全”这样的逻辑，后端验证的是“对不对，危险不危险”这样的逻辑。虽说不能保证完全不重叠，但是你要明白前后分离的真正目的不是一对一的服务，而是一对多的服务（一个 API 端可以服务于多个/种客户端），所以时间紧的时候可以优先只考虑后端验证，返回出错信息也是可以接受的。

3. SEO 问题已是昨日黄花，处理和解决办法有很多，不能说它不存在，但真没有人们想象的那么夸张。当初 Ajax 大量用来替换页面内容的时候和现在的 SPA 在这方面又有什么本质区别？多跟一下 Google 的 Youtube 频道，有很多讲这方面优化的。

4. session 保持……这个很难吗？我做了好几年的前后分离，没觉得这有什么技术难度啊？或许我没理解你说的意思，不妨单独讨论。

@nightire

同意你所说的，虽然现在前端还处于混沌状态，但前端需要一批勇于使用和拥护新技术的人。 你们用不用是一回事，了不了解是一回事，但反不反对却是另外一回事了。

#40 楼 @nightire

那比如说现有 devise 这样的登录系统，以及 cancancan 这样的权限控制用的，ember 或其它前端框架有现有，或者比较好的解决办法吗？

#42 楼 @seaify 我问你一个问题，假设你用 Rails 做了一个 API，认证用了 devise，鉴权用了 cancancan，那么这个 API 如果给 iOS 或是 Android 用了，他们和你的 API 也是前后分离体系，那么他们又是怎么处理的？（这是等价的概念）

由于我工作中公司里用的是 Java Spring 做的后端 API，我很难针对 devise 以及 cancancan 说什么特定的解决方案。但是认证这块，不就是要么 session，要么 JWT，要么某种开发协议（比如 OAuth）嘛，说到底就是和 HTTP 打交道。这种类型的现成解决方案不要太多啊，React 我不了解生态环境，Angular 一大把，Ember 也有 simpleAuth，Torii 等库来做。

至于另外一块鉴权，我没用过任何第三方的组件，做了四年 Angular 都是自己写的 service，这东西没有想象中那么难，当然也可能是我没碰到足够复杂的应用场景。正好我新工作开始换用 Ember 了，有关心得体验也在连载中，等到了这一块我单独开贴写好了。

#43 楼 @nightire

认证我知道 jwt, token 这种东西能解决。peatio 里有一份 api token 的解决办法。而鉴权现在想想，认证后，用户身份已知，返回其相应能获取的 json 数据。

cancancan 比较方便的点是，view 里面可以 if can?，但是现在通过 api 返回 json，只能通过 json 里的数据去针对性的 render, 会复杂些，但仔细想，很多场景下，应该还是够用的。

在你看来，ember 或其他框架熟练后，分离出来的前端代码，是否开发效率也能很高，ember 的生态环境怎么样？

好热闹啊。

我只谈感受，在页面复杂的情况下，我觉得，用 angular 之类的前端框架，还是能够比纯 jQuery DOM 要感觉代码容易理解多一点。这点毋庸置疑。

#43 楼 @nightire 好好写 ember，等你的经验分享。 讨厌前后端分离的都是兰博，注重个人效率。 喜欢前后端分离的都 care 的是更多管理方面的东西。

我觉得管理不一定能让东西高效，但是能够事物更加容易管理，容易分工，容易责任分离。 日本人做事情步骤冗余复杂，中国人步骤简单偷懒，但是日本人犯错误几率低啊，中国人犯错误几率高啊。 中国人犯错后责任互相推过，日本人犯错的时候能够从步骤中确认是谁的错误。 前后端能够分离可以把工作的责任分的更清楚，在公司不是小打小闹以后，我觉得在管理上还是有相当的作用的。

#40 楼 @nightire 我们公司前后端分离技术上全部没问题而且还更加好了。

1. SEO 用 prerenderer，以前用 rails 的时候还要把 search engine robot 给屏蔽掉，因为服务器承受不了，现在呢转到静态的页面了。
2. 页面请求可以分几个小请求代替一个大请求，或者模块之间复用请求得到的数据还能 cache 以前页面切换的时候必须重新加载的数据。
3. 前端体验速度更快，后端 api 更加简单快速了。

做管理老大的童鞋们认同的给个赞啊，还等什么呢，别犹豫了点右上角。

@nightire 其实争论是没有必要的，可以看看 BAT 的首页源代码，用事实说话 baidu 和腾讯（qq.com）都是用的 jQuery, 唯独淘宝用的是 KISSY，他们自己开发的前端框架。KISSY 出来的很早，但是文档很差（我很早前看过，当时世界上应该只有 jQuery 和 KISSY，最近没看过，所以我说的是以前，以前，以前），所以影响了它的推广。 虽然没有深入查看腾讯首页的 js 源代码，但是从之前看过的一篇技术文章里有写到，为了实现快速加载，qq 首页采用了很多异步读取的操作来提升网页加载速度。 前端用什么样的框架，在于应用程序前端交互的复杂度，更重要的是

1. 同事的技术栈
2. 代码的健壮性、可维护性 作为一个极客肯定希望使用最新的、最尖端的产品；作为产品的开发，更重要的是开发的进度和代码的稳定性。

#44 楼 @seaify 对的，你已经想到了鉴权信息返回 JSON 了，那么 SPA 框架就是再做一步类似 cancancan 的事情，写一个 service，封装获取的鉴权信息数据，提供一些类似你说的 if can? 这样的 helper，然后就可以在模板里用了。原理上并没有什么区别，就是一个单例对象，应用程序初始化的时候实例化，里面封装了当前用户以及整体的鉴权信息，然后有一些 API 可以操作。你在 Angular 里可以依赖注入这个 service 到需要的 controller，然后视图里直接用就是了（Angular 没有 View 层，controller 维护一个 view model 对象供模版使用）。其他的框架都有类似的机制，React 的话应该是干脆统一保存在 Store 里吧，没写过大型的 React 应用，照原理猜测的。

只是我不知道有什么 3rd party API 特别像 cancancan 的第三方 service，如同我说的，我都是自己写的，我觉得不难。

#46 楼 @roclv 其实我根本就没有争论的意思，原本就是一个分享而已，活在梦里的又不是我。

而且你拿 BAT 举例其实很不恰当，这里有多少人天天做的是那么个庞然大物的？更多的是能做到 Skylight，Strikngly，Teambition 等等的就好了吧，BAT 为什么离不开 jQuery 那是有历史和市场包袱的好吗？而且人家的核心技术团队在推动前端发展上面也是不遗余力的好吧？现在 BAT 做些新东西还不是一样会与时俱进？

现实的例子我就知道有阿里云，因为我的前同事小兄弟就去那里高就的，阿里云用的啥？Angular，做的好不好咱另说，至少人家往前走了吧？我那小兄弟也很高兴当初在我们这个小小公司可以尽早接触到这些东西，对未来的成长也是有利无弊啊。如果我当初就跟他说你就用 jQuery 别折腾，这剧本会按现在走？

#47 楼 @nightire

嗯。实现原理我懂。之前拿来主义居多，倒是木有想，自己写个 helper 封装下。

感觉这个帖子，是目前在 ruby-china 上看到最有价值的帖子了。

其实觉得，多争论挺好的。都拿出自己的理由，要是再有个 react 大神参战就更好了

#49 楼 @seaify React 大神这里有的，我知道，不过他貌似是个纯技术宅，钻的很深很广，这样的讨论我从来没见他参与过。我是一个没什么天赋的人，更热衷于让更多的人开拓视野，所以才会唠叨个没完没了，我也知道会让很多人烦。可是你烦归你烦，世界还是要转的，路还是往前走的。

对了，你看到本站右边的友情链接没有？React China 那个，管理员就是我说的大神，可以去找他单独探讨。

我默默的出来贴一个我的 Github 问题收集 (由于发现内容太多，放在 Github 上不好找了，整到自己的 OneNote 里面去了)

https://github.com/wppurking/ember-cli-todos 这个里面是我在 demo 一个 ember 项目过程中碰到的一些问题以及一些比较简单的思考。一个 demo 寻坑的过程。

• 错误验证
  • 还可以补充下 Parsley.js 纯前端方案。
  • 后端 ember-data 的 DS.Errors + JSON API
• SEO => prerender.io
• 权限
  • 朝向独立处理方案 (类似 https://www.okta.com/)
  • JWT

然后我说个具体在 "用 rails 与 用 rails 当 api 后端 + ember 前端的感觉":

• 在纯写 rails 的时候，是拿着 rspec 写后端测后端 (复杂点的). 然后就是一大票时间在前端改 css 写 js.
• 分开后。至少我写后端就盯着 rspec 写后端测后端。然后 controller 里面就 render json 出去了，然后再控制下。接下来又是一大票时间改 css 写 js...

感觉上写起来真不是很慢，前提："用的东西找自己熟悉感差不多的，你拿着 angualr, ember 新手的状态 + rails 与熟练的 rails 全栈的状态对比，那..... 我没话说"

不说开发速度与复杂性，但在我身上使用这两种方法的时候，我实现功能的思路都同样是区域功能放在这个区域里面实现。jQuery 操作 dom 也会特定将一些东西绑定到一起处理，然后数据放 data-xxx 再拿。在写 ember 的时候就直接封到 Component 里面写，要拿数据直接从在前面穿参数就好。

这都是工具，当然不会"拿着锤子到处都是钉子", 你还是要根据项目来估计你的工具组合的。页面越复杂，你越能感觉操作 JS 对象控件的方便。类似 CMS 给用户看的，爱用啥用啥~ 伴随着云分发 (CDN) 服务 300K 都是小事，800K, 1M 才开始有事~ (你觉得用 2G 手机的用户对移动互联网有多依赖呢？)

#51 楼 @wppurking 呵呵，无独有偶，我自己写了一个项目叫 fagie（Filling all gaps in ember），也是用来填坑的。工作中遇到的问题我就在这里做实验，然后写文分享出来。

支持你，加油，我会保持关注的。

我不怎么写 todo list，我是把每一个具体功能用梳理好的 git log 来记录，大的东西分成分支来做，回头查阅的时候 checkout 就好了

#51 楼 @wppurking 我刚才有个想法，我看到你已经梳理的问题与解决方案都很完整详细了，所以我在想我们是不是可以搞一个 project issue tracker

比方说用 trello 那样的东西，把我们大家遇到的问题、思路、解决方案统一整理到那里面去？这样群策群力应该比个人独立维护一个 demo 项目要更有价值。

甚至于实验用的 demo 项目都可以统一起来，遇到新问题之后可以自己开个分支折腾，或者干脆 fork 一份。但是 issues 统一管理？

反正自己琢磨也是要记录的，大家一起记录可以资源集中共享，遇到想不明白的事情也有个商量的地方，如果你觉得好的话，还可以多拉些人参与，比如 @darkbaby123

以前我用 Angular 的时候就搞过，但是国内 Angular 社区的人都特别浮躁，少有能沉下心研究点实务的人，后来就不了了之了。我的想法是能够最终写出一些开源的 addon 之类的东西，也做做造福大众的事情。

我对前端重量很在意，所以就是 VanillaJS。这些库说实话我觉得没有什么实际意义，门槛太高。

对于多数任务，考虑到招聘难度和完成质量，jQuery 或者 Zepto 的确是最好的选择。有追求点的就 VanillaJS 基于自己的场景做一套 DSL，一切轻松。

PreProssecor 简单拿 Ruby 脚本做个拼接和模版替换也就好了，没必要用什么库

前后端分离对于现在这个时代是好选择，服务器端一套 API 就好了。但是怎么实现就是另一回事了。超过 100k 的框架我觉得都没什么存在意义。

#54 楼 @pepsin 交互少，肯定就上 VanillaJS 了，毕竟世界上最轻量级的库

#55 楼 @xiongxin8802 交互多也一样，好像 ember 什么的就不是 JS 写的一样。

@nightire 我说的 session保持 的问题可能太泛泛，举个例子：current_user.

你前端想要一个 current_user, 用了 simpleAuth, 在 initializer 里面注入到 session, 得到一个 promise. 然后我在 application route 里面还有一部分逻辑，是处理购物车的，跟 current_user 相关，session(cookieStore) 只能放很少的东西，你要依次初始化这些对象 (去后台去取，都要发请求，如果服务器端生成页面的话就直接取了), 难度体现在：

1. 处理 promise. 我为了每次都有一个可用的 ember model 对象，把 resolve 好的对象塞到 applicationController 里面，其它 controller 里面定义一个别名引用它 (这样很傻..).
2. 考虑到 购物车 列表，商品列表等，即使用了 side load, 请求次数和数据量也挺大的。且每次用户刷新，上述逻辑都要跑一遍，数据都要跑一遍。

现在看来，有些问题是我 ember 没用好造成的，比如为了烦躁的 promise 问题，我后来将所有的模型全部定义为同步的了.. 还有的是 ember 本身还在快速演进，比如 ember service, 至少在我使用的 1.X 版本里面没有。

作为一个全职写了一年 ember 的人，我后来总结是使用 ember 拖了项目进度的后腿，当然这不是 ember 的问题，一是可能场景不适用，二是学习成本 (以及没学好用好..)

我也认可你的观点，前后端分离及 ember 是前端的方向，仅一个 双向绑定 可能就会让你爱不释手。有厉害一点的前端，或者团队允许一定的试错，ember 可以上的。

在你的大力普及下，我对 ember 的关注度和信心又上升了

ps: 作为一个厉害的前端，怎能没用合适的后端，看看这个？https://github.com/artificialio/sane

#57 楼 @feitian124 你举的那个例子其实挺有代表性的，我其实吧并没有特别想要大力普及 ember，这都是缘分。当初在我自己的公司里评估的时候的确大家会觉得当时的 Ember 有很多问题没有明确的回答，而且那个时候大家对 Promise 的理解（比如你之前提到的，为了重用 promises 返回的对象，该怎么办）都不到位，相比较而言觉得 angular 抽象的 $http 更容易理解一些，所以我们选了 Angular，一直到今天。

所以我使用 Angular 其实比 Ember 厉害多了（笑），真要大力普及的话，前者对我的压力也肯定会小的多，后者我普及它的时候别人问我问题有时候我还得犯傻，还得现查资料，还得去求助别人……如果只是为了当传教士，这个代价也太大了。

那么为什么在这里我总是喜欢谈 Ember 呢？第一，Ember 和 Rails 有着不解之缘，Ember 的很多机制和理念都和 Rails 如出一辙，因为 Java 带给我的影响（我在另外一篇里谈到过），我对 Rails 是有着深深的“爱恋”的，有时候我也郁闷为啥我不去做后端……然而 Ember 给了我很多 Rails 当初给我的感觉。第二，Ember 虽然还有这样那样的不完善之处，但是我对 Ember 的社区和核心开发团队很有信心（这来自于很多细节，版本更迭与发布流程，先后兼容政策，RFC 策略等等）

然而我也承认以前的 Ember 的确有很多缺陷（所以让你痛苦了好一阵子），不过类似的问题放在别的地方也不是没有啊，Angular 处理 current user 很轻松吗？市面上有的 modules 基本上都是针对 token based authentication 的，而我们以前的项目基于很多原因都还是 session 那一套，我们为了 current user 这样的问题在 Angular 里面前后尝试了 n 套方案，最后才封装了一个适合自己的 module 来复用，折腾起来也不一定会比 Ember 轻松多少。

有些东西就是这样，场景需求变化太细致，太复杂，以致于很难搞出特别通用化的 solution。我对这样的问题的看法是：不怕有问题，总会有好的解决方案，我们是程序员，程序员就是 problem solver。有了这个信心，用什么都一样，但总会有更好的。

前后端分离算是我进入前端之后折腾的最大的事情（架构级别），它是不是未来的方向？其实我在我的总结里已经分析过了，至于 Ember 的前景……我未必会有那么乐观——然而这不妨碍我去用它，我用什么东西，市场占有率和前景从来都不是主要的考量指标。

#57 楼 @feitian124 最怕高级黑，你这一说连 @nightire 都只能说“Ember 的前景……我未必会有那么乐观”了。

其实 Ember 就是奔着 Rails 的思路去了，大而全，架构啥的全给你考虑好了（虽然一堆前端在大叫，我们不要大而全的框架，我们怎么写不要你管那么宽，我们只用熟悉的 jQuery）。

现在 Ember 主要两个问题，框架大，没后爹，仔细想想应该都不是大问题。

框架大，只要核心开发者是有经验的（这点 Yahuda/Tom Dale 应该绝对有经验，都是十几年前从大公司辞职出来的开发者），其实是功能全的副效应，Rails 框架同样庞大，但是人家功能全啊。

没后爹，短期看发展的确会慢，但是长期看，单一公司推动东西总是输给社区推动的。（Flash, Silverlight, iOS）

Ember 2 现在的阶段是 Rails 2，坑是必然的，很多人选择不填坑，但至少也要尊重一下努力填坑的先行者吧？Ember 是最亲 Rails 的前端框架（理念，人员），学习一下真心不错的。至于最近大火的 React 现在才 0.13，还早呢，最近 Ruby Tuesday 聊了下，其实产品级使用远不能和 Emberjs/Angularjs 比。

#54 楼 @pepsin

对于多数任务，考虑到招聘难度和完成质量，jQuery 或者 Zepto 的确是最好的选择。有追求点的就 VanillaJS 基于自己的场景做一套 DSL，一切轻松。

能做出 DSL 的高手来说，当然一切轻松，可惜现在国内有能力做 DSL 和框架的人不多，能说服别人接受你的 DSL 的，就。。。还是放弃吧，你看一堆人还在吵到底用 React/Emberjs/AngularJS 还是 Vue 呢。和这些比比，凭啥用你的自制 DSL 呢？给钱就用的是好的开发者么？

#60 楼 @ericguo 其实我很不理解一群工程师干嘛要考虑招聘难度？这又不是我们的责任，而且这种事情你考虑了也解决不了，从自身出发来看：凭啥因为市场上没有足够多好的开发者，我就要迁就剩下的人？非常古怪的思路。如果你的队友跟不上，那就淘汰他们，你做好自己的事情就对了，如果你的领导看不出这种差距，看不到你的努力和价值，那就说明你跟错了人上错了车。拿钱给人干活的，想那么些有的没的干啥？如果是创业的，那眼下重点也不在于技术选型上，现在找不到人以后有钱了还怕找不到人吗？总是抓不住思路的重点。

#61 楼 @nightire 加油，少灌水，用产品说话。

#59 楼 @ericguo 误会误会啊，其实我的意思和你一样，ember 是个好东西，鼓励有能力有精力的人捣鼓，个人觉得比 rails 门槛高. 其实我用 ember, 从 ruby 圈子进入了 nodejs 圈子，这本身就让我受益匪浅。

#60 楼 @ericguo 我反正没有说服别人这个问题，实际场景就是需要 JS 重量小。

我很搞不懂现在都是移动时代了，每个手机联网效果差了一大截，怎么还有人喜欢各种大架子。真的是一堆公司被某些人的喜好绑架了，舍本逐末的感觉。

@nightire 可以推动一个 Filling all gaps in ember 啊，其实也无需每一个场景 fork 一个 repo, 可以使用 ember 专门的 Ember Twiddle 来展示代码。

其实我的目的是记录下大概的思路，因为如果细节写下每一个场景问题，可是可以扩展得很开的。但那样就会有可能收不回来而太细节。只要能够为相同场景下的问题有一个指导的方向，就可以很快找到思路避免走弯或者再在场景下优化思路。不写太细的原因是考虑到，能够碰到一些比较细节的问题的同学已经度过新手的阶段，只要"抛砖"就能够接上。

对于 trello 的形式，这个问题就 Github Issue 这个级别 + tag 就可以了，毕竟没有啥复杂的内容，只要在 Issue 中讨论也足够清晰。

@feitian124
我估计，后端作为 API Server 那 Session 的概念估计会被另外一个思路给替换了。拿购物车为例子，前端后端 (html 作为前端也是，js 作为前端也是), 都需会需要一个衔接的 "key", html 前端可以是 cookie 作为 Http 的补充，那 JS 前端估计就会需要调整为 token 作为凭证。在后端的购物车状态信息，应该是需要被持久化的了，可以是 db (数据库) 也可以是 redis (缓存), 这都是为了能够横向部署多个进程扩展嘛。

换到前端要获取信息，html 前端会 jQuery 异步处理再返回结果 (js/html 片段), JS 前端也会 Ajax 回去再获取返回结果。购物车的操作一定是会沉淀到后端去的。

最后，大家都别那么激动嘛，无论 HTML 的前端还是纯 JS 的前端都是很好的方案，而且都有各自的演进线向前演进着。开源的多样性不正是好事嘛，一个个新的项目冒出来一个个新的想法迸发，看到新思路赞善一句也无妨哈，默默关注也 OK 嘛。

#23 楼 @seaify strikingly.com :D

http://www.infoq.com/cn/news/2015/09/css-javascript-npm

对 Rails 开发者来说我觉得比较好玩的还是 Volt 和 Ember，React 前端门框还是有不少的

用原生 API 从头实现功能还是很辛苦的，阿里应该也就只有无线有这个条件，能够不担心兼容性放心去写。其他事业部要么 jQuery 要么 KISSY，终究还是需要库的。我们造了一个小轮子，实现了 jQuery 中 DOM 操作和事件绑定的部分，用来广告代码里，文件尺寸能小很多，叫做 yen

看了一圈，没有 vue 的字眼，好失望啊

#70 楼 @ftandy 哈哈

@wppurking @pepsin @xiongxin8802 ...

#70 楼 @ftandy vue.js 看起来还不错很轻量级，但是听了 teahour，作者节目里去喷别家类似框架，感觉不太好。

感觉好失望

jquery is for backend developer.

@tim_lang 没有喷，只是对比而已。vue 确实好用，很适合轻量级的前端应用。

前後端分離是大勢所趨，不過很多大項目基於歷史原因還是無法脫離 jQuery 也是事實。大家不願意付出學習成本大概也有生活壓力的原因吧。

Backbone+marionette+jquery is always my favorite.

整日追框架，累，还是紧抱 jquery 靠谱

#61 楼 @nightire

最近看 ember 的书，对 rails 开发者确实太亲切了，各种能对应。

对 emberjs，还不算熟，有几个疑问。

ember-data，如果客户端的数据和服务器端不一致呢，比如 save 后，发 api 请求，但因一些意外失败了？

另外 ember-cli，为什么要要是 bower，又是 npm，包管理一定要 2 个？

似乎 react 里的组件间通信，在 ember 里并没有体现？

graphql，socket.io 这些东西，ember 社区有相应的努力吗？ember 的社区怎么样？

#80 楼 @seaify

1. ember-data 是客户端的 data store，实际上它和你怎么与 server 通信并没有直接的关系，只是它自带的 adapter 实现了对应的接口，底层还是 ajax，该怎么 handle server error 是你的事情。客户端的数据与服务端不一致可以通过 serializer 层来转换。

2. bower 和 npm 的问题是前端生态圈的历史遗留问题，并非 ember-cli 非要这么选择，其他的 build system 也有类似的情况，比如 yeoman。

3. 组件间的通信看 component 的文档就是了，怎么叫没有体现？包括 DDAU 也是可以的，ember 并不限制你如何通信。

4. graphql，socket.io 这些东西本质上就是第三方库，ember 的核心团队不会对此有什么特别“看法”，ember 提供的 service 机制可以让你把任何第三方库整合进你的 ember app 里，你也可以选择直接使用它们，并不会因为你用了 ember（或其他什么框架）这些东西就变了。当然，社区会有人做一些 addon 把常用的第三方库封装好以便快速使用，这就好像 gems 一样。你可以看看这里：http://www.emberaddons.com/

react 有点废材了。 rails 光做 api 又太重了。