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.
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.
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.
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.
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.
