I have used both in my startup job and vastly prefer angular to backbone, however I think it's not quite an apples to apples comparison as angular provides a lot more than backbone.
That isn't meant as a criticism of backbone per se, rather I think they are actively going for different things - backbone makes it easy to achieve a client-side rendered single page website with MVC separation but lets you control actual rendering and data binding, i.e. maximal control, whereas angular allows you to do the same thing but provides 2-way data binding, code/html reuse via directives [0], local scoping of data on DOM elements [1], dependency injection [2], vastly improved testability [3] and lots more.
My experience of actually developing websites with both is that angular is a better experience and involves a hell of a lot less boilerplate than backbone and even though, when it doesn't work, it can be infuriating it is net a simply amazing framework.
Obviously I'm very biased and by my own admission my understanding of both is limited and I am certainly not the best developer ever blah, so take this with a pinch of salt. I think if you need maximal fine-grained control over the behaviour of your website while getting help with MVP you're better off with backbone, but in any other situation use angular (or possibly batteries-included alternatives like ember.js or knockout.js - I have no experience with them so can't comment there.)
After spending two or three months with Angular, I’m running away screaming. I really owe people a blog post about it, but basically, it’s hard to debug, weird for weird’s sake, and polluting of the HTML namespace. Death by a thousand cuts — and by disregard for best practice.
I'd be interested to read about your issues with it. It is definitely weird, but I don't think it's for its own sake, rather it's adding a new layer of abstraction which will always come off as a bit strange until you get used to it, e.g. lisp.
I've not had awful problems debugging it, certainly no more than any other js library spitting out "cannot read property 'foo' of null" all over the place with stack traces that give you no help, though I don't deny it can be a bitch.
I'm not sure I understand your point about polluting the HTML namespace - sure you can introduce new HTML tags which can conflict, but if you're careful it's not an issue (and you can choose what directives to make available in a given module.)
I think one key thing I'd say to newcomers to angular is that when it doesn't work it can be an absolute bitch to resolve problems, though you gradually adapt to its patterns over time and such pain reduces significantly.
Like I said in the grandmother* post I do think the positives outweigh the negatives. In fact, I think they MASSIVELY outweigh the negatives, easy 2-way data binding and the code/html reuse of directives alone are enough to make me love it, but hey I get where you're coming from on the painful aspects.
* A sad attempt at reducing sexism in tree analogies.
I do love having easy two-way data binding, too, certainly.
To clarify: When you use a directive with an "isolate scope", you have to pass it parameters in your template, which means using arbitrary "HTML attributes" in ways that do not, in fact, have anything to do with HTML attributes. E.g.:
Is it plausible that HTML eventually defines a meaning for `model` and/or `compact` attributes? Did you just write illegal HTML? Yes. Is there already a way to do this in HTML? Yes, the `data-*` attribute namespace is free to use.
The whole dirty-checking thing requires an insane amount of CPU work, sometimes. Once you’re doing 15 or 20 AJAX requests, your browser may use 100% CPU for minutes (and that’s on desktop)! Why? We aren’t exactly sure. But I have bumped into other people at local JS meetups who have experienced the same thing. (Their solution? Give up and use Backbone. Ours? Load fewer things. I think it may also be viable to do all your network requests out of the Angular context to avoid a full dirty-check cycle on each `readyStateChange` event, but that’s not entirely straightforward, either, since we used Angular services to create our models, which know how to load their own dependencies… ack… it’s a mess.)
Batarang[0] is chrome plugin that vastly helps with debugging angular. I also highly recommend approaching it from a TDD standpoint. The seed[1] project comes with a baked-in testrunner. This also helps you move away from direct dom manipulation unless absolutely necessary: treat it like the definition of an html DSL specific to your app.
I have to agree that it's hard to debug: AngularJS has this bad habit of complaining about an error without telling where it is. However, things really clear up once you dive in the source code. Now, I couldn't live without it :)
Polluting the HTML namespace? Have you looked at the emberjs (actually handlebars) generated html recently? View the generated output for everything that is bound and tell me you don't want to run away screaming.
Comments
I have used both in my startup job and vastly prefer angular to backbone, however I think it's not quite an apples to apples comparison as angular provides a lot more than backbone.
That isn't meant as a criticism of backbone per se, rather I think they are actively going for different things - backbone makes it easy to achieve a client-side rendered single page website with MVC separation but lets you control actual rendering and data binding, i.e. maximal control, whereas angular allows you to do the same thing but provides 2-way data binding, code/html reuse via directives [0], local scoping of data on DOM elements [1], dependency injection [2], vastly improved testability [3] and lots more.
My experience of actually developing websites with both is that angular is a better experience and involves a hell of a lot less boilerplate than backbone and even though, when it doesn't work, it can be infuriating it is net a simply amazing framework.
Obviously I'm very biased and by my own admission my understanding of both is limited and I am certainly not the best developer ever blah, so take this with a pinch of salt. I think if you need maximal fine-grained control over the behaviour of your website while getting help with MVP you're better off with backbone, but in any other situation use angular (or possibly batteries-included alternatives like ember.js or knockout.js - I have no experience with them so can't comment there.)
[0]: http://docs.angularjs.org/guide/directive
[1]: http://docs.angularjs.org/api/ng.$rootScope.Scope
[2]: http://docs.angularjs.org/guide/di
[3]: http://docs.angularjs.org/guide/dev_guide.unit-testing
After spending two or three months with Angular, I’m running away screaming. I really owe people a blog post about it, but basically, it’s hard to debug, weird for weird’s sake, and polluting of the HTML namespace. Death by a thousand cuts — and by disregard for best practice.
I'd be interested to read about your issues with it. It is definitely weird, but I don't think it's for its own sake, rather it's adding a new layer of abstraction which will always come off as a bit strange until you get used to it, e.g. lisp.
I've not had awful problems debugging it, certainly no more than any other js library spitting out "cannot read property 'foo' of null" all over the place with stack traces that give you no help, though I don't deny it can be a bitch.
I'm not sure I understand your point about polluting the HTML namespace - sure you can introduce new HTML tags which can conflict, but if you're careful it's not an issue (and you can choose what directives to make available in a given module.)
I think one key thing I'd say to newcomers to angular is that when it doesn't work it can be an absolute bitch to resolve problems, though you gradually adapt to its patterns over time and such pain reduces significantly.
Like I said in the grandmother* post I do think the positives outweigh the negatives. In fact, I think they MASSIVELY outweigh the negatives, easy 2-way data binding and the code/html reuse of directives alone are enough to make me love it, but hey I get where you're coming from on the painful aspects.
* A sad attempt at reducing sexism in tree analogies.
I do love having easy two-way data binding, too, certainly.
To clarify: When you use a directive with an "isolate scope", you have to pass it parameters in your template, which means using arbitrary "HTML attributes" in ways that do not, in fact, have anything to do with HTML attributes. E.g.:
<my-directive model="myModel.foo" compact="true"></my-directive>
Is it plausible that HTML eventually defines a meaning for `model` and/or `compact` attributes? Did you just write illegal HTML? Yes. Is there already a way to do this in HTML? Yes, the `data-*` attribute namespace is free to use.
The whole dirty-checking thing requires an insane amount of CPU work, sometimes. Once you’re doing 15 or 20 AJAX requests, your browser may use 100% CPU for minutes (and that’s on desktop)! Why? We aren’t exactly sure. But I have bumped into other people at local JS meetups who have experienced the same thing. (Their solution? Give up and use Backbone. Ours? Load fewer things. I think it may also be viable to do all your network requests out of the Angular context to avoid a full dirty-check cycle on each `readyStateChange` event, but that’s not entirely straightforward, either, since we used Angular services to create our models, which know how to load their own dependencies… ack… it’s a mess.)
FYI, you can prefix all of Angular's HTML additions with data-ng-* attribute.
That’s true for `ng-model` but is it true for parameters passed in to directives?
When you write directives you can define the attributes into which you pass parameters however you want, including making them HTML spec compliant.
Angular supports data-attributes as well.
Batarang[0] is chrome plugin that vastly helps with debugging angular. I also highly recommend approaching it from a TDD standpoint. The seed[1] project comes with a baked-in testrunner. This also helps you move away from direct dom manipulation unless absolutely necessary: treat it like the definition of an html DSL specific to your app.
0. https://chrome.google.com/webstore/detail/angularjs-batarang...
1. https://github.com/angular/angular-seed
I have to agree that it's hard to debug: AngularJS has this bad habit of complaining about an error without telling where it is. However, things really clear up once you dive in the source code. Now, I couldn't live without it :)
Polluting the HTML namespace? Have you looked at the emberjs (actually handlebars) generated html recently? View the generated output for everything that is bound and tell me you don't want to run away screaming.