Well that seems incredibly useful.

The new-ish methods are handy when your models live longer then your views do. Because this inversion tracks the listeners on the object that's listening to events, instead of the object that's emitting them, it makes it easier to unbind all of the things a view is listening to, when you want to remove just that view. To that end, `view.remove()` stops listening automatically.

First I'm hearing of Lo-Dash. How long has this been in the Backbone.org docs?

Appears there was a fair bit of tension in it's dev history. Eg: https://github.com/documentcloud/underscore/commit/4e4bc194c...

https://github.com/bestiejs/lodash/blob/master/lodash.js#L35...

It's a very fun bit of code, and a great example of how differently a fork can be implemented while preserving more or less the same API. There's never been any tension about the project itself -- just about some of the "marketing" methods used to pitch it in the past. That said, Lo-Dash's main developer is contributing to Underscore directly as well these days, so it's all copacetic.

> Model validation is now only enforced by default in Model#save and no longer enforced by default upon construction or in Model#set, unless the {validate:true} option is passed.

From the documentation on Model#set:

> If the model has a validate method, it will be validated before the attributes are set, no changes will occur if the validation fails, and set will return false. Otherwise, set returns a reference to the model. You may also pass an error callback in the options, which will be invoked alongside the "error" event, should validation fail.

Is the documentation out of sync, or do I not understand the changelog correctly?

---

Anyone know the best way to make it so set defaults to {validate:true}? Override Backbone.Model.set, extend options and call original?

Only reason it's tricky is because there are two different forms of attributes that can be passed to set. Something like this should work:

  var oldSet = Backbone.Model.prototype.set;
  Backbone.Model.prototype.set = function(key, val, options) {
      if (key == null) return this;
      if (typeof key === 'object') {
        options = val;
      }
      options || (options = {});
      options.validate = true;
      oldSet.call(this, key, val, options);
  };

I've been writing my first single-page app (yeah, yeah, behind the times) using Backbone, and at first it was really exciting and intuitive, but I'm starting to realize Backbone is a pretty, er, bare-bones lib. Everyone seemed to suggest Handlebars as a template lib, so I added that to my project, and RequireJS to manage those two libs and their dependencies, and the RequireJS text plugin to load templates from other files in the project, and now it all just seems like a mess. The promise of a framework with everything you need, right out of the box, is tempting.

Edit: Most of the alternatives (e.g. Ember, Angular, Knockout, Meteor, etc.) are already in my bookmarks. I'm looking for reports from people who actually used the things, not links.

I think that a lot of people dismiss Angular as yet-another-mvc-framework without ever discovering the key elements of Angular that are actually novel and worthy of study. Personally, I think that Angular is a local maximum in client-side JavaScript app development. But even if you don't agree, you should at least understand how it is different.

1) Angular prefers declarative

This doesn't mean you don't write procedural code. This means that if you want to do something proceedural, you should package it up as a Directive. Directives are where behavior and logic live. Your templates simply arrange and parameterize a tree of directives. This means that you have limited and well understood moving parts that can be tested in isolation, in combination, or in the application context. Contrast with the traditional big bag of event callbacks, which can only be tested in the application context and are more difficult to re-use in other application contexts.

2) Angular works like a game engine

Most traditional UI frameworks are a graph of intertwined callbacks. Games, however, traditionally have a pair of functions called Update and Render. The Update functions permutes the world and the Render function draws the new world. Angular works similarly, but it might not be immediately obvious. There is a "Dirty Checking" pass, where your view models, a simple hierarchy of poorly-named "scopes" are essentially diff-ed against the previous iteration. Then the Directives take over and permute the DOM to match the new view model.

Let's call the "Controller" part of the "ViewModel" and then just simplify that down to "Model". Inherently, Model and View systems are co-dependent. You have a graph like M <--> V. Angular's system graph is less like single bi-directional edge, and more like two directed edges in a cycle. That makes little difference when viewed abstractly with the two subsystems as nodes. However, once you break M and V down into subgraphs, the traditional Model & View systems look like a spaghetti mess of bi-directional relationships. An Angular application, on the other hand, would look like less like a lattice and more like a circle.

