求 Ember.js 开发经验的分享

novtopro #1 2015年03月14日

学习 Ember：http://kickass.to/usearch/codeschool%20ember.js/ Use ember-cli with rails: http://reefpoints.dockyard.com/2014/05/07/building-an-ember-app-with-rails-part-1.html

3 个赞

ery #2 2015年03月14日

研究的过程中，发现 Ember 的核心成员之一，居然是 Yehuda Katz http://emberjs.com/team/ http://yehudakatz.com/ https://github.com/wycats https://twitter.com/wycats

Yehuda Katz is a member of the Ember.js, Ruby on Rails and jQuery Core Teams

当年上海 Rails 小组，曾有幸邀请过 Yehuda 来上海演讲。我也有幸见其肉身，现在想想，遗憾未能合影。 Handlebars 就是 Yehuda 主导的。我第一次知道他，是因为 <> http://book.douban.com/subject/2368647/ http://book.douban.com/subject/3446112/ 当时这本书对我帮助极大，JS 水平得到了提升。书写的也非常好，一气呵成，几天就读完了。

2 个赞

nightire #3 2015年03月14日

YouTube 上有几个 Meetups 的频道过一遍，我记得有 chicago，seattle，boston，nyc，london 等等地区的，其中 nyc 最活跃，里面主持人两个都是 Ember Core 的成员，每个月会更新。去年的 EmberConf 过一遍，今年的 EmberConf 也快来了，记得跟上。另外还有一些零散的比较好的视频，一个比较好的搜索策略是把 Core Team 成员的名字放在 YouTube Twitter 等地方扫一遍基本上都能找到了。

还有就是这里：http://emberwatch.com/ 你可以依此为起点顺藤摸瓜，就不再需要别的 resource list 了。

5 个赞

darkbaby123 #4 2015年03月14日

@nightire 补充一句，EmberConf 2015 不是快来了，是已经开完了。所有演讲资料都在这里。BTW ng-conf 也是最近，不知道开完了没有，里面一个关于 component 的演讲挺不错。

我一般就看看 Twitter 和 Ember Weekly。一个每天了解下动态，一个每星期汇总。

2 个赞

blacktulip #5 2015年03月15日

我也在纠结是学 ember 还是 ng，最后肯定都要学，但是从谁下手呢？本来我已经决定先搞 ng 的了，但是麻痹人家来个 2.0 全部重写不兼容 1.x，你说我学是不学？学 1.x 学完就过时没用了，学 2.0 吧还没出来。

流行度来说 ng 比 ember 高得多得多，也是我想先学它的原因，谁知道就给你来这么一手。

nightire #6 2015年03月15日

#4 楼 @darkbaby123 哈哈，我本来的意思是视频快来了，没想到这次 Confreaks 动作这么快！多谢提醒

nightire #7 2015年03月15日

#5 楼 @blacktulip 我建议你不要都学，并且学哪个其实都不错，很难分出绝对的上下来。另外，到了如今的阶段，无论学哪一种（包括 React）其实都是去接收和习惯 Components 的思想，最终的最终大家都要回归 Javascript（框架依然有用，但是无须太多的 hacks），因此这几年就是一个过渡期，不用纠结选哪个。

nightire #8 2015年03月15日

#4 楼 @darkbaby123 BTW，有兴趣和精力组织 Meetup 吗？我记得你也在上海吧？

qsun #9 2015年03月15日

我们最近做的帮推客，是一个 P2P 的个人影响力交换平台，开发过程中用的就是前后端分离，Ember.js 和 Python Flask 的 API 搭配。我来说说我们的吐槽与经验吧。开发时间是 2 月中旬。

这些吐槽与经验，有可能不对或者有更好的解决方案，请大家指教。

能使用 Ember CLI 就尽量使用 Ember CLI。我们刚刚开始的时候，用 Yeoman 生成的 webapp，然后手动增加的 Ember.js 框架，到后面的话增加测试之类的就比较难受。
我曾经在有些别的项目中尝试使用 Ember.js，后来效果不是很好。我觉得是因为对比 ng，Ember.js 更加霸道，属于顺我者生，不顺我者我让你很难受类型的。
在本地开发，对 promise 求值的时候非常快，所以感觉不到延时。但是部署上生产环境，如果网络比较慢的情况下，延时会让 UI/UX 很受伤。我们最后的解决方法是加入 NProgress 给用户一些视觉反馈。
用户登陆和认证部分，我们最后没有使用 session/cookie直接验证，而是直接使用了token，通过 Ember.$.ajaxPrefilter 加进了 ajax 请求头。
开发速度当然是非常快了，我对 Ember.js 其实不熟，但是两天的 Hackathon 也就把帮推客的原型做出来了
页面体积那是一个巨大，打开的话比较慢，后来我们就加上了一个 Loading... 页面，告诉客户正在努力加载，然后等 Ember 初始化结束之后，再把这个页面替换掉。
为了帮助客户使用，我们很多地方都用了实时的通知系统，比如注册邮件不可送达，或者管理员通过了审核等等，都通过 socket.io 将事件实时的发送到浏览器。但是有的事件需要子Route来处理，有的是中间的 Route 需要处理，这样的话 socket.io 和 Ember.js 的通信比较坑，后来我们用了这样一种方式解决
1. 在 ApplicationRoute 中，加入 socket.io 的初始代码
2. 初始代码包括 dispatch，当 socket.on('some_event') 触发的时候，找到对应的 container 并且通过 send 发送事件

