Hacker News Reader

Comment by pjmlp | Hacker News Reader

It doesn't help when one needs to target enterprise markets or devices that only have their factory provided browser.

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

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

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.

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

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.

Nope, not everything is for everyone.

Of course it helps, only there is a bit of a lag. How many 'enterprise markets' run <IE9 nowadays?

I know of eight products, compulsory for school's to use, such as OnDemand [0], put out by the Australian government, that only run under IE7/8. (Though the published specs say it runs on IE9+ for admin, and IE10+ for students, but I've never got admin to run under anything but IE7, and students on anything more than IE8.)

I'd imagine that enterprises are still running many products with similar insane requirements, because they never get updates.

[0] http://www.vcaa.vic.edu.au/Pages/prep10/ondemand/index.aspx

Have you tried IE11 Enterprise (IE8) mode?

https://www.howtogeek.com/184634/how-to-enable-and-use-inter...

Unfortunately there are some minute differences in the way headers get passed to the server, and the user-agent string is slightly different as well.

Badly made software doesn't play ball.

Though it is theoretically possible to force it to work under IE8 mode, its simpler to supply real IE8 over a remote login.

Pharma industry, labs with XP machines doing robot automation with IE 8 installed.

But who needs to access your web app from a dedicated special purpose lab equipment control workstation?

Reply on news.ycombinator.com