Then I tried AngularJS and I was blown away. "Yes!" I exclaimed "JS/HTML5 has truly come of age". It is a beautiful thing that saves shit tons of time. And as I have got deeper into it, I hardly write JS anymore, YOU CAN DO 95% OF PRESENTATION LOGIC IN THE HTML. You can modularise. You can ... test! Its amazing. IT WILL ENABLE YOU TO STRUCTURE REALLY REALLY BIG PROJECTS! I hear similar evangelism from the knockoutJS community, so I am keen to try that out too, although I am getting pretty proficient with AngularJS and I personally think its got more chance of survival given its googly backers, and its more likely that chrome will start supporting AngularJS features natively. So I am betting on longevity as well as functionality with NG.

For us developers that have fought for years for separation between content, presentation, and logic, this is the very reason Angular/Ember/Knockout are not as popular as Backbone or other frameworks.

<input type="checkbox" ng-model="todo.done">

I guess I'm a purist.

Using xml namespace: <input type="checkbox" ng:model="todo.done">

Using underscore in the attribute name: <input type="checkbox" ng_model="todo.done">

As an x-* attribute: <input type="checkbox" x-ng-model="todo.done">

As a HTML5 data attribute: <input type="checkbox" data-ng-model="todo.done">

I think their may be a few more, but in any case, Angular is flexible enough that you can choose the representation that is best for you and your team.

I really don't want basic stuff in my application logic.

Allowing users to flip arbitrary booleans is a bit like declaring a public variable though. You can of course make them go through a setter if you prefer encapsulation.

<input type="checkbox" ng-click="setDone($event.target.checked)">

AngularJS is great for simple apps but once I got beyond that I ended up fighting how to makes things work with the ng-* attributes often having to resort to $apply. Things that are simple with underscore templates and jQuery (the Backbone way) can become very frustrating in AngularJS.

AngularJS reminds me of ASP.NET controls with repeaters and coding through attributes. That works for a lot of people but I'm more comfortable with templates and jQuery.

https://github.com/tbranyen/backbone-boilerplate

http://walmartlabs.github.com/thorax/

https://github.com/marionettejs/backbone.marionette

https://github.com/chaplinjs/chaplin

Outside of Backbone, there's also http://emberjs.com/

I would say with Angular, what you write is not javascript , it is Angular JavaScript, which gets compiled into javascript on running over compiler. Having been worked with GWT for many years, I am disappointed with Angular doing the same mistakes of not allowing the developers to think in terms of Javascript. But in terms of the framework, which they had brought in.

However, Backbone gives me lot of freedom in customizing the app by adding Javascript and using its model view observable logic. If i find any shortcoming in backbone, i can see a plugin available in the Community. Which is really great.

To conclude , If your are experienced JS developer (JS ninja), you will love backbone. If you are intermediate/beginner JS developer you will love angular. However, this is just my perspective.

Backbone: http://javascriptjabber.com/004-jsj-backbone-js-with-jeremy-... Ember: http://javascriptjabber.com/034-jsj-ember-js/ Angular: http://javascriptjabber.com/032-jsj-angular-js/ Knockout: http://javascriptjabber.com/013-jsj-knockout-js-with-steven-... enyo: http://javascriptjabber.com/033-jsj-enyo-js/

[1]http://javascriptjabber.com/

http://stackoverflow.com/questions/6548826/angular-js-vs-bac...

markme (in AngularJS) : http://markme.alwaysdata.net/

which is a clone bookmarly.com , done with backbone.

The source is here :

https://github.com/Mparaiso/silex-bookmarkly

AngularJS is great , it doesnt do everything so you still need to build your own stack, as for backbone ( jquery ,bootstrap, and even requirejs as it doesnt do AMD out of the box ... ). It comes with a lot of testing tools , make it easy to mock backends , DOM elements ...

It is the best frontend framework for LOB , period. It has builtin form support , filtering , validation , is easy to integrate with bootstrap , and extend , and produce sane code , unlike ExtJS for instance( SenchaTouch is however very good for mobile apps , it is blazing fast. ).

If you are doing some animation heavy stuff ,where you need total control over dom elements lifecycle , i would not recommand it, backbone is better for that , i still use backbone for data light apps.

There is always the compromise, however, in that frameworks that have "everything" tend to force you to abide by their view of the world. AngularJS, for instance, offers many arguable advantages for some tasks, but can turn into an enormous impediment whenever you want to go outside of the painted lines. Of course opinions differ, but I prefer that relative simplicity of backbone -- it is more convention than framework, really -- because it scales to full-products with less friction.