App.ApplicationRoute = Ember.Route.extend({
    init_io_dispatcher: function () {                                                                                                                                                                                               
        var me = this; 
        socket.on('friend_count_update', function (data) {
            var friend_count_checks_route = me.container.lookup('route:friend_count_checks');
            if (friend_count_checks_route) {
                friend_count_checks_route.send('update_friend_checks');
            }

            var dashboard_route = me.container.lookup('route:dashboard');
            if (dashboar_route) {
                dashboard_route.send('update_friend_checks');
            }
        });
    }).on('init')
});

上面写的比较乱，我会总结一下写出来。

6 个赞

mogodb #10 2015年03月15日

#5 楼 @blacktulip ng 1.5 会考虑和 2.0 的集成？

mogodb #11 2015年03月15日

#7 楼 @nightire JS 本身也在变，ES6 以后会全面推行么？io.js 好像支持 es6 的，你用过哪些 es6 特性呢？

darkbaby123 #12 2015年03月15日

@nightire 可惜了，我在武汉，不在上海。不然跟你面谈聊聊应该挺有收获的。

@qsun 你最后的一个例子应该可以用 service 来做，数据放在 service 里，socket.io 通知 service 更新，然后 sevice 可以同时注入 dashboard 和 friend_count_check 这两个 route。

nightire #13 2015年03月15日

#9 楼 @qsun

赞同，不用 Ember－CLI 比较傻
Ember 不是霸道，而是生态系统自成体系且比较健全并还在继续健全中，对比 Rails 差不多，也不见有人说 Rails 霸道吧。Ember 是 opinionated 框架，这才一开始就是定性的，客观地说有利有弊。利者，在工程架构上不必花心思，也不用刻意制定规范，再加上 Ember－CLI，连 automation workflow 都帮你考虑好了；弊者，想改不容易，门槛相对较高（特别是要整个团队都跟上，这不容易），然而 ng 固然灵活，可是团队里也得有靠谱的前端架构师来 handle 住，否则一旦项目上规模，到处都是坑。
速度的问题，诸如初始化和异步请求等——向来都不是 Ember 的强项，这里面有许多历史遗留因素，不过作为选择 Ember 为主力框架的开发者，其实更应该关注它的未来，毕竟这个时期的基调就是如此。@darkbaby123 及时告诉了我们 EmberConf 2015，我建议您把这个会议过一遍，你关注的问题和槽点 Ember 都有解决。过去 24 小时，我全部看了一遍，信心大增。
对的，这里应该用 service，这也算是相对比较新的机制，主要解决的就是 DI 的应用。

@darkbaby123 啊，可惜了，有机会来上海的提前通知一声，我接待你啊

@mogodb 我最近已经有点懒得回答你了，在这里我想认真的问你一个问题，也希望你认真的考虑一下自己的答案，答案不用给我——我不关心，不过你得坦诚的回答你自己：你真的想清楚自己要做什么了吗？

ES2015（也就是 ES6），必然会全面推行，因为它已经是得到整个业界认可的标准，无须为它的前途担心。退一万步说哪怕出了什么惊天动地的大事导致 ES2015 夭折了，那也会有 ES2016，2017……，哪怕将来不叫 ES 了，但是 web 终究还是要进化的。如果有人告诉你 ESxxxx 不会有前途的，你就不学了？随便举个例子，Promise 是 ES6 中的一个特性（主流环境如 Chrome 已经有了实现），假使 ES6 最终没有推行，你是不是觉得就可以不学了，继续延续过去的老一套？如果你觉得可以，那就不要学，然后看看两三年后你还玩不玩得转吧。

至于我用过哪些，这和你有什么关系呢？你千万不要说我用什么你就用什么，我可担不起“毁人不倦”的罪过。

