Backbone.js, Rails 3 and asynchronous interfaces

Currently at Monterail we're building a frontend-heavy app. With a lot of cool stuff. Like preloading data for daily views so that you won't have to wait for every surrounding day to load. Many, many interactive elements that should be really interactive - not in an oldschool, ajax spinner way. And a lot of other stuff we shouldn't talk about yet.

We decided to put more emphasis on Backbone.js with Rails and build most of the app with this combination.

Below you can find some of our findings on the topic of making those two speak to each other in a nice manner.

Asset pipeline

Really makes things easier. Organizing your JS code before it meant a lot of things: handling dependencies, minifying & compressing the code, organizing it into a lot of different files and building connections between them. With asset pipeline and it's awesome require directive, you can forget about handling it manually. You just create the structure in app/assets/javascripts. Or app/assets/javascripts/backbone. Your choice. You can have many different files in whatever directories you like - in the end you'll get one (or more, if you decide to) JS file that has everything your webapp need.

Don't forget to:

• gzip your JS/css assets

• minify them!

Rails-backbone gem

Also makes things easier. It puts backbone.js (& underscore.js) library code into your asset pipeline. It gives you some great generators to get started if you don't know where to start. 

Coffeescript & underscore.js

Obviously. It makes Javascript code feel fresh. You can fold, iterate and do a lot of stuff. Be sure to check out coffescript docs, of course, but I bet you know it already. 

V in MVC done right

Views are classes. You handle logic inside them using the hardcore code, which is receiving so much hate in Rails views. They can have many methods, they do not have to render a single action. And templates are templates - and nothing else. There is a lot of discussion recently on the matter of Views/Templates in Rails, but you can start implementing it right away. Go and try it. You'll fall in love.

You have many options for templates - eco, Handlebars.js, {{ mustache }}, but we recommend haml_coffee_assets. It gives you the HAML you (probably) already know with the ability to use coffeescript within it.

Single-page app

Yes. You will use Rails to render only the core view of the application. Of course, you will have to handle all things around the core of your app.

For example, you should probably leave out:

• authentication logic: sign up / in, reset password

• steps necessary to use the app: billing pages

But, other than that, you can use the views rendered in JS. What does that mean?

• if they do not include any dynamic data, they are lightning fast

• if they include dynamic data, you can preload it and they still will be lightning fast

Backbone comes with it's own router. You can utilise pushState without any effort. How cool is that?

Asynchronous interface

Since you'll be doing most of the association/validation work in background, you don't have to worry too much about server responses. It's the same with rendering elements: you'll be doing it in JS, not Rails. You don't have to wait for the request to return the rendered element to actually display them. If you create something, the UI should respond right away and the ajax request can persist the data with it's own pace.

You should, however, prepare a global something went wrong, reload the page request rescuer - in case of network outages, backend app failures and so on. But it's way easier to manage.

API

You get it for free. It doesn't have to be public, but if you decide to, it's a matter of adding OAuth as the way of authenticating requests and it's done. (Or you could go with http basic auth, which is obviously bad for a lot of reasons).

With smart caching (give redis-store a try), you'll save tons of server power. You know, relating to the old ruby saying, views are most resource-consuming.

Conclusion

There are, obviously, downsides, which I'll cover in future (I silently hope that there won't be any reason to do that). And topics I haven't covered. I'm curious about other stacks and ways of doing things. Share in the comments or ping me on Twitter!