Curiously enough JavaScript was in fact designed to run on the server too, Netscape LiveWire shipped it in 1995.

Node is getting better each year imo. I've been pretty happy with ES6.

What makes you say Babel is horrible? Not disagreeing but I haven't heard anyone say that before.

I write JavaScript daily and my gripe with Babel (and transpilers in general) in the JS ecosystem is that it makes it easy to have 10 dependencies written in 10 similar-but-different languages. If you have to edit a dependency then you're stuck editing their source file (written in ES6-ES11 plus random unaccepted proposals / TypeScript / Coffeescript / Purescript / etc), installing their devDeps tree to run their build process, integrating their sourcemaps to un-break your stack traces, and writing code in a slightly different language each time you make a change. It's exhausting.

It's really neat that we have the option to transpile, and I was actively working on transpilers in the Meteor ecosystem when they were all the rage, but at this point I try to avoid them whenever I can.

People don't say it directly, but all the constant complaining about the bloat and complexity of the JS ecosystem and the size of node_modules folder boils down mostly to two tools: Babel and Webpack.

When people make fun of leftpad they are not talking about babel and webpack.

The bloat is a lot about the lack of a standard library in JS. Or rather, too many of the damn things. That and an inconsistent and unpredictable type system.

> The bloat is a lot about the lack of a standard library in JS.

Which is why someone created core-js, which a bunch of libraries use but, in my experience, never update. Every React project will have multiple libraries complaining that core-js 2 is deprecated.

So basically even the "fix" has all those problems.

> That and an inconsistent and unpredictable type system.

Agreed and honestly, I don't think TypeScript's solution for third party types is any better, either. I recently ended up in a situation where `some-library` and `@types/some-library` got out of sync and I simply had to try versions of `@types/some-library` until it would compile again. This happened because typedef versions are not pinned to library version in any way, they are versioned just like any other library, and to the best of my knowledge you can't simply look up this information to figure out which @types release you need for a library. You can only enumerate released versions and hope the latest of each work fine. Was there a breaking change that the typedefs haven't accounted for yet? Well guess what, you can't update that library, yet, even if there were security fixes. Your code won't compile.

This means you could potentially have `some-library` at version 1.2.1 and `@types/some-library` at version 1.1.0. There's no relationship there. This happens the moment there's a revision in a library that doesn't require a revision in the typedefs.

Sorry to ramble, I'm just really unhappy with the state of our two major ES languages.

Babel was the largest package that was dependent on leftpad back in 2015 when the leftpad issue happened.

The package bloat issue doesn't happen with Typescript, for instance, which occupies a similar niche in the ecosystem (it's also a transpiler), or prettier.

But that is a sign is it not? If tools as badly designed as webpack is the standard, is that not saying there is an issue with the entire ecosystem?

There are other standard tools that don't suffer with package bloat, like Prettier and Typescript, which don't have dependencies. This issue is not inherent to the ecosystem.

I don't think it's the tools' fault. They were built to solve problems, and they solve those problems quite well IMO.

Sure, but I don't think those things are related. It's possible to solve problems without causing package bloat. Typescript and Prettier have no dependencies, for instance.