别再问这些无聊的问题了，你不会有任何收获的。

10 个赞

darkbaby123 #14 2015年03月15日

@nightire 谢谢！有时间来上海玩一定通知你。

robertyu #15 2015年03月16日

直接来react算了，不喜勿喷~

blacktulip #16 2015年03月16日

还有一个问题是 ng 的资料比 ember 多很多，要找教程找帮助都容易得多

1 个赞

flowerwrong #17 2015年03月16日

#16 楼 @blacktulip +1

darkbaby123 #18 2015年03月17日

@blacktulip 国外资料 Ember 也不少，不管是 Google 的还是 SO 的，教程更多。不过哪个框架的教程都只对初学者有些帮助。国内就不说了，风吹过来什么种子就发什么芽。

ery #19 2015年03月17日

#3 楼 @nightire 能否留个联系方式，我想和你私聊

nightire #20 2015年03月17日

#19 楼 @ery 抱歉比较忙，私聊就算了，就什么问题还是公开讨论更好一些。

ery #21 2015年03月17日

#20 楼 @nightire 你应该认识我，像认识这个世界是如此精彩

ruby -r base64 -e 'p Base64.decode64("ZXJ5bGVpQGdtYWlsLmNvbQ==\n")'

1 个赞

nightire #22 2015年03月17日

#21 楼 @ery 是的，你已经认识我了，我在网络上留下的全是真实资料。

你有什么问题就在这里问好了，能回答的也不止是一个人或几个人，大家一起探讨何乐而不为？

要单独和我聊也无妨，但是我最近特别忙，恐怕没有时间长篇大论的。你愿意的话，发电子邮件给我好了，可是我不一定有时间回复。[email protected]

ery #23 2015年03月17日

Ember CLI 文档中有这么一段话，

Ember CLI uses the ES6 Module Transpiler, which turns ES6 module syntax into AMD (RequireJS-style) modules. Using the transpiler, you can write code using tomorrow’s syntax, today.

ES6 不熟，于是搜了一下，搜到了一份资料《ECMAScript 6 入门》阮一峰 http://www.ruanyifeng.com/blog/2014/04/ecmascript_6_primer.html http://es6.ruanyifeng.com/#docs/class

foxzool #24 2015年03月18日

说说两个 tips

1、在 route 用使用 nested resources 时，将 path 里的 id 直接写为 model_name_id，这样就不用在 route 里再定义一次 model 的调用

this.resource('users', function () {
  this.route('detail', {path: '/:user_id'});
  this.route('edit', {path: '/:user_id/edit'});
});

2、如果要 html escape，直接用三个尖括号 {{{model.body}}}

1 个赞

teddy_1004 #25 2015年03月18日

看了看 Discourse Ember 部分的代码，学到了很多。还有作者的博客里面货也很多，http://eviltrout.com/

teddy_1004 #26 2015年03月18日

#7 楼 @nightire 想知道你们在实际项目中是不是用 ember-data，很喜欢它的一些特性，但是感觉对服务端的 api 要求有点过于 opinioned 了。看了 Discourse 的代码，发现他们就是用 Ember 自己的 Ember.Object，不知道你们在 model 层是怎么处理的？

nightire #27 2015年03月18日

#26 楼 @teddy_1004 我自己玩的项目有用，API 那边也努力按照 JSON API 的规范去写，不习惯时有发生但是总能解决。ember-data 归根结底也还是基于 Ember Object 写出来的，Discourse 没有用一是因为你说的关于主观的 API 规则；二是因为那时候 ember-data 太不成熟。

现在好多了，even 你的 API 没法去跟着它的要求走，你要可以自己写 Adapter。以前我一直觉得写 Adapter 是很莫测高深的事情，但经过了 Angular 的“锤炼”（在这方面 Angular 更糟糕，只有相对更低层的 ngResource 可用，data 层都是要靠人写的；当然也有一些 3rd party 的模块可用，不过 opinioned 的影响也是一样的），再加上 ember-cli 的友好，现在觉得小菜一碟。

所以简单滴说：长远利益跟着 JSON API（或其他）规范你的 API，ember-data 就可以开箱即用；要么搞定 Adapter 让它为我所用（或者有符合你 API 的靠谱的 3rd party adapter）。

虽然不知道是否和你遇到的格式问题类似，但是解决方法的思路描写的很清楚。

另外，ember-data 其实是一个很难的项目（前端领域），它走了不少弯路，看它艰难的 v1 之路就知道了，想要用的话就一定得有自己搞定很多“坑”的心理准备和技术储备！还好，貌似 ember-data 终于走上正轨了，期待 12th June 的 v1 吧。

