4 ms·

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

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. I'll be glad if/when Edge (blink) is deployed with a windows update.. the sooner the better, as far as I'm concerned.

DaiPlusPlus 7y ago
> 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).
- depressedpanda 7y ago
  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-production-today/ https://philipwalton.com/articles/deploying-es2015-code-in-p... https://calendar.perfplanet.com/2018/doing-differential-serving-in-2019/ https://calendar.perfplanet.com/2018/doing-differential-serv...
  - tracker1 7y ago
    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.
- tracker1 7y ago
  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
  - DaiPlusPlus 7y ago
    TypeScript does shim async functions, you just need to supply your own `Promise<T>` polyfill ( https://mariusschulz.com/blog/compiling-async-await-to-es3-es5-in-typescript 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).
    - tracker1 7y ago
      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).
xp84 7y ago
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.

DaiPlusPlus 7y ago

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

depressedpanda 7y ago
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-production-today/ https://philipwalton.com/articles/deploying-es2015-code-in-p... https://calendar.perfplanet.com/2018/doing-differential-serving-in-2019/ https://calendar.perfplanet.com/2018/doing-differential-serv...
- tracker1 7y ago
  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.
tracker1 7y ago
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
- DaiPlusPlus 7y ago
  TypeScript does shim async functions, you just need to supply your own `Promise<T>` polyfill ( https://mariusschulz.com/blog/compiling-async-await-to-es3-es5-in-typescript 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).
  - tracker1 7y ago
    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).

xp84 7y ago

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.