Learning JavaScript is like archaeology, you must learn the fossilized layers to understand what exists now and the reasons for all sorts of compatibility code. Layer-by-layer you peel back all the different design decisions in order to work around what initially started out as a slapped-together scripting language way back in the mid-90's. I recently came across these three articles by Peter Jang when taking survey of the "modern" web development landscape:
https://medium.com/actualize-network/modern-html-explained-for-dinosaurs-65e56af2981
https://medium.com/actualize-network/modern-css-explained-for-dinosaurs-5226febe3525
https://medium.com/the-node-js-collection/modern-javascript-explained-for-dinosaurs-f695e9747b70
There's also this video by Douglas Crockford from Nordic.js in 2014 (there's another more recent one by him from 2017 saying many of the same things):
What I find most depressing is that nearly none of the issues (dynamic scene graph, minimal tooling, standarized REST-API NoSQL backend, transparent abstractions, ...) I was working with/to solve eight years ago-- and am still working to solve in a roundabout way --have been popularly explicated half as being solved. You can sum up much of what has transpired as "sprinkle syntactical sugar everywhere" for enabling various programming idioms that programmers were used to in other languages. It's hacks on top of shivs, preferences on top of dependencies. It seems JavaScript has unofficially become the language where programmers come to do holy battle over which idiom should be preferred; build faux-classical inheritance on top of prototypes? take functional programming and run with it? how many ways can we create objects? strict type checking or dynamic evaluation? the list goes on.
All of these conflicts are reflected in the frameworks and libraries. For example, ReactJS decides to bundle model and view which leads to predictable state management issues so libraries like Redux are created to manage state. Functional programming with its focus on immutability and no-side-effects comes riding in on this wave. The question then becomes: is functional programming used because it is an overall better programming idiom or because it is necessary to make up for the shortcomings of ReactJS design decisions? and on it goes.
There's more that could be said but really, and as always, the tried and true way to create a properly informed decision is to just tune out the noise, jump in and build something with sense, reasoning and analysis as guides. All these years later and the approach remains the same: what can be built with the most minimally necessary tools? Time to find out.
Next.