3 个赞

nightire #28 2015年03月19日

#26 楼 @teddy_1004 非常有意思的，在回复了你之后不久我看到一篇文章，里面恰好讲到关于 opinionated 的问题。看到这篇文章是因为总有人对于 Ember 的 opinionated 抱有很大的 prejudice，我一直很不理解：带有 opinionated 的框架怎么了？多少年来后端的框架不都是这样的吗？为什么到了前端以后就这么不招待见？

我摘录一段内容在此（粗略翻译），因为我觉得这恰恰代表着一个针对大型项目（ambitious project，Ember 的首页就明确表示它为此而设计）的框架理应做到的事情。如果要为一个团队选择合适的前端框架，我一定会首推 Ember！（遗憾的是，我自己所在的团队已经选择了 Angular，作为架构师，其中甘苦自知）

Honestly, I was kind of annoyed with how opinionated Ember was, but then something happened that completely changed my mind on the matter. Let me share.

坦白讲，我对主见武断的 Ember 有些抗拒，然而随后发生的事情让我完全改变了自己的态度。

About six hours into learning Ember, I decided to take a break from the course and take a look at the source code for a production app that was using Ember. I knew the Discourse forum software was open source and built with Ember. So I found its Github page and started browsing its Ember code. ......

在学习了 Ember 六小时之后，我决定暂停教程的学习转而看一看采用了 Ember 的产品级项目源代码。我知道 Discourse 论坛软件是开源的 Ember 的项目，所以我找到 Github 上开始浏览 Ember 代码。

（后面略去详细过程，大致内容是随便打开一个模版 => 看到一个值 => 找到控制器，看到这是一个基于关联模型声明的计算属性 => 找到对应路由，看到模型如何获取 => 回到模版，看到在视图助手的帮助下如何渲染这个值 => 找到视图助手，看到实现细节……）

And then I distinctly remember pausing and thinking something didn’t feel right. Something was off, but I couldn’t put my finger on it. And then it hit me: I was actually understanding the code base for a project I had never looked at before.

我清楚地记得此时我停了下来并且感觉到哪里有些不对，发生了很不可思议的事情可是我却没意识到。紧接着我大悟：原来我已经领会了一个项目的代码结构，而此前我从来没看过它。

For a project the size of Discourse, it typically takes a few hours to a few days to just begin to understand its code base. But Ember’s strong opinions and conventions allowed me to open a project I had never seen before and understand what was going on in only a few minutes.

像 Discourse 这般规模的项目，通常要花费数小时至数天的工夫才能开始了解它的代码结构。但是 Ember 的强主观性和约定却使得我能在几分钟内就理解一个从未见过的项目结构。

And that’s when my opinion about Ember changed. Up until that point I had been hesitant about Ember and didn’t think it was better than Angular. But that experience browsing the source code of a production Ember app helped me begin to understand Ember’s benefits over Angular.

这就是我对 Ember 有所改观的开始。在那之前我一直对 Ember 抱持怀疑并不相信它会比 Angular 更好。但那次浏览产品级 Ember 项目源代码的体验帮助我认识到 Ember 胜于 Angular 的优势之处。

I then I began learning all I could about Ember. And the more I learned about Ember and its community, the more I appreciated Ember. And now I fully recommend Ember over Angular. Let me share my reasons why.

然后我开始学习一切和 Ember 有关的东西。并且随着对 Ember 及其社区的了解越深入，我越是赞赏它。现在我会完全推荐 Ember 而不是 Angular，让我来说说原因。

（后略，详情见原文：http://blog.yodersolutions.com/why-i-recommend-emberjs-over-angularjs/）

我想说的就是，别害怕 opinionated & conventions，特别是在 Ruby 社区，这种体验和 Rails 没有什么不同！别处的人选择 Angular 我可以理解，但是品尝过 Rails 滋味的大家怎么也应该对 Ember 更有认同感才是。

至于 ember-data，它很过分么？不觉得啊！官方的适配器专门针对 REST API 写的，如果因为我们自己的 API Service 不够 REST 而埋怨 ember-data 恐怕就有点胡闹了吧……而 JSON API 则是进一步的规范和追求，这份出自 Yehuda Katz 和 Steve Klabnik 还有 Dan Gebhardt 的草案理应得到 Ruby 社区和 Javascript 社区的共同支持，而 ember-data 必然会完美支持 JSON API，因为这可是自家的孩子。

8 个赞

nightire #29 2015年03月19日

读完全文之后，我觉得我也有类似的感想应该分享给大家，特别是那些还在犹豫应该选择哪一个框架的人们。不过话先说在前头，我并不会因为喜欢 Ember 而排斥 Angular 或是其他（事实是我根本排斥不了），所有的大前提只有两个：

