What does Backbone.js or other MVC offer?

I'm beginning with backbone.js

Going through some tutorials, like the one shown below. I got the feeling, it is really more about how to organize your objects and how to instruct them to interact. And I can do them without backbone.js So backbone.js looks more like a set of rules, philosophies to me, then an actual plug-in for the most part. Is that what it is?

(function($){
  var Item = Backbone.Model.extend({
    defaults: {
  part1: 'hello',
  part2: 'world'
  }
 });      

 var List = Backbone.Collection.extend({
    model: Item
 });

var ListView = Backbone.View.extend({
el: $('body'),
events: {
  'click button#add': 'addItem'
},
   initialize: function(){
  _.bindAll(this, 'render', 'addItem', 'appendItem'); // remember: every function that uses 'this' as the current object should be in here

  this.collection = new List();
  this.collection.bind('add', this.appendItem); // collection event binder

  this.counter = 0;
  this.render();      
},
render: function(){
  $(this.el).append("<button id='add'>Add list item</button>");
  $(this.el).append("<ul></ul>");
  _(this.collection.models).each(function(item){ // in case collection is not empty
    appendItem(item);
  }, this);
},
// `addItem()` now deals solely with models/collections. View updates are delegated to the `add` event listener `appendIt开发者_运维知识库em()` below.
addItem: function(){
  this.counter++;
  var item = new Item();
  item.set({
    part2: item.get('part2') + this.counter // modify item defaults
  });
  this.collection.add(item); // add item to collection; view is updated via event 'add'
},
// `appendItem()` is triggered by the collection event `add`, and handles the visual update.
appendItem: function(item){
  $('ul', this.el).append("<li>"+item.get('part1')+" "+item.get('part2')+"</li>");
}
});

var listView = new ListView();
})(jQuery);

---

Backbone.js, underscore.js and jQuery (they are all interdependent) are an pragmatic abstraction layer and toolset over javascript that allow you to organize your business logic, templates, and models.

The key benefit of this is code readability (for long term projects/projects with multiple members), general good practice around organization of discrete parts (keeping your HTML out of your business logic, for example), time afforded to work on the hard/fun parts of your project as opposed to re-inventing the wheel on different browser compatibility issues, and (in the case of underscore) a great toolset to help you manage javascript objects, arrays, functions etc. for safe and sane programming.

Basically, if you choose not to use these tools, you are either prototyping something or have all the time in the world on your hands. If time and sanity is something you enjoy, don't be afraid to use them!

---

Backbone offers a cleaner separation of concerns that allows you to write cleaner code. I wrote a very elaborate rich client using jQuery without backbone. I had to store a lot of metadata directly on my DOM elements. This means I also had to interrogate my DOM elements periodically to read/use that metadata. While you can make anything work with the tools you've got, some tools make things easier (and cleaner).

With Backbone, your models store all your pertinent information. You don't need to store as much stuff inside DOM attributes. Each model exists only once so for any one fact (e.g. the first_name of a given person model) you have a Single Point Of Truth, the model itself. You're using the model to track its own facts, not the DOM. I guarantee your code will be much cleaner.

Backbone isn't a tool for all things. It makes sense to use it when your representing models (things that exist in your backend database) in the browser.

---

You are bang on, its mostly a philosophy on how to structure large js apps, with all the plumbing handled for you.

Backbone is still in its infancy, but it has a lot of traction. Even if you aren't too impressed now, I would keep an eye on it.

---

I'd say that the primary functionality that is supplied by Backbone.js is in fact the event model. And yea, it's possible to code this by hand, because it's an indeed simple model.

In case of Spine.js, a very similar library I'd say that the other feature that it offers is Class, a wrapper around javascript prototypes.

That said, there are I think quite a few important caveats that you'd like to get right. These caveats are among other things:

• When exactly are your events triggered?
  • Is it like in case of Backbone.js detected automatically?
  • OR do you want like in Spine.js to do that explicitly by calling save()
• If there are two functions triggered in response to an event and they receive a model instance:
  • Do they receive the same instance - i.e. changes done by one of them will be immediately visible to the other
  • OR do they receive some kind of copies. If copies:
    • Will they react to future changes on the model,
    • OR won't they
• The list goes on...

There are surprisingly many things to get right. I'm definitely biased, because I find the choices done by Backbone.js awfully cumbersome. I clearly like Spine.js much better. However I'd encourage you to look for some nontrivial examples of use-cases for both libraries and to make your mind for yourself.

It might be the right choice to go on and implement all of this yourself - Spine.js core is just 2KB of minified code. However I'd strongly encourage you to try to learn on others mistakes. There are plenty of things to get wrong in my opinion.