Well, while frameworks require a bit of boilerplate, it makes large projects MUCH more maintainable. Back in the bad old days, yes, you could bang out a bunch of features very quickly in JQuery, but as the size of the site increased there were lots of opportunities for disparate sections of code to interfere with each other. Additionally, there are serious performance concerns using jquery for any significant number of DOM mutations, which most of the major frameworks solve. Finally, you can't just arbitrarily mutate the DOM in these frameworks, so you can't use jquery willy-nilly if you're using them.
Some frameworks reduce boilerplate by implementing features for you in their way so that tiny trivial tweaks require reverse engineering the framework and maintaining your own fork of the framework. Hopefully generators that scaffold boilerplate instead of hiding features in the framework stay to pick up more.
Some of us still do. The whole world has not moved on to client side frameworks contrary to popular opinion on HN.
(I probably actually will move on at some point... when the dust settles and there are clearer options. And when I can go through some tutorials and have stuff all work. And when there isn't a huge huge library I don't need to to a few little things. In the meantime I proudly like jQuery and it works really well for the amount of JavaScript I need. Which amount incidentally is never on a server.).
With some frameworks, you must adhere to the rule:
"Doing it the [insert framework here] way"
Most frameworks try to change your beliefs about how and why you should do things, and they are differentiated by how different/better they are from then going through the "pain" (in their words) of using jQuery.
Personally I like the way Vue.js approaches things, it's like a nice mix of syntax readability and singe state/unidirectional data flow.