我推荐 Ember 给那些工作在团队中的项目和开发者；如果你不在此例，可以不论；
如果在你的团队中有相当靠谱的前端架构师（或经验丰富技艺高超且拥有足够前瞻性的前端工程师），那么我推荐什么都不重要了。

接下来我顺着上文原作者的思路说一说我的感受，实际上我要说的不仅仅是框架的优劣，更是前端的许多话题。

Angular 的问题

如果你要比较的是功能性，那么谁也分不出高下来，因为无论你用什么框架，前端开发的环境被限制在浏览器内（绝大多数情况下），用户所看到的和感受到的都是一样的——除非开发者的水平差异巨大。

如果你要比较的是性能，综合来看依然分不出高下，纯粹的 DOM 操作对比胜出者是 React，但是说到框架 React 还不够资格，它只是其他综合性框架的一部分而已，而且 React 用到的技术并不神秘，Ember 和 Angular 的下一个版本都会有所实现。

Angular 最大的问题，要我说恰恰就是它没做好一个框架应该做的事情——优秀的组织性，也就是我们所说的工程架构。

大型的前端项目，要么按特性分割代码结构（Model／Controller／Route……等等），要么按模块，也就是人们说的 POD，这是两个主流的架构方式。过去选择哪种几乎是看喜好，但是现在可以预见 POD 会占据主流。为什么？因为 WebComponent。

就一句话：若按特性分割，你怎么封装可复用的组件？

我是有切身体会的。在我工作的项目组，目前至少有四个足够规模的 Angular 应用，因为 Angular 对于架构的毫无引导性（说好听一点，non-opinionated），这四个应用的架构几乎找不到什么共同点；连带着因为 Angular 对于工作流程也毫无引导性（可没有 Angular CLI 这种好东西），四个应用采用了四种完全不同的构建／测试／发布的自动化流程，两个使用了 Grunt，两个使用了 Gulp；然后交替的，两个采用了独立子任务链区分环境（构建代码很繁琐），两个采用了环境变量＋独立配置文件区分环境（构建代码很简练，但是要求每一个开发者遵循一定的规范，Angular 可不管这一套，最终还是得自己琢磨）。

如果你是一个架构师，当你发现四个应用里有很多可重用的组件，你会怎么想？接着面对这四个使用了同一个框架却看起来风马牛不相及的项目，你能怎么办？

不要跟我说重构，我还想多活几年……

今时今日我算是对 Angular 有了清醒的认识（至少是 v1.x 的 Angular）：丫根本就不是一个框架！丫是一套让你实现一个框架的工具集！你若想在团队里用它开发多个上规模的项目，你首先得用丫造一个框架，然后配套合理的构建／发布环境，接着撰写好可靠的约束与规范。你说 Angular 毫无主见性？丫只是把这个担子留给你而已！

去年夏天，我尝试去做一个内部通用的 Angular 模块集，类似于 ui-bootstrap/ui-utils 这样的项目，但是我不得不说：实在太痛苦了！

我就举其中一个例子：angular.module。诸位知道这玩意应该怎么用么？你不踩这个坑，你永远不会知道，Angular 也永远不会给你一个使用 angular.module 的最佳实践，因为它给不出来。

如果你对 angular.module 有所了解，同时也对 CJS/AMD/ES6 Module 等等有所了解的话，你就应该想得到 angular.module 应该是粒度越细越好！可实际情况却是我见过非常多的 Angular 项目从头到尾就一个 angular.module 所有的组件，不管是自己写的还是第三方的统统都是这一个模块的依赖，所有的路由或状态（取决于你用 ngRoute 或 ui-router）统统都配置在这一个模块的配置函数内。你想抽象封装一个指令？天方夜谭！

然后你决定跟大家好好谈谈：

“同志们，为了组件的通用性，请大家多费心把 module 的粒度降低好么？”

“为什么呀！文档上也没说不能只用一个模块呢，写一个多省心……”，“反正是 SPA，angular 也没实现异步加载，不行就加上 require.js，angular.module 就保持一个吧……”

“……，那同志们，咱们都统一用 POD 好吗？这样想要抽象组件也好整理不是？”

“凭什么呀！Angular 不是不强制文件结构的么？我写 Java／PHP／……那么些年，就不习惯 POD！”

尼玛～前端和后端不一样好吗？！

