Beginner’s mistakes with Backbone.js

For a recent project we decided to use Backbone.js to provide structure to the client side of our RESTful Web application. Backbone.js is very much the vogue right now and since we already had an internal toy project that used Backbone.js we expected no big problems.
But of course we faced problems. No matter how good the example material is, it’s no substitute for actual experience. We gained this experience through our mistakes, and while there are already a number of articles online about the strengths, weaknesses and pitfalls of Backbone.js that I will include below, another article hopefully means good advice to those new to Backbone.js and a nudge in the right direction.

If you are new to Backbone.js (and the underlying), then Addy Osmani’s book-in-progress is a great place to start.

Don’t work outside your model

Probably the most important thing to remember is that Backbone.js is client-side MVC/MVP framework and you should use it as such.  This means that everything your application does is done through Backbone.js. A popular view on Backbone.js is that its applications should be event-driven. Views should not alter themselves or reference other views. Instead, all actions should have appropriate events that alter the state of the model, which then takes care of updating the view(s). Communication between views can be done using an event aggregator.
If you don’t stay in this backbone-centric mindset you might start to include small pieces of page-specific script in your templates that your model does not know about. This might put your model and view in an inconsistent state, and why should you execute scripts from your template when you can bind events to any object with Backbone.js?

Don’t manipulate the router

The Router has two main functions in Backbone.js. One is allowing a URL to be directly accessible from outside your site. The other is to add url’s to your browser’s history for better navigation. If for some reason you need to manually direct the router to another url this should only be because there is a need to have this url in your browser’s history, and almost never just to simulate a user’s action taken by clicking. The intended flow of control should go from the views event handler to the model and back to the view via the views event listener. This excellent article by Derick Bailey helped to understand Backbone’s function.

Keep Backbone.js in mind when designing your REST interface

As documented in its .sync function and in this post (https://blog.sendhub.com/post/19349219519/single-page-web-apps-with-backbone-js ), Backbone.js works well with REST, especially when the interface is designed properly around the use of nouns, id’s and the standard CRUD operations used on them.
If your REST design does not quite match, then a combination of the model’s .url function and/or routes can do the trick, but you’re better off sticking to Backbone’s suggestion (and good REST design in general).

Conclusion

Backbone.js is a great framework to use when your client-side JavaScript is reaching that icky-spaghetti-with-mudball-sauce-point. While it can be argued that its documentation isn’t always clear enough about the intended uses of the models, router and views, there is plenty of information available to help you along the right path for your application. I, for one, can’t wait to use Backbone.js again and put these experiences to practise.