Question

As many of you, I’ve started to write more and more web application using a backend that only talks JSON (in my case Django or Rails).

As a front I’ve been using a MVC client, for example Backbone.js. According to me, this solution is really nice and plays well with many type of applications.

What I found annoying is that I found myself producing a lots of Javascript code that do almost the same thing. It feels like I’m creating a new layer on top of Backbone for each new application. There must be something wrong in my way I am thinking here.

Lets give you an example:

Pretend that you have an API that gives you six collections and you would like to use Twitter Bootstrap to show this. You’ll have a navigation menu where you can select each of these collection to view.

There will be a lots of Javascript code just setting up all models, collections, views and the logic around routing and navigation. You must also consider which view that is active.

Such as:

Error handling when fetching collection

If a collection is loading, we would like to see “Loading”. If it fails, we would to see why. It’s the same with create/save/delete.

Routing

I found myself writing a complicated logic that in the end just render a specific view on matching URL:s. It’s just an array with all instantiated views. Sometimes you don’t even need a view, only a Template associated with an URL. Okey, if you have six menus you can have six functions. But if the menu is three levels deep with six options on each you can’t have a route function for each view.

Navigation bar and breadcrumbs

This will be a view which is called from my complex logic above. If the navigation is multi level deep, this can be really complex.

My question is: Am I so unique here? If not, how do you solve this?

Is Backbone.js not right for me? What alternatives would fit better (oh yes, I’ve searched)?

Thank you for your time, I really appreciating all your ideas.

Answer 1

I would say there are two factors at play here:

1. Backbone applications do easily become verbose, because the framework itself is so small and simple. For every feature and line of code Backbone doesn’t have, you have to write. This is part of its underlying philosophy. Quoting from the docs:

   Backbone.js aims to provide the common foundation that data-rich web applications with ambitious interfaces require — while very deliberately avoiding painting you into a corner by making any decisions that you’re better equipped to make yourself.

   So it’s a tradeoff. There are other, more holistic frameworks such as Ember.js and AngularJS, which tend to generate far less boilerplate code in your own codebase. Both of them are top-notch frameworks, and something you might want to look at. The tradeoffs, of course, are larger framework size, more third-party complexity, and a risk that you’ll “paint yourself in the corner”.

   If you want to stay with Backbone, but you feel you need some more help from the framework, look into Backbone.Marionette. I haven’t personally used it, but to me it looks like a great way of solving many common problems with less code and a maintainable structure.

2. You could probably do better with just Backbone. The Backbone Model–View–Router pattern can only get you so far, when talking about complex, larger applications, and Backbone is not particularly great at showing you the right way.

   When you start repeating code, you have to refactor, generalize and keep it DRY. For example:

   • To define a loading icon in one place, hook into jQuery.ajax events or override Backbone.sync.
   • For simple route actions define a declarative route->view map, use optional route parameters and autowire dependencies as needed. Make these hierarchical and generate a navigation view component based on this map.
   • Hook up your breadcrumb to Backbone.history.navigate and map route fragments to localized UI texts automatically on route change.

   .

   I’ve managed to get Backbone applications to scale from tiny 50-liners to 50 000+ LOC beasts by applying some general software development patterns, encapsulating logic into base classes, services, utilities, widgets, decorators, mixins and what-have-yous. It’s really no different from a large Rails project: when the application grows in complexity and size, the demand for code hygiene and structured patterns grows.

   To transfer the generalized solutions between projects, create standalone components out of each of them. Of the examples you provided, I can see a Backbone.LoadingIndicator, Backbone.Navigation and Backbone.Breadcrumb forming quite easily. To take this further, package your components with something like Bower and include them as dependencies in your projects.

There’s no correct answer to your question, but it’s safe to say that Backbone apps scale well beyond what you’ve described. It just expects you to do the scaling, and in return it gives you the freedom to build your application the way your application needs to be built, not in the way a frameworks says you have to. Choice is yours, as always.