大多数的 directives 都有特定的模版架构，最佳的做法是把每个 directive 单独声明在一个独立的 module 里，如果这个 directive 有专用的 service／filter 等等，也应该声明于同一个 module，更重要的是，如果依赖的模版需要 pre-compile，那也应该统属于这个 module。由此可见 POD 显然是最合适于前端项目的组织结构，你们非不干，那还抽象个毛！

于是经常有领导关心：咦？这个功能以前不是做过一样的，拿来改改样式就好了吗，为啥要重写？

哎～虽然倒不是真的要重写，但是每每看到复制粘贴的干活，我还是痛心不已啊。于是我的口头禅就多了句：你呀！都是给 Angular 惯的。

那 Ember 呢？Ember CLI 创建一个项目貌似也是按特性组织的啊？嗯，那是为了适应“上古”程序员们，免得你们太过惊讶，其实 Ember CLI 是可以随意切换至 POD 架构的，再加上积极的拥抱 ES6 module，就凭这一点在我眼里已经轻松秒杀 Angular 了。

Angular 的繁荣其实有其悲剧性因素：这年头识货的前端工程师太少了，理解前端架构的工程师更是凤毛麟角。

更合理的功能支持和发布流程

Ember 2 没有新功能！

惊讶吗？没有新功能发布个毛的 2 啊？！

因为 Ember 2 的所有新功能都会在 Ember 1.x 里实现到。这尼玛的才叫无痛升级！

即使有痛，那也会分布在固定周期的小版本升级上，并且不会直接弃用，而是先 deprecated，给你足够的时间和指导去替换过时的功能。比如说像 React 那样的 Virtual DOM 方案，很快就能在 Ember 项目里享用到了（已经发布在最新的 canary 版本里），Angular 的开发者至少也得等到 2 正式发布以后。

Angular 2 一开始宣布完全不向后兼容，后来才千呼万呼始出来一个过渡方案：要么自顶向下，要么自下而上，整个替换吧！唯一安慰的是它保证在替换过程中新旧代码可以同时工作。

我就呵呵一下，先不说这个“新旧并存”能有多靠谱和多顺滑，单单就从 angular.module 到 ES6 module 的改造，我现在都能想象得出小伙伴们届时的脸色……不说了，到时候还得是我的锅，我先谢谢您了，Angular。

还有发布，这里面牵扯的细节我实在是没有勇气一一细数下去。所以我强烈赞叹 Ember CLI 是一个真正的良心项目！这得解放多少苦逼的前端架构 case 啊～还是建议大家去看看 EmberConf 2015 吧，看看 FastBoot，Glimmer 等等令人振奋的新特性吧，这年头做前端，眼界真心比技术还重要。

忽然想到一个很重要的东西：路由！这是所有 SPA 应用最最重要的核心部分。Angular 到现在多久了？ngRoute 能用吗？看到会哭好不好！还好有 ui-router 这个尚属良心的项目，但人家压根就没想过 Angular 2……再看看 Ember Router，乐坏了好吗？（特别是 Rails 开发者们应该很熟悉的，虽然也有区别）Angular 到了 2 终于痛下决心要做一个 ngNewRouter 了，核心技术还是来自 Ember 的。每次提到 Router 我都莫名悲愤，Angular 你走点心行不？毫不夸张地说，若是没有 ui-router，Angular 早就死了！那些视 Angular 为神明的盲目者们，这些年来真正应该感激的是 ui-router。如今只能期待 ngNewRouter 对得起观众们了……

核心团队

这个呢在原文里已经阐述过了，我就再重复一次最重要的一件事：在 Ember 的核心团队里，每一位成员都在现实里同时开发着使用 Ember 框架的实际项目。每一位！

这一点意味着什么是不言而喻的，对我来说，它给我了信心。

16 个赞

blacktulip #30 2015年03月19日

#29 楼 @nightire ember 应该吸收你做宣传大使... 这两天我在从头学 ng 1.x，首先我找了个视频教程过了一遍，然后按官网 tutorial 敲了一遍，现在正在敲 http://angular-rails.com ，基本上摸到了一些门路，你说的不错，ng 的结构异常散乱，或者说根本没有结构。敲完现在这个我打算看看 ember 比较一下，请问能否推荐一下类似的教程，就是像 ng 的官网教程那样一步一步带着敲出一个 app 来那种。

yzdel2000 #31 2015年03月19日

http://gihyo.jp/dev/serial/01/emberjs/0001 这个 ember 入门讲解相对比较完整点，是个日本人写的。

teddy_1004 #32 2015年03月19日

#28 楼 @nightire 多谢这么细致的回复，受益匪浅。估计是我写的项目比较小，再加上后端 API 不是我写的，没有利用到太多 ember-data 的特性，反倒是要自己重写一堆 adapter 和 serializer 搞得有点郁闷。我也还是对 ember-data 挺期待的，尤其是可以在 Ember Inspector 结合觉得调试超级方便

