Structuring a Backbone.js Application


We recently made the decision to adopt Backbone.js as a foundational technology for HiringThing, and I thought I’d share some of our thinking and design that’s gone into our first forays.

Our current UI has been received very well by customers, however the underlying technology doesn’t quite have the flexibility we’d like to have moving forward. Newer javascript frameworks offer some great benefits for flexibility, maintainability and ease of development. And so, we began a review of all javascript frameworks we could lay our hands on, including AngularJS , Ember , Meteor and others.

We whittled down the list based on a number of factors, including available documentation, community activity and maturity… in the end, we decided on Backbone.js as our pick.

Using Backbone

Backbone is a relatively unopinionated framework, meaning that unlike frameworks that prescribe how to do things in a specific way, you are expected to mix and match the tools provided into whatever structure works for you. Although it means a little more work, this was a plus to me, as we’re able to design our UI architecture to match the way our system and team works.

Templates

Another decision was what templates to use. For those unfamiliar, javascript templates allow you to combine data and html on the fly, and are very useful for managing the view state of javascript applications. It makes it easy to update specific components and widgets in your UI any time your data changes.

There are a number of options for templates, including Handlebars and Mustache , however the main decision seems to be between templates that allow logic, vs. those that don’t.

In my opinion, logic-less templates are best for large teams of developers, where stability, maintainability and separation of concerns are critical. The tradeoff is that you lose the ability to make big changes quickly, and huge amount of flexibility that logic in the template allows. Some people get very worked up about why you should use one type over the other! It’s not a holy war for me, but I chose to go with templates that allow logic – it just seems more powerful for our small, highly-experienced team.

Underscore (which Backbone requires) includes built-in templates that allow full use of javascript – which we decided to go with rather than adding another library.

Application Structure

As I mentioned, Backbone is unopinionated, and so leaves you to construct the structure of your application as you’d like it. I’ve worked on javascript projects without a structure of any kind and knew from the beginning I wanted to design a predictable, reusable structure that would be shared by all our Backbone applications, and hopefully make them as portable as possible.

There are plenty of tutorials online about how to get started from scratch with Backbone (a quick search will get you started if you need a baseline), but precious little on how to organize applications. Here’s what we came up with as a directory structure for our Job Description Wizard:

  • /DescriptionWizard*
    css # css files specifically related to the UI app
    images # image files specifically related to the UI app
    models # Backbone models, which represent data
    routers # Backbone routers, which match requests to code
    templates # .JST template files, which are rendered with data
    —— components # reusable template components
    —— layout # common display templates, like header and footer — views # Backbone views, which do all the work
    wizard_app.js # initializing code, included on the HTML page to start the app

Deployment

Our Rails app uses Jammit (an alternative to the newer built-in asset pipeline) to compress and combine javascript files in production. Using it, we don’t have to feel guilty about including 20 or more .js files with every page load, as Jammit will take care of combining them into one tiny download for use in our live application.

Another nice feature is that Jammit precompiles all of our templates, speeding up our application and simplifying the use of templates in our code. We simply declare a template function in our assets file, and whenever we include a template file on a page, Jammit will have it loaded up and ready to use in a global template collection.

Moving Forward

We’ll be making some nice upgrades to our user interface over the next few months, many of them based on Backbone. Stay tuned!

HiringThing

Author: HiringThing

HiringThing is easy to use, intuitive online recruiting software that makes it easy to post jobs online, manage applicants and hire great employees.