RailwayJS vs TowerJS

Question

RailwayJS vs TowerJS

kin*_*pin 65 frameworks node.js express railway.js towerjs

再次......选择框架.我已停止使用这两个TowerJS和RailwayJS,但它们的接缝非常相似,选择哪种方式很困难

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

哪一个最有前途,哪一个会更受欢迎？

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

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

请帮忙,需要专家建议.谢谢

Answer 1

Lan*_*ard 153

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

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

我创建了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非常棒(超级干净,允许你执行任意红宝石,内置漂亮打印等),最接近的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)

Run Code Online (Sandbox Code Playgroud)

您应该可以在JavaScript中执行此操作:

App.User.where(email: /[a-z/).page(2).limit(20)

Run Code Online (Sandbox Code Playgroud)

Tower.js带有"可链接范围",意思是核心查询+分页.它以MongoDB查询API为模型,但此API"输入"将转换为适用于不同数据存储的数据库命令.

4. SQL和NoSQL数据存储区的统一接口

Tower.js目前有一个MongoDB和Memory(浏览器内)商店,旨在为其他流行的数据库(CouchDB,Neo4j,PostGreSQL,MySQL,SQLite,Cassandra等)提供统一的界面.

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

5.资源丰富的控制器

该inherited_resources红宝石宝石从我的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}

Run Code Online (Sandbox Code Playgroud)

给出一个类似的网址/users?email=abc&something=random,然后@criteria()会给你一个哈希{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

Run Code Online (Sandbox Code Playgroud)

你会得到这样的东西:

/stylesheets/application.css?1306993455524

Run Code Online (Sandbox Code Playgroud)

由于一些重要原因,这是一个问题.该滑轨资产管道指南有细节,但大的事情是S3不承认时间戳,所以它的阅读/stylesheets/application.css,如果设置远未来Expires头和你已经改变了你的CSS,任何人之前访问过您网站的用户必须清除缓存或强制刷新页面以查看更新.

RailwayJS也没有内置的资产编译管道(至少据我所知).

9. Watchfile

Guard是Rails中一个巨大的生产力助推器.它允许您编写快速的"监视任务",基本上像rake/cake任务,当创建/更新/删除匹配模式的文件时运行.

Tower内置了这个(使用design.io).这实际上是告诉CoffeeScript和Stylus资产编译成JavaScript和CSS的原因.但是您可以使用此功能执行非常强大的操作,请参阅https://github.com/guard/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,使用尽可能少的代码.尽管在最小化代码库的大小和编写清晰,有趣/高效的代码之间存在权衡.仍然想方设法让两全其美.

我肯定也是长期的.这是我们公司的基础,也是我个人将来建立的一切.我希望能够在一天内推出设计精美,功能强大且高度优化的应用程序.

希望有所帮助.

用简短的表格更新. (7认同)
我正在分析,那里有很多该死的节点框架!Tower&Railway似乎是功能最丰富的轨道式MVC,但有一些稍微轻一些的那些:Derby,Flatiron,Bones,Matador - 我错过了吗？我现在倾向于塔,但这是我的题库:http://goo.gl/tyHXI (2认同)
@lefnire我一直在研究一个类似的"braindump",请看这里:https://docs.google.com/spreadsheet/ccc？key = 0AmZ5QuG3wAaldFFWRlVUTzZGeWI3OFZCU2kxc0lQWkE它真的不完整,如果有人想贡献,请ping我. (2认同)

Answer 2

Juz*_*Ali 5

你有没有注意到Derbyjs？这个虽然尚未测试,但非常令人兴奋.它由前谷歌员工和Everyauth的作者撰写.你将不得不用这个编写最小的客户端javascript.参见摘自官方网页的摘录:

为什么不使用Rails和Backbone？Derby代表了一种新的应用程序框架,我们认为它将取代目前流行的库,如Rails和Backbone.

向使用Rails,Django和其他服务器端框架编写的应用程序添加动态功能往往会产生混乱.服务器代码呈现各种初始状态,而jQuery选择器和回调拼命地尝试理解DOM和用户事件.添加新功能通常涉及更改服务器和客户端代码,通常使用不同的语言.

许多开发人员现在都包含像Backbone这样的客户端MVC框架来更好地构建客户端代码.一些人已经开始使用声明式模型视图绑定库,如Knockout和Angular,以减少样板DOM操作和事件绑定.这些都是很棒的概念,添加一些结构肯定会改进客户端代码.但是,它们仍然会导致重复渲染代码并手动同步日益复杂的服务器和客户端代码库中的更改.不仅如此,每个部件必须手动连接在一起并为客户端打包.

Derby从根本上简化了添加动态交互的过程.它在服务器和浏览器中运行相同的代码,并自动同步数据.Derby开箱即用地处理模板渲染,打包和模型视图绑定.由于所有功能都旨在协同工作,因此不需要代码复制和粘合代码.当所有应用程序中的所有数据都是实时数据时,Derby为开发人员配备了未来.

没有粘合代码的灵活性Derby消除了连接服务器,服务器模板引擎,CSS编译器,脚本打包器,minifier,客户端MVC框架,客户端JavaScript库,客户端模板和/或绑定引擎,客户端历史库,实时传输, ORM和数据库.它消除了在模型和视图,客户端和服务器,多个窗口,多个用户以及模型和数据库之间保持状态同步的复杂性.

与此同时,它与其他人合作得很好.Derby建立在流行的库之上,包括Node.js,Express,Socket.IO,Browserify,Stylus,UglifyJS,MongoDB,以及其他流行的数据库和数据存储.这些库也可以直接使用.数据同步层Racer可以单独使用.其他客户端库(例如jQuery)和来自npm的其他Node.js模块与Derby一样工作.

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

但它还附带以下免责声明

Derby和Racer是alpha软件.虽然德比应该能够很好地进行原型设计和周末项目,但它仍在进行重大开发.API可能会发生变化.

它还没有授权实施,并且充满了安全问题,尽管它们将在未来几个月内得到处理.如果你可以等几个月,这似乎是一个很有前景的框架.

归档时间：	13 年，11 月前
查看次数：	20397 次
最近记录：	13 年，1 月前