nightire #33 2015年03月19日

#30 楼 @blacktulip 官方的：http://guides.emberjs.com/v1.10.0/getting-started/ CodeSchool 的：https://www.codeschool.com/courses/warming-up-with-ember-js 以及 https://www.codeschool.com/screencasts/soup-to-bits-warming-up-with-ember

由于过去两年，Ember 的演进非常之快，API 的变化也比较频繁，所以坦率地说至少目前 Ember 还处在“折腾”的阶段。不过我相信在六月十二日之后一切都会稳定下来。而在此之前，Ember 的教程绝对不少，只是因为框架本身演进太快使得很多教程太容易被过时。

我个人的感受是，Ember 是一个值得学习的框架，耐心的把 Guide 吃透，然后在实践的时候时时刻刻看一下用到的 API 最新文档，这样会扎实的多，以后不管遇到什么教程都能云淡风轻了。

cuterxy #34 2015年03月19日

#29 楼 @nightire 感谢大神的有料吐槽！总结一下，ember.js 和 angular.js 的区别就是一个是开火车一个是开汽车的区别，对吧？

nightire #35 2015年03月19日

#32 楼 @teddy_1004

adapter 和 serializer 的套路都是一样的，关键是 API 的设计，如果 API 设计本身就很差，你以为用 Angular 的体验就会好到哪里去么？我倒不是鄙视谁，我只是觉得前后应该是一体的，API 的设计和实现不能只是后端的人说了算，作为 API 的直接使用者，如果前端在 API 的设计实现上没有发言权，那这个团队是有些问题的。

foxzool #36 2015年03月19日

去年尝试在新项目中使用 angular，写了一版 DEMO 后放弃了，最终选用了 ember.js。原因：

ember 项目的架构很清晰 controller、model、route，template，让熟悉 rails 的人分外亲切。
ember-cli 很好用! code generate, js/css compile 都一键搞定，用 angualr.js 时还要自己配置 gulp/grunt. 而且 ember-cli 已经正式合并到 ember 项目里，成为官方推荐。
ember inspector 很好用! chrome/firefox 插件支持，调试利器，angular 找了很久没有好用的插件。
ember-addon 很好用! 很多常用需求都有 addon 支持，越来越有使用 gem 的感觉了。

foxzool #37 2015年03月19日

推荐一本 ember-cli 的书 https://leanpub.com/ember-cli-101

ery #38 2015年03月20日

我做了一个 Demo

https://github.com/ery/emknight 前端 Ember https://github.com/ery/emcastle 后端 Rails

blacktulip #39 2015年03月20日

话说，我稍微看了一下 ember 的结构，感觉这层数有点太多了，首先是网页上直接有 template，然后上面有 view，再往上是 controller，再上去是 route，后面还有 model，特别这个 controller 和 route 好像有些逻辑写哪个里面都可以一样，这两个怎么分工呢？

foxzool #40 2015年03月20日

#38 楼 @ery 你可以参考一下我最近做的 DEMO，
https://github.com/foxzool/deyeen-api https://github.com/foxzool/deyeen-webapp api 使用 grape + JSONAPI, doorkeeper 提供 oauth2 provider web 端使用 semantic-ui 做界面，用 simple-auth 插件登陆验证

foxzool #41 2015年03月20日

#39 楼 @blacktulip view 这块在 ember2.0 都会由 compoent 来代替。 controller 和 route 区别，说说我的理解，大家交流一下。

1、route 是准备页面数据的地方，在这里可以根据 url 的 params 查询数据，然后放到 controller 的 model 里。

2、controller 里对获取的 model 数据进行进一步的处理后 render 到 template 显示，比如说要对列表数据进行过滤排序，都是在 controller 进行的。

3、ember 的 action 有 popup 的机制，比如说在/posts/new 这个页面上进行调用'save'，会先去 controller/posts/new 找，然后去 routes/posts/new、routes/posts、routes/application 进行查找。所以说，如果你有个 action，比如是‘return-to-post-index'，返回文章列表页面，那么可以在 routes/posts 这个路由上进行设置，然后在/posts/下面的所有页面都可以调用'cancel'这个 action，ember 会自动找到 action 定义。当然，可以在 popup 过程中通过 return false 在中断查询，达到自定义的目的

1 个赞

ery #42 2015年03月21日

#40 楼 @foxzool 谢谢

stephen #43 2015年03月25日

