@JeskTop 不知道，今年之内应该有希望，不至于像 Ember Data 一样拖几年…… @billy 普通内容可以，但 class="{{foo}}"" 是不能用的，只能通过 bind-attr helper 去完成。

@TsingHan old 的简写

@lgn21st 高层抽象确实用的舒服，但也会带来更多的约束。选择一个框架，就得接受它所有的优点和缺点。我想直到现在还有不少人选择 Backbone/Marionette 或者类似的框架，也是因为可以有更大的自由度。

Angular 能获得现在如日中天的地位，也是类似的原因。它其实更类似于一个提供了关键 feature 的基础设施。不同的使用者能基于它，结合自己的业务逻辑去做自己的框架。按作者的话说：Angular is not a framework, it's an HTML compiler. 所以我一直觉得它的 killer feature 不在于 dependency injection, service 和 data binding，而在于 directive。

BTW 我一般不喜欢看框架比较的文章，但这篇 slide AngularJS from an Ember.js perspective 确实不错。它从设计哲学上分析了为什么两个框架会发展成现在的样子。我觉得不管用不用 Angular/Ember 的都值得一看。

@xds2000 说到框架是基于语言之上，我想说的是，任何框架都是在语言之上构建的，他们可以最大地挖掘语言的潜力，但没法做到语言做不到的事情。所以从语言特性上说，没有框架可以重新定义新的语言特性。 举个栗子，客户端 JavaScript 都是跑在浏览器的沙箱之内的，而且有严格的限制，比如 website A 的 JavaScript 读不到 website B 的数据，或者操作浏览器之外的资源（外加 ActiveX 这种插件的另当别论）。 我也并没有表达“如果没有 Rails 也会有其他框架诞生去挖掘 Ruby 的潜力”的意思。就像谁也不知道当年牛顿如果被苹果砸死了会不会导致物理学晚发展一百年。这种事情没有定论。

从影响力而言，Rails -> Ruby 的影响力确实存在。其实两者是相辅相成的，框架不能直接去修改语言特性，但可以通过提倡 best practice 去影响语言设计的趋势。Rails 大量用 hash 模拟可选参数，因为这种编程方式用的多了，到了 Ruby 1.9（忘了是 1.9 还是 2.0 了）有了内建的可选参数机制。与此相类似的还有 concern。很难说 Ruby 是不是受了 Rails 的影响。反过来说，从语言层面有了更好的支持，框架才可以以此为基础走的更远。

JavaScript 也有类似的情况。只是不是由一个框架说了算的。更类似于每个 lib 或 framework 产生一些新的点子。因为 JavaScript 从开始到现在都没有诞生过一个占统治地位和指导思想的框架。原因说起来很复杂，我觉得不仅仅是语言灵活度的因素，还有浏览器不一致的因素。

但这种语言和框架互相促进的情况也是有。实际上 ES 5 和 ES 6 的规范，都是基于现在人们碰到的问题而设计的。而不是先设计好标准然后框架坐等实现。举个栗子，ES 6 module 是为了从语言层面上提供模块化的功能。设计的原因在于模块化这玩意后端以 CommonJS 为主，前端以 AMD 为主。没有个统一的规则。但 ES 6 module 的语法现有的浏览器又不支持。怎么办呢？有人开发了 ES 6 transpiler 去把 ES 6 module 语法编译成 AMD 或 CommonJS 的语法。浏览器不支持的时候就先这么用着，等支持了再作处理。

与此类似的还有 observer，web component 等。我想说的是，前端这一块不仅仅是有人定规范，然后各家框架都去遵守，框架的发展也会推进或改变标准化的定义。

太晚了，瞌睡来了先写这些。

Less Rails ?

@billy @small_fish__ 有空说说 Backbone/Marionette 的经验？很多人对 Marionette 评价很高的样子。

@xds2000 框架都是基于语言之上的，语言做不到的，任何框架都做不到。Ruby 的灵活性和潜力就摆在那，只是被 Rails 发现并且发挥到一个极致了而已。所以这点上我觉得 Rails 没有“重新”定义 Ruby。

如果从影响力而言，Rails 把 Ruby 从一个小众的语言一下子拉入了大众视野，这确实可以算是重新定义。但是……它只是 重新定义了人们认知中 Ruby 能做的事情 而已。

