没有 Ember CLI 也可以把前端独立出来，只不过 Ember CLI 本身干得挺出色的罢了（针对 Ember 应用来说）。

前端的变化的确快且乱，这个原因还是蛮复杂的，不过总体来说是好事，当然另外一面也对工程师提出了更高的要求。

完全分离这件事情可以简单了说也可以复杂了说，简单了说就是你单独做一套前端工程，所有的东西都和 Rails 不牵扯，唯一和 Rails 交互的就是 API 调用。换言之就是 Rails 单纯作为一个 API 服务——当然这样一来到底还用不用 Rails 那就两说了。

剩下的东西全部转移到前端去，这个工程不可谓不大，不过难者不会会者不难，万事都是如此。

这里面几个关键就是 Node －》扮演 Ruby 的角色，Npm／Bower／等等－》扮演 Gem／Bundler 的角色，Grunt／Gulp／等等－》扮演 Rake／Assets Pipeline 的 角色。

至于 pre－processer，templating，ajax 等等，这些本来都是前端／Node 的份内事，不会比 Rails 弱的。

唯一的问题就是以前前端工程缺少像 Rails 这么全面的生态环境，不仅仅是一个 MVC 框架，还有配套的许多东西，conventions 等等……这个大家都是内行就不多说了。Ember CLI 为啥令人兴奋？因为它和 Ember／Ember Data／HTMLBars 这一家子共同组成了第一个可以和 Rails 相提并论的生态环境。

部署方面其实很简单，也不需要什么特定的 web server，Nginx／Apache 就行了，单纯的前端项目好处就是你可以完全视作 Static Resource 来处理。

优势是什么，其实很好理解，首先前后分离了，各管一片，怎么看也是更干净／清爽／低耦合高内聚吧？多方便管理啊。这一点无论是开发／测试／部署任何一个阶段都受益。特别是用到 vagrant／docker 等技术栈的团队，这种架构也能分离出更细的粒度便于管理维护调度。

第二，职责明晰了，负责 API 的就负责 API，负责 UX/UI／交互 的那就是负责这些，代码无论是逻辑层面还是实体层面都不掺乎，只通过 HTTP（或其他）来通讯交换数据。万一有一方做得不好，你想彻底替换也很容易，完全不影响另一端。而且单一的一端也可以同时服务于多个另一端，只要你们制定相互兼容的数据格式和协议就好。

还有些别的好处我就懒得细细说了，最近特别不想打字，已经有点要怒了……

补充最后几句，我之前说的都是从最简单的模型来讲前后分离，其实还有更复杂的，比如阿里系折腾的分离式“大／小”前端，当然他们有他们的应用场景完全可以理解。我个人觉得别一开始想太多了，但是也不要小看前端工程，它一点也不比后端工程更简单，而且以后会越来越复杂。

补充：现有的项目要拆，可以。但是前端这块儿得有一个能 hold 住的人，也就是进来流行的“前端架构师”这样的角色，最起码的，你要用 Ember，他得能把 Ember 的一整套生态系统玩转了，否则因为前端领域还在一个探索阶段，坑是不会少的，没有这样一个人的话，会耽误很多事儿，而且也会给未来埋下隐患。靠谱的前端工程师为啥难找？缺！