Hacker News new | ask | show | jobs
by mynegation 1748 days ago
From the first glance it replaces the jquery calls to some $utils implementation of the same methods. I guess final bundle contains only methods in $utils that are actually used in the code base, but it looks like re-implementation of jquery subset. Would not just using jquery with tree-shaking achieve similar effect? (not a JavaScript expert, so sorry if it is a dumb question).

Maybe another advantage of this is that new implementations target runtime version that is new enough to avoid most of the feature-checking and shims? Would be great if README addressed those questions.
2 comments
fabiospampinato 1748 days ago
jQuery is not tree-shakeable because it uses a chainable API. Like you don't import `toggleClass`, you access the `toggleClass` property of a jQuery instance, so it can't be tree-shaken off automatically.

Even if somebody made a bundler plugin for doing the heavy work jQuery can only be partially compiled with whole modules excluded, you can't exclude individual methods (e.g. you can't just remove `toggleClass`, you have to remove also `addClass`, `removeClass` etc.).

FYI I maintain a jQuery alternative that supports being partially compiled with individual modules turned off, but it requires manually listing them: https://github.com/fabiospampinato/cash

link
timostamm 1748 days ago
Tree shaking works well when you have ESM imports / exports.

jquery is/was usually loaded into the global scope. There is no standard way for tree shakers to deduct which parts of the library you are using.

Yes, browser APIs have matured significantly since jquery was new and such a library doesn't add much value anymore.

I agree it would be great if the README gave a bit more background. Whoever is looking to migrate away from jquery will be aware of the background though (and will likely appreciate this tool).

link