Thanks for taking the time to write out this reply - my initial comment sort of took on a life of its own, it wasn't originally supposed to turn into a rant and was never intended to be taken literally or to imply that it had been precisely crafted. I appreciate your responding to it nevertheless.

I am actually very aware of the differences between the various components, but I am appalled at just how many cogs it takes to get things working _with 3rd party libraries involved_. It seems as soon as you bring in a single dependency, Pandora's Box is opened and you suddenly have to bring in 12 different build systems along with it.

> I think a lot of the frustration came from people who liked just pasting a script tag to add new libraries to their frontend, and any system which requires them to actually think and configure before pushing to production is considered too complicated.

In my case, it's the other way around. I don't think you understand how much of a breath of fresh air being able to "just paste a script into your html" was for people that came from complicated build systems that required you to locally download, build, and install each dependency your code relied on because there was no module system and there were no URLs or CDNs or whatnot. What is sad is that JS, after seeing how horrible of a mess the C "module" system was, went down the same road when they could have embraced better alternatives and iterated html/browsers in-step with JavaScript to come up with something that wasn't such a mess.

I confess to not being a JS history expert, but as I understand it, require came from node running locally before people tried taking that to the web, and thus requireJS was born. Only it needed a mess of other components to get it to work with existing libraries. And then those 3rd party components were deprecated or replaced by newer iterations, sometimes by the same developers or sometimes by newcomers to the scene. And no one bothered with compatibility with existing systems, except people that drew up a type of "super standard" that encompassed n other types by simply multiplying their complexity instead of reducing it.

We went from being able to get a web app up and running with an HTML file and a single JS file, optionally combined into a single document, to requiring a dozen different build systems, separate compilers and transpilers, many layers of abstraction, required preprocessors and optional in-browser on-the-fly compilers, OS-specific tools, library-specific module systems, and a million different ways that a single statement ("export") could be translated into code, or the dozen different gotchas that you need to consider when you type in that one word ("import") because you'll have to dig up the documentation for the library you want to use to find out just how it exports its interface.. and then you need to make it play nice with the framework you already have in place.

We went from writing every line that of code that appeared in the browser to writing a simple "hello world" that require an insane 10x or 100x payload to run it... and only after studying the various build systems and trying to figure out which was old enough to be supported but new enough to still be around for longer than it took to learn JS itself.

With regards to deprecation, I personally (though not even a web developer by trade) ran into the official deprecation of both bower and typings; and while requireJS and co may not be deprecated per se, if they're not the "right" way of starting a new app today then they are deprecated because your time is better spent learning skills that will still matter tomorrow and sooner or later for a living app you will need to replace them with something else to be able to use the latest version of dependencies and libraries.