Why Use Backbone.js?
Even JavaScript language and front-end development has been 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
There are 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 minimalistic, actually.
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 every developer will come to theirselves.. dealing with JavaScript 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 Backbone.
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 state.
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 corresponding application.
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.
Conclusions
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.
Even JavaScript language and front-end development has been 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
There are 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 minimalistic, actually.
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 every developer will come to theirselves.. dealing with JavaScript 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 Backbone.
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 state.
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 corresponding application.
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.
Conclusions
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.