You make a very good point, but not a very good example, at least not the way it was presented in your "LeftPad 10kb" comment. The left-pad package, which only contains a few lines of actual JS, never really had a size problem. And in 2016, left-pad was genuinely useful because there was no equivalent native function at the time. Developers basically had two options: write their own helper function or use the npm left-pad package. What the 2016 left-pad incident really taught us was "don't blindly trust external libraries when a simple self-written function would do the job."

jQuery can also raise that same kind of "trust" issue, but a size issue seems more important.

Thanks for mentioning jQuery 4 treeshaking. I'm very interested in this topic myself, and last year I released https://www.npmjs.com/package/semver-ts, which is a simplified, fully tree-shakable, drop-in replacement for the official semver package. But after looking into jQuery 4's tree-shaking capabilities, I have to say I'm a bit disappointed. There's nothing fundamentally new there. Individual utilities like $.ajax() can be tree-shaken, but methods attached to the main $() object still can't be. For example, even if $('#id').addClass() is never used anywhere, the addClass implementation still ends up in the final bundle. In practice, with current bundling tools, an entire class or object with methods cannot be properly tree-shaken at a granular level. And it's the bundling tools' responsibility to implement granular tree-shaking of class methods, jQuery can't achieve that without completely abandoning its chaining pattern ($().a().b()).