RailwayJS vs TowerJS
再一次…select框架。 我已经停在了这两个TowerJS和RailwayJS，但它们的接缝非常相似，select哪种方式非常困难
两者都基于Express，都是RoR风格的框架。
哪一个最有前途，哪一个会更受欢迎？
或者，也许我已经走错了路？ 也许我应该select其他框架。
我讨厌什么时候有这么多的框架可供select，没有行业标准可以依赖，或多或less地肯定框架将在近两年内发展…
请帮忙，需要专家build议。 谢谢
这里是一个简要的表格来概述，我将会谈到下面的一些东西。
+ ----------------------- + ------------------------- ----- + ------------------------------------ + | | 铁路JS | Tower.js | + ----------------------- + ------------------------- ----- + ------------------------------------ + | 首先提交| 2011年1月| 十月2011 | | Rails | 2.3.x | 3.x | | Node.js | > = 0.4.x | > = 0.4.x | | 服务器| ✓| ✓| | 客户端| | ✓| | 模板不可知| ✓| ✓| | 默认引擎| EJS | CoffeeKup | | 数据库不可知| ✓| ✓| | 默认数据存储| MongoDB | MongoDB | | 模型validation| validatesPresenceOf（'email'）| validation（'email'，presence：true）| | 查询范围| ✓| ✓| | 可连接的示波器| | ✓| | 参数parsing| | ✓| | 控制器| ✓| ✓| | 资源控制器| | ✓| | 文件命名| users_controller.js | usersController.coffee | | vm.runInCustomContext | ✓| | | 资产pipe道| | ✓| | 资产压缩| | ✓| | 路由| map.resources（'posts'）| @resources'posts'| | 嵌套的路线| ✓| ✓| | 生成的url助手| ✓| | | 发电机| ✓| ✓| | 命令行api | ✓| ✓| | REPL（控制台）| ✓| ✓| | CoffeeScript控制台| | ✓| | 资产caching方法| 时间戳| md5散列| | 生产资产path| /app.css?123123123 | /app-859c828c89288hc8918741.css | | 首选语言| JavaScript | CoffeeScript | | CoffeeScript支持| ✓| ✓| | 国际化| ✓| ✓| | Heroku支持| ✓| ✓| | string大小写| snake_case | camelCase | | 表单构build器| ✓| ✓| | 语义表单构build器| | ✓| | 表builer | | ✓| | 文件观察者API | | ✓| | 实时重新加载资产| | ✓| | testing套件| | ✓| | testing生成器| | ✓| | Twitter Bootstrap | ✓| ✓| | HTML5 Boilerplate | | ✓| + ----------------------- + ------------------------- ----- + ------------------------------------ +
我创build了Tower.js来实现几个目标，而现有的框架都没有做足够的工作。 以下是其中一些目标。
1.客户端和服务器上的代码相同
由于Node.js在服务器上使JavaScript成为可能，因此没有理由在Rails中编写应用程序的一部分，而在Backbone中编写其他部分。 这不过是干的。 您应该能够定义一次模型，并在客户端和服务器上使用它们。
RailwayJS只能在服务器上运行，因为它是围绕快车build造的。 Tower.js也是以express为基础构build的，但是可以使其适用于客户端和服务器。 Tower.js为客户端和服务器提供相同的确切API。 这意味着我不得不重写一些像路由器一样的东西，所以它在客户端和服务器上的工作原理是一样的（再加上它允许你使用history.pushState做一些事情，像history.pushState一样，使用同一组路由）。
2.在客户端和服务器上有相同的“视图”
我花了很多时间在Rails上编写Haml模板。 除此之外，我正在使用模板语言（如小胡子）编写Web和移动JavaScript接口。 这是更多的代码重复…你应该能够在客户端（如JavaScript模板）和服务器（呈现静态HTML）上使用相同的视图/模板集。
由于Haml非常棒（超级干净，允许你执行任意的ruby，内置漂亮的打印等），最接近的JavaScript替代品是CoffeeKup 。 它可以在客户端和服务器上运行。 CoffeeKup允许您使用JavaScript的所有function编写模板，所以您没有任何限制。 在Mustache中构buildFormBuilder要么需要大量的工作，要么需要大量的代码，要么两者兼而有之。
但请注意，您可以自由地更换模板引擎，并为客户端或服务器使用Jade，Mustache，Handlebars等。 CoffeeKup只是一个干净而强大的默认设置。
3.客户端和服务器上的Rails-quality模型API
ActiveModel（由ActiveRecord for SQL和Mongoid for MongoDB for Rails实现）是一个非常全面和经过充分testing的API，允许开发人员定义和与数据交互。 它既强大又愉快。 所有以前的（和现在的）JavaScript实现从来没有像devise的那样健壮，而且在不久的将来我也没有看到任何事情发生。
如果你可以写在Rails中：
User.where(:email => /[az/).page(2).limit(20)
你应该可以在JavaScript中做到这一点：
App.User.where(email: /[az/).page(2).limit(20)
Tower.js带有“可链式范围”，意思是硬核查询+分页。 它是在MongoDB查询API之后build模的，但是这个API“input”被转换为适用于不同数据存储的适当的数据库命令。
4.与SQL和NoSQL数据存储的统一接口
Tower.js目前有一个MongoDB和内存（浏览器内）的商店，旨在提供统一的接口到其他stream行的数据库（CouchDB，Neo4j，PostGreSQL，MySQL，SQLite，Cassandra等）。
铁路JJ似乎也通过JugglingDB来做到这一点，这看起来是一个好的开始。 但我select不使用它有几个原因。 首先，它看起来是围绕Rails 2.x API（ User.validatesUniquenessOf "email"与User.validates "email", presence: true ） User.validates "email", presence: true 。 其次，Rails 3并没有丰富的可链接查询。 第三，我希望能够快速地将代码添加到代码库中，而且由于我非常挑剔，所以最终可能会使用CoffeeScript重构整个代码，哈哈。 而且我也不想为此构build一个层，因为它必须在客户端上工作，所以尽可能保持库体系结构是最重要的。
5.资源丰富的控制器
这个inherited_resources Ruby gem从我的Rails控制器中删除了大约90％的代码。 它为实现7个基本的控制器行为制定了一套惯例。 Tower.js包括这样的东西，所以默认情况下，你不必在你的控制器中写任何代码，他们仍然会用JSON和HTML做出响应。 这也使得你可以定义嵌套的路线。
6.自动的URL到数据库查询parsing器
在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}
给定一个类似于/users?email=abc&something=random的url，那么@criteria()会给你一个hash {email: /abc/} 。
这不是在Rails，但我希望是。
7.语义forms
我超级语义的HTML。 Rails的表单生成器生成相当丑陋的HTML，所以很多人和我自己使用Formtastic ，它生成更多的语义forms。 Tower.js几乎和Formtastic使用相同的API。 它还有一个语义表生成器，这使得为pipe理视图构build可search/可sorting的表非常容易。
8.资产pipe道
Rails 3有一个很棒的资产pipe道，你可以在CoffeeScript中编写你的JavaScript，在SCSS中编写你的CSS，并自动重新编译。 然后rake assets:precompile你的资产，你会得到md5哈希gzip资产准备好S3。 这是很难build立你自己，我没有看到任何人在Node.js工作。
RailwayJS使用时间戳资产path的Rails 2方法，所以不用这个md5哈希版本：
/stylesheets/application-51e687ad72175b5629f3b1538b65ea2c.css
你会得到这样的东西：
/stylesheets/application.css?1306993455524
这是几个重要原因的问题。 Rails资产pipe道指南有详细的信息，但最重要的是S3不能识别时间戳，所以它读取/stylesheets/application.css，如果你设置了一个远期的Expires头，并且你已经改变了你的CSS，任何访问过您的网站的人都必须清除caching或强制刷新页面以查看更新。
RailwayJS也没有内置的资产编译pipe道（至less据我所知）。
9. Watchfile
Guard在Rails中是一个巨大的生产力提升者。 它允许你编写快速的“监视任务”，本质上就像耙/蛋糕任务，当匹配模式的文件被创build/更新/删除时运行。
塔有内置（使用design.io ）。 这实际上是告诉CoffeeScript和Stylus资产编译成JavaScript和CSS。 但是，您可以使用此function执行非常强大的function，请参阅https://github.com/guard/guard/wiki/List-of-available-Guards中的示例。;
10. CoffeeScript
CoffeeScript的大爱好者。
CoffeeScript将需要编写的JavaScript数量减半（ 6,501次，将整个Node.js库转换为CoffeeScript的15,896次删除 ）。 这使得编码更快，更容易。
此外，CoffeeScript是保持Rails向全世界展示高效且令人愉快的编码体验的唯一方式。 JavaScript只是不这样做。
小事
我是标准迷。 RailwayJS坚持使用snake_case的Ruby约定，我也想这样做，但是JavaScript社区使用camelCase，所以Tower就是这么做的。 CamelCase还有一些额外的好处，比如你不需要把服务器端Rails的snake_case转换成客户端的camelCase或者从客户端的camelCase转换出来，而删除这个额外的字符会给你一个很小的文件大小。
我也爱上超级干净的代码。 在我考虑为一个项目做出贡献之前，我通读了源代码……如果它太麻烦了，我可能会重写它。
我也喜欢优化代码。 有了Tower.js，一个大目标就是构build它，这样它就可以完成Rails所做的一切，在客户端和服务器端提供完全相同的API，并尽可能使用最less量的代码。 尽pipe最小化代码库的大小和编写清晰且有趣/有用的代码之间有一个权衡。 仍然在设法获得两全其美。
我肯定也在这个长途旅行。 这是我们公司的基础，也是我个人将来build立的一切。 我希望能够在一天内抽出devise精美，function强大且高度优化的应用程序。
希望有所帮助。
你有没有关注Derbyjs ？ 这个虽然还没有testing版，但是相当令人兴奋。 它由一个前谷歌雇员和everyauth的作者撰写 。 你将不得不写这个最小的客户端JavaScript。 请参阅从官方页面摘录的摘录：
为什么不使用Rails和Backbone？ Derby代表了一种新的应用程序框架，我们相信它将取代目前stream行的Rails和Backbone等库。
将dynamic特性添加到使用Rails，Django和其他服务器端框架编写的应用程序往往会产生混乱。 服务器代码呈现各种初始状态，而jQueryselect器和callback拼命试图理解DOM和用户事件。 添加新function通常涉及更改服务器和客户端代码，通常以不同的语言。
现在许多开发人员包括像Backbone这样的客户端MVC框架，以更好地构build客户端代码。 一些开始使用声明式的模型视图绑定库，如Knockout和Angular，以减less样板DOM操作和事件绑定。 这些都是很好的概念，增加一些结构当然会改善客户端代码。 但是，它们仍然导致复制渲染代码并手动同步日益复杂的服务器和客户端代码库中的更改。 不仅如此，这些部件中的每一部分都必须手动连接在一起并为客户打包。
德比从根本上简化了添加dynamic交互的过程。 它在服务器和浏览器中运行相同的代码，并自动同步数据。 Derby负责模板渲染，打包和模型视图绑定。 由于所有function都可以一起工作，因此不需要代码复制和粘合代码。 当所有应用程序中的所有数据都是实时的时候，Derby为开发人员提供了一个未来。
无需粘合代码的灵活性Derby消除了将服务器，服务器模板引擎，CSS编译器，脚本包装器，缩小器，客户端MVC框架，客户端JavaScript库，客户端模板和/或绑定引擎，客户端历史库，实时传输， ORM和数据库。 它保证了在模型和视图，客户端和服务器，多个窗口，多个用户以及模型和数据库之间保持状态同步的复杂性。
与此同时，它与其他人一起玩。 Derbybuild立在stream行的库之上，包括Node.js，Express，Socket.IO，Browserify，Stylus，UglifyJS，MongoDB以及其他很受欢迎的数据库和数据存储。 这些库也可以直接使用。 数据同步层Racer可以单独使用。 其他客户端库（如jQuery）和其他来自npm的Node.js模块与Derby一起工作。
遵循默认文件结构时，模板，样式和脚本将自动打包并包含在适当的页面中。 另外，可以通过dynamicAPI使用Derby，如上面的简单示例所示。
但它也带有以下免责声明
德比和赛车是alpha软件。 虽然德比应该足够用于原型devise和周末项目，但它仍然在进行重大的发展。 API可能会发生变化。
它还没有授权实施，并且充满了安全问题 ，虽然它们将在未来几个月内得到处理。 如果你可以等几个月，这似乎是一个有前途的框架。
select一个框架归结为您的舒适程度与它..通常基于..
-
这个项目有多活跃？ 最后一次提交是什么时候？ 如果不在github上，这对我来说是一个直接的问题，因为这会让用户的贡献更难。
-
我可以在框架中find多less篇博文？ 如果没有人谈论这件事，那通常是一个不好的迹象，因为人们自然而然地谈论激发他们的事情。
-
我对框架有什么看法？ 这可能很难判断，但应该有足够的例子，至less你可以得到一个基本的想法。 如果没有，那么这本身就是一个大问题。
呃..当然，显而易见的问题是，如果你想要一个RoR框架..为什么不只是使用RoR？ ;）
看起来TowerJS与MongoDB作为其数据存储更紧密地结合在一起，而RailwayJS似乎具有模型适配器的灵活性。 这可能会影响你在两者之间的select。 我个人会select使用RoR编写Rails站点。 节点似乎更适合不同types的服务，你不觉得吗？ （我在使用AJAX REST服务的客户端中思考Backbone）。
