IIFE

Grundform

Eine IIFE besteht aus einer Function-Expression — in Klammern, damit der Parser sie als Ausdruck erkennt — und einem direkten Aufruf-Klammerpaar dahinter.

(function() {
    const geheim = 'privat';
    console.log('IIFE läuft, geheim =', geheim);
})();

// console.log(geheim); // ReferenceError — von außen unsichtbar

IIFE läuft, geheim = privat

Die Variable geheim lebt nur im Function-Scope der IIFE — von außen unerreichbar. Das ist der Hauptzweck: Scope-Isolation ohne Namens-Konflikte.

Syntax-Varianten

Mehrere Schreibweisen sind gleichwertig. Die Engine muss die Funktion als Expression parsen — daher braucht es einen Trigger, der den Statement-Kontext bricht.

// Klammern außen (Crockford-Stil)
(function() { console.log('A'); }());

// Klammern außen, Aufruf außerhalb (verbreiteter)
(function() { console.log('B'); })();

// Unary-Operator als Trigger
!function() { console.log('C'); }();
+function() { console.log('D'); }();
-function() { console.log('E'); }();

// Arrow-IIFE (ES2015+)
(() => { console.log('F'); })();

// Named — für Stack-Traces
(function eigen() { console.log('G'); })();

A
B
C
D
E
F
G

Die Klammer-Form (function() {})() ist die am häufigsten gesehene. Die !function(){}()-Form spart ein Zeichen und war in Minifier-Output beliebt.

IIFE mit Argumenten

Die IIFE kann beim Aufruf Argumente übergeben — praktisch, um globale Objekte (window, jQuery) als lokale Aliase zu übergeben.

// Klassisches Pattern: globale Objekte als Aliase einbinden
(function(global, doc) {
    console.log('Document-Title:', doc.title);
    global.MyLib = { version: '1.0' };
})(globalThis, typeof document !== 'undefined' ? document : { title: 'Node' });

console.log(globalThis.MyLib);

Document-Title: Node
{ version: '1.0' }

Die Aliase haben drei Vorteile: minifier-freundlich (g statt globalThis), schneller (Property-Lookup ohne Scope-Chain), und ein klarer Vertrag zwischen Modul und Umgebung.

IIFE als Modul-Pattern

Pre-ESM war eine IIFE, die ein Objekt zurückgibt, das Standard-Pattern für „Module".

const Counter = (function() {
    let stand = 0;
    const max = 100;

    function inkrement() {
        if (stand < max) stand++;
        return stand;
    }
    function reset() { stand = 0; }
    function lese() { return stand; }

    return { inkrement, reset, lese };   // public API
})();

Counter.inkrement();
Counter.inkrement();
Counter.inkrement();
console.log('Stand:', Counter.lese());
Counter.reset();
console.log('Nach reset:', Counter.lese());

Stand: 3
Nach reset: 0

Das ist im Kern dieselbe Idee wie ein ESM-Modul: privater State innen, öffentliche API außen. ESM macht es nur deklarativer und tooling-fähiger.

Async-IIFE — Modern noch praktisch

Eine moderne Anwendung: async-IIFE für Top-Level-Init in CommonJS oder Skripten ohne Top-Level-Await-Support.

(async function init() {
    console.log('Start');
    // simuliertes asynchrones Laden
    const data = await new Promise(r => setTimeout(() => r({ ok: true }), 10));
    console.log('Geladen:', data);
})();

console.log('Sync-Code läuft weiter');

Start
Sync-Code läuft weiter
Geladen: { ok: true }

Das ist eine der wenigen Situationen, in denen IIFE auch in modernem Code idiomatisch ist. In ESM mit Top-Level-Await ist auch das überflüssig — await foo() darf direkt im Modul-Top-Level stehen.

Block-Scope statt IIFE

Für reine Variable-Isolation reicht heute ein einfacher Block mit let/const:

// Alt — IIFE für Scope-Isolation
(function() {
    var temp = 'altmodisch';
    console.log(temp);
})();

// Neu — einfacher Block mit let/const
{
    const temp = 'modern';
    console.log(temp);
}

// temp ist außerhalb beider Formen unsichtbar

altmodisch
modern

Der Block ist kürzer, einfacher und genauso effektiv für Scope-Isolation. Eine IIFE für reine Scope-Isolation ist in ES2015+ obsolet.

UMD — Universal Module Definition

Eine erweiterte IIFE-Form, die in alten Library-Bundles üblich ist: das UMD-Pattern prüft die Umgebung (AMD, CommonJS, Browser) und exportiert entsprechend.

(function(root, factory) {
    if (typeof define === 'function' && define.amd) {
        // AMD (RequireJS)
        define([], factory);
    } else if (typeof module === 'object' && module.exports) {
        // CommonJS / Node
        module.exports = factory();
    } else {
        // Browser-Global
        root.MyLib = factory();
    }
})(typeof self !== 'undefined' ? self : this, function() {
    return {
        version: '1.0',
        gruss() { return 'Hallo'; },
    };
});

UMD ist heute nur noch in Legacy-Library-Bundles relevant. Moderne Libraries publizieren ESM + CJS-Builds parallel, ohne den UMD-Detector. Aber: wer mit alten CDN-Skripten arbeitet, sieht das Muster ständig.

Wann heute noch eine IIFE?

In modernem Code reduziert sich der Einsatz auf wenige Fälle:

• Top-Level await in Nicht-ESM-Umgebung (Browser-Skript ohne type="module", ältere Node-Versionen).
• Sofort-Ausführung mit Argumenten, etwa zur One-Liner-Konfiguration.
• Generierter Code in Bundlern oder Source-Maps, der mehrere Module in eine Datei wickelt.
• CDN-Library-Bundles, die ohne Module-Loader auskommen müssen.

// Sofort-Auswertung mit Argument
const config = (function(env) {
    return {
        api: env === 'prod' ? 'https://api.app' : 'http://localhost:3000',
        debug: env !== 'prod',
    };
})('dev');

console.log(config);

{ api: 'http://localhost:3000', debug: true }

In modernem Code wäre dasselbe meist ohne IIFE lesbar als Funktion mit Parameter und direktem Aufruf — die IIFE ist nur dann motivierter, wenn der Code-Block einmalig und nicht wiederverwendbar ist.

Performance — kein Argument

Moderne Engines inline-optimieren IIFEs aggressiv. Es gibt keinen messbaren Performance-Vorteil oder -Nachteil gegenüber Block-Scope oder normalen Funktionen.

Frühere Annahmen, dass lokale Variablen-Lookups in einer IIFE schneller wären, gelten heute nicht mehr — V8, SpiderMonkey und JSC erkennen die Pattern und optimieren entsprechend.

Die Wahl IIFE vs. Alternative ist eine Lesbarkeits- und Style-Entscheidung, keine Performance-Frage.

Weiterführende Ressourcen

Externe Quellen

• IIFE – MDN Glossary
• Function expressions – MDN
• Module pattern – MDN Learn
• Ben Alman: IIFE explained

Verwandte Artikel

• Closures
• Function-Declaration vs. Expression
• Arrow Functions
• Hoisting verstehen
• Variablen: var, let, const