Hacker News Reader

Comment by Carpetsmoker | Hacker News Reader

> For example, the Fetch API can replace jQuery’s Ajax functions

Except that it won't work for ~6% of your visitors (± a few percentage points, based on your locality and audience).

Some developers sneer at these kind of numbers and comaplain about old browsers and whatnot. Yeah, it's annoying. But it's also reality, and as a professional you'll have to deal with it.

> The querySelector and querySelectorAll methods replicate jQuery’s selection capabilities

The jQuery selectors have quite a bit of extra useful functionality though.

View on HN

So, I work with car salespeople at dealerships, and also their customers (car-buying folks).

We recently checked our top sending domains (the car-buying customer’s email address), and of course @gmail.com is #1, but @aol.com and @comcast.net are in the top 5.

Depending on the dealership, all the PCs can be locked-down on IE9.

You can polyfill it in under 500 bytes: https://github.com/developit/unfetch

And 7 more polyfills later and you've ended up with a hacky and incomplete version of jQuery.

No, you've ended up with standard web APIs so you can safely drop those polyfills whenever browser support is at an acceptable level.

Yes, there is also polyfill.io, which sniffs user agents and only sends the scripts a particular browser needs.

You still have to polyfill Promise, so it's definitely not under 500 bytes.

> ± a few percentage points

The variance is a lot higher than that. Tons of web projects are for internal tools (controlled environment), for mobile first, or in industries or language communities or countries or markets where the browser distribution is entirely different.

So as a professional what you do is (1) measure, (2) reach a business decision about browser support, and only then (3) choose technologies.

With polyfills and Babel, using new features in old browsers isn't really a problem, but it's unfortunate that this is often required, and it's unfortunate that Web development has become so fragmented by developers preferring to use tools built on the platform rather than authoring for the platform directly.

> and as a professional you'll have to deal with it.

Yes, by not supporting those users. If you want to use IE 11 that's fine by me, doesn't mean I need to go out of my way to ensure it works for them.

As a person for your hobby project or whatnot? Sure. As a business? Yeah nah, that's not how it works. Imagine turning away 7% of your customers at the door of your shop.

In some industries it's much more than 7%. Luckily once IE11 is EOL (which IIRC is in January) I'll be able to block requests from that browser, but only because I can use the argument "this browser is EOL and using it is a security risk." Not every business has that luxury.

https://gabriellaroche.dev/ie11-death-countdown/

I really hope you are right about January and this counter is wrong.

In the meantime I'm not worrying about IE anymore (have luxury of not working at bigco and can say, "sorry, we don't support that").

Ah, crap. It’s IE10 I was thinking of, so it’s still IE11 I’ll be suffering with for some years.

I very well might be in a management role before I have to stop worrying about IE 11 directly. This countdown couldn't come sooner.

IE10 will be EOL in January. IE11 will only be EOL in 2025...

It's all just a matter of cost x profit. If supporting those 7% doesn't make up for the the cost of supporting them, then it doesn't make sense to support them. However, if supporting them is worth more than the cost to do so, then it'd be silly not to.

At a previous job ignoring these users meant ignoring the size of a small country monthly.

Support them the same way you support users without JavaScript. There will always be users without JS, so you need to deal with that. Treat old browsers as just another browser without JavaScript. It’s very easy to do if you use script type=module.

Reply on news.ycombinator.com