There’s a really interesting video with @dhh talking about his thoughts on client-side MVC frameworks with Rails.
He goes into some detail about Pjax and 37signals caching strategy so that partial page updates are snappy and that gives you an experience much like the client-side frameworks without the added complexity.
After working with Backbone.js for a while now I agree with him that development experience of client-side views isn’t nearly as nice as generating the views from rails.
Cool stuff. Thanks for sharing this.
@DHH is a really smart guy and he has a nice (relaxed) presentation style; I have seen him a few times at conferences.
I have not had time to take a look at Backbone.js but it seems to be “coming up in conversation” quite a lot lately. I am very curious. How would you characterize it in “an elevator speech”?
The intro on the site is pretty succinct.
Backbone.js gives structure to web applications by providing models with key-value binding and custom events, collections with a rich API of enumerable functions, views with declarative event handling, and connects it all to your existing API over a RESTful JSON interface.
It gives you models which you can fetch, destroy, update, delete over a JSON api.
A router for updating the URL’s with pushState when navigating around different “pages” client-side.
View classes for you to put your event bindings.
It’s all driven by a nice set of events, e.g. when data changes in your models you can respond to them.
It’s pretty nice and is popular but there’s a lot of other frameworks like Ember.js and Angular.js which are also becoming popular.
You really wouldn’t use backbone.js within a rails app – it is meant for pure JS apps where there isn’t as much server-side framework to hang off of. It solves a different problem than rails.
The huge disadvantage of rendering partial views and returning them down to the client is larger payload going down the wire and increased server load from rendering templates.
Backbone actually works really well with Rails. It is great for building json api’s and routing, controllers, models, db migrations, validations etc… are all just as relevant - it’s only the views that change with Backbone.
dhh is arguing that you shouldn’t build your entire application client-side, and I agree with him. I prefer to keep client-side complexity for those parts of the app that will really benefit from it. And backbone works well here, able to be used in some parts of your application but not all.
Did you watch the video?
This turns out to be not such a “huge disadvantage” as you think, the speed difference really is negligible. After all, we’ve been developing applications with full page refreshes for a long time now. PJax is the simplest way to get an big speed boost without changing a lot. Sending HTML is not a disadvantage.
As I see it there’s far more disadvantages to doing this 100% on the client, a few benefits of doing this on the server are:
- It’s far less complex, that’s #1 for me
- You’re sending a lot less js at the start
- You’re waiting for less things to initialize on the client
- You can use all of the server-side tools you’re used to
- Pjax and Caching makes this just as responsive, for the most part.
- It’s faster to develop
- Easier to test
- Fewer bugs
- Easier to make accessible
- SEO friendly