同样从影响力而言，Prototype 和 jQuery 完全可以说重新定义了人们对 JavaScript 的看法。让人们认识到可以用如此统一的方法解决跨浏览器的问题，可以用 css selector 的语法去操作 dom 树。可以让不擅长编程的设计师都能上手做一做动画效果。这都不算是影响？没有这些基础框架我们现在还在做 if else 去判断 ajax 用 ActiveX 还是 XMLHttpRequest，还在纠结事件绑定该用哪种 API，还在纠结某些特定事件是没有冒泡版本的。没有这些库把底层都统一了，你哪有时间去做高大上的 app？

同理，在 jQuery 做的前端越来越复杂的前提上，Backbone 引入了 MVC 的基本概念来构建前端代码结构，让人们认识到 JavaScript 是能构建前端 app 的“语言”，而不只是到处绑定一下事件写写 callback 的“脚本”，Angular 和 Ember 更进一步让人认识到作为展现和逻辑分离的框架，没必要去手动更新 template，可以让人们更专注于数据。这些都不算进步什么算进步？

如果你觉得 Rails 基于 Ruby 的元编程做了很多的事情，可以在此基础上重新定义 DSL 等等算是重新定义，我只能说语言特性和应用场景不同，不必拿 Ruby 的标准去衡量 JavaScript，反过来也没必要。举个例子，Promise 在 JavaScript 中特别有用，单这一点就可以改变很多地方的编程模式，但在 Ruby 中没得到重视，除开语言特性的不同，在 server 端也有很多其他的方式（比如 background job）去做到异步调用，以一种更适合 server 端的方式。

至于 contributor。我本意只是想表达学习框架跟成为 contributor 没有必然联系。想要作贡献也必须要有非常深入的了解，不然就是添乱。很多使用者都只是跟跟源码，能做到发现 bug 并且打补丁都是进一步的了（框架都不了解谁能去打补丁，酱油也不是这么打的）。真正能做到贡献很大的都是对框架有不下于原作者理解的人。这需要大量的时间和精力去积累。只是学习框架没必要定这么高的目标。自己实际上手用用，看开发理念合不合自己的 style 就行。

@xds2000 第二点和第三点不赞同。JavaScript 社区现在确实不成熟，但并不代表差 Rails 社区几个档次，实际上论创新程度，Github 上的 JavaScript 项目绝对比 Ruby 项目多。因为某些程度上说，不成熟才代表有足够的进化空间。不成熟，但有前景，就更好了。这两点 JavaScript 都符合。而且严格来说 JavaScript 不存在一个统一的社区，这点跟 Rails 没有可比性。拿 jQuery 社区，Angular 社区和 Ember 社区相比还差不多。

框架就是语法糖，换个角度也可以说，Ruby 才是最主要的（这点没错），Rails 就是语法糖，没啥新意（这点没人同意吧）……

学习和使用框架也没必要成为 contributor。如果说每种框架代表一种思想，能跻身进入 top 10 contributors 的都是对框架有不下于原作者理解，并且做出绝大贡献的人。我等使用者能去按照实际情况提几个 feature & bug，发 pull request 修复下 issue 都算是不错了。

@jeff_duan 随着 web 端越来越重视交互，和浏览器功能的日益强大，前端 MVC 只会发展的越来越好。因为本身就是因为需求导致的前端 js 越来越复杂，才会有人想到加入模式去构造系统。不管从现实世界用户需求的发展还是从技术发展来看，现在已经接近前端 MVC 的黄金时期。

不过传统的 server rendered website 还是不会消失。有些页面像公司主页或者一些宣传页面，结构简单并且各种动画效果做的很酷。这些页面直接 server render page + jQuery 干活反而更快。还是那句话，不同的应用场景使用不同的技术。

@lgn21st 谢谢！大家都是夜猫子~

@hysios 这倒是有意思，有时间我去看看。JSON API 的标准确实很有必要。Ember 就自己折腾了一套规范（名字就叫 JSON API），你说的功能像 batch get，batch update，relationship 和 side loading 都有定义。不过还在完善中，某些地方我觉得也不够实用。目前这方面还有一个比较有名的规范 HAL 。

JSON API 和 HAL 这两个都是属于 hyperlink API，我感觉很像把网页的数据直接转换成了 JSON 格式，有数据有链接，如果以后搜索引擎支持的话，完全可以做到搜索引擎友好。也可以避免前端 MVC 动态生成模板导致的 SEO 问题，估计会是以后 API 发展的一个方向。

@hysios 你没理解我的意思。实际上用 Rails 做 API server 也就是返回 json 而已，不涉及到任何 view & helper 的事情。自然不会有 server render。我举 Parse 的例子只是想说明有些业务逻辑还是自己写更方便。而不是让第三方 API server 托管一切。

