4 ms·
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/es
by styfle 9y ago
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:
https://github.com/mikeal/r2 https://github.com/mikeal/r2
- WorldMaker 9y agoI 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.