[Crinus]

What sort of features does a mail client need though? Up until recently i was using SquirrelMail and only stopped because my webhost removed it (likely because there hasn't been an official release for a few years now... which is weird since there is progress in the code repository, just not official releases). In case you haven't used it, SqurrelMail barely uses anything beyond a couple of frames (normal ones, not iframes), a table of links for the mail and a few simple controls (search, delete, mark as read, etc) with some very little (and optional) javascript for selecting all mails and stuff like that. And i really didn't miss anything using it, whereas every other web-based mail client i've seen is both slower and more annoying to use.

So, what is the use case here really, what sort of features IE11 does not provide that you'd need to implement a web-based mail client?

(note that i'm not trying to promote IE11 here, i just do not understand why IE11 would block implementing any feature to the point of dropping it entirely)

[realusername]

I'm sort-of supporting IE11 at my current company and it's not about the features, IE11 is full of rendering bugs & quicks which make you work more. Lots of CSS bugs, lots of JS bugs, it's just an outdated browser which has a real cost to support.

Then you need to be careful to include enough polyfills because even what you assume would be there probably isn't, there's no Promises, no Array.prototype.includes, no arrow functions.

[Crinus]

So it isn't a case of something being impossible but more of a case that it needs workarounds to make things work with it?

[realusername]

Not really impossible no but very costly since every feature shipped will likely break in one way or another on IE.

[TimTheTinker]

> What sort of features does a mail client need though?

How about a consistent, reliable implementation of modern web standards? If you had to write a mail client in Java, would you rather target Java 1.5 or the most recent version?

Many small (and large) features together make a huge difference when it all adds up to providing an implementation of modern web standards that is consistent with other browsers and with modern standards. It's a huge burden to always be checking "is this supported in IE11 or is there a polyfill we can use" when wanting to use a native function or object (not to mention features that can't be polyfilled or transpiled, like ES6 proxies).

[Crinus]

It might sound like i am trying to be a contrarian, but Java for me is a special case and actually i'd probably stick with Java 1.5 or even 1.4 which was the last Java that i liked (i always liked the idea of Java as a very simple OO language and i disliked it when it started getting extra baggage - useful baggage to some, but still it deviated from the simplicity). But really that is a case of personal taste. If you replaced Java with some other language, like -say- Go, i'd most likely go with the latest version (...although again Go 2 does sound like it might follow Java's trajectory, so who knows, but for now i'd use the latest one).

But honestly i'm not a fan of requiring the latest version of something just for developer convenience. It might have to do with growing up using outdated computers for years and seeing most programs not work or work slowly/badly, often without a good technical reason (outside programmer preference).

[worble]

I mean, dropping support doesn't mean it definitely won't work, just that it isn't taken into consideration when developing new features / bug fixing.