

Backbone.js 1.1 is out - calebgilbert
http://backbonejs.org/

======
bratsche
For anyone who's looking for the changelog, it's at the bottom of the page so
it's easy to miss.

* Made the return values of Collection's set, add, remove, and reset more useful. Instead of returning this, they now return the changed (added, removed or updated) model or list of models.

* Backbone Views no longer automatically attach options passed to the constructor as this.options, but you can do it yourself if you prefer.

* All "invalid" events now pass consistent arguments. First the model in question, then the error object, then options.

* You are no longer permitted to change the id of your model during parse. Use idAttribute instead.

* On the other hand, parse is now an excellent place to extract and vivify incoming nested JSON into associated submodels.

* Many tweaks, optimizations and bugfixes relating to Backbone 1.0, including URL overrides, mutation of options, bulk ordering, trailing slashes, edge-case listener leaks, nested model parsing...

~~~
byroot
I don't think I'm very picky about versions meanings. But still the first two
items are huge breaking changes for a dot release...

If I hadn't left my previous job, It would take me a day or two to upgrade.
Even Rails 3.2 => 4 is more straightforward.

~~~
masterj
How?

* Made the return values of Collection's set, add, remove, and reset more useful. Instead of returning this, they now return the changed (added, removed or updated) model or list of models.

Given that calling `collection.add(foo)` returned `collection`, when were you
ever using the return value for anything? Going forward you might, but I would
be very surprised if much if any code was broken by this.

* Backbone Views no longer automatically attach options passed to the constructor as this.options, but you can do it yourself if you prefer.

This might require going through your code base, but it's just adding one line
in the `initialize` function:

    
    
        initialize: function(options) {
          this.options = options;
    

Annoying if you have hundreds of views that directly extend Backbone.View, but
not something that should take a day to fix?

Am I missing something?

~~~
ChiperSoft
The return values change matters if you are chaining actions anywhere, which
isn't that uncommon.

And yes, some people do have lots of views. In my current codebase we use
Backbone.View as the base of all our frontend web components. This won't take
us a day to update, but it's far from trivial, and we will have to regression
test every component.

~~~
jashkenas
This should actually only take you 2 minutes if you'd like to keep the old
behavior ... regardless of how many View classes you happen to have in your
app. For example:

    
    
        var originalView = Backbone.View;
        Backbone.View = function(options) {
          var instance = new originalView(options);
          instance.options = options;
          return instance;
        };
    

Ahh..., isn't JavaScript just a lovely thing ;)

~~~
byroot
Sure you can hack things up like that. But when you use and update a library,
you don't want to rely on deprecated behaviors.

------
visarga
How is Backbone faring against AngularJS these days ?

~~~
epidemian
We were lucky to have jashkenas for a talk last week, and one of the questions
he answered was how Backbone compares to Angular and Ember.

One of the key differences in philosophy with Angular is that Backbone tries
to separate the UI representation from the core logic of your app by focusing
on having rich models (alla MVC). Your models should have meaningful domain-
related methods, and they should not know at all about the UI at all. Then
have the UI observe those models.

In Angular, while it still draws a line between the UI and the rest of your
app, there's not much focus on having rich model objects. However you want to
represent your data is up to you, as long as you update the properties of
$scope to have the views know about it.

Another key difference is the size of the feature set of each framework. While
Backbone tries to give you the basic components for building a JS rich app and
lets you decide how to solve no-so-basic things, Angular goes for a more full-
featured approach.

An obvious example of this is view rendering. Angular provides templates with
data-binding, filters, a way to abstract new "components" though directives
and probably much more (disclaimer: i'm not an Angular user). In Backbone, on
the other hand, the View#render method is empty, up to you to do whatever you
want. You might simply use _.template and $.fn.html, or you can use some
library to handle the data-binding (e.g. Rivets.js [1]).

This difference in feature coverage also reflects in the code size of the
frameworks. You can totally read, and understand, Backbone's whole source code
in an afternoon or probably less.

\----

Personally, i'm not fond of the monolithic approach of Angular. In fact, i'd
really love to see Backbone taking an even more minimalistic approach and
decomposing its components even further: make the events, models&collections,
REST handling, views and routing be separate libraries, and have "Backbone" be
just a namespace with these things in it.

It's not that opting-out Backbone's specific features is difficult (it's
actually very easy, as there's very little magic to what it does). But, for
example, i don't think what Backbone provides for dealing with UI (basically,
tracking of the DOM element associated with it and listening to DOM and model
events... and a dependency of jQuery) is useful if you're going to use some
library for data-binding. So, in that case, i'd prefer to opt-out and not even
have Backbone.View lingering around. It'd be awesome to be able to do that by
just removing a "backbone-views" dependency from the project.json file hehe.

Anyways, i think it's cool to have some healthy competition on this front of
web development; there's still much to be polished.

[1]: [http://rivetsjs.com/](http://rivetsjs.com/)

~~~
tuxracer
I think [http://chaplinjs.org/](http://chaplinjs.org/) provides a nice happy
medium between the two approaches. It extends (does not fork) Backbone objects
to solve those no-so-basic things for you. Yet it still keeps the UI as
separated from the core logic of your app as much as vanilla Backbone.

Less tediousness than vanilla Backbone and a cleaner separation from UI and
core logic than Angular.

------
sidcool
No direct link to Change log. :(

~~~
hellosmithy
[http://backbonejs.org/#changelog](http://backbonejs.org/#changelog)