体贴程序员，研究技术之余提供一点福利……

@hysios 感觉和 Parse 比较类似。其实把 server API 化也是不用管 UI 的，只用管 resource 和 action 就行。但我一直不喜欢 Parse 的原因之一在于，这种服务简单的把 model 和 RESTful 的 resource 画了等号，面对简单的应用场景没问题，但复杂的地方我觉得还是自己写后端逻辑更好。而且 Rails 本来处理 model, validation 这些就不麻烦。

@Rei 如果是有多种客户端（web app, mobile app）这种，server 只当 API 传递 json，web app 用 MVC 就是一个合适的选择。mobile app 如果使用 PhoneGap 的话用 MVC 也是个好方法。

如果只考虑 web app 的话用什么都行，DHH 曾经发过一个推，大概意思就是为什么我们需要 double MVC 共 6 层把事情搞得很复杂。实际使用中我确实感觉到麻烦一些。所以不建议只是为了架构或尝鲜去使用前端 MVC。简单有效的方案就收好方案。

Angular 把我所有用过的经验加上也就 2 个月，不算高手，就不评价了。

Ember 我想我还是有发言权的。从不到 1.0 版开始跟起，1.0 刚出就用进项目中（大概去年 8 月）一直到现在，并且 web app 和 mobile app 都用过。对框架的理解程度自认算中级水平。

技术比较之类的太多了。我就不细讲了，网上文章很多。有心可以去 Google。

Ember 除开技术之外的优势

我觉得 Ember 最大的优势，不在于结构清晰，跟 Rails 结合好，从各种工具函数到常用 mixin 无所不包……而是在于自 1.0 以来快速稳定的发展速度，持续的创新精神和活跃的社区。这点很像 Ruby 社区的氛围。总有新东西冒出来，然后作为 best practise 并入框架之内。

这也是我有信心它以后会变得越来越好的前提。虽然目前还有不完善的地方。但就我用过的 Backbone, Angular, Ember 三个框架来说，没有一个达到了完善的程度，或者说整个前端 MVC 都仍在摸索中。

Ember 自 1.0 版后每六个星期更新一次，目前已经到了 1.3，每次 release 都会有若干 feature（不完全是小修小补），1.2 加入了 loading/error substate，1.3 加入了大幅改进的 RSVP 并完善了文档。还有 query parameter 这种已经实际可用，但为了保险仍在 canary 分支中测试的 feature。

今年将会有几个重大改进：具体细节可以看看 What's coming in Ember in 2014 。基本上，我对 Ember 比较不满的地方都会在今年得到弥补，而且会解决的比较完美。

Ember 不够好的地方

如果你想做一个产品，Angular 和 Ember 基本都能满足你的需求。这方面两者提供的特性不相伯仲。相比而言我觉得“哪个框架不适合做什么”更重要。实际使用中，Ember 作为一个大而全的框架，没有明显的短板。但仍然有不够好的地方。

Handlebars 和数之不尽的 script 标签

Ember 的 binding 没有 Angular 那么高性能，而且 Handlebars 对 if, each 之类的绑定都会生成 script 标签帮助定位，所以页面复杂后生成的 dom 数量不少。这点在 web 端感觉不到性能差距，在 mobile 上一般页面也还可以接受，但对于很长的列表和各种 input 比较多的 form，在进入页面是就能感到明显的停顿，因为需要花时间 render template。

这点可以通过减少双向绑定的元素来解决。适当使用 unbound，each 中可以使用 group，或者删掉滚动到屏幕区域外的 view（Discourse 的 ember-cloack）就是用来做这个事情的。

今年 Ember 准备用 HTMLBars 替换 Handlebars 来获得更高的模板引擎性能，根据现在的测试，双向绑定的性能直逼纯 JavaScript 修改页面 ，而且额外的 script 标签也都消失了。而且还让 Ember 可以在 template 中写类似 Angular 的复杂表达式，不再局限于只绑定某个属性了。

Ember Data

没有一个好的 Data layer 是 Ember 绕不过去的坎，Ember Data 一直在开发中，其他的替代品如 Ember Model, EPF 各有擅长，但缺点也同样明显，不大适合用在产品环境中。Angular 的 $resource 虽然也不给力，但还有 Restangular 撑大梁。

