现在转 Scala 了。

建议开发“评论打赏”功能！

我补充一个，macOS 其实默认就支持 Emacs 键位映射，所以在绝大部分需要输入文字的地方（浏览器，终端，IDE，编辑器，etc）都可以使用 Emacs 的快捷键，我比较常用的有：

ctrl-a: 到行首
ctrl-e: 到行尾
ctrl-f: 向前一个字符（右箭头）
ctrl-b: 向后一个字符 （左箭头）
ctrl-d: 删除当前光标字符
ctrl-k: 删除当前光标至行尾
ctrl-n: 向下移动一行 (可以代替下箭头)
ctrl-p: 向上移动一行 (可以代替上箭头)

觉得 Ctrl 不好按？到键盘设置里把 Cap Lock 改成 Ctrl 键就好啦，反正这个键极少用，用的话也可以用 Shift 代替。

#47 楼 @nightire 其实我引用 Redux 的例子并不是想说它好，而是想支持之前的一句话，用的人多其实才是好事，集思广益才能加速促进。我对 Redux 也并不感冒，就不多加评判了。

从去年开始边学边用 Ember.js 到现在一年多，业余也做一些 Ember 的技术咨询，说说我对这个框架整体的看法吧，先来优点：

• 开箱即用 这一点是我最直观的感受，不仅可以用，而且超好用，比如无需任何配置直接写 ES6，整个人都好了很多。ember-cli除了在安装和升级项目的时候有点麻烦外，其他时候完全可以媲美 rails 的命令行工具，Ember 这一点启发了很多其他前端框架。

• 与现有技术融合顺畅 尤其是可以直接大量借鉴现有的丰富的 jQuery 库，不知道可以省掉多少时间，少造多少没有明显收益的轮子。

• Ember Addon 当然还是有人愿意造轮子，而且还愿意分享出来，一些复杂的场景现在都有了成熟的解决方案，比如ember-simple-auth, ember-cp-validations，etc。以前自己写的一个select2.js的 wrapper 各种别扭各种不兼容，然后我发现了ember-power-select，原生实现，好用到哭。

• Ember-data 不只是有很多好用的 API，而是用多了之后你会不由自主地围绕 Data 来思考，因为这是 The single source of truth,而且 Ember data 也是一个极好的存储状态的地方，可以省掉不同视图间大量的状态传递和计算。

• 大量杀手级特性 比如 Computed Property，熟读其 bool, equal, oneway等 APIs 代码优雅指数可获极大加成。再比如 queryParams，对URL即状态这一理念的完美实践，记得这个理念是 Yahuda Katz 在哪个演讲里提出的，个人深以为然。

接下来说说感觉不是那么良好的：

• 学习曲线 真的不是一般的陡峭，基本上新手安装完，做完 ToDoList 了之后差不多新鲜感就过渡到就迷茫感了，老老实实去啃文档去吧。记得我开始学的时候，除了把最佳入门读物 Rock and roll with Ember.js过了一遍之外，还和一个以色列的哥们做了 5，6 次的远程结对编程，才慢慢地感觉有点头绪，真正写起来有行云流水的感觉就要到好几个月之后了。印象最深的是把后端的 snake_style 转换成 js 通用的 camelCaseStyle 就用了我 3 天，而那个 hook 就隐藏在文档的某个小角落里……

• 使用场景局限 就是小项目不是不能用，而是用起来显现不出 Ember 的优势，用传统的技术比如 jQuery 也能实现的很好。这一点 @nightire 总结的很好，我就不多赘述，只是比较最近用 Ember 帮客户做了一个简单的 CRUD 的 app，感觉确实有点杀鸡焉用牛刀了。不过如果你的后端是 API-only 的那就另说了，

• 文档（或者说缺少文档）平胸而论，官方现在的文档质量已经好很多了，但这也是很少甚至是唯一可以依赖的地方，其他方面比如书啊，教程啊要么很少要么就很过时，尤其是 Stackoverflow，上面关于 Ember 的问答大部分都「年代久远」，根本都不能看。 比如一个比较新的Contextual component特性，基本除了 RFC 和 Release Notes, 还没有看到有 blog 提到关于它的最佳实践，除非去扒开源 add-on 的源码。当然 Ember 有自己的 slack group，YouTube 上也有很多演讲，但太过分散而且效率低。所以很多时候想要真正自信地采用某个方案，还是得回去看官方文档，然后自己领悟，只有真正懂了才能形成自己的最佳实践，不然就是给自己或别人挖坑，这也算是某种程度的倒逼吧。

