I had the same question after trying to use Backbone on a couple different small projects and giving up after seeing it introduce more complexity that I saw it removing.
Recently, I discovered Knockout.js, which is a "competitor" to Backbone with what I think is a clearer interface and a much clearer value proposition. I've had a lot of success with Knockout and fully expect that, like Sinatra did to me with Rails, Knockout will teach me to appreciate Backbone soonish. In the meantime, here's the knockout pitch:
What Knockout does is allow you to keep separate models (which are plain-old Javascript objects; Knockout doesn't need to infect them or enforce any kind of structure to them at all) and DOM UI. Knockout's job is to keep the two in sync. For instance, if you have an array of Foo's rendered in a table, Knockout allows you to bind a "foreach" to the table's body, effectively turning a single TR into a template for each Foo. Then, if the elements of the Foo array change dynamically, Knockout makes the table reliably reflect the constitution of the array.
The core value here isn't "templating". It's "keeping the DOM in sync with Javascript objects".
Off the top of my head, I think we're talking about 3 lines of code to get that functionality: the data-bind attribute on the TBODY element, the ko.observableArray() that wraps your otherwise plain array of Foos, and the ko.applyBindings(RootModel, RootDomElement) call that kicks off Knockout.
The same functionality would probably cost 10-20 lines of jQuery; more importantly, that jQ code would be fiddley, not at all declarative, and duplicated every place you wanted to bind an array to some repeating DOM structure. Knockout is here, to my eyes, a clean win.
Or take forms: you bind (with data attributes) INPUT elements to Javascript objects, so that what their values are changed by user input, the Javascript objects automatically reflect their new values. The JS code that then cares about the value of these objects doesn't ever need to scrape out the values of forms, and can reliably assume whatever's in the fields or hashes or whatever you set up is going to be current input. Also: you can bind multiple form inputs to the same data and keep them in sync, which I found to be a pleasant way to implement an "Advanced Search" feature.
What I didn't like about Backbone was the notion it had of "Models" and "Routers" and stuff like that. I'm sure that's valuable structure to have, but I like the flexibility --- and, more importantly, the freedom for More Stuff I Have To Memorize --- that comes with the KO.js approach.
Recently I discovered AngularJS (http://angularjs.org) by some of the guys at Google. I spend most of my time on the backend and have never been a fan of JavaScript, but the AngularJS declarative design really caught my eye. It's so clean and so simple. I think it's brilliant.
A colleague and I are using it, and it's been great thus far. The learning curve is a bit steeper than other similar frameworks, but once you get the hang of it, development is very quick. The Angular guys are very helpful as well.
I'm using it on a project right now. It's my first project with it, but so far so good. The tutorial is quick and straightforward, and it really gives you a flavor for it (http://docs.angularjs.org/tutorial/).
AngularJS is a lot like Knockout, without the ko.observables everywhere.
I've been using Angular in a few prototypes and ran across funky problems using their routing in HTML5 mode with IE9.
Theoretically their router should prepend the hash fragment to the URL, but it gets stuck in a redirect loop and hangs the browser. The workarounds I've found so far are to use hash style URLs or not use a default route, neither of which are optimal. (Edit: updating to 1.0.1 fixes the problem as long as your "otherwise" route is a defined route)
Version 1.0 (they are currently on 1.0.1) of the framework broke their website for IE users, which makes me a little nervous about the level of cross-browser testing that the framework uses. Their documentation is sparse in some areas, which is an annoyance more than anything (the source is fine to read, but be forewarned that it's not a small project by any stretch of the imagination).
On the plus side, not having to litter ko.observable everywhere was nice, their concept of services (for working with REST endpoints) is great, and it's been pretty easy to break everything up into maintainable modules.
Neat. I don't love the ko.observables, but as an alternative to having to have objects fit into a predefined structure/class hierarchy, they seemed like a good tradeoff.
I used Knockout.js on a project before switching over to Backbone.
My experience was that while Knockout is great for simple projects, it becomes a lot more complex than Backbone once things get complicated.
All those data-binds in the HTML get really annoying and the application becomes difficult to maintain. I like my templates clean.
Backbone takes care of syncing your data with the server, provides you with an event system so you can subscribe to changes, gives you a sane convention for how to structure your views and then gets out of your way.
It's also easy to extend, so you could write your own data-binding system if you really need it. A simple 1-way data-bind is quite easy to implement.
If you aren't writing a single page app and only need to make a primarily static page more interactive, Knockout is probably the right choice.
If you are writing a single page app, you often need to sync your models and collections with the server, or if your UI is very complex, Backbone is probably better.
I believe you, but would just say that for me, syncing data between the browser and the server is pretty easy; it's syncing data to the DOM that's challenging. I totally believe Backbone is great that that, but it makes design tradeoffs for syncing to the server too, and I just found no benefit from that.
Anyways, I think we're saying the same thing. The question: how is Backbone better than jQ; many answers; Ko.js as a middle ground.
I want to echo this last remark. We often need to sync with the server and our UI can get to be relatively complex. Backbone is an outstanding tool for us. However, we don't have single page apps (yet) and we've removed any routers from our apps since they were unnecessary.
I believe many of the references on the web regarding Backbone (blogs, tutorials, stackoverflow) actually confuse matters and made my team's learning curve steeper than it needed to be. Also, the Backbone documentation isn't particularly newbie friendly. I strongly advise anyone first looking into Backbone to ignore Routers completely until the relationship between Models and Views is understood, and you've deciphered the patterns that express that relationship.
We also use Coffeescript, which increased the trouble of learning Backbone. But it was well worth the extra head scratching.
I've had a similar feeling, and have been experimenting with a little library that's fairly similar to Knockout(which is awesome), but is smaller and enforces what I think is a cleaner binding syntax.
>I've had a lot of success with Knockout and fully expect that, like Sinatra did to me with Rails, Knockout will teach me to appreciate Backbone soonish.
Someone asked me to describe the difference between backbone and knockout the other day - and I said "knockout is to backbone what sinatra is to rails" - if focuses on one tiny part of the problem and leaves you to sort the rest however you want.
Recently, I discovered Knockout.js, which is a "competitor" to Backbone with what I think is a clearer interface and a much clearer value proposition. I've had a lot of success with Knockout and fully expect that, like Sinatra did to me with Rails, Knockout will teach me to appreciate Backbone soonish. In the meantime, here's the knockout pitch:
What Knockout does is allow you to keep separate models (which are plain-old Javascript objects; Knockout doesn't need to infect them or enforce any kind of structure to them at all) and DOM UI. Knockout's job is to keep the two in sync. For instance, if you have an array of Foo's rendered in a table, Knockout allows you to bind a "foreach" to the table's body, effectively turning a single TR into a template for each Foo. Then, if the elements of the Foo array change dynamically, Knockout makes the table reliably reflect the constitution of the array.
The core value here isn't "templating". It's "keeping the DOM in sync with Javascript objects".
Off the top of my head, I think we're talking about 3 lines of code to get that functionality: the data-bind attribute on the TBODY element, the ko.observableArray() that wraps your otherwise plain array of Foos, and the ko.applyBindings(RootModel, RootDomElement) call that kicks off Knockout.
The same functionality would probably cost 10-20 lines of jQuery; more importantly, that jQ code would be fiddley, not at all declarative, and duplicated every place you wanted to bind an array to some repeating DOM structure. Knockout is here, to my eyes, a clean win.
Or take forms: you bind (with data attributes) INPUT elements to Javascript objects, so that what their values are changed by user input, the Javascript objects automatically reflect their new values. The JS code that then cares about the value of these objects doesn't ever need to scrape out the values of forms, and can reliably assume whatever's in the fields or hashes or whatever you set up is going to be current input. Also: you can bind multiple form inputs to the same data and keep them in sync, which I found to be a pleasant way to implement an "Advanced Search" feature.
What I didn't like about Backbone was the notion it had of "Models" and "Routers" and stuff like that. I'm sure that's valuable structure to have, but I like the flexibility --- and, more importantly, the freedom for More Stuff I Have To Memorize --- that comes with the KO.js approach.