Slim 大爱，我一直觉得应该替代 Haml。

抽象出一层统一的 API 也不是坏事，真搞得好以后换个后台任务的 gem 都不用改代码了。 @huacnlee 我也记得这事，刚才查了一下，叫 Queue API，Rails 4.0 正式发布时被移除了。至于为什么被废掉，这里可以找到一点答案。https://blog.engineyard.com/2013/rails-4-queue-api

@QueXuQ 关于 meta，我是因为 JSON API 规范和 Ember Data 期待的数据结构里都用，才用的。而且我那个 model 写法是相当简单的，基本除了封装下 $.ajax 之外没干什么事情。你可以自己修改下 _findAll 方法去加上 meta 的逻辑。

举个栗子：

$.get("/api/tasks.json", params).then (payload) ->
  array = payload.tasks.map (obj) -> modelClass.create(obj)
  Em.set array, 'meta', payload.meta
  array

如果你是非常简单的情况，你甚至可以直接把 json 数据保存成 object 绑定到页面上，不一定需要自己写 model 封装。

API 比直接写 view 更灵活，不用关心怎么生成 html。我的一个例子：

meta = nil
# query 中调用了 page 方法才会有 current_page ，否则是没有的。
if products.respond_to?(:current_page)
  meta = {
    next_page: products.next_page,
    page: products.current_page,
    total: products.total_pages,
  }
end

json = { json: products, meta: meta }
render json

我自己用的懒人方法查 API：

Product.page().methods.grep /page/

有时候“自己试试”这种 看起来最笨的方法其实最高效 。

@wcc526 虽然我很想说你大胆用吧，但这个真取决于你适不适应这种开发方式。建议你先找个前端 MVC 框架做个试验项目练练手。不然别人的一些经验说了你也不会有切身体会。

相比用什么 MVC 框架，我觉得你更应该的考虑下 是否有必要使用前端 MVC 。

@wcc526 没研究过跟 Rails 如何集成，不好回答你的问题。如果你希望跟 Rails 结合的更好点，试试 Ember 吧，那里面很多人都是同时搞 Rails 的，所以跟 Rails 集成也做得最方便。一个 ember-rails gem 就可以解决了。

说到前端 MVC，如果是新项目，现在的大趋势就是 Angular 和 Ember 了。而 Angular 基本成为 MVC 的事实标准了。当然还有一些用 micro framework 自己组装的。另外虽然现在还没到 1.0，但 Batman 很早就有了。

一直在断断续续地用，非常赞的工具！个人觉得这个工具如果结合一个完整的 task management 会很有市场。目前的 task 系统还是太简单了。

所以这就是为什么 Rails 要加入 turbolink。你会发现这些决定都是一环套一环的：

1. 简单容易的集成前端功能？默认全部 js 和 css 打包成一个。
2. 打包成一个文件导致页面切换时反复加载？使用 turbolink 只更新 title 和 body。这点本身不见得对，如有错误请指正。

不止一次根据截图一个一个字的敲 UUID 进 developer center 的页面的飘过……

@quakewang :plus1:

@QueXuQ 没用过 iCheck，但一般任何这种第三方插件和 Ember 集成，都需要调用 Ember 的 set 方法才能使用 Ember 的双向绑定。你看看在 iCheck 里有没有 check 触发的回调，然后在里面用 set 方法修改 checked 值。

一个基本上排除了干扰因素的例子：http://emberjs.jsbin.com/sucur/1/edit

@quakewang 1 还不知道有这一点。不过选定一堆代码 ->折叠 -> 缩进，跟选定一堆代码 -> 缩进所需要的工作量也差不多了吧。2 现在真举不出来，好久没写过 template 了，都忘光了。 @Kabie 其实把两者各有各的好。以前写 Rails template 我就只用 slim，现在写 handlebars 才又用回了 html，发现也没那么不能接受。看久了发现一层层的嵌套也挺有美感的……

虽然有 zencoding（现在叫 emmet 了），但我还是觉得“写更少的代码”优于“敲很少的代码然后自动生成代码” 。从这点来说 slim 比 erb 好。

不过 slim 也有不爽的地方：

1. 强制缩进，不缩进就报错。最终的代码确实应该严格缩进，但有时写 html 需要反复改写标签的嵌套关系去尝试最好的方案，用 slim 就导致删除一个 div 就必须调整里面的所有标签的缩进。在试验过程中比较烦人。
2. 写多个 inline 标签，或者 text 和标签混用总觉得像在 hack。这点用过 slim 的都有感受吧……

@imlcl Mina 好久没更新了，所以现在还是 Cap 3 靠谱点。打算过段时间换到 Cap 3 的。

美！

@tyaccp_guojian 说错了，应该是 reduceComputed …… Ember 里面很多跟数组有关的 computed property 方法都基于它完成的。 http://emberjs.com/api/classes/Ember.html#method_reduceComputed http://discuss.emberjs.com/t/ember-computed-filterby-question/4288/3

选题的话，reduceProperty，injection 和 ES6 module 我觉得都是还不错的 topic。

@tyaccp_guojian 你如果愿意就拿去吧。但我觉得那个挺粗糙的……简单情况下真不如用 Ember Model 或者 EPF 省时省力，个人意见。

@tyaccp_guojian 不好意思啊，这段时间都挺忙的。估计没时间写博客准备了。而且之前想写的一些东西国外 Ember Weekly 里基本都有人写了。我觉得你们如果想讲的话可以抽 Ember Weekly 里面的东西讲讲。希望对你有些帮助。

@blacktulip 手机换成充话费送的呢？ @nightire 你写的基本涵盖各方面了，说个 Git 相关的，SourceTree。有时候分支多了查看起来还是图形化工具省时省力。

快吧 CanCanCan 名字改回来……我一听到这个名字就想到了某广告的“砍砍砍”……

别用敬语了，听着挺奇怪哈。抱歉，如果是最近就办我可能来不了了，下次我争取吧~

只在北京么？

挂掉的时候看到 It works! 总有种莫名的喜感。

@Victor 我的意思是不管 Web app 还是 Hybird app，只要有用到浏览器，都会碰到浏览器相关的问题，而往往那些问题对 Native app 来说不需要考虑的。所以不是简单写一套代码放在里面就高枕无忧了。

我是用的 PhoneGap + Ember.js 来做的，PhoneGap 除了打包，也就是负责一些浏览器无法做到的事情（跟设备进行交互）。所以我碰到的问题大多都是浏览器相关的。虽然一些组件也可以考虑用原生代码实现，然后做成 PhoneGap plugin，但那样而言就失去了“Write once, run everywhere”的便利性了。当然 web 和 native 的比重这个涉及到很多方面的权衡，各人有各人的选择。

@ashchan 曝内存的问题我还没遇到，不过确实很多人抱怨过。不过我碰到过一个很长的 list 会导致 app 变慢，暂时解决方法是把滚动到区域外的 item 取消掉，用相同高度的空白 div 代替。滚动时无事件是什么问题？可以说说么？