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...
Post
I don't think it matters for the web. But does for Node and the like: v8.dev/features/mod...
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...
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!
When testing this locally, the trace event `BackgroundCompileTask::Run` (source.chromium.org/chromium/chr...) was visible for both file extensions, however they later clarified that it will begin streaming compilation in both cases but drop it in the case of `.js`.
thank you for digging this out. is it possible that maybe background compilation is not supported for modules _at all_ regardless of extension? source.chromium.org/chromium/chr...
0 reposts3 likes
V8 team advised that I create a crbug to add a trace event when the streaming parsing results are dropped: issues.chromium.org/u/1/issues/3...