在 Ember Data 完工之前，甚至是完工以后，我都推荐用 Em.Object 和 $.ajax 自己封装 model。这样可以根据需求做到最大的灵活性。实际使用中没什么困难，也没什么问题。Discourse 那么复杂，也是用这种方法做的。

对于喜欢类库的人，今年有个 Ember 社区衍生出来的类库 Orbit.js 倒是可以期待一下。功能还比较强大。而且上升势头非常猛，上星期我看了下 star 才几十，今天已经到 600+ 了。可以看看这篇 slide：Introducing Orbit.js 。

Animation

Ember 到目前为止，实现 Angular 那样的 animation 都不现实。目前只有一个 animated outlet。Angular 的 animation 已经细化到连 ng-if 都有 animation 了。这点确实很赞。

目前只知道 animation 也是 Ember 今年的重要目标之一，虽然目前还没有成型的 API，但我相信最终公布时，会有一个完善的解决方案。这是 Ember 引入新功能一贯的标准。其实前段时间有人加入了 animation 的 pull request，但最后因为觉得不好被 revert 掉了……

顺便提提 animation 的性能。我的实际经验中，mobile app 只要使用 -webkit-transform 做动画，是会有硬件直接加速的。流畅程度跟 native app 不相上下。但 JavaScript 控制 style 这种动画就非常卡，所以如果用 -webkit-transform 的话，影响不大。HTML5 构建的 mobile app 慢的主要原因其实是 dom 过多。

总的来说，Ember 我觉得可以作为长期的生产力工具去投资学习。这是一个完全由社区推动，崇尚研究和整合通用的 best practice，并且非常活跃的框架。

最后，大晚上写了这么多，觉得有所收获的给个喜欢吧 :-)

CoffeeScript 本身就不是一个必须用的语言，它不像 JavaScript 那么没选择性（浏览器只能跑 JavaScript）。但 CoffeeScript 给我们这些不喜欢 JavaScript 某些繁琐地方的人另外一种选择。

对熟悉 JavaScript 的人来说，CoffeeScript 没有任何学习成本可言。它只是简化了我们反复写的繁琐的代码，就如 jQuery 简化了 dom 操作。有的地方我们需要用类库来简化工作，但有的地方我们不得不用语言来简化工作。抱着“学习 CoffeeScript 就避免学 JavaScript”的想法才是大错特错。

要说 JavaScript 的优势，我能想到的就是一点：所有懂 CoffeeScript 的人都懂 JavaScript，但不是所有懂 JavaScript 的人都懂 CoffeeScript。这也是 Discourse 把所有 CoffeeScript 全部转成 JavaScript 的原因。但他们这么做是因为，作为一个开源项目，需要更广泛的贡献者。也不是因为 CoffeeScript 本身的原因。

看了下介绍和视频，很有爱的环境啊，支持一个。

我也用的 anjlab 的版本，看来得换了…… 当时用它是因为支持 Bootstrap 3，而那个时候 bootstrap-sass 对 3 的支持还放在某个 branch 里面。刚看了一下，bootstrap-sass 也升级到 3 了，那就没问题了。切换这个应该成本不高。

修正一点：edgeguide 那个链接得把最后一个 / 去掉，不然打不开页面。

enums 是个好东西，再也不用在 model 里自己维护状态常量了。Spring …… 我只能说又一个 gem 要崛起了，历代被 Rails 宠幸的 gem 都升天了。 再补一篇，看的舒服点：http://coherence.io/blog/2013/12/17/whats-new-in-rails-4-1.html

@loveky 原来如此，3Q

@loveky 想知道那个 tab 标签的图标是怎么做成动态的？用的什么技术？https://pomotodo.com/ 也是可以控制动态图标。

微博的 500？

书很不错，而且作者让你决定出多少钱购买，果断入了。

@small_fish__ BTW 作为 Rails API 依赖的一部分，active_model_serializers 貌似也是有 Yehuda 参与的。它默认生成的 json 格式和 Ember Data 是吻合的，不过现在有点不一样了。

@small_fish__ 反正我现在是没用的，就是 Rails + Ember。因为我还是用的 Devise 的 session 验证。虽然有办法去跟 Rails API 结合，但我还需要 sprocket，懒得折腾了。 其实 Rails API 就是个减去了不必要 middleware 的 Rails，其他地方没什么区别。

@HungYuHei 如果他还没走说不定 Rails 就直接变成 API server 了……

@xds2000 话说我怎么觉得这帖子标题有点像新闻联播？比如“XXX 再次重申 XX 自古以来都是中国不可分割的一部分……”