2 ms·

> First stop, I looked at babel-polyfill.js but was surprised to see it is 259kb unminified/uncompressed. I’m sure it does a lot, but the entire JavaScript bund

> First stop, I looked at babel-polyfill.js but was surprised to see it is 259kb unminified/uncompressed. I’m sure it does a lot, but the entire JavaScript bundle for the whole site is only 93kb unminified/uncompressed. It’s hard for me to recommed a +300% increase. I just tested it, and the minified and compressed babel-polyfill is 34K. Going from 12K of JS to 46K of JS just to make modern loops work may be a little unsettling, but those are both really small numbers these days. The blog post is about 10x bigger. It's also worth noting that babel-polyfill adds lots of other useful stuff; there are plenty of similar problems that you'll never have to think about if you're willing to drop in the whole babel-polyfill. I think that for most use cases, bundle size is a distraction and it's best to just focus on building things. You should still keep an eye on bundle size in case it gets out of hand, but I don't think that's the case here.

jopsen 9y ago
Agreed, you can always optimize for size later... And conditionally load the polyfill, etc. All that said: dropping all the fancy logic and just going with plain JS has some nice simplicity to it. In the JS world you can spend a lot of time on tooling.
always_good 9y ago
I agreed with you until I had to be wary of performance on mobile devices where the user may have to pay 10s of milliseconds just on boot per every 15kb of javascript you add. At the end of the day you ask yourself "do I really need to add 34kb for 'for..of' or can I get away with a small concession?" like the blog post asked. You may find that it might not cost you much to pay attention to your trade-offs.