65

再次...选择框架。我已经停在这两个 TowerJS 和 RailwayJS 上，但是它们接缝非常相似，很难选择哪种方式

两者都基于 Express，都是 RoR 风格的框架......

哪一款最有前途，哪一款会更受欢迎？

或者也许我已经走错路了？也许我应该选择其他框架。

我讨厌有这么多框架可供选择，没有可以依赖的行业标准，或多或少地确定框架将在近几年内开发......

请帮助，需要专家建议。谢谢

4

4 回答 4

153

这是一个简短的表格来概述，我将在下面讨论一些内容。

+------------------------+-------------- -----+------------------------------------+
| | 铁路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 是为了实现几个现有框架都无法实现的目标。以下是其中一些目标。

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（由 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 做到了这一点，这看起来是一个好的开始。但出于几个原因，我选择不使用它。首先，它看起来是围绕 Rails 2.x API ( User.validatesUniquenessOf "email"vs. User.validates "email", presence: true) 构建的。其次，它没有 Rails 3 那样丰富的可链接查询。第三，我希望能够快速将代码添加到代码库中，由于我非常挑剔，我可能最终会重构整个东西以使用 CoffeeScript，哈哈。而且我不想围绕它构建一个层，因为它也必须在客户端上工作，所以保持库架构尽可能小是一个高优先级。

5. 资源丰富的控制器

inherit_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}

给定一个类似的 url /users?email=abc&something=random，然后@criteria()会给你一个 hash {email: /abc/}。

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

7.语义形式

我对语义 HTML 非常感兴趣。Rails 的表单构建器生成的 HTML 非常难看，所以很多人和我自己都使用了 Formtastic，它可以生成更多语义表单。Tower.js 使用与 Formtastic 几乎相同的 API。它还有一个语义表构建器，可以很容易地为管理视图构建可搜索/可排序的表。

8. 资产管道

Rails 3 有一个很棒的资产管道，你可以用 CoffeeScript 编写 JavaScript，用 SCSS 编写 CSS，它会自动重新编译。然后rake assets:precompile您的资产和您将获得 md5-hashed gzipped 资产准备好用于 S3。这很难让自己建立起来，而且我没有看到有人为 Node.js 做这件事。

RailwayJS 使用 Rails 2 方法为资产路径添加时间戳，所以不要使用这个 md5-hashed 版本：

/stylesheets/application-51e687ad72175b5629f3b1538b65ea2c.css

你会得到这样的东西：

/stylesheets/application.css?1306993455524

由于几个重要原因，这是一个问题。Rails 资产管道指南有详细信息，但重要的是 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 的忠实粉丝。

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

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

小事

我是标准的粉丝。RailwayJS 坚持使用snake_case 的Ruby 约定，我也想这样做，但是JavaScript 社区使用camelCase，所以Tower 也这样做了。CamelCase 还有一些额外的好处，例如您不需要为客户端将服务器端Rails snake_case 转换为camelCase 或从camelCase 转换，并且删除该额外字符可以使您的文件大小更小。

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

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

我肯定也会长期参与。这是我们公司的基础，也是我个人未来将建立的一切。我希望你可以在一天之内推出一款设计精美、功能强大且高度优化的应用程序。

希望有帮助。

于 2012-03-28T09:15:45.130 回答
5

你关注过德比吗？这个虽然还不是测试版，但非常令人兴奋。它由前谷歌员工和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 一样工作。

当遵循默认文件结构时，模板、样式和脚本会自动打包并包含在相应的页面中。此外，可以通过动态 API 使用 Derby，如上面的简单示例所示。

但它也附带以下免责声明

Derby 和 Racer 是 alpha 软件。虽然 Derby 对于原型设计和周末项目应该足够好，但它仍在进行重大开发。API 可能会发生变化。

它还没有授权实现，并且充满了安全问题，尽管它们将在未来几个月内得到解决。如果您可以等待几个月，这似乎是一个很有前途的框架。

于 2012-05-04T10:46:46.157 回答
3

选择一个框架取决于您对它的舒适程度..通常基于..

  • 项目有多活跃？最后一次提交是什么时候？如果它不在 github 上，那对我来说是一个直接的问题，因为这会使用户贡献变得更加困难。

  • 我可以在该框架上找到多少篇博文？如果没有人谈论它，那通常是一个不好的迹象，因为人们自然会谈论让他们兴奋的事情。

  • 我怎么看这个框架？这可能更难判断，但应该有足够的例子，你至少可以得到一个基本的想法。如果没有，那么这本身就是一个大问题。

Erm.. 当然，显而易见的问题是如果您想要一个 RoR 框架.. 为什么不直接使用 RoR？;)

于 2012-03-27T21:17:54.660 回答
3

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

于 2012-03-28T04:18:44.503 回答