这里有一个简要的概述表，我将在下面讨论一些内容。

+-----------------------+------------------------------+------------------------------------+
|                       | RailwayJS                    | Tower.js                           |
+-----------------------+------------------------------+------------------------------------+
| First commit          | Jan 2011                     | Oct 2011                           |
| Rails                 | 2.3.x                        | 3.x                                |
| Node.js               | >= 0.4.x                     | >= 0.4.x                           |
| Server                | ✓                            | ✓                                  |
| Client                |                              | ✓                                  |
| Template agnostic     | ✓                            | ✓                                  |
| Default engine        | EJS                          | CoffeeKup                          |
| Database agnostic     | ✓                            | ✓                                  |
| Default datastore     | MongoDB                      | MongoDB                            |
| Model validations     | validatesPresenceOf('email') | validates('email', presence: true) |
| Query scopes          | ✓                            | ✓                                  |
| Chainable scopes      |                              | ✓                                  |
| Param parsing         |                              | ✓                                  |
| Controllers           | ✓                            | ✓                                  |
| Resource controllers  |                              | ✓                                  |
| File naming           | users_controller.js          | usersController.coffee             |
| vm.runInCustomContext | ✓                            |                                    |
| Asset pipeline        |                              | ✓                                  |
| Asset compression     |                              | ✓                                  |
| Routing               | map.resources('posts')       | @resources 'posts'                 |
| Nested routes         | ✓                            | ✓                                  |
| Generated url helpers | ✓                            |                                    |
| Generators            | ✓                            | ✓                                  |
| Command-line api      | ✓                            | ✓                                  |
| REPL (console)        | ✓                            | ✓                                  |
| CoffeeScript console  |                              | ✓                                  |
| Asset cache method    | timestamp                    | md5 hash                           |
| Production asset path | /app.css?123123123           | /app-859c828c89288hc8918741.css    |
| Preferred Language    | JavaScript                   | CoffeeScript                       |
| CoffeeScript support  | ✓                            | ✓                                  |
| Internationalization  | ✓                            | ✓                                  |
| Heroku support        | ✓                            | ✓                                  |
| String case           | snake_case                   | camelCase                          |
| Form builder          | ✓                            | ✓                                  |
| Semantic form builder |                              | ✓                                  |
| Table builer          |                              | ✓                                  |
| File watcher API      |                              | ✓                                  |
| Live-reload assets    |                              | ✓                                  |
| Test suite            |                              | ✓                                  |
| Generators for tests  |                              | ✓                                  |
| Twitter Bootstrap     | ✓                            | ✓                                  |
| HTML5 Boilerplate     |                              | ✓                                  |
+-----------------------+------------------------------+------------------------------------+

我创建Tower.js是为了实现现有框架都无法充分实现的几个目标。

1.客户端和服务器上的代码相同

既然Node.js让JavaScript在服务器上成为可能，就没有理由用Rails编写应用程序的一部分，而用Backbone编写另一部分。这绝不是干的。您应该能够定义模型一次，然后在客户端和服务器上使用它们。
RailwayJS只在服务器上工作，因为它是围绕express构建的。Tower.js也是围绕express构建的，但在某种程度上使它同时适用于客户端和服务器。Tower.js为客户端和服务器提供了完全相同的API。这意味着我必须重写一些东西，比如路由器，以便它在客户端和服务器上工作相同（另外，它还允许您使用相同的路由集，通过#回退来执行history.pushState之类的操作）。

2.客户端和服务器上的"视图"相同

我花了很多时间在Rails和Haml模板上。同时我还使用模板语言（如Mustache）编写Web和移动JavaScript界面。这是更多的代码重复......您应该能够在客户端（作为JavaScript模板）和服务器（呈现静态HTML）上使用相同的视图/模板集。
因为哈默尔很厉害（超级干净，允许你执行任意的ruby，内置漂亮的打印，等等），最接近的JavaScript替代品是CoffeeKup。它在客户端和服务器上都能工作。CoffeeKup允许你用JavaScript的所有功能编写模板，所以你没有任何限制。用Mustache构建一个FormBuilder要么需要大量的工作，要么需要大量的代码，或两者皆有。
不过请注意，你可以自由地替换模板引擎，在客户端或服务器上使用Jade、Mustache、Handlebars等，CoffeeKup只是一个干净而强大的默认引擎。

3.客户机和服务器上的Rails质量模型API

ActiveModel（由ActiveRecord for SQL和Mongoid for MongoDB for Rails实现）是一个非常全面且经过良好测试的API，允许开发人员定义数据并与数据交互。它既强大又令人愉快。所有以前（和当前）的JavaScript实现都从未像它那样健壮且设计良好，我也没有看到在不久的将来会发生什么变化。
如果你可以用Rails来写这个：

