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).