这是概述的简要表，下面我将讨论一些东西。

+ ----------------------- + ------------------------- ----- + ------------------------------------ +
| | RailwayJS | Tower.js |
+ ----------------------- + ------------------------- ----- + ------------------------------------ +
| 首次提交| 2011年1月| 2011年10月|
| 滑轨| 2.3.x | 3.x |
| Node.js | > = 0.4.x | > = 0.4.x |
| 服务器| ✓| ✓|
| 客户| | ✓|
| 不可知模板 ✓| ✓|
| 默认引擎| EJS | CoffeeKup |
| 数据库不可知| ✓| ✓|
| 默认数据存储| MongoDB | MongoDB |
| 模型验证| validatesPresenceOf（'email'）| validates（'email'，在线状态：true）|
| 查询范围| ✓| ✓|
| 可链接范围| | ✓|
| 参数解析| | ✓|
| 控制器| ✓| ✓|
| 资源控制器| | ✓|
| 文件命名| users_controller.js | usersController.coffee |
| vm.runInCustomContext | ✓| |
| 资产管道| | ✓|
| 资产压缩| | ✓|
| 路由| map.resources（'posts'）| @resources'帖子'|
| 嵌套路线| ✓| ✓|
| 生成的URL帮助器| ✓| |
| 发电机| ✓| ✓|
| 命令行API | ✓| ✓|
| REPL（控制台）| ✓| ✓|
| CoffeeScript控制台| | ✓|
| 资产缓存方法| 时间戳| md5哈希|
| 生产资产路径| /app.css?123123123 | /app-859c828c89288hc8918741.css |
| 首选语言| JavaScript | CoffeeScript |
| CoffeeScript支持| ✓| ✓|
| 国际化| ✓| ✓|
| Heroku支持| ✓| ✓|
| 弦盒| snake_case | camelCase |
| 表单生成器| ✓| ✓|
| 语义表单生成器| | ✓|
| 桌布| | ✓|
| 文件监视程序API | | ✓|
| 实时充值资产| | ✓|
| 测试套件 | ✓|
| 测试发电机| | ✓|
| Twitter引导程序| ✓| ✓|
| HTML5样板 | ✓|
+ ----------------------- + ------------------------- ----- + ------------------------------------ +

我创建了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）上使用相同的视图/模板集。

由于Haml非常出色（超级干净，可让您执行任意的ruby，内置漂亮的打印等），因此最接近JavaScript的替代方法是CoffeeKup。它在客户端和服务器上都可以工作。CoffeeKup允许您使用JavaScript的所有功能编写模板，因此没有任何限制。在Mustache中构建FormBuilder要么需要大量工作，要么需要大量代码，或者两者兼而有之。

不过请注意，您可以自由地交换模板引擎，并将Jade，Mustache，Handlebars等用于客户端或服务器。CoffeeKup只是一个干净而强大的默认设置。

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

ActiveModel（由用于SQL的ActiveRecord和由用于MongoDB的Rails的Mongoid实现）是一种非常透彻且经过测试的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和内存（浏览器）存储，并旨在为其余流行数据库（CouchDB，Neo4j，PostGreSQL，MySQL，SQLite，Cassandra等）提供统一的接口。

RailwayJS似乎也通过JugglingDB做到了这一点，这似乎是一个不错的开始。但是出于某些原因，我选择不使用它。首先，它似乎是围绕Rails 2.x
API构建的（User.validatesUniquenessOf "email"vs. User.validates "email", presence: true）。其次，它没有Rails
3所具有的可链接查询的丰富性。第三，我希望能够将代码快速添加到代码库中，并且由于我非常挑剔，所以我可能最终会使用咖啡脚本来重构整个东西，哈哈。而且我不想围绕它建立一层，因为它也必须在客户端上工作，因此，将库体系结构保持在最小限度是一个高度优先事项。

5.足智多谋的控制器

该inherited_resources红宝石宝石切割出大约从我的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，然后@criteria()会给你一个哈希值{email: /abc/}。

它不在Rails中，但我希望是。

7.语义形式

我非常喜欢语义HTML。Rails的表单生成器生成非常难看的HTML，因此许多人以及我本人都使用Formtastic，后者生成了更多的语义表单。Tower.js使用与Formtastic几乎相同的API。它还具有语义表构建器，这使得为管理员视图构建可搜索/可排序的表变得非常容易。

8.资产管道

Rails
3有一个很棒的资产管道，您可以在其中用CoffeeScript编写JavaScript，在SCSS中编写CSS，然后它会自动重新编译。然后，rake assets:precompile您的资产就会准备好md5散列的压缩资产以供S3使用。要自己建立起来非常困难，而且我没有看到有人为Node.js进行这项工作。

RailwayJS使用时间戳记资产路径的Rails 2方法，因此代替此md5哈希版本：

/stylesheets/application-51e687ad72175b5629f3b1538b65ea2c.css

你会得到这样的东西：

/stylesheets/application.css?1306993455524

这是一个有几个重要原因的问题。《Rails资产管道指南》提供了详细信息，但是重要的是S3无法识别时间戳，因此它正在读取/stylesheets/application.css，并且如果您设置了远距离的Expires标头并且您更改了CSS，谁曾经访问过您的网站，则必须清除其缓存或强制刷新您的页面以查看更新。

RailwayJS也没有内置的资产编译管道（至少据我所知）。

9.监视文件

Guard在Rails中极大地提高了生产力。它允许您编写快速的“监视任务”，本质上类似于耙/蛋糕任务，该任务在创建/更新/删除与模式匹配的文件时运行。

塔具有内置功能（使用design.io）。这实际上是在告诉CoffeeScript和Stylus资产编译为JavaScript和CSS。但是您可以使用此功能执行非常强大的功能，有关示例，请参见https://github.com/guard/guard/wiki/List-
of-available-Guards。

10. CoffeeScript

CoffeeScript的忠实粉丝。

CoffeeScript将您需要编写的JavaScript数量减少了一半（增加了6,501个，删除了15,896个，将整个Node.js库转换为CoffeeScript）。而且它使编码更快，更容易。

而且，CoffeeScript是保持Rails向全世界展示的高效，愉快的编码体验的唯一方法。JavaScript只是不这样做。

小事

我是标准迷。RailwayJS坚持使用snake_case的Ruby约定，我也想这样做，但是JavaScript社区使用camelCase，因此Tower做到了。CamelCase还具有其他一些优点，例如，您不需要为客户端将服务器端Rails
snake_case转换为camelCase，也可以删除多余的字符，从而使文件大小更小。

我也爱上了超级干净的代码。在考虑为一个项目做贡献之前，我会仔细阅读源代码…如果它太乱了，我可能只会重写它。

我也喜欢优化代码。使用Tower.js，一个重要的目标是对其进行结构化，使其能够完成Rails所做的一切，并使用尽可能少的代码在客户端和服务器中提供完全相同的API。但是，在最小化代码库大小和编写清晰，有趣/易于使用的代码之间需要权衡。仍在寻找兼顾两全其美的方法。

对于长途旅行，我绝对也是。这是我们公司的基础，也是我个人将来将建设的一切。我想说的是，您一天之内就可以推出设计精美，功能强大且高度优化的应用程序。

希望有帮助。