> 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, ne

> 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.