两者都基于Express，都是RoR风格框架…
还是我已经走错了路？也许我应该选择其他框架。
我讨厌什么时候有这么多的框架可供选择，没有行业标准依赖，更多或更少的确定框架将在近几年发展…
请帮助，需要专家的建议。谢谢
解决方法
+-----------------------+------------------------------+------------------------------------+ | | 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只在服务器上工作，因为它是建立在快速。 Tower.js也是建立在express的基础上，但是在某种程度上使它适用于客户端和服务器。 Tower.js为客户端和服务器提供相同的API。这意味着我不得不重写一些东西像路由器，所以它在客户端和服务器上工作相同(加上它允许你使用#fallback，使用相同的路由集，做history.pushState)。
2.客户端和服务器上的“视图”相同
我花了很多时间在Rails和编写Haml模板。除此之外，我正在使用模板语言(如“小胡子”)编写Web和移动JavaScript界面。这是更多的代码重复…你应该能够在客户端(作为JavaScript模板)和服务器(呈现静态HTML)使用相同的视图/模板集。
因为Haml是相当真棒(超级干净，允许你执行任意ruby，内置漂亮打印等)，最接近的JavaScript替代是CoffeeKup.它可以在客户端和服务器上工作。 CoffeeKup允许你使用JavaScript的所有功能编写模板，所以你没有限制。在Mustache中构建FormBuilder需要花费大量的工作或者大量的代码，或者两者兼而有之。
不过请注意，您可以自由换出模板引擎，并为客户端或服务器使用Jade，Mustache，Handlebars等。 CoffeeKup只是一个干净和强大的默认。
3.客户端和服务器上的Rails质量模型API
ActiveModel(由ActiveRecord用于sql和Mongoid用于MongoDB用于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 Query API之后，但是这个API“input”被转换为适用于不同数据存储的数据库命令。
Tower.js目前有一个MongoDB和内存(浏览器内)存储，旨在为其他流行数据库(CouchDB，Neo4j，PostGresql，MysqL，sqlite，Cassandra等)提供统一的接口。
RailwayJS似乎也通过JugglingDB这样做，它看起来像一个好的开始。但我选择不使用它的几个原因。首先，它看起来是围绕Rails 2.x API(User.validatesUniquenessOf“email”vs. User.validates“email”，presence：true)构建的。第二，它没有Rails 3的可链接查询的丰富性。第三，我想能够快速地添加代码到代码库，并且由于我很挑剔，我可能会最终重构的整个事情使用CoffeeScript，哈哈。我不想构建一个层，因为它必须在客户端上工作，所以保持库架构尽可能最小是一个高优先级。
资源丰富的控制器
inherited_resources Ruby宝石从我的Rails控制器中删除了约90％的代码。它确定了一组用于实现7个基本控制器动作的约定。 Tower.js包括这样的东西，所以默认情况下，你不必在控制器中写任何代码，他们仍然会使用JSON和HTML响应。它也使它使您可以定义嵌套路由。
在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}
给定一个url，就像/ users？email = abc& something = random，然后@criteria()将给你一个散列{email：/ abc /}。
它不是在Rails，但我希望是。
语义形式
我超级语义HTML。 Rails的表单生成器生成相当丑的HTML，所以许多人和我自己使用Formtastic，它产生更多的语义形式。 Tower.js使用与Formtastic几乎相同的API。它还有一个语义表生成器，这使得它很容易构建可搜索/可排序表的管理视图。
8.资产管道
Rails 3有一个真棒的资产管道，你可以在CoffeeScript编写你的JavaScript，你的CSS在SCSS，它会自动重新编译。然后rake assets：预编译你的资产，你会得到md5哈希的gzipped资产准备S3。这很难建立自己，我没有看到任何人为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是一个巨大的生产力增强。它允许您编写快速“观察任务”，本质上类似于耙/蛋糕任务，在创建/更新/删除与模式匹配的文件时运行。
塔有这个内置(使用design.io)。这实际上是告诉CoffeeScript和Stylus资源编译成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只是不这样做。
小事
我是标准的粉丝。 RailwayJS坚持使用snake_case的Ruby惯例，我也想做到这一点，但JavaScript社区使用camelCase，所以Tower一起使用。 CamelCase还有一些额外的好处，例如你不需要为客户端转换服务器端Rails snake_case到/ camelCase，并且删除那个额外的字符给你一个小的文件大小。
我也爱上超级干净的代码。在我考虑为一个项目做贡献之前，我阅读了源代码…如果它是超级凌乱，我可能只是要重写它。
我也喜欢优化代码。使用Tower.js，一个很大的目标是结构化，所以Rails做的一切，在客户端和服务器提供完全相同的API，使用尽可能少的代码。有一个权衡，尽量减少代码库的大小和编写代码清晰，有趣/高效的使用。仍然找到方法来获得两个世界的最好的。
我肯定是在这个长途以及。这是我们公司的基础，以及我个人将来会建立的一切。我想要达到的点，你可以泵出一个精心设计，功能和高度优化的应用程序在一天。
希望有帮助。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