@nightire @foxzool @ery 刚学习 ember，看完了资料，想亲自动手做一个，但是在界面布局上，不知如何入手，按传统的 rails，把通用部分放在 layout/application，如果有两个不同的 layout，比如前台，后台，可以是 layout/application，layout/admin，在 ember 应该要如何？

ery #44 2015年03月25日

#43 楼 @stephen 我采用的是前后端分离的方式，不是传统的 rails，所以木有 layout，也不需要

stephen #45 2015年03月25日

@ery 我也是前后端分离，但是也需要 layout 吧，比如公用的 html，怎么处理呢？

nightire #46 2015年03月25日

#43 楼 @stephen 关键词：outlet

其实如果是我的话，我也可能把前后台分割成两个 Ember App（代码不一定要分开，应用可以是多个），所谓前后分离有时候也不单单是“前”与“后”分离，更可以是“前”“前”分离。总之分离式架构更加灵活，像你的这个情况可以有多种方式实现的。

darkbaby123 #47 2015年03月25日

@blacktulip Ember 虽然有很多名词和 Rails 是一样的，但如果照着 Rails 的思路去理解你就掉坑里去了。以下是我理解的各层作用。

Route

Ember 的核心理念。主要负责调用 model 层获取数据，调用 view 层渲染页面。起一个连接和控制各层的作用。Ember 认为对 web app 而言 url 是其核心，url 和应用程序状态是互相映射的。任何一方改变都会引起另一方改变。所以 Route 被设计成支持嵌套结构的有限状态机。但是它并不保存应用程序状态，那是由 Model/Service/Controller 负责的。Route 只是承上启下的管理者。

如果对比 Rails 的概念的话，它就是 Rails 里的 Controller，所以就不用奇怪为什么推荐尽量把 action 写在 Route 里面了。

Controller

完全的 presenter，大部分情况用于保存和展示应用程序状态，所以这个对象被设计成 singleton 的。但也有少数情况不是 singleton 的（比如在 template 里用 render controller model）。因为设计容易让人迷惑，在 2.0 里会被 Routable Component 和 Service 代替。

View

类似 Backbone 的 View，整个 view 层的支撑架构。Ember 早期设计就是像 Backbone 看齐的。整个 app 的页面就是由 View 嵌套起来的。每个 template/helper 后面都有一个 View，甚至包括 if/else/each。只是 Ember 比较智能地管理了 View，大多数时候不需要操心这个。因为和 Component 在一起会有误用的情况，View 也会在 2.0 被废弃。有自定义 view 层逻辑请使用 Component。

Component

和 Web Component 同样功能的东西。设计某部分是照着 Web Component 看齐的（只是各种 hook 方法名称不同）。用于抽象可重用的 view 层组件，或者封装应用程序专有的 view 层逻辑。

Template

Handlebars 语法的模板。目前已经换成 HTMLBars。

Helper

和 Handlebars 里的 helper 差不多，Ember 加入了 data binding 的功能。一般用于扩展 template 的语法。也可以适用于不需要被页面标签封装的 view 层逻辑，比如 {{time-format}}。因为 2.0 的 Component 准备支持无标签的情况（RFC 里叫 Fragment），所以通常情况下用 Component 也足够了，除非需要扩展 template 语法。

Service

跟 AngularJS 里的 Service 一样的概念。特点是 singleton。各种不适合放在 Route 和 Component 的逻辑都应该放在这里。用途比较灵活。其实它就是 Ember Object + inject API，没什么特殊的。

以上概念确实很多，这也是 Ember 学习成本比较高的原因之一。但 Ember 现在为了简化概念，已经计划把一些东西在 2.0 废弃掉了，所以想学 Ember 的话，着重在 Route, Component, Service 就行。

BTW 其实我还没提 Ember Data 的 Store, Model, Adapter, Serializer, Transform 呢……

12 个赞

blacktulip #48 2015年03月25日

@darkbaby123 非常感谢。一看 route 就是 rails 的 controller 我一下就感觉清楚了好多。请问什么地方能找到 2.0 的学习内容呢？我知道还没出，不过想看看具体的变更预报和例子等。

darkbaby123 #49 2015年03月26日

@blacktulip The Road to Ember 2.0 是一个总览型的 RFC。部分特性的细节还在另外开 RFC 讨论，比如 Routeable Components RFC 。

fantasticfears #50 2015年03月26日

#26 楼 @teddy_1004 @nightire Discourse 没有用 Ember-data 是因为那时候 Ember-data 官方强烈建议不要使用。能迁移肯定会迁移过去的，不过要花很长时间。可以看到 active_model_serializers 0.10 就会按照 JSON:API 标准来序列化对象了。而 Discourse 这现在只好用老版本。