Bringing Modern JavaScript to Libraries

Posted on by Gary Chew (DevRel at Google)
Bringing Modern JavaScript to Libraries

tl;dr: To bring modern JavaScript to our libraries, we should adopt a new "browser2017" conditional export key. The "browser2017" key points to modern code that targets modern browsers, without the polyfills that bloat our bundles. This change requires support from bundlers and adoption from package authors.

OK … that’s a summary

a bit more


Although modern browsers represent over 90% of web traffic, many websites still transpile JavaScript to ES5 to support the <10% still stuck on older browsers like IE 11. To do this, most websites transpile their code and deliver polyfills which reimplement functionality already included in modern browsers. This produces larger bundles, which mean longer load and parse times for everyone.

and a bit more


Though the module/nomodule pattern has introduced a mechanism to serve modern bundles, there’s still one glaring problem: virtually all our third-party dependencies (and thus the majority of our JavaScript code) are stuck in ES5 . We’ve left transpilation to package authors, but have established no mechanism for them to publish a modern version of their code. Until we develop a standard for doing so, applications cannot truly reap the benefits of modern JavaScript. Conditional exports can provide that standard.

and after that a long article with a lot of details, all good but man I’m so glad I didn’t head down into JS development, that looks like a fucking nightmare.

Morality for AS3 dev, we have imports thanks to ES4 and sharing/using pre-compiled bytecode libraries (SWC) is so much more easy.

And look, if JS is stuck to cross-compile to ES5, we can reuse all those JS libraries into AVM2 runtimes (ok … maybe need a bit of polyfill for specific ES5 stuff, but still mostly compatible).

Anyway, the article above, that’s modern JS in 2020 FFS.


That’s the cost of abandoning ES4.
So much pain till today

1 Like