shrug pretty much. The issue is that framework docs are often better than js docs. So instead of people sitting down with a decent js book and learning the right way to do something, they just use a framework.
The fact that pretty much all js frameworks periodically announce speedups of 50%+ should ring alarm bells.
Wow, if you code half as well as you can over-generalize, you must be a JavaScript god. But seriously, frameworks and smaller code libraries should be used when do something useful. If you don't find a framework useful, don't use it. And if you find that you're copying code from project to project, make your own library. This is all pretty simple stuff, I guess you just wanted an excuse to flex your amazing JavaScript ninja muscles on the internets.
Your point about framework docs being better than JS docs is a little puzzling. I think the folks at Mozilla.org would take issue. Plus, there is at least one very excellent JS book ("JavaScript: The Good Part", Crockford) out there to get people started, and most of the silly "Learn JavaScript in 24hours" type books aren't on any JS dev's bookshelf that I've seen (except as a joke).
I can actually code JS fine without a framework. However do I want to keep up to date with all the idiosyncrasies of a growing number of browsers? Do I want to rewrite every function that exists in a framework, such as getting the height of an element or the viewport? No.
The speedups in frameworks are realizations of better ways to do things that a group of programmers came up with - which is almost definitely going to be a better way of doing things outside of a community. That argument would only work if your functions were always as fast as possible at start. Don't forget Chrome was already the fastest browser out there for JS, and they still have improvements of 50%+ in updates.
The fact that pretty much all js frameworks periodically announce speedups of 50%+ should ring alarm bells.