• 开发进度 这一点 @nightire 也解释了，主要是这个新的 Glimmer 2的开发耽误了许多，社区追求更好的实现当然无可厚非，但客观事实就是 Ember 丧失了迅速发展的机会。想想去年这个时候（2015-11 月），Angular 1 已经日薄西山，2 还在无限 beta，React 的生态比现在还混乱，Vue.js 更是小众中的小众，那时候要做技术选型，作为唯一一个稳定先进的框架，有点常识的人都会认真考虑一下 Ember.js。可现在如果再选，你有不是一个而是四个成熟的选择，Ember 对那些技术决策人的吸引力不得不说小了很多，不是 hard core fan 或前端大拿，选 Ember 还是要很大决心的，这也导致了 Ember.js 至今仍然是不愠不火地发展着。虽然说做 early adopter 的感觉良好，但用的人多其实才是好事，集思广益才能加速促进。想 Redux 玩非主流的 FP，连 OO 都没搞明白的新手还不是趋之若鹜？这一点，Ember 社区真的还是要好好学习一个。

缺点说了这么多，搞得我的口气好像在批评一样，但其实不然，我个人对 Ember 的整体感觉还是瑕不掩瑜，Ember 的理念还是很先进的，掌握 Ember 之后面对其他框架的确有种高屋建瓴的感觉，很多看似新鲜的东西其实深究起来在 Ember 里早就实现了。但具体到个人需求，每个人都不一样，Ember 也不是银弹能照顾到所有，所以个人还是要按需选择。我们的目标是：不追 HYPE！

#31 楼 @nightire

我对 Ember 的诸多不满意之处是促使我深钻 React 的初始原因

可以说说当初你对 Ember.js 有哪些不满意的地方吗？我觉得我现在也到这一阶段了，对 Ember.js 很熟稔，但真有点审美疲劳，有学习 Vue.js 的打算，或许对比之下能重新发现 Ember 的强大。

终于更新了！

支持！

#8 楼 @kgen #7 楼 @jasl 这种功能一开始肯定会有新鲜感，并且如果是仅对自己可见的话也许还有些帮助，但我个人来说是绝对不希望让别人知道在我这个论坛的活动记录的。无关这个论坛的好坏，仅仅只是出于个人隐私。如果知道自己的一举一动都在被别人观察，哪怕仅仅是小范围内，我也会觉得受到侵犯的，这就是我的个人看法。

这个真的没有隐私的问题吗？

#26 楼 @kgen 心里有谱了，感谢！

#17 楼 @kgen 请教你的顶配带独立显卡吗？如果是，你觉得这会是发热量大的主要原因吗？ 因为最近也在关注新款 MBP，想一步到位，又怕买了后悔。

#2 楼 @nightire 想不到您这浓眉大眼的楼主也背叛 Ember.js 了……

#28 楼 @nightire 嗯，我有在 medium 上看到她的 post，立马就关注了，好像还是你推荐的。

#12 楼 @darkbaby123 我也在用 JSON API，我能体会到的好处大概有：

1. 格式丰富而且统一，基本上覆盖到了绝大多数需要的数据类型。一般数据在 data 里，分页有 links，associations 有 relationship，错误有 error，统计类的可以放到 meta 里。各归其所，简直不能太舒心。
2. 便于团队协作。基于上述原因，Android，iOS，web 都可以遵循同样的规范，最大限度地减少了后端的 parsing 工作，不必再自定义一套接口协议。大赞！
3. Rails 集成度不完美但够用，并且也是官方推荐。因为这个规范比较新，目前还是不能很好处理 associations（也有可能是我们团队里的 bug，这个锅也不一定是 jsonapi serializer 的），但我觉得这个可以适当的做折衷。

大概就是这些了。

