One additional thing to further the article's points is to mention @std/esm [1][2], doing a similar thing for node module loading. Between the tools the article mentioned and this library we are quickly approaching that big inflection point to start distributing only ES2015+ modules for many libraries.
I read about @std/esm and I wasn't totally sold on it. But now that I read the browser side of the story, I think it makes way more sense to make use of @std/esm in all packages on npm.
The old way of doing things was write for node, and transpile/polyfill the browser with browserify/webpack/etc. But the amount of bytes you ship to the browser really matters. So now the new way of doing things is to write for the browser and transpile/polyfill node which is what @std/esm is doing.
This is explained a little better in the r2 readme:
I agree, a large amount of npm code is always going to be targeting browsers for many uses and the better the Node world converges with browser APIs, the easier it is for everyone.
It makes sense from the Node side of things too, because there's an ability to sometimes borrow the browser-hardened native implementations of "web" APIs directly from partner tools like Chromium, v8, and even ChakraCore. A rising JS tide can lift all boats, and the more "universal" the web platform is the easier it is to develop for.
Also, File I/O is still a bottleneck in Node, even if nowhere near the bottleneck of browsers requesting files over HTTP, and it feels like webpack/rollup is starting to be more of a thing on server-side/NodeJS side, because there are benefits to reducing the bytes you need to read from disk in startup times of NodeJS apps, too. So it's interesting seeing some optimization tools converge on that side of the fence as well.
> async/await, classes, arrow functions, etc. However, despite the fact that all modern browsers can run ES2015+ code and natively support the features I just mentioned
What is everyone's cutoff for de-supporting a browser? According to caniuse.com[1], >30% of browsers don't support the mentioned feature-set; that seems like … a lot.
(<script type="module"> is listed at 60% unsupported, which seems very high, but his point that if you allow it, you should allow everything else mentioned seems sound. I also heavily agree w/ his point about delivering modern JS, and letting end consumers transpile as needed.)
On GOV.UK: take the most used browser from the stats, then add on the next most used and repeat until you get to 95% of the total. At that point start looking at ease of support. Typically browsers will be dropped from the testing list at ~0.4%, unless there’s a security need to remove support.
If not supporting IE, a good gauge is evergreen browsers (Chrome, Firefox, Edge) and Safari going back 2 major versions. This means supporting 2 years of Safari 9.x and 10.x as of today. macOS doesn't upgrade as often as evergreen browsers.
So it depends a little upon your user demographic (or whether you want to keep supporting users or companies that can’t afford to upgrade their device).
Also keep in mind that in addition to limited language feature support, many of those older devices have limited performance capabilities as well.
So, while you may be able to get your code to run on them, it might not be a great experience and of limited value to your customers to even try offering support.
I love this, but I'm missing a key piece to make this effective for non-tiny code bases.
The author proposes using 2 webpack configs, one for es2015 and one for es5. That means running webpack twice from scratch. This, in turn, means you can't effectively use webpack's devserver because that's just a single instance with a single webpack config.
The author's boilerplate [0] "solves" that by hand-coding a watcher based on chokidar which just rebuilds both files on every change. On our code base, clean webpack builds take minutes (and when babel is even configured to exclude /node_modules/, as the author recommends against). If we'd follow the author's advice, we'd be waiting for minutes every time we make a change.
Anyone got a good idea here? The best I can come up with is to use the es2015 build (but with node_modules excluded) in dev mode, and then for staging and production, running webpack twice as the author suggests. That makes the dev version rather different from both the production es2015 output and the production es5 output, however, so if there's any bug in the chain anywhere (babel bug, webpack bug, babel-env browser support table error, etc etc) we may not always find it.
In all honesty that itches me a bit (even though by skipping uglify in dev mode we already depend on at least 1 tool being essentially bug-free). Any ideas?
Actually, I believe you can already run webpack-dev-server with a multi-config just by making your webpack.config.js export an array instead of a single object. The article seems unaware of this capability, but you should be able to have both builds be part of a single webpack config file.
Service Worker already introduced the need (or you could argue possibility) to have multiple configs since SW code has a much different transpiling baseline compared to legacy browser code. And module code just adds one more level to this.
I think webpack dev server will update if this practice becomes popular, but for the moment I think your idea of only building the es2015 build in dev mode is probably the best temporary solution (as long as you make sure to run your test suite in multiple environments and include the legacy build there).
This solution for loading the scripts is great. We have been experimenting with this and browser sniffing was our approach. Will start testing this new approach. Really makes integration and fallback much easier to manage.
One thing missinh here is that dependencies are still published as ES5, sometimes with ESM as an addition. There is no easy way to provide a library with async/await as of today. We would need module:es2017 property in package.json for that. It mitigates a lot the benefit becausr in most code bases dependencies represent the majority of the final JS, and they gain nothing with this approach.
Was mildly interested at the headline, but the fact that this works even for static hosting is pretty great. To be honest I was expecting browser sniffing.
Relevant to module publishing: Axel Rauschmayer's proposal for package authors to start packaging untranspiled code in addition to legacy Javascript: http://2ality.com/2017/06/pkg-esnext.html
[1] https://www.npmjs.com/package/@std/esm [2] https://medium.com/web-on-the-edge/es-modules-in-node-today-...