You mean it's super hard in java? All they have is maven with hard links into eclipse from my observation.

Npm is light years ahead in execution and usage. Python distribution is.... interesting with eggs & poetry

I agree. I don't find it's hard in Java.

But with that being said, in the JavaScript world, the tooling treat developers more like "users" rather than "engineers". For example:

- Many documentations are cohesive, well-thought, and well main-maintained.

- There are usually handy shortcuts for things like `npx` or `npm i <package name>`

- And many other improvements strive for developers' life-quality, such as call back-end and databases with strong typing, but without messy code generator at the same time.

Meanwhile, I have worked with Java and C# for quite a while, those documentations are so daunting, they feel like math textbooks from the Soviet Union. And companies like Microsoft never bother to fix their blur resolutions for SQL Server Management Studio and such. It's just like nobody cares, and they make working really feels like screwing codes on production lines.

> But with that being said, in the JavaScript world, the tooling treat developers more like "users" rather than "engineers". For example:

Tooling really is about becoming a user. It takes a dozen different file types and shoves them through at least a dozen different type-specific pieces of software. Understanding any one of those to any real degree would take weeks to months.

Just JS itself would require understanding transpilers, minifiers (an optimizing compiler), how NPM works, how these work with all the other tools, various module bundling styles, map files, feature differences for literally 10 versions of JS, browser JS limitations (eg, Chrome and FF break the JS spec for tail calls), JS API differences and polyfills, hot reloading techniques, and wrapping an entire server instance into all of this. I'm sure there are other parts I'm not thinking of.

I did the hand-rolling of all this stuff for several years before jumping on to create-react-app. I've spent many days reading the documentation only to have to read it all again when the next major version drops and everything changes in slightly incompatible ways.

I love learning, but on the whole, this adds very little value to most of the projects I've worked on (though some really did need hand-rolling for very niche requirements).

I rather like laving all the tooling to domain experts who know far more about it than I ever will. I'd rather be a "user" and leave all my engineering headspace for the problems at hand.

It's C# that created and popularized async/await, not JS (and it having an already open source implementation at the time, it was available to everyone for free).

JS introduced promises to the world around 2005 (they were in an unused experimental language a few years before).

async/await is mostly specialized syntax over generators. I'd note that ES4 had generators in the early 2000s

F# introduced async/await in 2007.

C# was mostly copying F# (like it's done for almost every new feature in the past decade or so).

Haskell libraries added support around the same time as C# (likely inspired by F#)

JS had the feature for several years via transpilers before it was finally added officially.

Based on usage numbers, I'm gonna say it was a mix of both. But JS brought it to the very mainstream.