近段时间是令前端工程师们非常兴奋的时期，因为三大
框架陆续发布新版本，让我们见识到了更强大的 Web 框架！ 2.0 已于去年 6 月发布，从 1.0 升级到 2.0 会非常简单；随即
也发布了 0.14 版本。还有很多流行的前端框架，像
、 及 Aurelia 等。如果你想开发一个 ，建议采用 ，Ember 或 React 三种框架中的一个。这三个框架可以说是安全级别最高，技术非常成熟的框架，而且有很多技术社区支持。如果你又开始纠结了，到底改用哪个框架呢？哪个更好用更安全更强大呢？那么通过本文，你就可以详细地介绍三大框架新版的优缺点并进行对比，希望能够对你有所帮助！1. Angular 2.0（与1.0对比，发生了翻天覆地的变化）Angualr 2.0 版本重新定义了框架，自身发生了非常巨大而又戏剧性的变化，因为 Angualr2.0 不支持向下兼容，使低版本升级到 2.0 版本成为一条绝路！然而，软件行业总是充满了奇迹和天才，Angular 团队为从 Angular 1.X 到2.0的升级指出了一条明路，使升级变成渐进增强的过程。我想正是因为这个方法才拯救了 Angular！到底 Angular2.0 有什么令人兴奋的功能？砍掉了些不必要的功能，提升性能如$scope从Angular 2.0中移除，取而代之的是ES6类。除了框架自身变得更简洁，还有一些其他注意的特性：性能提升性能提升可以说是众望所归，如果你对 Angular 非常熟悉，你已经具有分解功能的能力，创建 App 也不在话下，性能问题总是有办法解决的。原生App支持使用 Angular 开发是 2.0 版本的最大改进，Agular 团队与 React 联合，在Angular 2.0 中底层使用React Native渲染原生App，可实现新一代的混合App，执行过程与本地App相同，但可在逻辑层可在多平台中共享。服务器端渲染能力Angular 2.0实现了服务器端渲染能力的很大提升，减少了初始页面加载时间，通过动态页就能提升SEO。页面渲染速度的提升，将大大改进Web App的体验。为什么选择 Angular?Augular 已然成为 Web 应用开发世界里最受欢迎的开源框架。开发新项目选择Angular无疑是一种安全的选择，Angular2.0 与1.0有很大的不同。事实上，Augular 2.0 演化过程与 Ember演化类似（Ember最早被称为SproutCore2.0）。Angular支持使用
语言（由提供的，为JavaScript提供类型检测等高级功能）。在实际开发中，很多开发人员还在使用。Angular很多方面的改进都期望能够使Angular成为众多企业开发首选的框架，使用2.0目前来看似乎有点冒险，但我相信Angular2.0时代即将到来。2. Ember 2.0Ember.js 号称是一个“雄心勃勃”的JavaScript 、现代JavaScript 的代表，是构造单页面应用等现代Web的新型端开发框架。有很多App的创建都在使用Ember，如’s properties,Discourse,等。Ember 是由两个非常传奇的工程师开发创建的，并不是由大企业研发而成，尽管如此，Ember仍有众多强大的技术爱好者的支持。Ember2.0 特点：Ember 2.0主要改进——移除了之前不建议开发的功能，旨在成为一个瘦身框架。在Ember 1.13上运行的程序，可以无缝切换到Ember 2.0上。Ember 2.0进一步采用ES2015功能模块，类，和decorators。修改了项目分布结构，使用“pod”分类代替功能分类（控制器，models，组件等）。控制器被移除，支持路由控件。高级服务器端渲染器减少了页面加载时间，优化。谁更适合使用Ember？实现 ，Ember是最佳选择！目前，已有很多App都使用了Ember框架，Ember也将被协会所接纳，并且它还拥有大量的资源供你使用，如文档，技术等。Ember 对购买工具包含框架的人来说是非常好的选择，我们经常会浪费时间去寻找、研究、评估一些开发框架。EMber为你提供的选择非常多，而且都非常有价值。3. React1.0React1.0 是三个框架中最轻量级的框架，React在渲染UI控件方面做的非常好，经常与其他框架结对使用，例如与Flux 体系架构联合使用等。Flux是与React生态系统类似，却与 完全不同的体系架构。创建React的目的，是为了保证多个页面的外观一致性。使用REACt确实能够达到这种效果，它提供了令人难以置信的性能表现和服务器端的渲染效果！有个很有趣的现象，Angular和Emver都在争相发布新版本，只有React在自己擅长的领域内继续创新！React1.0版本的重大功能：1. 升级项目网站2. 升级框架文档3. 增强动画的鲁棒性React改进的核心目的为了提升开发人员的体验，React的一大亮点是使用React提供的元素来创建动画，会变得非常简单！谁更适合使用React？开发新项目或是改进旧项目，React都是很好的选择。使用React框架，可以让创建App UI变得非常简单。如果你想逐渐改善你的项目，选择React是非常合适的！React项目通常用ES2015编写，如果你的项目只需要应用框架中一些简单的库，React就是最佳选择！三大框架对比首先需要说明的是，三大框架几乎可以覆盖所有需求。这些框架的功能都很独特，许多好的设计和实现思想，都已经在三大框架中体现的淋漓尽致了。Ember可视为是启动最快的框架，但是 的学习成本较高，而就最终App而言，Angular JS 开发的app只需要写很少的代码，就可以实现。从上图种可以看出，为什么三大框架如此流行？这是因为各自的优势都很明显。三个框架没有绝对的好，只有相对而言，哪个框架更容易满足项目需求与设计的App的功能所需，就可以选择哪个。并且三大框架都将向着更好且更快地支持服务器端渲染的方向发展，Angular和 将支持和的原生，使用此三种框架未来能够做很多的事情。前端工具用起来渐成热潮，了解前端框架后，还需要了解开发工具：新一代 /
UI控件Wijmo，大而全面的工具包，现已全面支持 2。下载试用，请联系我们：微信：GrapeCityDT邮件：marketing.官网：.cn关于葡萄城控件葡萄城是一家跨国软件研发集团，专注控件领域近30年，是全球最大的控件提供商，也是认证的金牌合作伙伴。将为您减少类似内容我要收藏0个赞不感兴趣分享到分享到：相关文章还可以输入140字热门频道44.2万人订阅17.6万人订阅11.7万人订阅52.2万人订阅119.5万人订阅你还可用第三方账号来登录请输入你注册的电子邮件地址绑定密保手机*您可用使用此密保手机找回密码及登录*请勿随意泄露手机号，以防被不法分子利用，骗取帐号信息手机号码发送验证码确定电子邮件请输入您的意见和建议请您输入正确的邮箱地址，以便我们和您联系，帮您解决问题。扫描下载手机客户端热门搜词2015 最新调查：现在的前端工程师都用什么？ · Ruby China
本帖已被设为精华帖！
推荐大家去扫一眼：
即使你完全不做前端开发，但身边也离不开前端伙伴们，看看这个调查可以知道你身边的前端工程师靠谱不靠谱。
话说回来，看到 jQuery 和测试工具的结果还是令人挺沮丧的啊，尽管这两年前端发展日新月异，可是总体水平提升还是有点赶不上。
那些用 jQuery 已经在线上跑的好好的东西，谁没事找事换啊，钱谁出、风险谁担呢。
在 rails 里做像用 jQuery 替换 prototype 那件事 ， 那就说明 jQuery 老矣 O(∩_∩)O哈！
PostCSS and Rework 这块没有接触过, 其他还是有所耳闻
看不懂他的问卷啊。jQuery heard of/read about: 1.7%， never heard of: 0%。这两个指标不应该是mutual exclusive么。
jQuery，万金油，也没那么不堪，发现在技术社区只要是易学易用的东西，评价都不高，特别是“易学”这个特点，最招黑
四个选项我是这样脑补:
jQuery / Zepto 实用又轻量, 我可以用它做任何事情
而那些臃肿的框架, 经常做点简单事情都会查到未 fix 的 github issue...
你可以不用所谓“臃肿的框架”，但作为前端工程师你也不能离开了 jQuery 就不会做任何事情，这是对于前端工程师的要求而已。
我们对 jQuery 的结果感到沮丧，不是因为 jQuery 不好，也不是鄙视还在用 jQuery 做项目的团队／个人——这些都很正常，比方说使用 Angular 或 Ember 等“臃肿框架的”，当面对 DOM 操作的时候多数人还是会操起 jQuery／Zepto。
但是作为前端工程师的我们必须知道 jQuery 的来由，知道它曾经如此红火的原因，同时也应该知道现在生态环境的逐渐成熟，有多少事情其实是不必依赖 jQuery 的。太多太多的人用各种理由来为自己“离不开 jQuery”做辩护，太多太多的人用这些理由束缚自己的脚步和视野。
更多的我不想说了，叫不醒的人永远都叫不醒，他们永远都会有数不清的理由，随便吧。
只说一点：离不开 jQuery 的，将永远把 UI 编程弄成“以 DOM 为中心”的编程，如果你觉得 fine，那就 fine。
对用户的调查是按熟悉程度划分百分比的。比如 jQuery
Heard of/Read About
Used a little
Feel Comfortable Using
Never Heard of
91.5% (955)
四项加起来正好 100%
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。尼玛。写着都烦。
你前后分离，还关带 viewer 的 gem 什么事？恕我愚钝看不明白你在说什么。
另外，使用新技术的往往都是从内部项目或是非开放型项目开始的，所以公众平台上可能比较少也很正常。别的框架我不了解，Angular 的开源项目简直不要太多，问谷歌吧。Ember 的话可以看看这里： 都是质量很高的。
这五个都是值得一看的，它们都符合你的要求：开源，Rails／Grape Backend API，大项目，有线上产品可以参考等等
就当做是考量。有些舍不得这么多已有的gem
非常感谢你的这些推荐。特别是第2和3项开源项目.
我不懂前端。但是我以为，考量前端的功力不是应该是 JS 玩的多溜吗？框架这件事不要那么在乎吧，项目适合用哪个就用哪个啦。今天 Angular, Ember, 明天就出了个 Bngular, Fmber
离开了 jQuery 就写不了 DOM 操作也没什么好羞耻的吧, 毕竟 W3C 的 DOM API 设计得不好用啊... 离开 Angular/Ember/React 就不会操作 DOM 的人也有一大堆
功能和 jQuery/Zepto 不重合的小框架也有不少, 它们可以一起用. 有些框架干脆就实现了部分类似 jQuery 的 API
16楼 已删除
咱们不说这个了好吗？我觉得你也是一个高手，我很不好意思和你争论这个话题。
这就好比我也懂一些 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。 你喜欢这样认为就认为吧，我无所谓 兄弟，还能不能好好讨论了？
不知道是谁神经敏感了，好吧，不说了。
如果你觉得 fine 那就 fine，我不觉得我这句话有什么问题。作为前端工程师，我知道有比 jQuery 更好的方法和思想去做我的工作，但是非专业的前端工程师却要对我说：jQuery 没什么不好的，你不能指责用 jQuery 的人。问题是我有说 jQuery 不好吗？我有认为还在用 jQuery 的人羞耻吗？我只是觉得到了今时今日，还有这么多的前端工程师（请注意，这个调查的对象都是前端工程师，不是偶尔做一些前端的后端工程师）还如此依赖 jQuery，舍不得迈开探索的一步，这个现象让我觉得沮丧而已——这么多人看不懂吗？
既然你们觉得停留在 jQuery 的 comfort zone 就足够了，那我的确没什么好说的，觉得 fine 就觉得 fine，有错？
至于后面那句话，其实是我回错人了，所以我删了，向你道歉。
当我们说到“前后端分离”的时候，我不知道诸位后端工程师是怎么理解的，但是在我们前端看来所谓“分离”就是所有和前端相关的代码：HTML＋CSS＋JavaScript，它们都是可以在完全没有后端的环境下进行开发的。我们不需要把源代码混合在一起，我们不需要把运行环境混合在一起，我们不需要把部署混合在一起，从开始敲下第一个字母直到最终上线，前端工程师都完全不需要知道后端到底用了什么，放在哪里，如何运行。唯一联系彼此的纽带就是 API 的通信和线下的设计、业务沟通等等。
我的确看到一些 Rails 项目使用了 Angular／Ember 等 SPA 框架，但是代码却是混合在 Rails 框架里的，如果你仔细审视他们的写法你会发现他们根本就没有分离，他们还是用着老一套的思想去做 UI 编程，唯一不同的是他们利用了那些 SPA 框架里的一些特性而已，比如说数据双向绑定，模版系统等等。然而这和我们前端所说的分离还相差很远。
如果在架构体系上做到了我所说的那种分离，也就意味着你之前所用到的任何 gems 都不再需要了，因为我们根本就不需要依赖 Ruby 环境好吗？所以你不用舍不得的，任何涉及到前端开发的 gems，前端的生态系统里（主要是 node＋npm）都一定会有一样的或类似的，只可能更好不可能更糟。从另外一个角度说，现有的项目并不建议彻底的分离，因为的确如你所说有很多东西需要替换。
我给你加了一个新项目在原来的回复里，这个新项目不是很知名但是它很新，你可以看到基本上都在用最新的版本，而且代码更新也比较勤快（应该是正在开发中的项目）
我明白你说的前后端分离，是仅通过api通信, 写过一个很烂的react代码，就是通过api通信的，。
而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太蛋疼，目前正在想用什么样的解决方案来替换掉它，影响开发效率和心情
能不能推荐些react线上在运行着的开源web项目？SPA的。要是界面更漂亮那就更好了.
要是再有react vs ember。。O(∩_∩)O~，从周边来看，觉得使用react的人更多了.
awesome-react的app节点下的推荐太少了，Khan Academy'的perseus也不好看.
前端的世界变化太快...
ember 还没掌握好, react , webpack 什么的又火起来了..
前端变化快是不假，但是 ember 和 react 不是一个概念呀，一个是全功能的框架，一个只是视图层的库，不用都学啊。webpack 就只是一个模块加载打包器罢了，周边工具而已，学起来也没有什么负担。而且ember 有 ember cli，webpack gulp 之类的都不需要用的，而 react 本身只是解决了视图层的问题，你要做大规模的应用还得解决其他环节，比如路由，数据映射，事件分派等等，最终你等于用各种库拼出一个 ember 来——当然还是有区别的。但是 react 的优势其他框架又不是没有，DDAU ember 也可以实现啊，virtual DOM ember 的 glimmer 引擎也毫不逊色啊。
现在的趋势就是真正在干活的人被 前后端分离信仰和 micro service 神教夹击 -_-
你觉得 Vanilla JS 优于用 jQuery, 但是想尽快完成任务的人不一定会这么想, 因为实施起来还需要 Modernizr 检测载入 Polyfill, 要编译 ECMAScript 到 Javascript, 而且标准 API 写起来都特别长, 也没有 $.css(), $.addClass() 这些工具.
我也感到沮丧, 因为调查者觉得自己的工具和理念比 jQuery 优越, 但他却完全不提 Elm, ClojureScript, LiveScript 等前端语言, 以为前端都得围绕着 JavaScript 转, 这也是一种狭隘和 staying in the comfort zone. 一些框架里设计的半吊子 DSL, 换个语言就会清爽简洁得多并且容易调试得多
另外我说的臃肿框架, 还包括 jQuery-UI 和很多膨胀的 jQuery 插件, 但不包括 React 等简单的渲染库.
我有这么说么？我觉得你只是把你的怨念强加在我身上而已，你所说的一切，比如：
你觉得 Vanilla JS 优于 jQuery
觉得自己工具和理念比 jQuery 优越
我没有这样说过吧？我对“沮丧”的解释在前面已经说得很清楚了，不知道你为什么总是认为我们在排挤 jQuery？
另外，elm clojure 等等要用在浏览器里就不需要编译了？
只靠 React 就能写大型应用程序了？
没有哪一种工具是万能的，但偏偏很多人却觉得 jQuery 是万能的，别人连说它都不能说了？更何况也没有强求大家不要用它，只是希望能有更多人往前迈一步，有错？难道不用 jQuery 就只剩下 DOM 着一种选择？难道你用 React Ember Angular 的时候还要天天写 getElementById 这样的 API？
我和你的根本分歧就在于：
我说不用 jQuery（其实也没说不用，只是少用，但偏偏都觉得我是说不用），不是不让用，而是鼓励去尝试更多的选择。
你说不用 jQuery ，然后就只剩下 DOM 这一个选择了……这样一对比你自然是稳居不败之地。
现在的趋势就是想推动前端继续进步的人却被一群自恃全栈工程师却死抱 jQuery 还不许人家撒手人拖着后腿
很讨厌像这样乱开地图炮，模仿一下而已，不会生气吧？
都没人提 Backbone 哼
我了解过调查问卷里面提及的大部份工具，结论是在我的场景用不上。不是所有网站都有复杂的交互逻辑，我用着 Rails 默认栈感觉良好。
前后端分离有点为了用而用的意思了，劝说使用这些工具之前应该看需求有没有必要。现在就算是前后端分离也向着全栈的方向去，因为后端提供的 api 不一定适合前端，又有很多理由不能改动，这样前端团队就要变成全栈，参考淘宝 UED 的前后端分离：。跟现有的服务端分离后，要重新实现一套基于 js 的框架、库、构建工具、部署工具，而这些工具都还在混战中。同时前端实现的 api 服务器成为服务端面向公众的第一线，就要考虑安全、性能等等各方面原先服务端考虑的内容。
这对 js 程序员可能是好事，因为工作需求增加了；对原有服务端是好事，因为工作量减少了；对大公司也是好事，因为可以并行安排工作给不同团队了。但是对于已经适应全栈开发的团队，换一个语言重新实现一遍没有什么好处，这些工作本来就是自己做的，分割两个程序还需要更多的调试和管理；对于小公司，快速满足业务需求才是最重要的。
另外我不认可前端后端这样区分开发者，我认为 Web 开发就是任何相关的知识都要了解，但是按照纯血
js 前端的定义我就是后端程序员了，似乎先天性缺乏前端基因。实际上我写的 js 也不少，适当的地方使用适当的工具。过于激进的推动前端独立可能会产生被重视的感觉，但是脱离实际就没有生存的土壤，对 jQuery 感到舒适的比例那么高应该看作用脚投票。我喜欢那些跟现有技术栈协作良好的工具。
支持 Backbone，一直放在我的后备箱中，它跟我的开发理念很匹配，不过一直没有复杂场景用得上。
我用，这东西正如他的名字一样，真心提供了她该做的（一样儿也不多）。
你感觉淘宝 UED的nodejs做中途岛怎样？，好吗？我有一个小项目是做一个学校的门户网站，我用了nodejs来做中途岛大概框架就是参考的，我自己感觉很好，做到模板复用，解决了seo问题，同时也解决了angularjs等单页面第一次加载慢的问题，而且写复杂的前端交互也挺顺的，写起来也很自由没有前后台的界限。这是我自己的感觉。说实话，我们公司挺小的，我正打算以后都做成完全前后台分离的，前端可以用nodejs或单纯用angular等，后台可以是soa框架（按功能分块），当然了，我只是停留在想法上，没啥经验对这方面。
而我"感到沮丧"段说的是调查者, 不是你... 因为调查者说
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确实很臃肿
淘宝 UED 的方案在他们的场景有合理性，但不是适合所有人。我觉得 Martin Fowler 的
也适用于这个问题：
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、首页加载这些都是前后端分离才引入的问题，用服务端渲染就好。如果是技术人员维护我还推荐静态网站。
的分析 非常棒！补充一点，创业公司很难招到那些熟悉和掌握理念上比较“超前”的js框架，更多时候backbone+jquery或许是更好的选择。
淘宝 UED 感觉最近收声了啊。midway 炒了个大新闻，不懂后来如何了
前后端还分离烦躁的事情还是有不少的, 部分代码要写两遍, 比如前后端的 model 呀, 一些验证逻辑等, seo, session保持 等,
单个看是小问题, 堆积起来多了也郁闷.
哈？难道你就是这么理解的？今天真心见识了！
总体水平提升还是有点赶不上，这句话哪里暗示了初始水平低这个条件了？
所谓总体水平提升，指的是从范围（前文的这两年是范围）开始到结束，在这个区间内的增长程度；我原话是拿这个程度与同时间段内前端业界总体的发展程度做对比，才得出“有点赶不上”的结论。这怎么就是暗示初始水平低了呢？
再说了，就算两年前你的 jQuery 用的出神入化，但是两年后你还只是 jQuery 出神入化，那说“水平提升跟不上”又有什么错误呢？
而且我也强调了，对于偏重后端的全栈型工程师，出于各种因素考虑必须还得和 jQuery 对付着的，这是可以理解的，我也没说不能用啊？！
但是这个调查面对的是纯前端工程师或偏重前端的全栈型工程师好吗？我针对这个前提说“总体水平提升有点赶不上”又有什么错？
如果你现在是一个只会做前端的工程师，你跟人家说我就会 jQuery，测试？不会！自动构建？不会！ES2015？没听说过！这样的，就算说你水平低，有异议？今年是 2015 年，不是 2005 年好吗？
我还能说什么？语死早吗？算了算了，我真不想和你就此问题争执下去了，我作为偏重前端的工程师一向都特别尊重后端工程师，但是在这篇帖子的众多回复里，我看到的却是众多后端工程师对前端这块发展所抱持的怀疑和否定，总觉得在你们眼里大家就停留在 jQuery 就好了，前端也不要瞎折腾了。
我不知道历史上是不是也有同行这样看待过力求进步的后端工程师们，如果你们觉得这没什么那就没什么吧。
我们他妈的求进步就等同于认定你们水平低？这什么逻辑！
顺便借回帖多说一句，前后分离并没有说要用在所有类型的项目上，什么需要什么不需要这是需要您们自己判断的，而且众多新技术也不只是为前后分离而诞生的。不想用也可以不用，没人逼你们，何必总是一副受迫害者的样子？
model 看起来是写两遍，但实际上是把一部分以前在后端的 model 逻辑移交给了前端，减少后端的代码量和处理负担。比如说数据库有 firstName lastName 俩字段，前端定义 model 不是为了单取这俩字段，而是为了合成另外一个 virtual attribute，fullname。这就是个例子，具体能怎么用要看大家的群策群力。现在的确还不算特别成熟，但是不努力就不会有未来，你也可以观望到成熟再用。
验证逻辑也要重复那说明前后的职责不太明确，一般来说分离之后前端验证的是“有没有，全不全”这样的逻辑，后端验证的是“对不对，危险不危险”这样的逻辑。虽说不能保证完全不重叠，但是你要明白前后分离的真正目的不是一对一的服务，而是一对多的服务（一个 API 端可以服务于多个/种客户端），所以时间紧的时候可以优先只考虑后端验证，返回出错信息也是可以接受的。
SEO 问题已是昨日黄花，处理和解决办法有很多，不能说它不存在，但真没有人们想象的那么夸张。当初 Ajax 大量用来替换页面内容的时候和现在的 SPA 在这方面又有什么本质区别？多跟一下 Google 的 Youtube 频道，有很多讲这方面优化的。
session 保持……这个很难吗？我做了好几年的前后分离，没觉得这有什么技术难度啊？或许我没理解你说的意思，不妨单独讨论。
同意你所说的，虽然现在前端还处于混沌状态，但前端需要一批勇于使用和拥护新技术的人。
你们用不用是一回事，了不了解是一回事， 但反不反对却是另外一回事了。
那比如说现有devise这样的登录系统，以及cancancan这样的权限控制用的，ember或其它前端框架有现有，或者比较好的解决办法吗？
我问你一个问题，假设你用 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 了，有关心得体验也在连载中，等到了这一块我单独开贴写好了。
认证我知道jwt, token这种东西能解决。peatio里有一份api token的解决办法。而鉴权现在想想，认证后，用户身份已知，返回其相应能获取的json数据。
cancancan比较方便的点是，view里面可以if can?，但是现在通过api返回json，只能通过json里的数据去针对性的render, 会复杂些，但仔细想，很多场景下，应该还是够用的。
在你看来，ember或其他框架熟练后，分离出来的前端代码，是否开发效率也能很高，ember的生态环境怎么样？
好热闹啊。
我只谈感受，在页面复杂的情况下，我觉得，用angular之类的前端框架，还是能够比纯jQuery DOM要感觉代码容易理解多一点。这点毋庸置疑。
好好写ember，等你的经验分享。
讨厌前后端分离的都是兰博，注重个人效率。
喜欢前后端分离的都care的是更多管理方面的东西。
我觉得管理不一定能让东西高效，但是能够事物更加容易管理，容易分工，容易责任分离。
日本人做事情步骤冗余复杂，中国人步骤简单偷懒，但是日本人犯错误几率低啊，中国人犯错误几率高啊。
中国人犯错后责任互相推过，日本人犯错的时候能够从步骤中确认是谁的错误。
前后端能够分离可以把工作的责任分的更清楚，在公司不是小打小闹以后，我觉得在管理上还是有相当的作用的。
我们公司前后端分离技术上全部没问题而且还更加好了。
1. SEO 用prerenderer，以前用rails的时候还要把search engine robot给屏蔽掉，因为服务器承受不了，现在呢转到静态的页面了。
2. 页面请求可以分几个小请求代替一个大请求，或者模块之间复用请求得到的数据还能 cache以前页面切换的时候必须重新加载的数据。
3. 前端体验速度更快，后端api更加简单快速了。
做管理老大的童鞋们认同的给个赞啊，还等什么呢，别犹豫了点右上角。
其实争论是没有必要的，可以看看BAT的首页源代码，用事实说话
baidu和腾讯（qq.com）都是用的jQuery, 唯独淘宝用的是KISSY，他们自己开发的前端框架。KISSY出来的很早，但是文档很差（我很早前看过，当时世界上应该只有jQuery和KISSY，最近没看过，所以我说的是以前，以前，以前），所以影响了它的推广。
虽然没有深入查看腾讯首页的js源代码，但是从之前看过的一篇技术文章里有写到，为了实现快速加载，qq首页采用了很多异步读取的操作来提升网页加载速度。
前端用什么样的框架，在于应用程序前端交互的复杂度，更重要的是
1. 同事的技术栈
2. 代码的健壮性、可维护性
作为一个极客肯定希望使用最新的、最尖端的产品；作为产品的开发，更重要的是开发的进度和代码的稳定性。
对的，你已经想到了鉴权信息返回 JSON 了，那么 SPA 框架就是再做一步类似 cancancan 的事情，写一个 service，封装获取的鉴权信息数据，提供一些类似你说的 if can? 这样的 helper，然后就可以在模板里用了。原理上并没有什么区别，就是一个单例对象，应用程序初始化的时候实例化，里面封装了当前用户以及整体的鉴权信息，然后有一些 API 可以操作。你在 Angular 里可以依赖注入这个 service 到需要的 controller，然后视图里直接用就是了（Angular 没有 View 层，controller 维护一个 view model 对象供模版使用）。其他的框架都有类似的机制，React 的话应该是干脆统一保存在 Store 里吧，没写过大型的 React 应用，照原理猜测的。
只是我不知道有什么 3rd party API 特别像 cancancan 的第三方 service，如同我说的，我都是自己写的，我觉得不难。
其实我根本就没有争论的意思，原本就是一个分享而已，活在梦里的又不是我。
而且你拿 BAT 举例其实很不恰当，这里有多少人天天做的是那么个庞然大物的？更多的是能做到 Skylight，Strikngly，Teambition 等等的就好了吧，BAT 为什么离不开 jQuery 那是有历史和市场包袱的好吗？而且人家的核心技术团队在推动前端发展上面也是不遗余力的好吧？现在 BAT 做些新东西还不是一样会与时俱进？
现实的例子我就知道有阿里云，因为我的前同事小兄弟就去那里高就的，阿里云用的啥？Angular，做的好不好咱另说，至少人家往前走了吧？我那小兄弟也很高兴当初在我们这个小小公司可以尽早接触到这些东西，对未来的成长也是有利无弊啊。如果我当初就跟他说你就用 jQuery 别折腾，这剧本会按现在走？
嗯。实现原理我懂。之前拿来主义居多，倒是木有想，自己写个helper封装下。
感觉这个帖子，是目前在ruby-china上看到最有价值的帖子了。
其实觉得，多争论挺好的。都拿出自己的理由，要是再有个react大神参战就更好了
React 大神这里有的，我知道，不过他貌似是个纯技术宅，钻的很深很广，这样的讨论我从来没见他参与过。我是一个没什么天赋的人，更热衷于让更多的人开拓视野，所以才会唠叨个没完没了，我也知道会让很多人烦。可是你烦归你烦，世界还是要转的，路还是往前走的。
对了，你看到本站右边的友情链接没有？React China 那个，管理员就是我说的大神，可以去找他单独探讨。
我默默的出来贴一个我的 Github 问题收集(由于发现内容太多, 放在 Github 上不好找了, 整到自己的 OneNote 里面去了)
这个里面是我在 demo 一个 ember 项目过程中碰到的一些问题以及一些比较简单的思考. 一个 demo 寻坑的过程.
还可以补充下
纯前端方案.
后端 ember-data 的 DS.Errors + JSON API
prerender.io
朝向独立处理方案 (类似 )
然后我说个具体在 "用 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 手机的用户对移动互联网有多依赖呢?)
呵呵，无独有偶，我自己写了一个项目叫 fagie（Filling all gaps in ember），也是用来填坑的。工作中遇到的问题我就在这里做实验，然后写文分享出来。
支持你，加油，我会保持关注的。
我不怎么写 todo list，我是把每一个具体功能用梳理好的 git log 来记录，大的东西分成分支来做，回头查阅的时候 checkout 就好了
我刚才有个想法，我看到你已经梳理的问题与解决方案都很完整详细了，所以我在想我们是不是可以搞一个 project issue tracker
比方说用 trello 那样的东西，把我们大家遇到的问题、思路、解决方案统一整理到那里面去？这样群策群力应该比个人独立维护一个 demo 项目要更有价值。
甚至于实验用的 demo 项目都可以统一起来，遇到新问题之后可以自己开个分支折腾，或者干脆 fork 一份。但是 issues 统一管理？
反正自己琢磨也是要记录的，大家一起记录可以资源集中共享，遇到想不明白的事情也有个商量的地方，如果你觉得好的话，还可以多拉些人参与，比如
以前我用 Angular 的时候就搞过，但是国内 Angular 社区的人都特别浮躁，少有能沉下心研究点实务的人，后来就不了了之了。我的想法是能够最终写出一些开源的 addon 之类的东西，也做做造福大众的事情。
我对前端重量很在意，所以就是 VanillaJS。这些库说实话我觉得没有什么实际意义，门槛太高。
对于多数任务，考虑到招聘难度和完成质量，jQuery 或者 Zepto 的确是最好的选择。有追求点的就 VanillaJS 基于自己的场景做一套 DSL，一切轻松。
PreProssecor 简单拿 Ruby 脚本做个拼接和模版替换也就好了，没必要用什么库
前后端分离对于现在这个时代是好选择，服务器端一套 API 就好了。但是怎么实现就是另一回事了。超过100k的框架我觉得都没什么存在意义。
交互少，肯定就上VanillaJS了，毕竟世界上最轻量级的库
交互多也一样，好像 ember 什么的就不是 JS 写的一样。
我说的 session保持 的问题可能太泛泛, 举个例子: current_user.
你前端想要一个 current_user, 用了 simpleAuth, 在 initializer 里面注入到 session, 得到一个 promise. 然后我在 application route 里面还有一部分逻辑, 是处理购物车的, 跟 current_user 相关, session(cookieStore) 只能放很少的东西, 你要依次初始化这些对象(去后台去取, 都要发请求, 如果服务器端生成页面的话就直接取了), 难度体现在:
处理 promise. 我为了每次都有一个可用的 ember model 对象, 把 resolve 好的对象塞到 applicationController 里面, 其它 controller 里面定义一个别名引用它(这样很傻..).
考虑到 购物车 列表, 商品列表等, 即使用了 side load, 请求次数和数据量也挺大的. 且每次用户刷新, 上述逻辑都要跑一遍, 数据都要跑一遍.
现在看来, 有些问题是我 ember 没用好造成的, 比如为了烦躁的 promise 问题, 我后来将所有的模型全部定义为同步的了..
还有的是 ember 本身还在快速演进, 比如 , 至少在我使用的 1.X 版本里面没有.
作为一个全职写了一年 ember 的人, 我后来总结是使用 ember 拖了项目进度的后腿, 当然这不是 ember 的问题, 一是可能场景不适用, 二是学习成本(以及没学好用好..)
我也认可你的观点, 前后端分离及 ember 是前端的方向, 仅一个 双向绑定 可能就会让你爱不释手. 有厉害一点的前端, 或者团队允许一定的试错, ember 可以上的.
在你的大力普及下, 我对 ember 的关注度和信心又上升了
ps: 作为一个厉害的前端, 怎能没用合适的后端, 看看这个?
你举的那个例子其实挺有代表性的，我其实吧并没有特别想要大力普及 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 的前景……我未必会有那么乐观——然而这不妨碍我去用它，我用什么东西，市场占有率和前景从来都不是主要的考量指标。
最怕高级黑，你这一说连
都只能说“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比。
对于多数任务，考虑到招聘难度和完成质量，jQuery 或者 Zepto 的确是最好的选择。有追求点的就 VanillaJS 基于自己的场景做一套 DSL，一切轻松。
能做出DSL的高手来说，当然一切轻松，可惜现在国内有能力做DSL和框架的人不多，能说服别人接受你的DSL的，就。。。还是放弃吧，你看一堆人还在吵到底用React/Emberjs/AngularJS还是Vue呢。和这些比比，凭啥用你的自制DSL呢？给钱就用的是好的开发者么？
其实我很不理解一群工程师干嘛要考虑招聘难度？这又不是我们的责任，而且这种事情你考虑了也解决不了，从自身出发来看：凭啥因为市场上没有足够多好的开发者，我就要迁就剩下的人？非常古怪的思路。如果你的队友跟不上，那就淘汰他们，你做好自己的事情就对了，如果你的领导看不出这种差距，看不到你的努力和价值，那就说明你跟错了人上错了车。拿钱给人干活的，想那么些有的没的干啥？如果是创业的，那眼下重点也不在于技术选型上，现在找不到人以后有钱了还怕找不到人吗？总是抓不住思路的重点。
加油，少灌水，用产品说话。
误会误会啊, 其实我的意思和你一样, ember 是个好东西, 鼓励有能力有精力的人捣鼓, 个人觉得比 rails 门槛高.
其实我用 ember, 从 ruby 圈子进入了 nodejs 圈子, 这本身就让我受益匪浅.
我反正没有说服别人这个问题，实际场景就是需要 JS 重量小。
我很搞不懂现在都是移动时代了，每个手机联网效果差了一大截，怎么还有人喜欢各种大架子。真的是一堆公司被某些人的喜好绑架了，舍本逐末的感觉。
可以推动一个 Filling all gaps in ember 啊, 其实也无需每一个场景 fork 一个 repo, 可以使用 ember 专门的
来展示代码.
其实我的目的是记录下大概的思路, 因为如果细节写下每一个场景问题, 可是可以扩展得很开的. 但那样就会有可能收不回来而太细节. 只要能够为相同场景下的问题有一个指导的方向, 就可以很快找到思路避免走弯或者再在场景下优化思路.
不写太细的原因是考虑到, 能够碰到一些比较细节的问题的同学已经度过新手的阶段, 只要"抛砖"就能够接上.
对于 trello 的形式, 这个问题就 Github Issue 这个级别 + tag 就可以了, 毕竟没有啥复杂的内容, 只要在 Issue 中讨论也足够清晰.
我估计, 后端作为 API Server 那 Session 的概念估计会被另外一个思路给替换了. 拿购物车为例子, 前端后端(html 作为前端也是, js 作为前端也是), 都需会需要一个衔接的 "key", html 前端可以是 cookie 作为 Http 的补充, 那 JS 前端估计就会需要调整为 token 作为凭证. 在后端的购物车状态信息, 应该是需要被持久化的了, 可以是 db (数据库) 也可以是 redis (缓存), 这都是为了能够横向部署多个进程扩展嘛.
换到前端要获取信息, html 前端会 jQuery 异步处理再返回结果(js/html 片段),
JS 前端也会 Ajax 回去再获取返回结果. 购物车的操作一定是会沉淀到后端去的.
最后, 大家都别那么激动嘛, 无论 HTML 的前端还是纯 JS 的前端都是很好的方案, 而且都有各自的演进线向前演进着. 开源的多样性不正是好事嘛, 一个个新的项目冒出来一个个新的想法迸发, 看到新思路赞善一句也无妨哈, 默默关注也 OK 嘛.
对 Rails 开发者来说我觉得比较好玩的还是 Volt 和 Ember，React 前端门框还是有不少的
用原生 API 从头实现功能还是很辛苦的，阿里应该也就只有无线有这个条件，能够不担心兼容性放心去写。其他事业部要么 jQuery 要么 KISSY，终究还是需要库的。我们造了一个小轮子，实现了 jQuery 中 DOM 操作和事件绑定的部分，用来广告代码里，文件尺寸能小很多，叫做
看了一圈，没有 vue 的字眼，好失望啊
vue.js看起来还不错很轻量级，但是听了teahour，作者节目里去喷别家类似框架，感觉不太好。
感觉好失望
jquery is for backend developer.
没有喷，只是对比而已。vue确实好用，很适合轻量级的前端应用。
前後端分離是大勢所趨，不過很多大項目基於歷史原因還是無法脫離 jQuery 也是事實。大家不願意付出學習成本大概也有生活壓力的原因吧。
Backbone+marionette+jquery is always my favorite.
整日追框架,累,还是紧抱jquery靠谱
最近看ember的书，对rails开发者确实太亲切了，各种能对应。
对emberjs，还不算熟，有几个疑问。
ember-data，如果客户端的数据和服务器端不一致呢，比如save后，发api请求，但因一些意外失败了？
另外ember-cli，为什么要要是bower，又是npm，包管理一定要2个？
似乎react里的组件间通信，在ember里并没有体现？
graphql，socket.io这些东西，ember社区有相应的努力吗？ember的社区怎么样？
ember-data 是客户端的 data store，实际上它和你怎么与 server 通信并没有直接的关系，只是它自带的 adapter 实现了对应的接口，底层还是 ajax，该怎么 handle server error 是你的事情。客户端的数据与服务端不一致可以通过 serializer 层来转换。
bower 和 npm 的问题是前端生态圈的历史遗留问题，并非 ember-cli 非要这么选择，其他的 build system 也有类似的情况，比如 yeoman。
组件间的通信看 component 的文档就是了，怎么叫没有体现？包括 DDAU 也是可以的，ember 并不限制你如何通信。
graphql， socket.io 这些东西本质上就是第三方库，ember 的核心团队不会对此有什么特别“看法”，ember 提供的 service 机制可以让你把任何第三方库整合进你的 ember app 里，你也可以选择直接使用它们，并不会因为你用了 ember（或其他什么框架）这些东西就变了。当然，社区会有人做一些 addon 把常用的第三方库封装好以便快速使用，这就好像 gems 一样。你可以看看这里：
react 有点废材了。
rails 光做 api 又太重了。
后方可回复, 如果你还没有账号请点击这里 。
共收到 81 条回复