Hacker News Reader

Comment by paol | Hacker News Reader

That's what Babel[0] is for. Realistically you can't rely on native ES2016 for any target audience yet, but with Babel you can blissfully live in the future, today :)

Also, thrown in core-js[1] while you're at it.

[0] https://babeljs.io/

[1] https://github.com/zloirock/core-js

View on HN

Babel is only part of the history, then there is HTML and CSS support levels.

Some of our projects are with customers that still rely on XP with IE 8, require using the "Internet Browser" for pre-Android 4.4 or Windows Safari (!) or IoT devices without updatable browsers.

Your customers are lucky to have you. I imagine they will rely on XP and IE8 as long as you are around.

Not me personally, my employer is quite big, and any consulting company will happily sell such services.

Yep and with Babel we recommend using https://github.com/babel/babel-preset-env to compile only what's missing in the targets you support.

Hopefully we have a better solution about making multiple bundles (separate one for IE) soon

I'm currently experimenting with if-no-window.Promise-then-polyfill via polyfill.io (I dont quite trust synchronous dynamic script loading yet, but we'll see if that's robust enough on old browsers). Sure, old browsers need an extra roundtrip, and it's an additional point of failure - but it simplifies dev tooling, and if your users actually cared about perf, they wouldn't be using ancient browsers.

It won't fix many issues (e.g. CSS), but at least some, and without making your build complicated, and without performance sacrifices for the majority of devices.

> if your users actually cared about perf, they wouldn't be using ancient browsers.

Many of them do care, but not the IT department that vets their machines.

There are pros and cons there. The overhead isn't huge; if you use any ads whatsoever those likely swamp this effect anyhow. And dev time is limited - how much time is it worth shaving at best 100ms off for a small and shrinking group of clients? It's cacheable, so it's a not a commonly recurring delay, and it's likely to be a lot smaller on decent networks. (https://tools.keycdn.com/ping puts the worst ping as being from tokyo at 84ms; many are sub-ms as you might expect from a cdn).

I think it's (potentially) a better tradeoff than making most clients pay for larger bundle sizes even though they don't need it.

But well: tradeoffs.

A pedantic correction: web extension and add-on authors mostly can in browsers that auto-update.

Babel has it's own set of flaws like causing a performance hit.

Reply on news.ycombinator.com