User.where(:email => /[a-z/).page(2).limit(20)

您应该能够在JavaScript中执行此操作：

App.User.where(email: /[a-z/).page(2).limit(20)

Tower.js带有"可链接的作用域"，即核心查询+分页，它模仿MongoDB Query API，但是这个API的"输入"被转换为不同数据存储区的相应数据库命令。

4. SQL和NoSQL数据存储的统一接口

Tower.js目前有一个MongoDB和Memory（浏览器内）存储，旨在为其他流行的数据库（CouchDB、Neo4j、PostGreSQL、MySQL、SQLite、Cassandra等）提供统一的接口。
RailwayJS似乎也通过JugglingDB实现了这一点，这看起来是一个良好的开端，但我选择不使用它，原因有以下几个：首先，它看起来是围绕Rails2.xAPI构建的（User.validatesUniquenessOf "email" vs. User.validates "email", presence: true）第二，它没有Rails3那样丰富的可链接查询第三，我希望能够快速地向代码库添加代码，由于我非常挑剔，我可能最终会重构整个东西来使用CoffeeScript，哈哈。我不想围绕它构建一个层，因为它也必须在客户端上工作，所以保持库架构尽可能最小是一个优先事项。

5.资源丰富的控制器

inherited_resources Ruby gem从我的Rails控制器中删除了大约90%的代码。它为实现7个基本的控制器动作制定了一组约定。Tower.js包含了类似的内容，所以默认情况下，你不必在控制器中编写任何代码，它们仍然会以JSON和HTML进行响应。它还使你可以定义嵌套路由。

6.自动URL到数据库查询解析器

在Tower.js中，您可以告诉控制器监视url中的特定参数，它会将这些参数转换为哈希值，以便应用于模型查询。

class App.UsersController extends App.ApplicationController
  @param "email"

  index: ->
    App.User.where(@criteria()).all (error, users) =>
      @respondTo (format) =>
        format.json => @render json: users
        format.html => @render "index", locals: {users}

给定一个类似于/users?email=abc&something=random的url，那么@criteria()会给你一个哈希值{email: /abc/}。
Rails中没有，但我希望它是。

7.语义形式

我非常喜欢语义HTML。Rails的表单生成器生成的HTML非常难看，所以很多人和我自己都使用Formtastic，它生成更多语义表单。Tower.js使用的API与Formstastic几乎相同。它也有一个语义表格生成器，这使得为管理视图构建可搜索/可排序的表格变得非常容易。

8.资产管道

Rails3有一个很棒的资产管道，你可以在CoffeeScript中编写JavaScript，在SCSS中编写CSS，然后它会自动重新编译。然后rake assets:precompile你的资产，你会得到md5散列的gzip资产，为S3做好准备。这很难自己构建，我没有看到任何人在Node.js上做这方面的工作。

RailwayJS使用Rails 2方法为资产路径添加时间戳，因此不使用以下md5散列版本：

/stylesheets/application-51e687ad72175b5629f3b1538b65ea2c.css

你会得到这样的结果：

/stylesheets/application.css?1306993455524

这个问题有几个重要的原因，Rails Asset Pipeline Guide有详细说明，但最大的问题是S3无法识别时间戳，所以它阅读/stylesheets/application. css，如果您设置了一个未来的Expires头文件，并且更改了CSS，那么之前访问过您网站的任何人都必须清除缓存或强制刷新页面才能看到更新。
RailwayJS也没有内置的资产编译管道（至少据我所知）。

9.监视文件

Guard是Rails中的一个巨大的生产力提升器，它允许您编写快速的“监视任务”，本质上类似于rake/cake任务，在创建/更新/删除与模式匹配的文件时运行。
Tower内置了这个功能（使用design.io）。这实际上是告诉CoffeeScript和Stylus资产编译成JavaScript和CSS的原因。但是你可以用这个功能做一些非常强大的事情，参见https://github.com/guard/guard/wiki/List-of-available-Guards的例子。
10.咖啡脚本
咖啡脚本的超级粉丝。
CoffeeScript将您需要编写的JavaScript代码量减少了一半（6,501 additions, 15,896 deletions将整个Node.js库转换为CoffeeScript），并且使编码变得更快更容易。
此外，CoffeeScript是保持Rails向世界展示的高效和愉快的编码体验的唯一方法，JavaScript不能做到这一点。

小事情

我是一个标准的爱好者。RailwayJS坚持Ruby使用snake_case的约定，我也想这么做，但是JavaScript社区使用camelCase，所以Tower选择了它。CamelCase还有一些额外的好处，比如你不需要为客户端转换服务器端Rails的snake_case和camelCase，并且删除额外的字符会让你的文件更小。
我也喜欢超级干净的代码，在我考虑为一个项目做贡献之前，我会通读源代码......如果它超级混乱，我可能会重写它。
我也喜欢优化代码。使用Tower.js，一个大目标是构建它，使它做Rails做的所有事情，在客户端和服务器端提供完全相同的API，使用尽可能少的代码。尽管在最小化代码库的大小和编写清晰、有趣/高效的代码之间有一个权衡。仍然在寻找方法来获得两个世界的最佳效果。
我肯定也是为了长远的目标。这是我们公司的基础，也是我个人未来要打造的一切。我希望能在一天之内推出一款设计精美、功能强大、高度优化的应用。

你有没有注意过Derbyjs？这个虽然还没有beta版，但已经相当令人兴奋了。它是由一位前google员工和everyauth的作者编写的。你必须用这个编写最小的客户端javascript。请看官方页面的摘录：
为什么不使用Rails和Backbone呢？Derby代表了一种新的应用程序框架，我们相信它将取代目前流行的库，如Rails和Backbone。
为Rails、Django和其他服务器端框架编写的应用添加动态特性往往会产生混乱。服务器代码呈现各种初始状态，而jQuery选择器和回调则拼命尝试理解DOM和用户事件。添加新特性通常涉及更改服务器和客户端代码，通常使用不同的语言。
许多开发人员现在都包含了一个客户端MVC框架，比如Backbone，来更好地构建客户端代码。一些开发人员已经开始使用声明性的模型-视图绑定库，比如Knockout和Angular，来减少样板DOM操作和事件绑定。这些都是很棒的概念，添加一些结构肯定会改进客户端代码。然而，但它们仍然导致复制呈现代码和手动同步日益复杂的服务器和客户机代码库中的变化。这些部件中的每一个必须手动地连接在一起并为客户打包。
Derby从根本上简化了添加动态交互的过程。它在服务器和浏览器中运行相同的代码，并自动同步数据。Derby可以处理模板呈现、打包和模型视图绑定。由于所有功能都是为了协同工作而设计的，因此不需要代码重复和粘合代码。Derby为开发人员提供了装备，使他们能够在未来所有应用程序中的所有数据都是实时的。
没有粘合代码的灵活性Derby消除了将服务器、服务器模板引擎、CSS编译器、脚本打包器、小型化器、客户机MVC框架、客户机JavaScript库、客户机模板和/或绑定引擎、客户机历史库、实时传输、ORM和数据库连接在一起的繁琐工作，并消除了在模型和视图、客户机和服务器、多个窗口、多个用户、模型和数据库。
同时，它也能很好地与其他人合作。Derby构建在流行库之上，包括Node.js、Express、Socket.IO、Browserify、Stylus、UglifyJS、MongoDB，以及很快其他流行的数据库和数据存储。这些库也可以直接使用。数据同步层Racer可以单独使用。其他客户端库，如jQuery、和npm中的其他Node.js模块与Derby沿着工作得很好。
当遵循默认的文件结构时，模板、样式和脚本会自动打包并包含在相应的页面中。此外，Derby可以通过动态API使用，如上面的简单示例所示。
但它也附带以下免责声明
Derby和Racer都是alpha软件。虽然Derby对于原型和周末项目应该足够好用，但它仍在进行重大开发。API可能会发生变化。
它还没有一个授权实现，并且充满了security issues，尽管它们将在未来几个月内得到解决，如果你能等上几个月，这似乎是一个有前途的框架。

选择一个框架取决于您对它的熟悉程度。通常基于。

• 这个项目有多活跃？最后一次提交是什么时候？如果它不在github上，这对我来说是一个直接的问题，因为这会让用户更难做出贡献。
• 我能在这个框架上找到多少博客文章？如果没有人谈论它，这通常是一个坏兆头，因为人们自然会谈论令他们兴奋的事情。
• 我对这个框架有什么看法？这可能很难判断，但应该有足够的例子，至少你可以得到一个基本的想法。如果没有，那么这本身就是一个大问题。

呃...当然，明显的问题是如果你想要一个RoR框架...为什么不直接使用RoR？）

看起来TowerJS与MongoDB的数据存储耦合得更紧密，而RailwayJS似乎具有模型适配器的灵活性。这可能会影响您在两者之间的选择。就我个人而言，我会选择使用RoR编写Rails站点。Node似乎更适合不同类型的服务，您不认为吗？（我认为客户端中的Backbone具有 AJAX REST服务）。