5 ms·

Huh, oddly no mention of native browser support in the form of <script type=“module”> and importmaps! To me, that felt like the last platform to offer ESM supp

Huh, oddly no mention of native browser support in the form of <script type=“module”> and importmaps! To me, that felt like the last platform to offer ESM support. I also feel like browser support “feels” more official than support from bundlers. Just weird to leave out a mention of that.

deleted 2y ago
[deleted]
akoboldfrying 2y ago
It's certainly nice, and makes possible Vite's very quick reloads of developer code, but even Vite still makes (ESM) bundles for performance reasons, both for production (with everything, using Rollup) and for dev (with just the external deps, using ESBuild). My understanding is that HTTP 2 pipelining was supposed to make requesting lots of ESM modules from the same site fast enough that bundling could be consigned to history, but for various reasons it didn't work as intended and it was ultimately removed from most browsers.
- deleted 2y ago
  [deleted]
- dieulot 2y ago
  HTTP/2 “pipelining” (multiplexing) is still there and works as intended; but bundling is still much more efficient. This article delves into just that: https://csswizardry.com/2023/10/the-three-c-concatenate-compress-cache/ https://csswizardry.com/2023/10/the-three-c-concatenate-comp... The first pair of waterfall graphics illustrates the problem clearly. (What you vaguely remember as not working as intended is probably Server Push).
- chrismorgan 2y ago
  HTTP protocol changes were never, ever, going to make bundling unnecessary. No one actually involved in the things said it would, or thought it would. It was less-deeply-involved people misunderstanding things that led to that popular impression. HTTP/2’s better multiplexing helps a little, but you’ve still completely got the waterfall problem: so you have at an absolute minimum of overhead the dependency graph depth times the round-trip time—frequently multiple seconds. HTTP/2 Server Push could have improved it in some regards, as it can in theory break out of the waterfall problem, but in practice it would have required much more complex servers, and was missing important pieces so that it was completely useless anyway (a way for the client to tell the server what resources it has cached), and they eventually just removed it all round rather than inventing and implementing the missing pieces, with which it still would have been a good deal less efficient to execute than bundling. Minifying and bundling is just better, no matter what.
- graypegg 2y ago
  Oh yeah I assumed so. I just thought it was weird to not mention it in an article about ESM becoming the standard JS modules format. Even if it’s not the most performant use of ES modules, I still think it’s certainly the most official “signal” of support to have it in all major browsers.
