This probably isn't true, but more importantly this statement misses the point because you're bundling a bunch of stuff into the "anti-bloat libs" bucket with no consideration for the individual architectures of each.
To come back to the example above—React—the core react library is 3.2kb[0] gzipped. (and it hasn't died out). What I'm selectively omitting here is the architectural detail that React have separated their API implementation (core), their renderers (DOM, Server, Native) and their templating (JSX), all of which are loosely coupled optional components. That's a very effective approach to omitting bloat, and is a model that can be copied in an approximately compatible way (see e.g. the anti-bloat Preact and Inferno, further examples of anti-bloat approaches that have not "died out")
[0] https://unpkg.com/[email protected]/cjs/react.production.min.js
This idea puzzles me. It's not like the code suddenly breaks or the world changes so much as to render it completely obsolete.
It's borderline madness to keep chasing new and shiny things and then complain that things keep changing.
Stability is a feature, not a bug.
Yes. And that is _exactly_ the point. These anti-bloat libraries either die or become the enemy they set out to defeat. We've been to this rodeo before, yes?
Nothing wrong with that per se. But we gain nothing by pretending this cycle doesn't exist.
Perhaps a smarter approach would be: I've replicated 80% of X's features with 20% of the weight. Here's what's missing.
Then if Library X puts on weight, so can you, if you want. But feather weight in and of itself is not a benefit per se (especially when it's likely temporary). It's a feature. And too often we all gets sucked into the feature trap because we forget it's ultimately about benefits.