Web Apps. Mobile Apps. Awesome!


Backbone.js and The Joy Of jQuery

April 1, 2012

42 has recently been engaged at a new client and we’ve been working on launching their new site (client to be named later). Neither the site nor the architecture was designed by us but we were retained to help implement it, something we’re very good at. At least, I thought so.

When the initial designs came down, I remember thinking to myself, “Well, hell, this will take all of a week to build.” Essentially, it involved a “dashboard” type design that could be manipulated and sorted a couple of different ways. Nothing all that complicated, really. Except for one requirement: we were to build it using Backbone.js.

For those who are unfamiliar with Backbone, it’s essentially an MVC library for JavaScript, to help modularize the code for single page HTML 5 dynamic websites. Even un-minified, it’s has a tiny footprint but a large effect on any project.

The Good

The upsides to using Backbone.js are many and, though I was loathe to originally support it, it has won over even me who usually objects to frameworks for framework sake.

Backbone offers a nice way to modularize front end code, including HTML layout and event handling. It is divided up into three main kind of “classes”: Models, Collections, and Views. (There are also “Routers” but for the purposes of this post, I’m going to leave them out for the time being.) Models represent a single data item to be displayed on a webpage. Collections represent a list of Models. And Views represent both the representation of an individual Model as well as the general layout.

On the current project, we define two different kinds of Views: Widgets and Views. There is no class or definition difference between them, merely a nomenclature of the individual files themselves. Generally, we define Widgets as being the representation of a Model and Views as a representation of a larger layout or Collection. This is helpful when looking for specific items. Does it affect the way items lay out in a list? It’s a Widget. Does it affect the larger layout? It’s a View. When naming things in this way, it helps keep the project organized.

Models and Collections generally represent the backend data object and there is little creativity in them. Where Backbone.js really shines is on the View layer.

Each View can separately bind events to itself and handle those events keeping project management limited and maintainable. If an event is firing (or not) when clicking on a specific item, it’s easy to know where to go to find where that is managed. Every item is specifically responsible for managing its layout as well.

Backbone also encourages the separation of layout and logic, a frequent issue with JavaScript who’s main job is to manipulate the DOM. Because of it’s dependence on the Underscore.js library, all the templating features included with Underscore are available in Backbone as well, allowing for discrete chunks of HTML to be created and manipulated through the normal use of jQuery.

This can’t be emphasized enough. With most projects using jQuery, and I am also guilty of this, the chains of chained callbacks becomes so long that the code is essentially unreadable after it’s done, a serious maintenance issue. As an example, see the not too exaggerated pseudo-code below:

url: '/api/get_profile.php?id='+id,
dataType: 'json',
success: function(data) {
//do something here. Maybe a call to another function.
statusCode: {
404: function() {
//handle not found...
500: function() {
//handle server errors...
}).done(function(data) {
//handle post-op whatever

The chain, as you can see, quickly becomes unmanageable and, even worse for any company that wishes to ever change its business model, unmaintainable. Backbone solves this with its simple and object oriented construction.

Additionally, if the REST services that the frontend queries are built to Backbone’s standard (utilizing GET, POST, PUT, and DELETE HTTP methods), then most CRUD operations are handled transparently. This is a massive advantage as the data handling code is already written and can happen with little work on the developer’s part. This alone makes Backbone.js a library worth investigating for use in any frontend project. But it does come with a few downsides…

The Bad

Like any framework, Backbone.js requires that developers need to learn the way that it does things. This can be good in the case of DOM manipulation and event delegation or potentially bad in the case of the REST service calls mentioned above.

As an example of the potential for bad, consider a REST service where there is one method for getting data and another for saving. It can be as simple as:

GET /api/get_profile.php?id=10

POST /api/save_profile.php

Logical, yes? Chances are, many of the services you are fetching or saving to are built like this. But Backbone.js is built with a mind toward REST “standards”. So that all services should be essentially the same URL with the HTTP method being used to determine how the service should react. An example:

GET /api/profile/10

PUT /api/profile

POST /api/profile

DELETE /api/profile/10

GET always fetches the data, PUT and POST will save or update depending on the standard though Backbone always uses PUT to update and POST to save, while DELETE is supposed to remove the data.

How many services does anyone know that are built this way?

At our client, where the services are being built from scratch, this is doable. But when dealing legacy services built to the first example, each model essentially requires an override of the basics of how Backbone processes service calls. And while this can be nicely encapsulated into each Model, it still adds development overhead for not having built the backend for the way this library thinks you should have.

Which leads to perhaps the biggest downside of Backbone.js: It’s yet another framework developers must learn.

I once read an article that said the biggest challenge to developers was not the language, those were easy enough to pick up, but frameworks, that use a known language but add their own learning curve to effectively implement. This was years ago and it was specifically referring to jQuery but the theme holds. A developer may know PHP but do they know WordPress? You may know Java but do you know Spring?

It’s not enough to just know JavaScript to implement Backbone. One also has to know the way Backbone does things. And in this regard, the documentation is sorely lacking. Writing a frontend application in jQuery may be a mess of chained function calls that are ultimately unmaintainable but it can happen quickly with an immediate result. Backbone adds a layer of complexity, requiring that the backend data model be entirely reproduced on the frontend and then have individual views created to represent every object.

Rather than having something to show in hours, Backbone requires days. Not unlike a Java versus a PHP project.

The Verdict

It’s a tough call to determine whether the overhead that the Backbone.js library imposes is worth it. There are many pluses and minuses to take into account. Thus, the verdict is bound to be mixed. So here it is:

If you are running a large web project with multiple developers, a long timeline, and the resources to absorb the startup overhead and learning curve, then Backbone is the right tool to use. Its encapsulation features alone make any project using it far more maintainable in the long term than writing straight up jQuery.

However, if the project that its being considered for is small, without a fair number of developers, or will be rewritten in two months when the business model changes yet again, the overhead of Backbone just isn’t worth it. It is not a rapid development platform and the maintainability it brings to a project is not worth it if everything will be scrapped tomorrow.

Still, Backbone is a step in the right direction, a lean library that imposes some standards on developers while offering simplicity in many areas of common frustration. It’s biggest disadvantage is that of many frameworks, in that it was built with what the developer believes to be best practices, the real world be damned. What it imposes may in fact be best practices but rarely do those ever make it to the final product where delivery date trumps ideal every time.

Back to Blog

42 Tags: , , ,


Content for class "bottomYellow" Goes Here
Content for class "bottomBlue" Goes Here

42 Solutions

Working with 42 Solutions, you’ll find that it’s not the technology that’s important, it’s the idea. Regardless of whether your company is based on proprietary software or open source, we will find the right tools to get the job done.

Invite us to your office and we’ll send a pair of consultants armed with laptops and bright ideas, ready to solve your problem and offer solutions. We pride ourselves in getting to know how you do business and integrating into your process.