Right, because tooling is standardized in eg Go. There’s no custom build pipeline, transpilation hell, or experimental language features that are selectively enabled randomly. I’m not even against JS, like at all, and I think the majority of perf issues can be resolved. However, JS tooling is the prime example of where things get truly nightmarish from a software development perspective. Webpack being a perfect example of this horror.

It's also a breeding ground where the best ideas often end becoming a sort of standard not only for javascript devs but for other langauges as well.

Well curious as to what some of these ideas might be.

NPM has done a pretty great job of showing everyone else what to avoid doing.

The mere mention of “web pack” sends most of the FE devs I’ve met into borderline trauma flashbacks.

There’s seemingly half a dozen package managements tools, some of which also seem to be compilers? There’s also bundlers, but again some of these seem integrated. Half of the frameworks seem to ship their own tools?

You can ship a 20MB Go program and no one blinks.

Go programs start at 20MB. The Go AWS Terraform provider is something like 300MB.

A massive amount of the complexity/difficulty in webdev build tools space has to with optimizing delivery sizes on the web platform.

Node.js tooling is straightforward comparatively.

To be clear: Server-side Node.js tooling is relatively simple. It the web tooling (Webpack, etc) that is complicated.

This is funny to me. Go and zig are built with the Unix shell in mind - the most extensible and modular system around.

The webpack ecosystem on the other hand is it’s own OS.

Maybe for some the appeal of JS is in (hopefully) never having to learn Unix?

I’ve heard several folks say that about Kubernetes, but in my experience the *nix core always resurfaces the second things get weird.

That certainly can be a benefit. But as we see here it also limits your thinking to that ecosystem.