Speeding up the JavaScript ecosystem – Polyfills gone rogue
1–10 of 112 posts
Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue
#2This series is great!
You should seriously think about consolidating them into a book. Something I notice other engineers struggle with is how to properly assess performance, read heap snapshots, or even understand how to read a flamegraph for stack tracing tools. It would be nice to point, or buy, them a resource showing this.
I'd definitely buy a copy.
Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue
#3You'll never get NPM apologists to acknowledge this. One of their only skills is making non-specific appeals to the necessity of it all (as essential infrastructure) and vague arguments that boil down to "you need to trust the wisdom of the crowds" (and e.g. the fact that it exists and everyone else is using it means that anyone who disputes its value just doesn't understand it—bonus points for them if they manage to work in a slight that's designed to paint you, implicitly or explicitly, as a junior), despite not being able to attest to any firsthand knowledge of the real why of anything they're defending.
> The new dependencies were all polyfills for JavaScript functions that have long been supported everywhere. The Object.defineProperties method for example was shipped as part of the very first public Node 0.10.0 release dating back to 2013. Heck, even Internet Explorer 9 supported that. And yet there were numerous packages in that dependend on a polyfill for it.
Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue
#4Marvin is doing wonderful work in the JS ecosystem around performance. It has been largely focused on tools and node, however, he did have an interesting set of things to say about how they optimized performance in Preact as well on his website that was really interesting too.
One thing I've noticed is the rampant duplication of polyfills and babel helpers. To the point that I now have overrides setup via pnpm and I re-write many imports of polyfills to point at my own shims, which simply re-export existing functionality native to the language, most of the time.
For smaller utility packages, I often simply clone the repo and copy things over that we need, or copy the src right out of the node_modules folder if possible, then I strip away all the superfluous imports (and often convert from commonjs to ESM if needed)
Saves so much headache, its better for users, smaller builds etc.
Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue
#5Marvin is doing wonderful work in the JS ecosystem around performance. It has been largely focused on tools and node, however, he did have an interesting set of things to say about how they optimized performance in Preact as well on his website that was really interesting too. One thing I've noticed is the rampant duplication of polyfills and babel helpers. To the point that I now have overrides setup via pnpm and I…
That sounds awesome. I've dabled with something like that but only for lodash (makings sure all different flavours get aliased to a single thing) but I never went too far with all the other stuff.
You wouldn't happen to have an example of what you're doing laying around would you? I'd be genuinely curious to try stuff like that out.
Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue
#6This series is great! You should seriously think about consolidating them into a book. Something I notice other engineers struggle with is how to properly assess performance, read heap snapshots, or even understand how to read a flamegraph for stack tracing tools. It would be nice to point, or buy, them a resource showing this. I'd definitely buy a copy.
Second that, I would definitely buy a book based on this series.
Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue
#7For what it's worth; `eslint-plugin-react` has been around for a long time and seems to support running in very old versions of Node.JS (back to v4[1] apparently! tho I can't find anything documenting that for sure.)
I was surprised to learn that Object.values is only supported in Node >v7, Object.fronEntries was added in v12, etc. So for this project maybe the polyfills are needed.
[1] https://github.com/jsx-eslint/eslint-plugin-react/pull/1038
Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue
#8> Polyfills that don’t polyfill
This is what's sometimes called a "ponyfill". The idea is to avoid messing with global scope (monkeypatching), which could be problematic if you have multiple polyfills for the same API or polyfills that don't perfectly match the native behavior.
This can be a good thing in some situations, but in general it's probably best to leave polyfill decisions to the bundler so you can decide which browsers you want to support. Or even produce multiple versions, a lightweight one for modern browsers and one with tons of polyfills that gets served to ancient ones.
Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue
#9You'll never get NPM apologists to acknowledge this. One of their only skills is making non-specific appeals to the necessity of it all (as essential infrastructure) and vague arguments that boil down to "you need to trust the wisdom of the crowds" (and e.g. the fact that it exists and everyone else is using it means that anyone who disputes its value just doesn't understand it—bonus points for them if they manage to…
> You'll never get NPM apologists to acknowledge this.
How should NPM prevent archaic dependencies, or the "even more bizarre" (author's words) problem of developers calling polyfills directly instead of the function that the polyfill fills?
Re: Speeding up the JavaScript ecosystem – Polyfills gone rogue
#10I don't really care to comment about the practice itself, but the "Polyfills that don’t polyfill" section is missing the point: the function is called directly instead of patching the global object so that the global object is not polluted by an possibly non-standard implementation. Additionally it does use Object.defineProperty if available - furthermore it doesn't even call itself a polyfill in the first place. If it's needed in 2023 is a valid point however.