Railwayjs vs towerjs

ArticleDirectory

• 1. Same code on the client and server
• 2. Same "views" on the client and server
• 3. Rails-quality model API on the client and server
• 4. uniform interface to the SQL and nosql datastores
• 5. Resourceful Controllers
• 6. Automatic URL-to-database query parser
• 7. semantic forms
• 8. Asset Pipeline
• 9. The watchfile
• 10. coffeescript
• The little things

I decided to use node. js to dynamically generate my framework documentation and pay attention to node. js again.

The following content is transferred from stackoverflow

+ ----------------------- + -------------------------------- + ------------------------------------ + | Railwayjs | tower. JS | + ----------------------- + -------------------------------- + ------------------------------------ + | First Commit | Jan 2011 | Oct 2011 | rails | 2.3.x | 3.x |. JS |> = 0.4.x |> = 0.4.x | Server | internal | external | client | external | template agnostic | external | default engine | ejs | coffeek Up | database agnostic | internal | external | default datastore | MongoDB | model validations | validatespresenceof ('email ') | validates ('email', presence: True) | query scopes | metric | percent | chainable scopes | percent | Param parsing | percent | controllers | percent | resource controllers | percent | File naming | users_controller.js | userscontroller. coffee | VM. runincustomcontext | pipeline | asset pipeline | | Merge | asset compression | merge | routing | map. resources ('posts ') | @ resources 'posts' | nested routes | bytes | percent | generated URL helpers | percent | generators | percent | command-line API | percent | | repl (console) | metrics | coffeescript console | metrics | asset cache method | timestamp | MD5 hash | production asset path |/app.css? 123123123 |/app-859c828c89288hc8918741.css | preferred language | JavaScript | coffeescript support | locale | percent | internationalization | percent | Heroku support | percent | string case | snail ke_case | camelcase | form builder | example | semantic form builder | example | table builer | example | file watcher API | example | live-Reload assets | generator | test suite | generator | generators for tests | generator | Twitter Bootstrap | generator | HTML5 boilerplate | generator | + ----------------------- + ------------------------ + Generator ------------------------------------ +

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 shoshould 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 likeHistory. pushstateWith#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 versions like mustache. That's more code duplication... You shoshould 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 login ID 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 shoshould 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 wowould probably end up refactoring the whole thing to use coffeescript, haha. and I don't want to build a layer around und 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 events des 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 it rails, but I wish it was.

7. semantic forms

I'm super into semantic HTML. rails 'form builder generates pretty uugly 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 cocould write your Javascript in coffeescript, your CSS in SCSs, And it wowould automatically recompile. ThenRake 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.

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-FutureExpiresHeader 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 snke_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 snke_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.