I tried to understand the utility of backbone.js from its site http://documentcloud.github.com/backbone, but I still couldn't figure out much.
Model is part of your code that retrieves and populates the data,
View is the HTML representation of this model (views change as models change, etc.)
Some pros that I discovered with Backbone:
jQuery.data(bla, bla): no need to store data in DOM, store data in models instead
event binding just works
extremely useful Underscore utility library
backbone.js code is well documented and a great read. Opened my eyes to a number of JS code techniques.
Here is a set of great tutorials on using Backbone with Rails as the back-end:
CloudEdit: A Backbone.js Tutorial with Rails:
p.s. There is also this wonderful Collection class that lets you deal with collections of models and mimic nested models, but I don't want to confuse you from the start.
If you're going to build complex user interfaces in the browser then you will probably find yourself eventually inventing most of the pieces that make up frameworks like Backbone.js and Sammy.js. So the question is, are you building something complicated enough in the browser to merit using it (so you don't end up inventing the same thing yourself).
It's that kind of app that these frameworks excel at making easier to develop. Without them you'll either end up glomming together a diverse set of individual libraries to get parts of the functionality (for example, jQuery BBQ for history management, Events.js for events, etc.) or you'll end up building everything yourself and having to maintain and test everything yourself as well. Contrast that with something like Backbone.js that has thousands of people watching it on Github, hundreds of forks where people may be working on it, and hundreds of questions already asked and answered here on Stack Overflow.
It's a front-end library, you include it in your web page with a script tag. It only affects the browser, and says little about your server, except that it should ideally expose a restful API.
If you have an API, Backbone has a few helpful features that will help you talk to it, but you can use Backbone to add interactivity to any static HTML page.
Backbone seeks to answer these questions by giving you:
We call this an MV* pattern. Models, Views and optional extras.
Despite initial appearances, Backbone is fantastically light, it hardly does anything at all. What it does do is very helpful.
It gives you a set of little objects which you can create, and which can emit events and listen to each other. You might create a little object to represent a comment for example, and then a little commentView object to represent the display of the comment in a particular place in the browser.
You can tell the commentView to listen to the comment and redraw itself when the comment changes. Even if you have the same comment displayed in several places on your page all these views can listen to the same comment model and stay in sync.
This way of composing code helps to keep you from getting tangled even if your codebase becomes very large with many interactions.
When starting out, it's common to store your data either in a global variable, or in the DOM as data attributes. Both of these have issues. Global variables can conflict with each other, and are generally bad form. Data attributes stored in the DOM can only be strings, you will have to parse them in and out again. It's difficult to store things like arrays, dates or objects, and to parse your data in a structured form.
Data attributes look like this:
<p data-username="derek" data-age="42"></p>
Backbone solves this by providing a Model object to represent your data and associated methods. Say you have a todo list, you would have a model representing each item on that list.
When your model is updated, it fires an event. You might have a view tied to that particular object. The view listens for model change events and re-renders itself.
Backbone provides you with View objects that talk to the DOM. All functions that manipulate the DOM or listen for DOM events go here.
A View typically implements a render function which redraws the whole view, or possibly part of the view. There's no obligation to implement a render function, but it's a common convention.
Each view is bound to a particular part of the DOM, so you might have a searchFormView, that only listens to the search form, and a shoppingCartView, that only displays the shopping cart.
Views are typically also bound to specific Models or Collections. When the Model updates, it fires an event which the view listens to. The view might them call render to redraw itself.
Likewise, when you type into a form, your view can update a model object. Every other view listening to that model will then call its own render function.
This gives us a clean separation of concerns that keeps our code neat and tidy.
You can implement your render function in any way you see fit. You might just put some jQuery in here to update the DOM manually.
You might also compile a template and use that. A template is just a string with insertion points. You pass it to a compile function along with a JSON object and get back a compiled string which you can insert into your DOM.
You also have access to collections which store lists of models, so a todoCollection would be a list of todo models. When a collection gains or loses a model, changes its order, or a model in a collection updates, the whole collection fires an event.
A view can listen to a collection and update itself whenever the collection updates.
You could add sort and filter methods to your collection, and make it sort itself automatically for example.
As much as possible, application components are decoupled from each other. They communicate using events, so a shoppingCartView might listenTo a shoppingCart collection, and redraw itself when the cart is added to.
shoppingCartView.listenTo(shoppingCart, "add", shoppingCartView.render);
Of course, other objects might also be listening to the shoppingCart as well, and might do other things like update a total, or save the state in local storage.
Decoupling your objects like this and communicating using events means that you'll never get tangled in knots, and adding new components and behaviour is easy. Your new components just have to listen to the other objects already in the system.
Code written for Backbone follows a loose set of conventions. DOM code belongs in a View. Collection code belongs in a Collection. Business logic goes in a model. Another developer picking up your codebase will be able to hit the ground running.
Backbone is a lightweight library that lends structure to your code. Components are decoupled and communicate via events so you won't end up in a mess. You can extend your codebase easily, simply by creating a new object and having it listen to your existing objects appropriately. Your code will be cleaner, nicer, and more maintainable.
I liked Backbone so much that I wrote a little intro book about it. You can read it online here: http://nicholasjohnson.com/backbone-book/
I also broke the material down into a short online course, which you can find here: http://www.forwardadvance.com/course/backbone. You can complete the course in about a day.
Here's an interesting presentation:
Hint (from the slides):
JQuery and Mootools are just a toolbox with lot of tools of your project. Backbone acts like an architecture or a backbone for your project on which you can build an application using JQuery or Mootools.
This is a pretty good introductory video: http://vimeo.com/22685608
If you are looking for more on Rails and Backbone, Thoughtbot has this pretty good book (not free): https://workshops.thoughtbot.com/backbone-js-on-rails
I have to admit that all the "advantages" of MVC have never made my work easier, faster, or better. It just makes the whole codeing experience more abstract and time consuming. Maintenance is a nightmare when trying to debug someone elses conception of what separation means. Don't know how many of you people have ever tried to update a FLEX site that used Cairngorm as the MVC model but what should take 30 seconds to update can often take over 2 hours (hunting/tracing/debugging just to find a single event). MVC was and still is, for me, an "advantage" that you can stuff.
With backbone you got freedom to do almost anything you wish for. Rather than trying to fork through the api and customize I would use Backbonejs for it's simplicity and ease of implementation. Again it is hard to say what you require out of the two one is a library another a component
Backbone helps developers manage a data model in their client-side web app with as much discipline and structure as you would get in traditional server-side application logic.
Additional benefits of using Backbone.js
It also adds routing using controllers and views with KVO. You'll be able to develop "AJAXy" applications with it.
See it as a lightweight Sproutcore or Cappuccino framework.
Is an MVC design pattern on the client side, believe me.. It's gonna save you tons of code, not to mention a more clean and clear code, a more easy to maintain code. Could be a little tricky at first, but believe me it's a great library.
So many good answers already. Backbone js helps to keep the code organised. Changing the model/collection takes care of the view rendering automaticallty which reduces lot of development overhead.
Even though it provides maximum flexibility for development, developers should be careful to destroy the models and remove the views properly. Otherwise there may be memory leak in the application.
A web application involving lot of user interaction with many AJAX requests, which needs to be changed from time to time, and which runs in real time (such as Facebook or StackOverflow) ought to use an MVC framework such as Backbone.js. It's the best way to build good code.
If the application is only small though, then Backbone.js is overkill, especially for first time users.
Backbone gives you client side MVC, and all the advantages implied by this.
©2020 All rights reserved.