这是概述的简要表，下面我将讨论一些东西。
+ ----------------------- + ------------------------- ----- + ------------------------------------ +| | 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，然后它会自动重新编译。然后，
rakeassets: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。但是，在最小化代码库大小和编写清晰，有趣/易于使用的代码之间需要权衡。仍在寻找兼顾两全其美的方法。
对于长途旅行，我绝对也是。这是我们公司的基础，也是我个人将来将建设的一切。我想说的是，您一天之内就可以推出设计精美，功能强大且高度优化的应用程序。
希望有帮助。
