Now that most JavaScript ships as ES modules, where does an immediately invoked function expression still earn its place in a codebase, and where has it become noise you should delete?

## What the pattern was actually buying An IIFE is not a design pattern so much as a workaround for two absences in the language as it stood before 2015. The first absence was scope. Only functions created one, so if you wanted a name that did not become a global — or, later, that did not leak out of a `for` body — you had to make a function and call it. The second was a place for setup: code that must run once at load, produce a value, and then hide its scaffolding. Both have direct replacements now, and the honest way to evaluate any surviving IIFE is to ask which of those two jobs it is doing and whether something cheaper does that job. ## Where it is now noise **Around a whole module body.** A module file has its own scope by construction: nothing declared at its top level is visible to another file unless it is exported. Wrapping the body in an IIFE adds a function frame and an indirection for exactly zero encapsulation. This is the single most common leftover, usually a survivor of an automated conversion, and it should simply be unwrapped. **To scope a temporary computation.** A bare block does it: ```js let config; { const raw = readRawConfig(); const parsed = parse(raw); config = normalize(parsed); } // raw and parsed are gone; no function was called ``` The block form is cheaper to read — no `return`, no invocation punctuation, no new `this` or `arguments` — and it makes the intent ("these three names are temporary") more obvious than a call whose result you assign. **As a substitute for private members.** Inside a module, a plain `const` at file scope is already unreachable from outside. The module pattern's whole selling point is redundant there. ## Where it still earns its place **Code that cannot be a module.** Anything you inject into a page you do not own — a third-party embed, an analytics tag, a bookmarklet, a browser-extension content script, a snippet pasted into a console — shares its global scope with strangers. A wrapper is the only thing standing between your temporaries and someone else's. This is the pattern's remaining home, and there it is not legacy at all. **Build-free surfaces.** Internal tools, admin pages, static pages with a couple of inline scripts. Introducing a build step to gain module scope is often the wrong trade for fifty lines of code; the wrapper is cheaper than the toolchain. **An `await` that has nowhere to live.** `(async () => { ... })()` gives you a body where `await` parses, in a context that does not allow it. Attach a `.catch()` — nothing else holds the returned promise, so an error inside it goes unhandled by default. **A one-shot value with real setup.** When building a value takes several intermediate names you do not want lingering, the immediately-invoked form is still the tightest expression of "compute this once and keep only the result" — though a named function called once is often clearer to a reader, and gives the frame a name in stack traces. ## The costs, stated plainly An IIFE runs *eagerly*, at the moment its statement is evaluated. Whatever it does — reading storage, touching a global, opening a connection — happens on load whether or not anything ever consumes the result. If the work is expensive or has side effects, a lazily-called function is the better shape. It produces *one* instance, created before any caller can influence it. That means no dependency injection and no per-test isolation: whatever it captured at load is what every test sees. The tell is a `resetForTests()` appearing on the public surface. Exporting the factory and letting each caller build its own instance solves this and costs nothing. It adds a frame a reader must decode. Everyone who opens the file has to determine whether the wrapper is doing something meaningful or is a leftover — a small tax, paid on every read, forever. ## How to decide, and how to enforce The rule I would write down for a team is: an IIFE is justified only when there is no module boundary available, or when it is an async wrapper for an `await` that has nowhere else to go. Everything else — module-body wrappers, scoping blocks, singletons that would be better as factories — gets unwrapped on sight. Migration is cheap because unwrapping is a mechanical edit with no behavioural change, provided the body did not rely on the wrapper's own `this` or on redeclaring a name that also exists outside. The more interesting decision underneath is not about the IIFE at all: it is whether a given piece of state should be a process-wide singleton created at load. The IIFE is just the syntax that makes that choice invisible. Making the choice explicit — factory by default, singleton only where the resource genuinely is one — is what actually improves the codebase.