#26 楼 @nightire 其实我还没那么水啦，哈哈。之前我也用 vim 好多年的，只是为做 ember 开始用 atom，上手快，装卸插件无脑流，但工具本身比较新，限制较多，尤其文件切换这块，功能也没 vim 全。 你这么讲我就差不多有底了，准备暂时先不改了，团队就我一个人负责前端开发，同时还要做 server API，觉得还是不折腾好了。 多谢分享。

#23 楼 @nightire 再问一个题外话，现在我的项目已经出具规模了，找文件代码有点不容易，在考虑转到 pods 结构。有几个疑虑：

1. 现在转到 pods 的条件成熟吗？
2. 使用 pods 过程中你体会到的好处多还是缺点多？
3. 有哪些 killer benefits，或有哪些大到让你想放弃的缺陷？
4. 如果现在重构，将来 pods 成主流了后需要做的升级工作会小很多吗？ 叨扰了。

#23 楼 @nightire 第二点的确有种恍然大悟的感觉，当时怎么都没想到测试一下先，现在架构已经改了。

但第一点描述的就是我想避免的，主要是不想在模板里写很多的 if else，（没办法，层级略多，不同 route 里 sidebar 的功能各异，给 sidebar-components 传参也略啰嗦，有的 sidebar 还绑定了 query params，耦合度比较高，想抽象出来有点费脑筋。

所以现在采取的办法比较笨，每一级模板才用最少化原则，尽量在模板里避免 if else，route 需要什么就渲染什么，虽然多一点重复代码，但好在够直白，将来重构起来也很容易（按 ember 的发展方向重构肯定是不可避免的），并且也用到了 block components，在里面把 UI layout 定义好，需要什么就往里面填什么。竟然代码也看得过去，边走边改吧。谢谢指点。

#21 楼 @nightire 的确很优雅的方法。但我的场景更复杂一些，不仅仅是 on/off 的问题，而是需要在不同 route 下渲染不同的 sidebar，所以我把你的思路扩充了下，结合{{component helper，通过在不同的 route 下定义需要渲染的 sidebar 来达到目的。然后问题来了：

1. 如果 / 下 有 /admin 和 /users，分别渲染admin-sidebar 和 users-sidebar，然而后两个 routes 下各有一大堆子 routes，怎样才能让这些子 routes 自然继承对应的 admin-sidebar/users-sidebar 而不必再每一个 route 重复定义呢？

2. 我把不同的 sidebars 都用 components 实现，如何给不同的 components 传递不同的参数呢？

#1 楼 @nightire 你指的是这个 talk 吗？ 刚刚大致看完了，觉得现阶段简直就是黎明前的黑暗啊，好用的特性都是即将到来，pods，routable components，ES5 getter/setter。虽然有的已经在 beta，但工作版本还是稳定一点好，只能暂时忍受一下不便了……

5.0 milestone 表示只完成了 66%，路漫漫其修远兮……

#2 楼 @nightire 我感觉这似乎是 Ember component 设计的一个不可逾越的限制，看来一些变通（workaround）是少不了的。我目前的方案就是从 action 入手判断是否需要 nested component，不然很容易产生面条式代码，也会使 Component 失掉 单一职责原则的设计初衷。

坐等！请多讲一讲在 nested components 的情况下 bubble up action 的 best practise，比如怎样避免一个 action 不得不需要被逐层捕捉然后向上抛出的 duplication。

#16 楼 @nightire 您好，我有发 gmail 邮件给您，希望您查收并给我一个回复，万分感谢。

#7 楼 @nightire 受教了，不过如果把内容单独发一篇帖子会更好，搜索起来方便，也可以让更多的人看到！

楼主在 rubychina 的发言我时不时地就会回来看一遍，因为从中实在获益匪浅。

我觉得楼主的目标听众是只会用 jQuery 的前端工程师， @luikore @rei 两位真的大可不必对号入座。

赞！持续关注中，谢谢 @nightire 分享

@nightire 希望能听听您的评论：）

并且 CSS Framework 用的还是 Foundation！

我在本次大会的 Associate Sponsors 之一 TInkerbox 工作，两位组织者@winstonyw, @elishatan我都熟识，如果大家有什么需要的可以联系我 hoodavy at gmail.com / David，欢迎面基。 :)