Post

is this still true, even for script type=module? 🤯 cc: @chromium.social … can’t for the life of me find the message but thank you to the person at @perfnow.bsky.social who sent this my way ❤️ web.dev/learn/perfor...

I don't think it matters for the web. But does for Node and the like: v8.dev/features/mod...

okay, so the docs I linked are outdated?

And yet oddly written after the doc I linked! @kevinfarrugia.bsky.social did you write web.dev/learn/perfor... ? Got any more info on mjs file extension?

I _think_ @kevinfarrugia.bsky.social thought the impact was minimal (but if it's even slight I think we should reconsider our default format in @nuxt.com and possibly also in @vite.dev). the key thing I'd like to confirm is that it really is the case first ...

for example, this commit (if it's the _only_ optimisation) seems to suggest it might just apply to link preloads where `modulepreload` is not explicitly set: github.com/chromium/chr...

Yea, that fix is about treating <link rel=preload href=foo.mjs> as if it's a modulepreload. I don't think Chromium has any mjs-specific things that cannot be achieved in better ways.

"The core problem is that when starting streaming, we need to guess whether the script will be used as a module or not, since that will affect how the script is parsed. If we get that guess wrong, we just silently ignore the streaming parsing results and parse it again."

I tested many different scenarios manually and couldn't observe any difference. I had suggested that they include a trace event to be able to recognize when the streamed script is dropped but I don't think it was done.

The bug ticket requesting the change in the module: issuetracker.google.com/issues/31000... Relevant bit: > Streaming compilation footguns: > Use .mjs extension instead of .js extension when shipping ES6 module code in prod—this breaks streaming compilation!