> Been tacitly supporting Edge myself, but drew a hard line at IE (even 11) for current projects. Without async functions, promises etc, it's just too much extra boilerplate, a separate build setup and a huge payload just to support IE11, let alone older.

We've been using TypeScript for all scripts longer than ~20 lines for years - so we got async functions for free (it compiles async/await TypeScript functions to IE11-compatible ES5 just fine).

Why force all your users to download transpiled ES5, just to accommodate IE11 dinosaurs?

Not to mention all the issues you'll have if you try to use CSS Flex or Grid.

Support IE11 only if you absolutely must, is my advice, and do that with differential serving: https://philipwalton.com/articles/deploying-es2015-code-in-p...

https://calendar.perfplanet.com/2018/doing-differential-serv...

Agreed, but I'd just assume avoid dual builds and targets at this point... a project I'm working on started with IE11 support and dual build targets, but broke in IE11 about 3 weeks in, so changed the "legacy" build mode to a page noting the requirement for a modern and secure browser.

TypeScript does NOT shim async functions[1] for you, or give you fetch-api[2]? AFAIK, if you want that functionality, you still need babel and the fills/transforms to support async in browsers without it are freakishly huge payloads. That doesn't count dynamic imports and a number of other features that TypeScript doesn't support.

I'd rather not support a dead browser, that's been dead for years now, that has clear replacements and alternatives. Not to mention security concerns above and beyond development pain..

    [1] https://caniuse.com/#feat=async-functions
    [2] https://caniuse.com/#feat=fetch

TypeScript does shim async functions, you just need to supply your own `Promise<T>` polyfill ( https://mariusschulz.com/blog/compiling-async-await-to-es3-e... ). `fetch` also works fine with a third-party polyfill. Combined, that's about 30KiB extra compared to pure ES6 (before GZip).

Thank you for pointing this out... I just know I've come across quite a few features of EScurrent/next that weren't supported in typescript and found the experience a bit irritating to do both babel and ts (and webpack).

Just out of curiosity, why not use a conditional polyfill using nomodule rather than outright breaking on something like IE11? Because we use nomodule, the script tag will be ignored by modern browsers, while IE will fetch the polyfill. polyfill.io serves this request, and we have it include all the polyfills we require (for our use case, we just request the default plus es2015-16-17-18, plus fetch).

The beauty of the approach is that the big pollyfill payloads are only borne by the users who choose (or likely are forced by employers) to use those browser versions.