It seems like every week there's a new JavaScript framework that claims to simplify the process of bringing desktop-like interactivity to web applications. The number of these libraries and frameworks seems to have exploded within the last year, and although they all attack the problem in different ways (and arguably all play some small role in pushing things forward), some are definitely more interesting than others. Unfortunately only a few things that seem interesting at first glance get a closer look, because, after all, we've got actual production code to write. Right?

When a few fellow developers that I respect started talking about Backbone.js, I liked what I heard. A few weeks later, I finally had some free time to play around with it :). After spending a mere 15 minutes thumbing through a tutorial, I already liked this framework for its sheer simplicity and reliance on existing conventions. Weighing in at under 1000 lines of code, less than 4kb minified and gzip'd, Backbone does an awful lot in a very natural way, without lots of new jargon to learn or a complicated directory structure. Backbone follows basic REST conventions, so it's easy to work it into your infrastructure if you're already following this pattern on the server side (using Rails or an equivalent MVC framework).

Backbone encourages users to decouple their data from their DOM elements and use its own concept of Models. Those data models can be -- surprise -- created, validated, saved to a server, destroyed; standard CRUD operations that you're already familiar with. When a user interacts with a model, a change event is fired, which will tell all of the Views that hold a reference to that model to update themselves, thus eliminating a ton of ugly view code that we use to control visual updates in modern JavaScript-heavy web UIs. Unlike a "View" in a traditional MVC framework, an individual Backbone "View" often manages a much smaller portion of a web page, like an item in a list or an on-screen widget. Backbone also offers support for collections of models of course, and you can leverage events with these collections in similar ways, such as when an item is added or removed from a collection.

In addition to offering abstractions for Model and View components, Backbone also has a concept of a Controller, which is not entirely dissimilar from the one found in Rails or other MVC frameworks. Backbone's Controller, however, acts as a router and intermediary between #hash fragment-friendly URLs and your own actions and events. This means that is also has a notion of browser history baked-in (Backbone.history) which allows you to use the back button in your browser in a sane manner for navigation.

And of course, it all plays nicely with jQuery.

DocumentCloud, the organization that has open sourced Backbone, is already using it in production and will be continuing to improve upon it. Other services already using Backbone include QuietWrite, Tzigla, MapBox, and 37 Signals' Basecamp Mobile product. Although existing production deployments may not be a prerequisite to deploying a library in your own application, it certainly helps to know that others are depending on the long-term health of the code.

All in all I really dig the approach that Backbone takes to structured JavaScript development. It's simple, it's lightweight, and it gets out of my way and allows me to concentrate on building application logic rather than managing lots of unnecessary glue code. If you want to see a live example of Backbone in a simple application (which for me is always the best way to start evaluating a technology), their example todo list application (with local storage) is very straightforward and easily grokked. There's also an excellent introductory piece over at Liquid Media, and an even more in-depth tutorial written by the author of QuietWrite.

The Backbone.js source is hosted on GitHub. Check it out, and let me know what you think!