node.js RailJS 与 TowerJS
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/9897017/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
RailwayJS vs TowerJS
提问by kingpin
Again... selecting framework. I have stopped on these two TowerJS and RailwayJS, but it seams these are very similar and it is very difficult which way to choose
再次...选择框架。我已经停在这两个 TowerJS 和 RailwayJS 上，但它们看起来非常相似，很难选择哪种方式
Both are based on Express, both are RoR style frameworks...
两者都基于 Express，两者都是 RoR 风格的框架......
Which one is the most promising, which one will be more popular?
哪一款最有前途，哪一款会更受欢迎？
Or maybe I'm already on the wrong way? Maybe I should choose other framework.
或者也许我已经走错路了？也许我应该选择其他框架。
I hate when there is so much frameworks to choose from, there is no industry standard to rely on, to be more or less sure that the framework will be developed in near couple years...
我讨厌有这么多框架可供选择，没有可以依赖的行业标准，或多或少地确定该框架将在近两年内开发出来......
Please help, need expert suggestion. Thanks
请帮助，需要专家的建议。谢谢
回答by Lance Pollard
Here's a brief table to overview, I'll talk about some of the stuff below.
这是一个简要的概述表，我将在下面讨论一些内容。
+-----------------------+------------------------------+------------------------------------+
| | 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.
我创建 Tower.js 是为了实现现有框架都没有充分实现的几个目标。以下是其中一些目标。
1. Same code on the client and server
1.客户端和服务器上的代码相同
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.
由于 Node.js 使 JavaScript 在服务器上成为可能，因此没有理由在 Rails 中编写应用程序的一部分，而在 Backbone 中编写另一部分。那不过是DRY。您应该能够定义一次模型并在客户端和服务器上使用它们。
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.pushStatewith the #fallback, using the same set of routes).
RailJS 仅适用于服务器，因为它是围绕 express 构建的。Tower.js 也是围绕 express 构建的，但其方式使其适用于客户端和服务器。Tower.js 为客户端和服务器提供完全相同的 API。这意味着我必须重写一些东西，比如路由器，这样它在客户端和服务器上的工作方式是一样的（另外，它允许你使用相同的路由集来做回退之类history.pushState的事情#）。
2. Same "views" on the client and server
2. 客户端和服务器上的“视图”相同
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).
我花了很多时间在 Rails 和编写 Haml 模板。除此之外，我还在使用 Mustache 等模板语言编写 Web 和移动 JavaScript 界面。这是更多的代码重复……您应该能够在客户端（作为 JavaScript 模板）和服务器（呈现静态 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.
由于 Haml 非常棒（超级干净，允许你执行任意 ruby，内置漂亮打印等），最接近的 JavaScript 替代品是CoffeeKup。它适用于客户端和服务器。CoffeeKup 允许您使用 JavaScript 的所有功能编写模板，因此您没有任何限制。在 Mustache 中构建 FormBuilder 要么需要大量工作，要么需要大量代码，或者两者兼而有之。
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.
但请注意，您可以随意更换模板引擎，并为客户端或服务器使用 Jade、Mustache、Handlebars 等。CoffeeKup 只是一个干净而强大的默认设置。
3. Rails-quality model API on the client and server
3. 客户端和服务器上的 Rails 质量模型 API
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.
ActiveModel（由 ActiveRecord for SQL 和 Mongoid for MongoDB for Rails 实现）是一个非常全面且经过良好测试的 API，允许开发人员定义数据并与数据交互。它既强大又令人愉快。所有以前（和当前）的 JavaScript 实现都从未如此健壮和设计良好，而且我没有看到在不久的将来会发生任何事情。
If you can write this in Rails:
如果你可以用 Rails 写这个：
User.where(:email => /[a-z/).page(2).limit(20)
You should be able to do that in JavaScript:
你应该能够在 JavaScript 中做到这一点：
App.User.where(email: /[a-z/).page(2).limit(20)
Tower.js comes with "chainable scopes", meaning hardcore queries + pagination. It's modeled after the MongoDB Query API, but this API "input" is converted to appropriate database commands for the different datastores.
Tower.js 带有“可链式作用域”，意思是核心查询 + 分页。它以MongoDB 查询 API为模型，但此 API“输入”被转换为适用于不同数据存储的数据库命令。
4. Uniform interface to the SQL and NoSQL datastores
4. 统一的 SQL 和 NoSQL 数据存储接口
Tower.js currently has a MongoDB and Memory (in-browser) store, and aims to provide a uniform interface to the rest of the popular databases (CouchDB, Neo4j, PostGreSQL, MySQL, SQLite, Cassandra, etc.).
Tower.js 目前拥有 MongoDB 和内存（浏览器内）存储，旨在为其余流行数据库（CouchDB、Neo4j、PostGreSQL、MySQL、SQLite、Cassandra 等）提供统一接口。
RailwayJS seems to be doing this as well via JugglingDB, and it looks like a good start. But I choose not to use it for a few reasons. First, it looks like it's is being built around the Rails 2.x API (User.validatesUniquenessOf "email"vs. User.validates "email", presence: true). Second, it doesn't have the richness of chainable queries that Rails 3 does. Third, I want to be able to add code to the codebase quickly, and since I'm very picky I would probably end up refactoring the whole thing to use CoffeeScript, haha. And I don't want to build a layer around that because it has to work on the client as well, so keeping the library architecture as minimal as possible is a high priority.
RailJS 似乎也通过 JugglingDB 做到了这一点，这看起来是一个好的开始。但我选择不使用它有几个原因。首先，它看起来是围绕 Rails 2.x API 构建的（User.validatesUniquenessOf "email"vs. User.validates "email", presence: true）。其次，它没有 Rails 3 那样丰富的可链接查询。第三，我希望能够快速地将代码添加到代码库中，而且由于我非常挑剔，我可能最终会重构整个事情以使用 CoffeeScript，哈哈。而且我不想围绕它构建一个层，因为它也必须在客户端上工作，因此保持库架构尽可能小是一个高优先级。
5. Resourceful controllers
5.资源丰富的控制器
The inherited_resourcesRuby gem cut out about 90% of the code from my Rails controllers. It figured out a set of conventions for implementing the 7 basic controller actions. Tower.js includes something like this, so by default you don't have to write any code in your controllers they'll still respond with JSON and HTML. It also makes it so you can defined nested routes.
该inherited_resources红宝石宝石切割出大约从我的Rails控制器90％的代码。它找出了一组用于实现 7 个基本控制器操作的约定。Tower.js 包含这样的内容，因此默认情况下您不必在控制器中编写任何代码，它们仍然会以 JSON 和 HTML 进行响应。它还使您可以定义嵌套路由。
6. Automatic URL-to-database query parser
6. 自动 URL 到数据库查询解析器
In Tower.js, you can tell a controller to watch for specific parameters in the url and it will convert them to a hash ready to apply to a model query.
在 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}
Given a url that's like /users?email=abc&something=random, then @criteria()will give you a hash {email: /abc/}.
给定一个类似于 的网址/users?email=abc&something=random，然后@criteria()会给你一个哈希值{email: /abc/}。
It's not in Rails, but I wish it was.
它不在 Rails 中，但我希望它是。
7. Semantic Forms
7. 语义形式
I'm super into semantic HTML. Rails' form builder generates pretty ugly HTML, so many people as well as myself used Formtastic, which generates more semantic forms. Tower.js uses pretty much the same API as Formtastic. It also has a semantic table builder, which makes it pretty easy to build searchable/sortable tables for admin views.
我非常喜欢语义 HTML。Rails 的表单生成器生成非常难看的 HTML，所以很多人和我一样使用Formtastic，它生成更多语义表单。Tower.js 使用与 Formtastic 几乎相同的 API。它还具有语义表构建器，这使得为管理视图构建可搜索/可排序的表变得非常容易。
8. Asset Pipeline
8. 资产管道
Rails 3 had an awesome asset pipeline, where you could write your JavaScript in CoffeeScript, your CSS in SCSS, and it would automatically recompile. Then rake assets:precompileyour assets and you'd get md5-hashed gzipped assets ready for S3. That's pretty hard to build out yourself, and I didn't see anyone working on that for Node.js.
Rails 3 有一个很棒的资产管道，你可以用 CoffeeScript 编写 JavaScript，用 SCSS 编写 CSS，它会自动重新编译。然后rake assets:precompile你的资产，你会为 S3 准备好 md5 散列的 gzipped 资产。自己构建起来非常困难，而且我没有看到有人为 Node.js 做这方面的工作。
RailwayJS uses the Rails 2 method of timestamping the asset path, so instead of this md5-hashed version:
RailwayJS 使用 Rails 2 方法为资产路径加上时间戳，所以不是这个 md5 哈希版本：
/stylesheets/application-51e687ad72175b5629f3b1538b65ea2c.css
You'd get something like this:
你会得到这样的东西：
/stylesheets/application.css?1306993455524
This is a problem for a few important reasons. The Rails Asset Pipeline Guidehas the details, but the big thing is S3 doesn't recognize the timestamp, so it's reading /stylesheets/application.css, and if you set a far-future Expiresheader and you've changed your CSS, anyone who visited your site before will have to purge their cache or force-refresh your page to see the updates.
由于几个重要原因，这是一个问题。该滑轨资产管道指南有细节，但大的事情是S3不承认时间戳，所以它的阅读/stylesheets/application.css，如果设置远未来Expires头和你已经改变了你的CSS，任何人之前访问过您网站的人必须清除他们的缓存或强制刷新您的页面才能看到更新。
RailwayJS also doesn't have the built in asset compilation pipeline (at least to my knowledge).
RailJS 也没有内置的资产编译管道（至少据我所知）。
9. The Watchfile
9.监视文件
Guardwas a huge productivity booster in Rails. It allowed you to write quick "watch tasks", essentially like rake/cake tasks, that ran when a file matching a pattern was created/updated/deleted.
Guard是 Rails 中一个巨大的生产力助推器。它允许您编写快速的“监视任务”，本质上类似于 rake/cake 任务，这些任务在创建/更新/删除与模式匹配的文件时运行。
Tower has this built in (using design.io). This is actually what's telling the CoffeeScript and Stylus assets to compile into JavaScript and CSS. But you can do very powerful things with this feature, see https://github.com/guard/guard/wiki/List-of-available-Guardsfor examples.
Tower 内置了这个（使用design.io）。这实际上是告诉 CoffeeScript 和 Stylus 资产编译成 JavaScript 和 CSS 的原因。但是您可以使用此功能做非常强大的事情，请参阅https://github.com/guard/guard/wiki/List-of-available-Guards以获取示例。
10. CoffeeScript
10. CoffeeScript
Big fan of CoffeeScript.
CoffeeScript 的忠实粉丝。
CoffeeScript cuts the amount of JavaScript you need to write about in half (6,501 additions, 15,896 deletionsconverting the entire Node.js library to CoffeeScript). And it makes coding much faster and easier.
CoffeeScript 将您需要编写的 JavaScript 数量减少了一半（添加6,501 次，删除 15,896 次，将整个 Node.js 库转换为 CoffeeScript）。它使编码变得更快、更容易。
Also, CoffeeScript is the only way to keep that productive and enjoyable coding experience that Rails showed the world. JavaScript just doesn't do that.
此外，CoffeeScript 是保持 Rails 向世界展示的高效和愉快的编码体验的唯一方法。JavaScript 不会那样做。
The little things
小事
I'm a fan of standards. RailwayJS stuck to the Ruby convention of using snake_case, and I wanted to do that too, but the JavaScript community uses camelCase so Tower went with that. CamelCase has a few added benefits as well, such as you don't need to convert server-side Rails snake_case to/from camelCase for the client, and removing that extra character gives you a tiny smaller file size.
我是标准的粉丝。RailJS 坚持使用 snake_case 的 Ruby 约定，我也想这样做，但 JavaScript 社区使用 camelCase，所以 Tower 也采用了它。CamelCase 也有一些额外的好处，例如您不需要为客户端将服务器端 Rails snake_case 转换为/从驼峰大小写转换，并且删除额外的字符可以让您的文件更小。
I'm also in love with super clean code. Before I consider contributing to a project, I read through the source code... and if it's super messy, I'm probably just going to rewrite it.
我也喜欢超级干净的代码。在我考虑为一个项目做贡献之前，我通读了源代码......如果它非常混乱，我可能会重写它。
I also love optimizing code. With Tower.js, a big goal is to structure it so it does everything that Rails does, providing the exact same API in both the client and server, using the minimal amount of code possible. There's a tradeoff though between minimizing the size of the codebase and writing code that's clear and fun/productive to use. Still finding ways to get the best of both worlds.
我也喜欢优化代码。对于 Tower.js，一个很大的目标是对其进行结构化，使其能够完成 Rails 所做的一切，在客户端和服务器中提供完全相同的 API，使用尽可能少的代码。但是，在最小化代码库的大小和编写清晰且有趣/高效的代码之间存在权衡。仍在寻找两全其美的方法。
I'm definitely in this for the long-haul as well. This is the foundation for our company, and everything I personally will build in the future. I want to get to the point where you can pump out a nicely designed, functional, and highly optimized app in a day.
我也绝对是长期参与的。这是我们公司的基础，也是我个人将在未来建立的一切。我想达到这样的程度，您可以在一天内推出一款设计精美、功能强大且高度优化的应用程序。
Hope that helps.
希望有帮助。
回答by Juzer Ali
Have you paid attention to Derbyjs? This one although not yet beta, is quite exciting. It is being authored by an ex google employee and the author of everyauth. You will have to write minimal client side javascript with this one. See the excerpts taken from the official page:
你关注过Derbyjs吗？这个虽然还不是测试版，但非常令人兴奋。它由前谷歌员工和everyauth的作者创作。你将不得不用这个编写最少的客户端javascript。见摘自官方页面：
Why not use Rails and Backbone? Derby represents a new breed of application frameworks, which we believe will replace currently popular libraries like Rails and Backbone.
Adding dynamic features to apps written with Rails, Django, and other server-side frameworks tends to produce a tangled mess. Server code renders various initial states while jQuery selectors and callbacks desperately attempt to make sense of the DOM and user events. Adding new features typically involves changing both server and client code, often in different languages.
Many developers now include a client MVC framework like Backbone to better structure client code. A few have started to use declarative model-view binding libraries, such as Knockout and Angular, to reduce boilerplate DOM manipulation and event bindings. These are great concepts, and adding some structure certainly improves client code. However, they still lead to duplicating rendering code and manually synchronizing changes in increasingly complex server and client code bases. Not only that, each of these pieces must be manually wired together and packaged for the client.
Derby radically simplifies this process of adding dynamic interactions. It runs the same code in servers and browsers, and it syncs data automatically. Derby takes care of template rendering, packaging, and model-view bindings out of the box. Since all features are designed to work together, no code duplication and glue code are needed. Derby equips developers for a future when all data in all apps are realtime.
Flexibility without the glue code Derby eliminates the tedium of wiring together a server, server templating engine, CSS compiler, script packager, minifier, client MVC framework, client JavaScript library, client templating and/or bindings engine, client history library, realtime transport, ORM, and database. It elminates the complexity of keeping state synchronized among models and views, clients and servers, multiple windows, multiple users, and models and databases.
At the same time, it plays well with others. Derby is built on top of popular libraries, including Node.js, Express, Socket.IO, Browserify, Stylus, UglifyJS, MongoDB, and soon other popular databases and datastores. These libraries can also be used directly. The data synchronization layer, Racer, can be used separately. Other client libraries, such as jQuery, and other Node.js modules from npm work just as well along with Derby.
When following the default file structure, templates, styles, and scripts are automatically packaged and included in the appropriate pages. In addition, Derby can be used via a dynamic API, as seen in the simple example above.
为什么不使用 Rails 和 Backbone？Derby 代表了一种新的应用程序框架，我们相信它将取代当前流行的库，如 Rails 和 Backbone。
向使用 Rails、Django 和其他服务器端框架编写的应用程序添加动态功能往往会产生混乱。服务器代码呈现各种初始状态，而 jQuery 选择器和回调拼命尝试理解 DOM 和用户事件。添加新功能通常涉及更改服务器和客户端代码，通常使用不同的语言。
许多开发人员现在包含一个像 Backbone 这样的客户端 MVC 框架来更好地构建客户端代码。一些已经开始使用声明式模型-视图绑定库，例如 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，如上面的简单示例所示。
But it also comes with following disclaimer
但它也带有以下免责声明
Derby and Racer are alpha software. While Derby should work well enough for prototyping and weekend projects, it is still undergoing major development. APIs are subject to change.
Derby 和 Racer 是 alpha 软件。尽管 Derby 对于原型设计和周末项目应该足够好，但它仍在进行重大开发。API 可能会发生变化。
It doesn't yet have an authorization implementation and is fraught with security issues, although they will be taken care of in months to come. If you can wait for a few months this seems to be a promising framework.
它还没有授权实施并且充满了安全问题，尽管它们将在未来几个月内得到解决。如果您可以等待几个月，这似乎是一个很有前途的框架。
回答by Shane Courtrille
Selecting a framework comes down to your comfort level with it.. usually based on..
选择一个框架取决于你对它的舒适程度……通常基于……
How active is the project? When was the last commit? If it's not on github that's an immediate concern for me since that makes user contributions harder.
How many blog posts can I find on the framework? If nobody is talking about it that's usually a bad sign since people naturally talk about things that excite them.
What do Ithink of the framework? This can be harder to judge but there should be enough examples out there that you can get a basic idea at least. If there aren't then that in of itself is a big problem.
项目有多活跃？最后一次提交是什么时候？如果它不在 github 上，这对我来说是一个当务之急，因为这会使用户贡献更加困难。
我可以在框架上找到多少篇博文？如果没有人谈论它，这通常是一个坏兆头，因为人们自然而然地谈论让他们兴奋的事情。
行什么我觉得框架？这可能更难判断，但应该有足够的例子，你至少可以得到一个基本的想法。如果没有，那么这本身就是一个大问题。
Erm.. of course the obvious question is if you want a RoR framework.. why not just use RoR? ;)
呃……当然，显而易见的问题是，如果你想要一个 RoR 框架……为什么不直接使用 RoR？;)
回答by Kevin Hutchinson
It looks like TowerJS is more tightly coupled with MongoDB as its data store, whereas RailwayJS seems to have model adapter flexibility. That might affect your choice between the two. Personally I'd choose to write Rails sites using RoR. Node seems to lend itself more to different kinds of services don't you think? (I'm thinking Backbone in the client with AJAX REST services).
看起来 TowerJS 与作为其数据存储的 MongoDB 更紧密地结合在一起，而 RailJS 似乎具有模型适配器的灵活性。这可能会影响您在两者之间的选择。我个人会选择使用 RoR 编写 Rails 站点。Node 似乎更适合不同类型的服务，你不觉得吗？（我正在考虑使用 AJAX REST 服务的客户端中的 Backbone）。
