Direct DOM manipulation. Event delegation. MVC. MVP. MVVM. Component trees. These aren't libraries, they're not unique to JS.
I've been doing frontend development since the 1990s and in many cases I could still solve the same problems very similarly to how I solved them 10 years ago (except I would probably forego jQuery and use the web APIs directly thanks to widespread browser support).
The reason I instead spent my time learning Backbone and Knockout and Angular and React is that the kind of problems I'm solving has changed over the years.
Your characterization is also hyperbolic. You don't learn an entirely new way to do exactly the same thing and throw all the old knowledge away. Learning Backbone informed how I used Knockout, learning Knockout helped me better understand Angular, having used Angular I know what problems to avoid in React. All of it helped me build intuitions about possible caveats when looking at new tools and libraries.
I mostly don't write Angular code anymore. I haven't touched Knockout in years now. My contact with Backbone is also fairly minimal these days. But learning each of them made it easier both to learn new things in general and to understand other libraries better.
Also, React is the odd one out here. To fully understand Angular (1.x that is), I had to learn about its internals and unique concepts and terminology that are mostly orthogonal to my application but vital to avoid certain mistakes. With Backbone and Knockout the overhead was smaller but a lot of the effort in gaining proficiency was spent learning their quirks and idioms. With React there was some of that initially but all effort beyond that went into language features that come in handy outside of React and concepts that are useful beyond React or JavaScript.
I've been doing frontend development since the 1990s and in many cases I could still solve the same problems very similarly to how I solved them 10 years ago (except I would probably forego jQuery and use the web APIs directly thanks to widespread browser support).
The reason I instead spent my time learning Backbone and Knockout and Angular and React is that the kind of problems I'm solving has changed over the years.
Your characterization is also hyperbolic. You don't learn an entirely new way to do exactly the same thing and throw all the old knowledge away. Learning Backbone informed how I used Knockout, learning Knockout helped me better understand Angular, having used Angular I know what problems to avoid in React. All of it helped me build intuitions about possible caveats when looking at new tools and libraries.
I mostly don't write Angular code anymore. I haven't touched Knockout in years now. My contact with Backbone is also fairly minimal these days. But learning each of them made it easier both to learn new things in general and to understand other libraries better.
Also, React is the odd one out here. To fully understand Angular (1.x that is), I had to learn about its internals and unique concepts and terminology that are mostly orthogonal to my application but vital to avoid certain mistakes. With Backbone and Knockout the overhead was smaller but a lot of the effort in gaining proficiency was spent learning their quirks and idioms. With React there was some of that initially but all effort beyond that went into language features that come in handy outside of React and concepts that are useful beyond React or JavaScript.