To be fair, the YUI version has more comments, but it's fundamentally harder to follow too, IMHO.
Further, YUI did a poor job of getting tutorials out at the quality of those available today for backbone, ember, and angular. As such, I at least found no approachable way to really get a mental model without working on an existing YUI project with a mentor or reading through a lot of documentation.
I had done a simple YUI proof of concept with YUI 2, and went, "this is more work than jQuery" and never went back.
So people reinvented the wheel, but they made it better. I'm glad that Yahoo blazed the path, but I'm not convinced it's the better option today.
This "X is old hat, use Y" phenomenon of "hype recycling" is part of a cultural problem that seems particularly endemic to the startup world. There is a lifecycle of "bleeding edge" to "mature" to "abandoned" that never lets up. There is always a newly-hyped library or framework or methodology that's trying to shift people's attention; and rather than refining and evolving the existing stuff into stability and maturity, many devs start new, wobbly, immature projects. But the bleeding edge is fickle, and when the dust settles there are some remaining competitors, but then suddenly the dust rises again and you're urged to abandon everything because the new stuff is in a separate programming language, so everything else is now incompatible; so the cycle goes. It results in a lot of work, and I like the competition and sheer energy of a developer community fired up about something, but I believe there is also a lot of work wasted.
Sometimes I wish software developers were more like engineers, and that people slowed down a bit. As one gets older, one gets to value maturity over novelty, and to see the importance of backwards compatibility, transition paths and careful releasing.
As for Ember, I'm sure Ember is wonderful. I still haven't figured out what design decisions in Backbone drove develpers to create Ember, but I'm not qualified to question it. Either way, Ember and Backbone are both trying to solve the same basic thing: Providing an MVC framework for JavaScript, mostly focused on the browser. As I understand it, Ember wants to be a more complete toolkit than Backbone, which is very simple and minimalistic and leaves things like templating to other libs.
What is interesting is that Yehuda Katz was also behind Merb, which in my mind is a good example of a gratuitous project; Merb was someone reinventing Rails with the goal of being perhaps 10% better than Rails in the areas of performance and modalarity, while at the same time completely incompatible, and a lot of people jumped on the bandwagon. As it turned out, the developers decided to reimplement Merb's conceptual improvements back into Rails and shut the project down.
Again, I'm not qualified to critique Ember, but the Ember/Backbone competition certainly looks, on the surface, a lot like the Merb/Rails situation back in the day. I would love to hear more about why the devs decided to create Ember and not evolve Backbone. If the Backbone devs did not want to go in Ember's direction, that is of course a perfectly acceptable (if unfortunate) reason to start over.
If you like minimal frameworks, like to make your own design decisions and want to build your own framework on top of a library, backbone is great.
If you are just looking for a minimal subset of MVC because you're doing some high-concept app that doesn't fit into the standard web application paradigm, it's worth looking at backbone.
Most importantly, if you're retrofitting an existing application, backbone will be invaluable for years.
The ideas behind it are solid and relevant today and it's not a bad idea to use it. I just believe that if you are starting a web application today, for 95% of the use cases, you are better off sticking with jQuery or moving to Ember, Knockout or Angular.
That isn't to disparage any of the other libraries and frameworks, though.
This is terrible advice. If you can't tell the difference between a procedural app full of jQuery callbacks and a an app modularized with Backbone objects, then I don't think you have had real experience writing apps with either of these libraries.
I haven't figured out how to get a team who is "barely" conversant in javascript productive in an MVC framework just yet, myself.
I agree about YUI though ;-)
Now, it's possible that YUI would show itself closer in terms of LOC/complexity to the other frameworks in a larger application. But looking piece by piece, ember and angular just seem to do things more efficiently, more clearly than YUI. And that was my point when discussing LOC.
Coincidentally, I wrote about earlier this week: http://blog.jerodsanto.net/2013/02/cloc-counts-lines-of-code...
Both Ember and Backbone depend on jQuery, incidentally. Leveraging popular libraries is an important feature of any framework.
Excellent as a learning exercise but other than that, what's the point? YUI has been around for so long compared to these. It's mature, it's under active development, very well documented, it has the option of including so many more things if you want, it's modularized,has a devcon every year, releases architectural videos every so often, has a dedicated CDN.
Why do you still pick ember or backbone or ...?