node.js - RailJS 与 TowerJS

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center为指导。




8年前关闭。




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

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

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

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

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

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

Answer 1

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

+-----------------------+------------------------------+------------------------------------+
|                       | 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     |                              | ✓                                  |
+-----------------------+------------------------------+------------------------------------+

I created Tower.js to achieve several goals which none of the existing frameworks did adequately. Here are some of those goals.

1. Same code on the client and server

Since Node.js made JavaScript possible on the server, there's no reason to be writing one part of the app in Rails, and the other in Backbone. That's anything but DRY. You should be able to define the models once and use them on both the client and the server.

RailwayJS only works on the server because it was built around express. Tower.js is also built around express but in a way that makes it work for both the client and server. Tower.js provides the same exact API for the client and server. This meant I had to rewrite some things like the router so it works the same on the client and the server (plus it allows you to do things like history.pushState with the # fallback, using the same set of routes).

2. Same "views" on the client and server

I spent a lot of time in Rails and writing Haml templates. Alongside I was writing web and mobile JavaScript interfaces using template languages like Mustache. That's more code duplication… You should be able to use the same set of views/templates on both the client (as JavaScript templates) and server (rendering static HTML).

Since Haml was pretty awesome (super clean, allowed you to execute arbitrary ruby, built in pretty-printing, etc.), the closest JavaScript alternative was CoffeeKup. And it works on both the client and server. CoffeeKup allows you to write templates with all the power of JavaScript, so you have no limitations. Building a FormBuilder in Mustache is either going to take a lot of work or a lot of code, or both.

Do note though, you're free to swap out template engines and use Jade, Mustache, Handlebars, etc. for the client or server. CoffeeKup is just a clean and powerful default.

3. Rails-quality model API on the client and server

ActiveModel (implemented by ActiveRecord for SQL and Mongoid for MongoDB for Rails) is a very thorough and well-tested API allowing developers to define and interact with data. It's both powerful and enjoyable. All of the previous (and current) JavaScript implementations were never close to as robust and well designed, and I didn't see anything happening in the near future.

If you can write this in 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 数据存储接口(interface)

Tower.js 目前拥有 MongoDB 和 Memory(浏览器内)存储，旨在为其余流行数据库(CouchDB、Neo4j、PostGreSQL、MySQL、SQLite、Cassandra 等)提供统一接口(interface)。

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

5.资源丰富的 Controller

inherited_resources Ruby gem 从我的 Rails Controller 中删除了大约 90% 的代码。它找出了一组用于实现 7 个基本 Controller 操作的约定。 Tower.js 包含这样的内容，因此默认情况下您不必在 Controller 中编写任何代码，它们仍然会以 JSON 和 HTML 进行响应。它还使您可以定义嵌套路由。

6. 自动 URL 到数据库查询解析器

在 Tower.js 中，您可以告诉 Controller 监视 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。它还具有语义表构建器，这使得为管理 View 构建可搜索/可排序的表变得非常容易。

8. Assets 管道

Rails 3 有一个很棒的 Assets 管道，你可以用 CoffeeScript 编写 JavaScript，用 SCSS 编写 CSS，它会自动重新编译。然后rake assets:precompile您的 Assets ，您将获得为 S3 准备的 md5 哈希压缩 Assets 。自己构建起来非常困难，而且我没有看到有人为 Node.js 做这方面的工作。

RailwayJS 使用 Rails 2 方法为 Assets 路径加上时间戳，所以不是这个 md5 哈希版本:

/stylesheets/application-51e687ad72175b5629f3b1538b65ea2c.css

你会得到这样的东西:

/stylesheets/application.css?1306993455524

由于几个重要原因，这是一个问题。 Rails Asset Pipeline Guide有细节，但最重要的是 S3 不识别时间戳，所以它正在读取/stylesheets/application.css，如果你设置了一个很远的 future Expires标题并且您更改了 CSS，之前访问过您网站的任何人都必须清除其缓存或强制刷新您的页面才能看到更新。

RailJS 也没有内置的 Assets 编译管道(至少据我所知)。

9.监视文件

Guard在 Rails 中是一个巨大的生产力助推器。它允许您编写快速的“监视任务”，本质上类似于 rake/cake 任务，这些任务在创建/更新/删除与模式匹配的文件时运行。

塔有这个内置(使用 design.io )。这实际上是告诉 CoffeeScript 和 Stylus Assets 编译成 JavaScript 和 CSS 的原因。但是您可以使用此功能做非常强大的事情，请参阅 https://github.com/guard/guard/wiki/List-of-available-Guards举些例子。

10. CoffeeScript

CoffeeScript 的忠实粉丝。

CoffeeScript 将您需要编写的 JavaScript 数量减少了一半(6,501 additions, 15,896 deletions 将整个 Node.js 库转换为 CoffeeScript)。它使编码变得更快、更容易。

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

小事

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

我也喜欢 super 干净的代码。在我考虑为一个项目做贡献之前，我通读了源代码......如果它非常困惑，我可能会重写它。

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

我也绝对是长期参与的。这是我们公司的基础，也是我个人将在 future 建立的一切。我想达到这样的程度，您可以在一天内推出一款设计精美、功能强大且高度优化的应用程序。

希望有帮助。