This is the same reason I was turned off to backbone. Being a Rails guy, and a guy who takes 5 minutes to pick a candy out of the machine, I'm much more attracted to an opinionated framework, which is why I've jumped on the angular.js bandwagon.
In fact, on a current project me and another guy are building identical prototypes in angular and backbone to compare notes on which framework we end up going with. He's running into the same issues mentioned in this article - namely, trying to figure out just how he should structure things. Some people love that freedom and flexibility, others find it paralyzing.
The thing that makes Backbone unfriendly to noobs is its lack of prescribed structure. Personally I love this approach because I know Javascript pretty well, but I haven't written a ton of huge JS apps yet, so I'm still experimenting with ways of architecting them. Backbone provides a lot of essential functionality in a flexible way that forces me to think critically about how I want to structure the app. I see that frameworks like Angular and Ember give me more out of the box, but they impose a lot of structure which I am not sure about yet. I'm sure sometimes that structure is ideal and sometimes it may be the wrong tool for the job. Eventually after I build out more Backbone.js apps in different ways I'll be in a much better position to evaluate the more heavyweight frameworks.
It's not unlike how I fell in love with Rails immediately in 2005 having spent the previous 5 years working in PHP, it was obvious why Rails was the way it was. But without that prior lower-level experience I would have been more skeptical.
"I'm sure sometimes that structure is ideal and sometimes it may be the wrong tool for the job. Eventually after I build out more Backbone.js apps in different ways I'll be in a much better position to evaluate the more heavyweight frameworks."
Somehow you saw immediate benefit in Rails in 2005, grokking that having defined structure coupled with out of the box functionality was a good starting point. Why do you not have the same reaction in the JavaScript world, instead feeling like you need to 'tough it out' for a few apps first?
Replace "backbone.js" with "php" and you get the argument I hear from PHP beginners and noobs as well. "After I do a few PHP projects really hacky and crappy, learning on my own as I go along, then I'll be able to judge the quality and useful of a mature framework". That's the reality of what happens to many (most?) devs, and they leave a mountain of legacy stuff behind that someone (sometimes themselves!) have to maintain for a long time.
I was neither a web beginner when Rails came out or a javascript beginner when I started working with Backbone, so your use of the word grok is ironically appropriate.
But to answer your question about why I was quicker to jump on board with a full-stack opinionated framework like Rails as opposed to equivalent JS frameworks. The reason is because there's a much larger common footprint of what a website needs to do than what javascript needs to do. Is it a single page app or a full site? How much JS code is there? Is it a lot of CRUD or is a more minimal crafted UI? Is it progressively enhanced or not? What other technologies are in the mix?
All of these affect the needs of a particular site's JS implementation, and even assuming that all JS framework authors are smarter and more knowledgeable than me (which is a dubious assumption btw), they may or may not have taken into account any of the conditions and constraints that are now staring me in the face.
As to leaving crappy legacy stuff behind, well, frameworks don't save you from that. For a simple app written by a beginner there's a good chance I'd prefer maintaining the 10-year-old PHP version to the 5-year-old Ruby version. But even assuming a framework is a good idea, how is the noob to know which one to use? You could just as easily end up with a dead-end Access database as something that can be coerced into stable software.
For #4, "Let’s say you fetched a record in one view of the app. Then you fetch and update that same record in a different view. In Spine.js, both records will update." This sounds like completely standard Backbone.js functionality to me. It just seems like the guy writing this post wasn't familiar enough with the framework to even begin making "why I switched" posts.
+1 Backbone. For me the more open-ended approach has allowed space to try different approaches to see where they fail, and refactoring. This open-ended approach seems to jive well with the spirit of js, and has definitely made me a better dev.
We just switched from backbone to angular. The thing that sold me was data-binding. You could write your own with backbone but it's done so why bother. Also the code reduction was about 1/3.
You don't need to write your own data binding in backbone. Several smart developers have already written plugins for this very thing. I usually forget about backbone plugins when workin on a new problem, and get halfway down my thought process before remembering to check https://github.com/documentcloud/backbone/wiki/Extensions,-P.... To be fair, the backbone website does a terrible job of promoting these resources.
like you, I also came from backbone.js and since then I have switched to CanJs. Backbone.js open endedness if I may compare to UX concept, is too open ended that it can cause analysis paralysis. There is no defined path for programmers to take. Of course this is not a bad thing, it's just different from what I would like.
CanJs takes care of live binding, memory management, syntatic sugar, etc, it feels to me it's like a backbone with everything that I want already built in. I have tried other frameworks too such as ember or angular, and I have to say, even though they are all in the same family (javascript mvc framework) but they target different types of customers (developers) and variety is good.
point 6 sold me. everything else i can live with, but just google ghost views with backbone.js and you know what i mean.
i don't really see the problem with 9's code. as long as you bind correctly you can get the clicked element. i guess the problem might occur if you want to access some random model from the dom. not sure when that would happen.
10 is also not a problem since you can easily extend underscore or backbone stuff.
3 is really up to you and not really an issue per se.
In fact, on a current project me and another guy are building identical prototypes in angular and backbone to compare notes on which framework we end up going with. He's running into the same issues mentioned in this article - namely, trying to figure out just how he should structure things. Some people love that freedom and flexibility, others find it paralyzing.