While I do like the idea of running my code straight in the browser without having to push it through a build chain first (like everyone did just a few years ago), I don’t like the idea of on-the-fly transpiling for IE, as this must have a major drawback on performance… which is already pretty bad in IE. Also, another major downside of your approach is the inability to use any modern JavaScript features that cannot be polyfilled.

Therefore, I’m more inclined to opt for the <script type=”module”> hack. By adding type=”module” to your script, only modern browsers (browsers with ES module support) will recognize your script and run it. Old browsers like IE11 will just ignore it, which means you can use stuff like ES modules, async/await, Classes, arrow functions, and much much more just straight in your browser without triggering any annoying errors in IE.

To add IE support, you’d just need a single build step to transpile your fancy ES2015+ into something older browsers can understand and add a single script tag with a nomodule property to makes sure it is only run in older browsers (browsers without ES module support).

So, basically, you’d be left a single build process that shouldn’t even be to run for testing in browsers like Chrome or Firefox. And what you get in return, is being able to use even very recent JavaScript features in older browsers, full support of older browsers as well as optimal performance and file-size for both.