Rails [译] 是否要在 rails 中使用 javascript framework
UPDATE(2014.12.24): 今天看了一篇文章 http://www.justinweiss.com/blog/2014/12/23/how-to-choose-from-conflicting-rails-advice/ 大概意思是说，如果你觉得一个技术需要你去考察一段时间优劣并且还难以做选择的话，那你不如先选择一个，总比什么都不选择好。技术总是在变，过一段时间你的想法可能就会变了，而且你学到的东西也是很有用的，就算再转换另外一项类似的技术也没那么难。送给像我一样有选择强迫症的人。
翻译这篇文章，一是想知道 rails 中用什么 framework 比较好，二是作为自己学习的一个输出。建议大家看原文： http://andrzejonsoftware.blogspot.com/2013/12/how-can-rails-react-to-rise-of.html
大家在 rails 中用什么 front-end framework，show 一下吧～
============
懒人看我的翻译吧：
现状
Rails 在处理后端部分毋庸置疑，做的是非常好的。基于 conventions，所有的 app 都有很类似的结构，每个人都知道如何玩的转。
放眼看看 Rails app 的前端部分，你就看不到啥 conventions 了，没有什么相同的结构让每个人都知道怎么玩。
对于一个创业团队来说，使用 Rails 是非常好的方式，因为许多 Rails 开发团队知道怎么用 Rails 的方法来完成项目，也更容易扩展团队。而现在情况变了。后端部分依然是我们熟悉的部分，而 JavaScript 呢？每个 Rails app 中都不同，JavaScript 正常他们占有代码的 50%.
有些开发者使用 jQuery 的 plugin。
有些开发者跟随 DHH 的建议使用 SJR（Server JavaScript Responses）。
最新的趋势，是对 JS framework 的使用，比如 Ember.js 或者 Angular.js，这种方式似乎也更符合 Rails 的哲学 (conventions, magic, implicit features)。
另外有些开发者（包括本文作者）不想使用任何的 framework，而是使用自己定义的架构比如 http://hexagonaljs.com/
那对于这种情况，Rails 要如何来应对呢？
不使用任何 framework DHH 推荐使用 SJR - Server JavaScript Responses - see http://37signals.com/svn/posts/3697-server-generated-javascript-responses 从我的观察来看，社区领袖没有反对使用当前流行的 JS framework，只是这个问题不是当前他们关心的焦点。 这种方式可能会让社区有些分化（倒不一定是坏事）。我遇到了一些人，他们比较担心 Rails 的未来，他们不知道是不是应该投入自己的时间去学习 Rails。对于这些人，可能长期来看，他们更加倾向于多学习一些 JS。现在招聘需求中要求使用 Angular 和 Ember 的工作也越来越多了。 这种方式，我们看到 rails-api（http://blog.steveklabnik.com/posts/2012-11-22-introducing-the-rails-api-project ）流行了起来。
rails 推荐使用某种 JS framework 可以是 Angular 或者 Ember，Angular 的发展势头很强劲（http://www.funnyant.com/choosing-javascript-mvc-framework/ ），Ember 是由 Rails 社区中的名人 Yehuda 来主导开发的，虽然没有 Angular 使用的人多，但 Ember 在 Rails 社区中更受欢迎。 这种场景在 Rails 的发展史上似曾相识，当年 Yehuda 创造了 Merb，之后 Merb 合并到了 Rails（http://yehudakatz.com/2008/12/23/rails-and-merb-merge/ ）。同样的事会再次发生在 Ember 身上么？很有可能。 Angular 会变成默认的 JS framework 么？Rails 会推荐 Angular 么？使用 Angular 配合 Rails 开发没什么难的，只是 Angular 还不是 Rails 默认的选择。DHH 之前对 Rails 做了一些大胆的改变，例如将 CoffeeScript 作为默认的选择（谢谢！）。Angular 会么？
Rails 鼓励使用 JS framework，只是对 JS framework 保持不可知的论调 这种情况其实在社区中已经发生了，很多人使用了一些 JS framework，效果还不错。
以上 3 种 DHH 会继续推荐使用 SJR，Rails 核心团队也会将 Ember 作为默认的选择（可以很容易禁用），而社区呢，每个人可以基于自己的情况选择相应的 JS framework。
未来
未来会怎样我也不知道。Rails 已经做的很好了，它可以不用有任何的回应。需要我们注意的是，这不只是关乎纯粹的合理的技术的选择，Rails 在市场方面一直做的很出色。我们会看到很多改变的，比如引入它自己的 JS framework。
我更喜欢的一种方式
我目前使用 rails-api（http://blog.steveklabnik.com/posts/2012-11-22-introducing-the-rails-api-project ）的方式来是用 Rails 构建 app。Rails 在 API 方面做的很好，所以我可以选择任何的 JS framework。
如果我的目标是让 Rails 对于新手来说更加流行，那我会建议选择 Angular 作为 Rails 的默认 JS framework。这样会有更多的人热爱 Rails 这个社区。我目前还不是太喜欢 Angular，但是选择 Angular 会对新手更加适合，因为这会省去了新手选择的烦恼。
同时，其它的后端社区也在持续进化。你知道 PHP 和 Symphony2 么？这个 framework 的架构比 Rails 还要超前。另外，你知道 Scala 目前有多流行么？
我们需要担心 Rails 的未来么？需要保持后端的独立让后开始学习其它的后端框架么？我们要使用 mixroservices（http://www.youtube.com/watch?v=2rKEveL55TY ）的方式让 app 同时与几种不同的后端技术交互么？（完）
Ember+1
现在选择 Angular 可能是最不好的时候。为了轻量级不如 React，为了全面不如 Ember。关键是考虑 2.0 出了之后如何升级的问题。这是任何一个打算维护几年的项目都需要考虑的事情。
Rails 的特点就是它是从实际项目中抽出来的，Rails 的发展方向也很大程度上取决于 Basecamp 用什么。虽然也有很多其他选择，但他们都只会以第三方 gem 的形式存在。Basecamp 团队一天不考虑前端 MVC，Rails 就不会默认集成。
很有趣的话题，我也正好刚刚写了一篇 关于 Rails 视界下的 web 前端的文章：https://ruby-china.org/topics/23365
关于这个集成前端的问题，@nightire, @Saito 也深深影响了我的看法：Rails 天生与前端框架不容，除非退化为 API 框架，所以这个问题的答案是：前端的事由前端自己解决，详细看我写的文章对于目前前端产物的看法。
rails 比较偏向于 SJR 前端框架的话考虑 backbone 作为主体，加上 react 和 sammy 增强 view 和 router。(好吧，其实这个组合我还没实践过… ember 还没用过 angular1.x 生态圈发展还可以，虽然因为 2.0 和他爹的原因会减点分，但不失为一个靠谱的选择
@luckyyang @lyfi2003 最开始的原因是项目同时有 web 和 mobile 版本，所以打算前后端分离，Rails 提供统一的 API，web 和 mobile 都用 Ember 做。但现在我觉得工程角度来讲，前端的归前端更加方便。细节方面过段时间我准备写点东西，目前大概说说，最典型的两个例子：
- UI component，把 html + css + js 组织在一起，提供一个功能。Rails 处理比较尴尬，如果纯前端渲染 html 就没法重用 helper/partial 等 view 层的代码，如果一半放前端一半放后端就有可能一套逻辑 ruby 和 js 代码各重复一次，只有纯后端渲染可以最大程度上利用 Rails 的功能（partial/helper 等）。这就涉及到后端渲染好 html + js 再推到前端去，才有了 SJR。但 server render page 不管怎么写在页面状态控制上都没与纯前端方便。
- 传统的 website 和 web app 有根本的理念差别，一个是 stateless 的，服务器不记录状态，处理完请求就忘掉一切，一个是 stateful 的，用数据抽象页面状态（或者说应用程序状态）进行精细控制。服务端渲染有时在涉及到前端页面状态时会无能为力。这个用两种思路分别写过代码的才会有体会。
@yukihiro_matz 我挺看好 Angular 2.0，甚至比 Ember 2.0 更看好。但我觉得 breaking change 就是最大的问题。生产环境的东西不是说句“我们要用最先进的技术就必须抛弃包袱”就能果断升级的。等 2.0 出了，目前用 Angular 1.0 写的项目都会碰到这些问题：
- 升级？怎么升？重写。
- 不升级？需要用到一个只有 2.0 支持的新特性怎么办？找第三方库吧。或者升级？
- 打定主意就用 1.0 了，碰到一个 1.0 的 bug，虽说 1.0 会继续维护 1 年（可能更多）但维护期过了之后碰到框架 bug 怎么办？别人只会在 2.0 上修复。要知道那继续维护的一年就是给人升级用的，不是 LTS（不过照框架火热程度说不定真会有）。
- 想用一个第三方插件，只支持 2.0 版本，怎么办？
其实我觉得用 Rails 的应该对此深有体会才对，太旧的 Rails 版本 = 某些 bug 不会修复 + 某些新的 gem 不能用。而且升级这种事情，不会因为拖了一年而变得更容易。
Ember 这方面我觉得还算做的挺好的，不管他们的 2.0 plan 和 stability without stagnation 的口号。从我 0.9 到 1.8 的升级经验来看，大部分时候就是改个版本号，有时间就修复下 deprecation 的事情。deprecation 还是我看提示看烦了改的。最近框架升级 HTMLBars，为了不造成大的破坏，core team 的人把 HTMLBars 拆成了 3 个部分放到 3 个版本里渐进升级。我个人比较喜欢这种平滑过渡的方式。
扯多了，说说正题，Ember Data 还没出 1.0，最近 issue 里面有计划 1.0，但……别期待具体什么日期为好。不过可以确定的是不会有大的改动了。而且现在的版本已经比较稳定，可以考虑用在项目中了。但用之前最好了解下它干了什么，不能干什么。
@lyfi2003 我这段时间也在想 Rails 做 API 方面的未来。从目前来看前景还不好说。抛开语言层面的原因，我觉得最主要和最致命的原因，是 Basecamp 目前用 SJR 用的挺好。短期内他们没理由把 Rails 往 API server 的方向推。
#12 楼 @darkbaby123 今天看了一篇文章 http://www.justinweiss.com/blog/2014/12/23/how-to-choose-from-conflicting-rails-advice/ 大概意思是说，如果你觉得一个技术需要你去考察一段时间优劣并且还难以做选择的话，那你不如先选择一个，总比什么都不选择好。技术总是在变，过一段时间你的想法可能就会变了，而且你学到的东西也是很有用的，就算再转换另外一项类似的技术也没那么难。送给像我一样有选择强迫症的人。
