再次...选择框架。我已经停在这两个 TowerJS 和 RailwayJS 上，但是它们接缝非常相似，很难选择哪种方式
两者都是基于 Express 的，都是 RoR 风格的框架...
哪个最有前途，哪个会更受欢迎？
或者也许我已经走错路了？也许我应该选择其他框架。
我讨厌有这么多框架可供选择，没有可以依赖的行业标准，或多或少地确定框架将在近几年内开发......
请帮忙，需要专家建议。谢谢
【问题讨论】：
标签： node.js frameworks express railway.js towerjs
选择一个框架取决于你对它的舒适程度..通常基于..
项目的活跃程度如何？最后一次提交是什么时候？如果它不在 github 上，那对我来说是一个直接的问题，因为这会使用户的贡献变得更加困难。
我可以在框架上找到多少篇博文？如果没有人谈论它，这通常是一个不好的迹象，因为人们自然会谈论让他们兴奋的事情。
我如何看待这个框架？这可能更难判断，但应该有足够的例子，你至少可以得到一个基本的想法。如果没有，那么这本身就是一个大问题。
Erm.. 当然，显而易见的问题是如果您想要一个 RoR 框架.. 为什么不直接使用 RoR？ ;)
【讨论】：
看起来 TowerJS 与 MongoDB 作为其数据存储的耦合更紧密，而 RailwayJS 似乎具有模型适配器的灵活性。这可能会影响您在两者之间的选择。我个人会选择使用 RoR 编写 Rails 站点。 Node 似乎更适合不同类型的服务，你不觉得吗？ （我正在考虑使用 AJAX REST 服务在客户端中使用 Backbone）。
【讨论】：
这里有一个简短的表格来概述，我将在下面讨论一些内容。
+------------------------+-------------- -----+------------------------------------+ | |铁路JS | Tower.js | +------------------------+-------------- -----+------------------------------------+ |第一次提交 | 2011 年 1 月 | 2011 年 10 月 | |导轨 | 2.3.x | 3.x | | Node.js | >= 0.4.x | >= 0.4.x | |服务器 | ✓ | ✓ | |客户 | | ✓ | |模板不可知 | ✓ | ✓ | |默认引擎 | EJS |咖啡杯 | |数据库不可知 | ✓ | ✓ | |默认数据存储 | MongoDB | MongoDB | |模型验证 | validatesPresenceOf('email') |验证（'电子邮件'，存在：真）| |查询范围 | ✓ | ✓ | |可链接范围 | | ✓ | |参数解析 | | ✓ | |控制器 | ✓ | ✓ | |资源控制器 | | ✓ | |文件命名 | users_controller.js | usersController.coffee | | vm.runInCustomContext | ✓ | | |资产管道 | | ✓ | |资产压缩 | | ✓ | |路由 | map.resources('帖子') | @resources '帖子' | |嵌套路由 | ✓ | ✓ | |生成的 url 助手 | ✓ | | |发电机 | ✓ | ✓ | |命令行 API | ✓ | ✓ | | REPL（控制台）| ✓ | ✓ | | CoffeeScript 控制台 | | ✓ | |资产缓存方法 |时间戳 | md5 哈希 | |生产资产路径 | /app.css?123123123 | /app-859c828c89288hc8918741.css | |首选语言 | JavaScript |咖啡脚本 | | CoffeeScript 支持 | ✓ | ✓ | |国际化 | ✓ | ✓ | | Heroku 支持 | ✓ | ✓ | |字符串大小写 |蛇盒 |骆驼箱 | |表单生成器 | ✓ | ✓ | |语义表单生成器 | | ✓ | |表制造商 | | ✓ | |文件观察 API | | ✓ | |实时重新加载资产 | | ✓ | |测试套件 | | ✓ | |测试生成器 | | ✓ | |推特引导 | ✓ | ✓ | | HTML5 样板 | | ✓ | +------------------------+-------------- -----+------------------------------------+我创建 Tower.js 是为了实现几个现有框架都无法实现的目标。以下是其中的一些目标。
由于 Node.js 使 JavaScript 在服务器上成为可能，没有理由在 Rails 中编写应用程序的一部分，而在 Backbone 中编写另一部分。那不过是干的。您应该能够定义一次模型并在客户端和服务器上使用它们。
RailwayJS 只能在服务器上运行，因为它是围绕 express 构建的。 Tower.js 也是围绕 express 构建的，但在某种程度上使其适用于客户端和服务器。 Tower.js 为客户端和服务器提供了完全相同的 API。这意味着我必须重写路由器之类的东西，以便它在客户端和服务器上的工作方式相同（此外，它允许您使用相同的路由集使用# 后备执行history.pushState 之类的事情）。
我花了很多时间在 Rails 和编写 Haml 模板。除此之外，我还使用 Mustache 等模板语言编写 Web 和移动 JavaScript 界面。那是更多的代码重复......您应该能够在客户端（作为 JavaScript 模板）和服务器（呈现静态 HTML）上使用相同的视图/模板集。
由于 Haml 非常棒（超级干净，允许您执行任意 ruby，内置漂亮打印等），最接近的 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 带有“可链接范围”，即核心查询 + 分页。它是在 MongoDB Query API 之后建模的，但是这个 API“输入”被转换为不同数据存储的适当数据库命令。
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 中，您可以告诉控制器监视 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 中，但我希望它是。
我非常喜欢语义 HTML。 Rails 的表单生成器生成非常丑陋的 HTML，所以很多人和我自己都使用了Formtastic，它会生成更多语义表单。 Tower.js 使用与 Formtastic 几乎相同的 API。它还有一个语义表构建器，可以很容易地为管理员视图构建可搜索/可排序的表。
Rails 3 有一个很棒的资产管道，您可以在其中用 CoffeeScript 编写 JavaScript，在 SCSS 中编写 CSS，它会自动重新编译。然后rake assets:precompile 您的资产，您将获得 md5-hashed gzipped 资产，为 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 也没有内置的资产编译管道（至少据我所知）。
Guard 在 Rails 中极大地提高了生产力。它允许您编写快速的“监视任务”，本质上类似于 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，并使用尽可能少的代码。尽管在最小化代码库的大小和编写清晰有趣/高效的代码之间存在权衡。仍在寻找两全其美的方法。
我肯定也会长期参与。这是我们公司的基础，也是我个人未来将建立的一切。我希望你可以在一天内推出一款设计精美、功能强大且高度优化的应用程序。
希望对您有所帮助。
【讨论】：
你关注Derbyjs了吗？这个虽然还不是测试版，但非常令人兴奋。它由一位前谷歌员工和everyauth 的作者创作。您将不得不用这个编写最少的客户端 javascript。查看摘自官方页面：
为什么不使用 Rails 和 Backbone？德比代表了一种新的 应用程序框架，我们认为目前将取代 Rails 和 Backbone 等流行的库。
为使用 Rails、Django 和其他语言编写的应用程序添加动态功能 服务器端框架往往会产生混乱。服务器代码 在 jQuery 选择器和回调时呈现各种初始状态 拼命尝试理解 DOM 和用户事件。添加 新功能通常涉及更改服务器和客户端代码， 经常使用不同的语言。
许多开发人员现在包含一个客户端 MVC 框架，例如 Backbone 更好地构建客户端代码。一些人已经开始使用声明式 模型视图绑定库，例如 Knockout 和 Angular，以减少 样板 DOM 操作和事件绑定。这些很棒 概念，并且添加一些结构肯定会改进客户端代码。 但是，它们仍然会导致重复渲染代码和手动 在日益复杂的服务器和客户端代码中同步更改 基地。不仅如此，这些部件中的每一个都必须手动接线 一起打包给客户。
Derby 从根本上简化了添加动态的过程 互动。它在服务器和浏览器中运行相同的代码，并且 自动同步数据。 Derby 负责模板渲染， 开箱即用的包装和模型视图绑定。由于所有功能 旨在协同工作，没有代码重复和胶水代码 需要。 Derby 为开发人员提供了一个在所有应用程序中都包含所有数据的未来 是实时的。
没有胶水代码的灵活性 Derby 消除了单调乏味 将服务器、服务器模板引擎、CSS 编译器连接在一起， 脚本打包器、压缩器、客户端 MVC 框架、客户端 JavaScript 库、客户端模板和/或绑定引擎、客户端历史 库、实时传输、ORM 和数据库。它消除了 在模型和视图之间保持状态同步的复杂性， 客户端和服务器、多个窗口、多个用户和模型和 数据库。
同时，它与其他人相处得很好。德比建立在 流行的库，包括 Node.js、Express、Socket.IO、Browserify、 Stylus、UglifyJS、MongoDB 和其他流行的数据库和 数据存储。这些库也可以直接使用。数据 同步层，Racer，可以单独使用。其他客户 库，例如 jQuery，以及来自 npm 工作的其他 Node.js 模块 和德比一样好。
当遵循默认的文件结构、模板、样式和 脚本会自动打包并包含在相应的 页。此外，可以通过动态 API 使用 Derby，如 上面的简单例子。
但它也附带以下免责声明
Derby 和 Racer 是 Alpha 版软件。虽然德比应该运作良好 足够用于原型设计和周末项目，它仍在进行中 重大发展。 API 可能会发生变化。
它还没有授权实现，并且充满了security issues，尽管它们将在未来几个月内得到处理。如果您可以等待几个月，这似乎是一个很有前途的框架。
【讨论】：