铁路JS vs TowerJS [英] RailwayJS vs TowerJS
问题描述
再次...选择框架.我已经停在这两个 TowerJS 和 RailwayJS 上，但是它们接缝非常相似，很难选择哪种方式
两者都是基于 Express 的，都是 RoR 风格的框架...
哪个最有前途，哪个会更受欢迎?
或者也许我已经走错路了?也许我应该选择其他框架.
我讨厌有这么多框架可供选择，没有可以依赖的行业标准，或多或少确定框架将在近几年内开发......
请帮忙，需要专家建议.谢谢
这里有一个简短的表格来概述，我将在下面讨论一些内容.
<上一页>+------------------------+-------------------+------------------------------------+||铁路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 查询 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.资源丰富的控制器
inherited_resources Ruby gem 从我的 Rails 控制器中删除了大约 90% 的代码.它找出了一组实现 7 个基本控制器操作的约定.Tower.js 包含类似的内容，因此默认情况下您不必在控制器中编写任何代码，它们仍会以 JSON 和 HTML 响应.它还可以让您定义嵌套路由.
6.自动 URL 到数据库查询解析器
在 Tower.js 中，您可以告诉控制器监视 url 中的特定参数，并将它们转换为准备应用于模型查询的哈希.
类 App.UsersController 扩展 App.ApplicationController@param电子邮件"索引:->App.User.where(@criteria()).all (error, users) =>@respondTo (格式) =>格式.json =>@render json: 用户格式.html =>@render "index"，本地人:{users}给定一个类似于 /users?email=abc&something=random 的 url，然后 @criteria() 会给你一个哈希 {email:/abc/}.
它不在 Rails 中，但我希望它是.
7.语义形式
我非常喜欢语义 HTML.Rails 的表单生成器生成的 HTML 非常难看，所以很多人和我自己都使用了 Formtastic，它会生成更多语义表单.Tower.js 使用与 Formtastic 几乎相同的 API.它还有一个语义表构建器，可以很容易地为管理员视图构建可搜索/可排序的表.
8.资产管道
Rails 3 有一个很棒的资产管道，您可以在其中用 CoffeeScript 编写 JavaScript，在 SCSS 中编写 CSS，它会自动重新编译.然后 rake assets:precompile 你的资产，你就可以为 S3 准备好 md5 散列的 gzipped 资产.这很难让自己建立起来，而且我没有看到有人在为 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 也没有内置的资产编译管道(至少据我所知).
9.监视文件
Guard 是 Rails 中一个巨大的生产力助推器.它允许您编写快速的监视任务"，本质上类似于 rake/cake 任务，在创建/更新/删除与模式匹配的文件时运行.
Tower 内置了这个(使用 design.io).这实际上是告诉 CoffeeScript 和 Stylus 资产编译成 JavaScript 和 CSS.但是你可以用这个功能做非常强大的事情，见 https://github.com/guard/守卫/wiki/List-of-available-Guards 例如.
10.CoffeeScript
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 转换，并且删除多余的字符可以让您的文件更小.
我也喜欢超级干净的代码.在考虑为项目做贡献之前，我通读了源代码……如果它超级乱，我可能会重写它.
我也喜欢优化代码.对于 Tower.js，一个很大的目标是对其进行结构化，使其完成 Rails 所做的所有事情，在客户端和服务器中提供完全相同的 API，并使用尽可能少的代码.尽管在最小化代码库的大小和编写清晰有趣/高效的代码之间存在权衡.仍在寻找两全其美的方法.
我肯定也会长期参与.这是我们公司的基础，也是我个人未来将建立的一切.我希望你可以在一天内推出一款设计精美、功能强大且高度优化的应用程序.
希望对您有所帮助.
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
Both are based on Express, both are RoR style frameworks...
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
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.
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)
You should be able to do that in 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.
4. Uniform interface to the SQL and NoSQL datastores
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.).
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.
5. Resourceful controllers
The inherited_resources Ruby 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.
6. Automatic URL-to-database query parser
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.
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/}.
It's not in Rails, but I wish it was.
7. Semantic Forms
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.
8. Asset Pipeline
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:precompile your 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.
RailwayJS uses the Rails 2 method of timestamping the asset path, so instead of this md5-hashed version:
/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 Guide has 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 Expires header 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.
RailwayJS also doesn't have the built in asset compilation pipeline (at least to my knowledge).
9. The Watchfile
Guard was 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.
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-Guards for examples.
10. CoffeeScript
Big fan of CoffeeScript.
CoffeeScript cuts the amount of JavaScript you need to write about in half (6,501 additions, 15,896 deletions converting the entire Node.js library to CoffeeScript). And it makes coding much faster and easier.
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.
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.
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.
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.
这篇关于铁路JS vs TowerJS的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
