再次......选择框架。我已停止使用这两个TowerJS和RailwayJS，但它们的接缝非常相似，选择哪种方式非常困难
两者都基于Express，都是RoR风格的框架......
哪一个最有前途，哪一个会更受欢迎？
或者我可能已经走错了路？也许我应该选择其他框架。
我讨厌有太多的框架可供选择，没有行业标准可以依赖，或多或少地确定框架将在近几年内开发......
请帮助，需要专家建议。感谢
答案 0 :(得分：153)
这是一个简要的概述表，我将在下面讨论一些内容。
+-----------------------+------------------------------+------------------------------------+
| | 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以实现几个目标，现有框架都没有充分实现。以下是其中一些目标。
由于Node.js可以在服务器上实现JavaScript，因此没有理由在Rails中编写应用程序的一部分，而在Backbone中编写另一部分。除了DRY之外什么都不是。您应该能够定义一次模型并在客户端和服务器上使用它们。
RailwayJS仅适用于服务器，因为它是围绕express构建的。 Tower.js也是围绕express构建的，但它的方式使它适用于客户端和服务器。 Tower.js为客户端和服务器提供了完全相同的API。这意味着我必须重写一些像路由器这样的东西，所以它在客户端和服务器上的工作方式相同（加上它允许你使用history.pushState后备来执行#之类的操作，使用相同的一组路由）。
我在Rails上花了很多时间并编写了Haml模板。我还在使用像Mustache这样的模板语言编写Web和移动JavaScript界面。那更多的代码重复......您应该能够在客户端（作为JavaScript模板）和服务器（呈现静态HTML）上使用相同的视图/模板集。
由于Haml非常棒（超级干净，允许你执行任意红宝石，内置漂亮打印等），最接近的JavaScript替代方案是CoffeeKup。它适用于客户端和服务器。 CoffeeKup允许您使用JavaScript的所有功能编写模板，因此您没有任何限制。在Mustache中构建FormBuilder要么需要大量工作，要么需要大量代码，或者两者兼而有之。
请注意，您可以自由地换出模板引擎并为客户端或服务器使用Jade，Mustache，Handlebars等。 CoffeeKup只是一个干净而强大的默认设置。
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带有＆＃34;可链接范围＆＃34;，意思是核心查询+分页。它以MongoDB Query API为模型，但此API＆＃34;输入＆＃34;转换为适用于不同数据存储的数据库命令。
Tower.js目前有一个MongoDB和Memory（浏览器内）商店，旨在为其他流行数据库（CouchDB，Neo4j，PostGreSQL，MySQL，SQLite，Cassandra等）提供统一的界面。
RailwayJS似乎也是通过JugglingDB这样做的，它看起来是一个好的开始。但我选择不使用它有几个原因。首先，看起来它是围绕Rails 2.x API（User.validatesUniquenessOf "email"与User.validates "email", presence: true）构建的。其次，它没有Rails 3所具有的可链接查询的丰富性。第三，我希望能够快速地将代码添加到代码库中，因为我非常挑剔，我可能最终会重构整个使用CoffeeScript的东西，哈哈。我并不想围绕它构建一个层，因为它必须在客户端上工作，因此保持库架构尽可能小是优先考虑的事项。
inherited_resources Ruby gem从我的Rails控制器中删除了大约90％的代码。它找出了一组用于实现7个基本控制器操作的约定。 Tower.js包含这样的内容，因此默认情况下，您不必在控制器中编写任何代码，他们仍然会使用JSON和HTML进行响应。它还使您可以定义嵌套路由。
在Tower.js中，您可以告诉控制器监视网址中的特定参数，并将它们转换为准备好应用于模型查询的哈希。
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中，但我希望它是。
我超级语义HTML。轨道＆＃39;表单生成器生成相当丑陋的HTML，所以很多人和我一起使用Formtastic，它生成更多的语义形式。 Tower.js使用与Formtastic几乎相同的API。它还有一个语义表构建器，可以很容易地为管理视图构建可搜索/可排序的表。
Rails 3有一个很棒的资产管道，您可以在CoffeeScript中编写JavaScript，在SCSS中编写CSS，它会自动重新编译。然后rake assets:precompile您的资产，您就可以为S3准备md5-hashed gzipped资产了。这很难自己构建，我也没有看到有人为Node.js做过这样的工作。
RailwayJS使用Rails 2方法为资产路径添加时间戳，因此不使用此md5-hashed版本：
/stylesheets/application-51e687ad72175b5629f3b1538b65ea2c.css
你得到这样的东西：
/stylesheets/application.css?1306993455524
这是一个问题，原因有几个。 Rails Asset Pipeline Guide有详细信息，但最重要的是S3无法识别时间戳，因此它正在阅读/stylesheets/application.css，如果设置了远期{{1}标题已经更改了您的CSS，之前访问过您网站的任何人都必须清除其缓存或强制刷新您的网页以查看更新。
RailwayJS也没有内置的资产编制管道（至少据我所知）。
Guard在Rails中是一个巨大的生产力助推器。它允许您编写快速＆＃34;监视任务＆＃34;，基本上像rake / cake任务，当创建/更新/删除匹配模式的文件时运行。
Tower内置此功能（使用design.io）。这实际上是告诉CoffeeScript和Stylus资产编译成JavaScript和CSS的原因。但是您可以使用此功能执行非常强大的功能，请参阅https://github.com/guard/guard/wiki/List-of-available-Guards示例。
CoffeeScript的忠实粉丝。
CoffeeScript将您需要编写的JavaScript数量减少一半（6,501 additions, 15,896 deletions将整个Node.js库转换为CoffeeScript）。它使编码更快更容易。
此外，CoffeeScript是保持Rails向世界展示的高效和愉快编码体验的唯一方法。 JavaScript只是不这样做。
我是标准的粉丝。 RailwayJS坚持使用snake_case的Ruby惯例，我也想这样做，但JavaScript社区使用camelCase，所以Tower继续使用它。 CamelCase还有一些额外的好处，例如你不需要将服务器端的Rails snake_case转换为来自camelCase的客户端，并且删除那个额外的字符会给你一个更小的文件大小。
我也爱上了超级干净的代码。在我考虑为项目做贡献之前，我先阅读了源代码......如果它非常凌乱，我可能只是想重写它。
我也喜欢优化代码。使用Tower.js，一个很大的目标是构建它，以便它完成Rails所做的一切，在客户端和服务器中提供完全相同的API，使用尽可能少的代码。虽然在最小化代码库的大小和编写清晰，有趣/高效的代码之间进行权衡。仍然想方设法让两全其美。
我也绝对会在这方面长途跋涉。这是我们公司的基础，也是我个人将来建立的一切。我希望能够在一天内推出设计精美，功能强大且经过高度优化的应用程序。
希望有所帮助。
答案 1 :(得分：5)
您是否关注Derbyjs？这个虽然尚未测试，但非常令人兴奋。它由前Google员工和everyauth的作者撰写。你将不得不用这个编写最小的客户端javascript。请参阅官方页面摘录：
为什么不使用Rails和Backbone？德比代表着一种新的品种 应用程序框架，我们认为目前将取而代之 流行的图书馆，如Rails和Backbone。
为使用Rails，Django等编写的应用程序添加动态功能 服务器端框架往往会产生纠结的混乱。服务器代码 在jQuery选择器和回调时呈现各种初始状态 拼命尝试理解DOM和用户事件。添加 新功能通常涉及更改服务器和客户端代码， 通常用不同的语言。
许多开发人员现在都包含一个像Backbone一样的客户端MVC框架 更好的结构客户端代码一些人已经开始使用声明式 模型视图绑定库，如Knockout和Angular，以减少 样板DOM操作和事件绑定。这些都很棒 概念，并添加一些结构肯定会改善客户端代码。 但是，它们仍然会导致重复渲染代码并手动复制 同步日益复杂的服务器和客户端代码中的更改 基地。不仅如此，每个部件都必须手动连接 一起为客户打包。
Derby从根本上简化了添加动态的过程 互动。它在服务器和浏览器中运行相同的代码 自动同步数据。 Derby负责模板渲染， 包装和模型视图绑定开箱即用。由于所有功能 旨在协同工作，没有代码重复和胶水代码 需要。德比为所有应用程序中的所有数据的未来配备了开发人员 是实时的。
没有胶水代码的灵活性德比消除了单调乏味 连接服务器，服务器模板引擎，CSS编译器， 脚本打包器，minifier，客户端MVC框架，客户端JavaScript 库，客户端模板和/或绑定引擎，客户端历史记录 库，实时传输，ORM和数据库。它消灭了 保持状态在模型和视图之间同步的复杂性， 客户端和服务器，多个窗口，多个用户以及模型和 数据库。
与此同时，它与其他人合作得很好。德比建立在之上 流行的库，包括Node.js，Express，Socket.IO，Browserify， Stylus，UglifyJS，MongoDB，以及很快其他流行的数据库和 数据存储。这些库也可以直接使用。数据 同步层，Racer，可以单独使用。其他客户 来自npm的库，例如jQuery和其他Node.js模块 和德比一样。
遵循默认文件结构，模板，样式和 脚本会自动打包并包含在相应的脚本中 页面。此外，Derby可以通过动态API使用，如图所示 上面的简单例子。
但它也附带以下免责声明
Derby和Racer是alpha软件。虽然德比应该运作良好 足以进行原型设计和周末项目，它仍在进行中 重大发展。 API可能会发生变化。
它还没有授权实施，并且充满了security issues，尽管它们将在未来几个月内得到处理。如果你可以等几个月，这似乎是一个很有前途的框架。
答案 2 :(得分：3)
选择一个框架可以达到你的舒适度......通常基于..
项目有多活跃？最后一次提交是什么时候？如果它不在github上，那对我来说是一个直接关注，因为这会让用户贡献更多。
我可以在框架上找到多少篇博文？如果没有人在谈论它，那通常是一个不好的迹象，因为人们自然而然地谈论激励他们的事情。
我对框架的看法是什么？这可能更难判断，但应该有足够的例子，你至少可以得到一个基本的想法。如果没有，那么这本身就是一个大问题。
答案 3 :(得分：3)
看起来TowerJS与MongoDB紧密耦合作为其数据存储，而RailwayJS似乎具有模型适配器灵活性。这可能会影响您在两者之间的选择。我个人选择使用RoR编写Rails站点。节点似乎更适合不同类型的服务，你不觉得吗？ （我在客户端使用AJAX REST服务思考Backbone。）