- WorldMaker 2y ago
  > My understanding is that HTTP 2 pipelining was supposed to make requesting lots of ESM modules from the same site fast enough that bundling could be consigned to history, but for various reasons it didn't work as intended and it was ultimately removed from most browsers. HTTP/2+ Pipelining works pretty well. (As others mentioned, it was HTTP/2 Server Push that didn't quite survive in the wild, which could have helped additional scenarios.) I've been personally moving towards Vite's dev approach for Production (just external deps and big libraries with esbuild) and little to no bundling in dev (only external deps that don't run out-of-the-box as ESM with an importmap). A handful of small "local" files and couple big shared libraries works very well in Production in my experience.
codedokode 2y ago
Sadly ESM don't work with local files (file:// protocol).
- graypegg 2y ago
  That would be expected for a browser environment though! I don’t want any module my browser imports to silently import something off the filesystem without telling me.
  - em-bee 2y ago
    while i agree with that, i don't quite understand why this is an issue if the main index.html file is from the local filesystem too. the filesystem should only be off limits if the main file is loaded from a website.
    - em-bee 2y ago
      i suppose the problem is mixing local and remote sources. i don't know if blocking remote sources from loading local ones is enough or even easy to do. if not then that would explain why local needs to be blocked.
- WorldMaker 2y ago
  Most systems come with Python today, so starting an HTTP server for local testing is often a one-liner like `python -m http.server`. Anyone already working with Node has access to one-liners like `npx http-server`. (Deno and Bun also have one-liners.)
  - codedokode 2y ago
    It is not that easy. You need to open console and navigate to the project directory first. While with ordinary HTML files all you need is to start typing its name in address bar (or simply never close the tab).
    - 2y ago

deleted 2y ago

[deleted]

akoboldfrying 2y ago

It's certainly nice, and makes possible Vite's very quick reloads of developer code, but even Vite still makes (ESM) bundles for performance reasons, both for production (with everything, using Rollup) and for dev (with just the external deps, using ESBuild). My understanding is that HTTP 2 pipelining was supposed to make requesting lots of ESM modules from the same site fast enough that bundling could be consigned to history, but for various reasons it didn't work as intended and it was ultimately removed from most browsers.

deleted 2y ago
[deleted]
dieulot 2y ago
HTTP/2 “pipelining” (multiplexing) is still there and works as intended; but bundling is still much more efficient. This article delves into just that: https://csswizardry.com/2023/10/the-three-c-concatenate-compress-cache/ https://csswizardry.com/2023/10/the-three-c-concatenate-comp... The first pair of waterfall graphics illustrates the problem clearly. (What you vaguely remember as not working as intended is probably Server Push).
chrismorgan 2y ago
HTTP protocol changes were never, ever, going to make bundling unnecessary. No one actually involved in the things said it would, or thought it would. It was less-deeply-involved people misunderstanding things that led to that popular impression. HTTP/2’s better multiplexing helps a little, but you’ve still completely got the waterfall problem: so you have at an absolute minimum of overhead the dependency graph depth times the round-trip time—frequently multiple seconds. HTTP/2 Server Push could have improved it in some regards, as it can in theory break out of the waterfall problem, but in practice it would have required much more complex servers, and was missing important pieces so that it was completely useless anyway (a way for the client to tell the server what resources it has cached), and they eventually just removed it all round rather than inventing and implementing the missing pieces, with which it still would have been a good deal less efficient to execute than bundling. Minifying and bundling is just better, no matter what.
graypegg 2y ago
Oh yeah I assumed so. I just thought it was weird to not mention it in an article about ESM becoming the standard JS modules format. Even if it’s not the most performant use of ES modules, I still think it’s certainly the most official “signal” of support to have it in all major browsers.
WorldMaker 2y ago
> My understanding is that HTTP 2 pipelining was supposed to make requesting lots of ESM modules from the same site fast enough that bundling could be consigned to history, but for various reasons it didn't work as intended and it was ultimately removed from most browsers. HTTP/2+ Pipelining works pretty well. (As others mentioned, it was HTTP/2 Server Push that didn't quite survive in the wild, which could have helped additional scenarios.) I've been personally moving towards Vite's dev approach for Production (just external deps and big libraries with esbuild) and little to no bundling in dev (only external deps that don't run out-of-the-box as ESM with an importmap). A handful of small "local" files and couple big shared libraries works very well in Production in my experience.

codedokode 2y ago

Sadly ESM don't work with local files (file:// protocol).

graypegg 2y ago
That would be expected for a browser environment though! I don’t want any module my browser imports to silently import something off the filesystem without telling me.
- em-bee 2y ago
  while i agree with that, i don't quite understand why this is an issue if the main index.html file is from the local filesystem too. the filesystem should only be off limits if the main file is loaded from a website.
  - em-bee 2y ago
    i suppose the problem is mixing local and remote sources. i don't know if blocking remote sources from loading local ones is enough or even easy to do. if not then that would explain why local needs to be blocked.
WorldMaker 2y ago
Most systems come with Python today, so starting an HTTP server for local testing is often a one-liner like `python -m http.server`. Anyone already working with Node has access to one-liners like `npx http-server`. (Deno and Bun also have one-liners.)
- codedokode 2y ago
  It is not that easy. You need to open console and navigate to the project directory first. While with ordinary HTML files all you need is to start typing its name in address bar (or simply never close the tab).
  - 2y ago