I feel ya. I keep having to stop myself from doing things the right way so that I can support my IE11 users.

Unfortunately, even after EOL, the ghost of IE11 will be around for a very long time. Heck, my November stats show 10% WinXP users.

It's utterly depressing how many red "No"s there are in the left column next to green "Yes"s -- all the features we could use if we could merely drop support for IE11.

The reason why IE11 will live for a long, long time is it's compatability modes. You can run apps all the way back to IE7 on it. And yes these still exist.

Wow, that would really frustrate me. One of the first things I do (or check to make sure it's done by whatever css library I'm using) is add

a { cursor:pointer; }

to my css file. The first time I tested a website in IE11, I would be pulling my hair out!! Or more likely I would google it, but still, it would be frustrating.

ES6/ES2015 - https://caniuse.com/#search=ES6

Every other major browser supports this natively aside from IE, but most people still transpile their modern code down to ES5 + polyfills for compatibility

CSS Variables - https://caniuse.com/#feat=css-variables

Again, widely supported, but instead we use tools like SASS/LESS

Web Components[1] (Shadow DOM[2] and Custom Elements[3])

Newer frameworks like Ionic 4 rely heavily and web components and see it as the future of all UI frameworks and the end of framework churn[4]. Once again IE 11 holds back the pack and has to be pollyfilled[5]

1. https://developer.mozilla.org/en-US/docs/Web/Web_Components

2. https://caniuse.com/#feat=shadowdomv1

3. https://caniuse.com/#feat=custom-elementsv1

4. https://blog.ionicframework.com/the-end-of-framework-churn/

5. https://blog.ionicframework.com/october-2018-a-big-month-for...

Proxy - https://caniuse.com/#feat=proxy

Vuejs is completely rewriting its observation mechanism[6] to be proxy-based in version 3, however it appears that cannot be polyfilled and so they will be providing a second, optional, not-fully-compatible build, specifically for IE 11[7]

> Most of the ES2015 features used can be transpiled / polyfilled for IE11, with the exception for Proxies. Our plan is to implement an alternative observer with the same API, but using the good old ES5 Object.defineProperty API. A separate build of Vue 3.x will be distributed using this observer implementation. However, this build will be subject to the same change detection caveats of Vue 2.x and thus not fully compatible with the “modern” build of 3.x. We are aware that this imposes some inconvenience for library authors as they will need to be aware of compatibility for two different builds

6. https://medium.com/the-vue-point/plans-for-the-next-iteratio...

7. https://medium.com/the-vue-point/plans-for-the-next-iteratio...

Imagine the number of hours that could be saved globally if all this work and testing didn't have to happen anymore.

Especially the second point isn't new. So in the past, MS has built compatibility modes into IE, where a modern rendering engine is used by default (or at least when a certain X-UA-Compatible header/meta tag is present) and a fallback engine is used upon certain triggers (explicitly via compatibility lists and X-UA-Compatible, or via heuristics, e.g. for intranet sites).

I don't understand why they couldn't do a similar thing now: use EdgeHTML in IE by default, and fall back to Trident via certain triggers.

Yes, it would have required using two different rendering engines, while IE 10 and earlier can be emulated by IE 11 Trident. I don't know how IE is built, but heck, in the early Firefox days, I used to have an extension that could seamlessly switch to IE rendering within the Firefox window. So I would like to believe that a better solution than making IE the new Walking Dead among browsers should be realistic for MS.