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.
I think 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.
Thank you for putting into words what I have failed to whenever someone asks me why I chose Backbone for our app development over Angular. The lighter wait library and MV* ness of it just made more sense over tying so much to the UI.
Comments
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/
I think 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.
Thank you for putting into words what I have failed to whenever someone asks me why I chose Backbone for our app development over Angular. The lighter wait library and MV* ness of it just made more sense over tying so much to the UI.