Why Use Backbone.js?
The Web Dev Zone is brought to you in partnership with Mendix. Discover how IT departments looking for ways to keep up with demand for business apps has caused a new breed of developers to surface - the Rapid Application Developer.
much matured recent time, I still see a lot of confusion about usage of
different frameworks and libraries.
For a half of year I use Backbone.js and feel
much satisfied with it. It's very popular library, probably because of
personal popularity of the creator of Backbone.js Jeremy Ashkenas, very much known also as author of CoffeScript language.
Frameworks and libraries
differences between frameworks and libraries. In one sentence, "library
is then you call some code, framework is then your code is called from
somewhere". The Backbone.js is clearly library. You usually have a lot
of different options with libraries and less with frameworks. It's very
At core it only contains of only 4 components
(Model, Collection, View, Router). This minimalism is both power and
weak side of Backbone.js. The power is that you can build things
whatever you like, Backbone fits the experience really smoothly. In the
same time, you are really confused the time you just started, since you
simply don't understand how to make everything work together properly.
The essence of Backbone.js
In one of
the podcasts with Jeremy, he said "Backbone is something that almost
applications for a while". I could not agree more. If you have previous
experience in programming and you see the value of architecture and
design, you will definitely start to invent something similar to
After some time spend of development jQuery based
application you will realize many fundamental issues, like: data does
not belong to DOM, events are not limited on jQuery and so on. But the
main issue is jQuery apps usually violates the "Single Responsibility
Principle", mixing and manipulation with data and views in the same
time. Experienced developers, tries to eliminate SRP issues as soon as
possible, almost naturally coming to MVC pattern.
In essence the Backbone is a way to structure you
application better. It makes clear de-coupling between data and views
that render that data. It's nothing more than that.
Abstracting things out
Programming is a matter of abstractions. As better abstractions you have as better code you have.
Every application works with data. The data does
not appear in browser just like that, it have to fetched from somewhere.
It's also have to be persisted somewhere. The data could be changed and
you have to validate that change is right. If some part of data is
changing, you want to be notified on that change. Notice that, this is a
very common functionality you want to keep between all data classes -
initialization, validation, persistence. This is where the Backbone.Model comes out. With Backbone.Model all that things are already "in the box" you just need to apply your own strategies of implementation.
You typically don't deal with one instance of model. REST interfaces are usually expose something like /api/tasks or /api/photos
and so on. You need to group the models into collections. Collection
(similar to model) are able fetch and persist itself, all it needs to
know is the actual type of Model and URL. This is where Backbone.Collection
shies. You are keeping all models close together, if some model become
destroyed the collection will be updated, so it always in consistent
With view is basically render your models as DOM structure. So, the Backbone.View is abstraction with primarily method - render.
Backbone does not say, how exactly you are going to do that. You can
create handcrafted HTML and append it DOM, or use some templating
mechanisms. Instead, it provides you convenient methods for listening to
view events (like clicks, focusout or any other DOM supported events).
Inside the handlers you either could update related model or apply some
changes to view parts, whatever.
And finally Backbone.Router is a
facility to building, so called Single Page Applications (SPA). SPA's
most popular example is GMail. You browsing emails, writing and sending -
without and page reloads. What's changing is only hash part of URL
(like #inbox, #sent, #all). Router is handling hash change events and
triggers registered handler. Inside the handler, you can initialize the
Don't repeat yourself
Now, please let
me know. How many times did you create (read copy-n-paste) the code for
RESTful data persistence? How many times, you did you create code for
validation? How many hours you spend for looking for some event listener
provoking the bug in your app and hiding somewhere among 200 .js files?
If your answer, more that 2 - stop doing that. Don't repeat yourself - reuse. And better - reuse from best.
There are great solutions, created by people experienced than me, amplified by huge community behind. Backbone.js is one best representatives of such solutions. Having a something that I could rely on, that works good and there places to get help is very strong reason for me, to keep doing that, instead of re-invent wheel yet another time.