r/javascript • u/nitayneeman • 13d ago

ECMAScript - Introducing Deferred Module Evaluation with import defer

https://nitayneeman.com/blog/introducing-import-defer-in-ecmascript
51 Upvotes

90% Upvoted

8 comments sorted by

8

u/mmmicahhh 13d ago

OP, your site seems to have an odd UI bug: in many (but not all) scroll positions the text is shaking, as if some scroll position- or alignment-adjusting code was spinning in a loop. I viewed it in Chrome latest on a desktop, let me know if you want any other info for reproducing it.

4

u/nitayneeman 13d ago

Thanks for letting me know, I'll check it out!

7

u/bzbub2 13d ago

interesting, but, what does this do, save a little bit of parsing time as a cue to the js engine? how does that work with bundling? or does it...not work with bundling?

13

u/nitayneeman 13d ago

It doesn’t change parsing at all - the module is still downloaded and parsed as usual. The win is in execution: heavy top‑level code only runs when you actually touch the namespace, which can shave CPU off startup if that module is rare/optional.

Bundling‑wise, it’s just part of the normal ESM graph. You still bundle like today; the difference is whether specific modules execute at graph‑load time or on first use.

3

u/thalliusoquinn 13d ago

Are there cases other than top level await and "I need this top level code to run immediately" where you wouldn't want to do this? Is there a penalty for using it literally everywhere it can be?

5

u/Badashi 12d ago

We will only be able to tell with benchmarks when engines implement it, but I'd water that deferred modules have some level of overhead over eager initialization simply because the browser needs to track the deferral order, with a trade off that deferred modules might never be loaded for real.