Was der void-Operator wirklich tut

Du hast ihn sicher schon gesehen: void(0) oder javascript:void(0). Hinter dieser kurzen Schreibweise steckt der unäre JavaScript-Operator void. Er wertet einen Ausdruck aus und gibt immer den primitiven Wert undefined zurück – unabhängig davon, was der Ausdruck eigentlich liefern würde.

// Syntax
void <expression>  // Ergebnis ist immer undefined

// Beispiele
void 0;            // undefined
void (2 + 2);      // undefined
void function(){}; // undefined

// Wichtig: Klammern sind optional
void(0) === void 0; // true

• void ist ein Operator, keine Funktion. Das ist wichtig für Parsing und Semantik.
• void(0) und void 0 sind identisch. Klammern dienen nur der Lesbarkeit.
• Rückgabewert ist garantiert undefined – praktisch, wenn du sichergehen willst, dass kein anderer Wert „durchrutscht“.

Historisch wurde void 0 auch deshalb genutzt, weil undefined früher (vor ES5) überschreibbar war. Selbst heute bleibt void 0 in Minifizierungsszenarien beliebt, weil es kürzer ist als undefined.

Merke: void zerstört den Wert eines Ausdrucks bewusst und liefert garantiert undefined. Genau das macht void(0) in Links so „nützlich“ – und gleichzeitig problematisch.

javascript:void(0) in Links: Wie Browser damit umgehen

Ein Klassiker aus den frühen Webjahren ist der Einsatz von javascript:void(0) im href-Attribut eines Links:

<a href="javascript:void(0)" onclick="alert('Hallo!')">Klick mich</a>

Was passiert? Beim Klick wertet der Browser den Ausdruck nach javascript: aus. Wenn dabei ein Wert zurückgegeben wird, den der Browser als Navigationsziel interpretieren könnte, kommt es zu einer (teils seltsamen) Navigation oder einem Seitenersatz. Durch void(0) ist das Ergebnis garantiert undefined – also navigiert der Browser nicht.

Noch ein Beispiel:

<a href="javascript:void(document.body.style.backgroundColor='green')">
  Hintergrund grün
</a>

Der Ausdruck wird ausgeführt (Hintergrund wird grün), aber die Seite lädt nicht neu und es findet keine Navigation statt.

Warum diese Praxis heute problematisch ist

• Sicherheitsrichtlinien (CSP): CSP kann javascript:-URLs blockieren. Viele Teams setzen strikte Richtlinien gegen Inline-Skripte ein, wodurch solche Links nicht mehr funktionieren.
• Barrierefreiheit: Ein Link ist semantisch Navigation. Wenn er nur eine Aktion triggert, irritiert das Screenreader- und Tastaturnutzende.
• Browser-History & UX: javascript: als Navigationsziel ist untypisch. Back/Forward-Verhalten und Fokusmanagement können unerwartet sein.
• Linting & Frameworks: React warnt aktiv vor javascript:-URLs. ESLint-Regeln (z. B. no-script-url) verbieten sie aus gutem Grund.

Moderne Alternativen zu javascript:void(0)

Für Aktionen (nicht Navigation) solltest du heute entweder echte Buttons verwenden oder Links mit sauberem Event-Handling:

1) Verwende einen Button für Aktionen

<button type="button" id="sayHello">Klick mich</button>

<script>
  document.getElementById('sayHello').addEventListener('click', () => {
    alert('Hallo!');
  });
</script>

• Semantisch korrekt und barrierefrei (Tastatur, Screenreader, Rollenmodell).
• Kein Navigationsziel nötig.

2) Link mit preventDefault() – nur wenn Navigation wirklich beabsichtigt ist

Wenn es ein Link sein muss (z. B. wegen Progressive Enhancement), nutze ein reales Ziel und verhindere JS-basiert die Navigation:

<a href="/profil" id="openPanel">Panel öffnen</a>

<script>
  document.getElementById('openPanel').addEventListener('click', (event) => {
    event.preventDefault();       // Kein Navigieren
    // Öffne dein Panel oder führe eine SPA-Aktion aus
    openSidePanel();
  });
</script>

Vorteil: Fällt JavaScript aus, funktioniert der Link dennoch (Progressive Enhancement).

3) Warum href="#" keine gute Idee ist

• Scrollt bei fehlendem preventDefault() nach oben.
• Semantisch unsauber: Ein Link ohne klares Ziel verwirrt Nutzer und Hilfstechnologien.

4) Inline-Handler sind ok, aber besser: entkoppelt

Inline-Events (onclick="") funktionieren, sind aber schlecht wartbar und oft durch CSP eingeschränkt. Bevorzuge entkoppelte Event-Listener mit addEventListener.

Praxisbeispiele: So ersetzt du javascript:void(0) sinnvoll

Veraltete Muster vs. moderne Alternativen

Muster	Problem	Empfohlene Alternative
<a href="javascript:void(0)" onclick="doThing()">	CSP, Semantik, Linting	<button type="button"> + addEventListener
<a href="#" onclick="event.preventDefault(); doThing()">	Scrollt nach oben ohne preventDefault(), semantisch fraglich	Echter Button oder Link mit realem Ziel + JS-Intercept
<a href="">	Undefiniertes Navigationsverhalten	Echter Button oder sinnvolles href

Weitere Anwendungsfälle für void jenseits von Links

IIFEs (Immediately Invoked Function Expressions)

Früher wurde void genutzt, um eine Funktion sicher als Ausdruck zu parsen und direkt auszuführen:

void function() {
  console.log('IIFE mit void');
}(); // Funktion wird sofort ausgeführt

Heutiger Standard ist die Klammer-Variante:

(function() {
  console.log('IIFE modern');
})();

Oder mit Arrow-Funktion:

(() => {
  console.log('IIFE mit Arrow');
})();

Arrow-Funktionen: Rückgabewerte absichtlich verwerfen

Arrow-Funktionen mit kurzer Syntax geben implizit zurück. Das kann in Event-Handlern stören, wenn aus Versehen false oder ein anderer Wert zurückfließt. Mit void eliminierst du die Rückgabe:

// Ohne void: Falls doSomething() false zurückgibt,
// könnte ein Inline-Handler (z. B. onClick-Attribut) das als "return false" deuten.
checkbox.onclick = () => doSomething();

// Sicher stellen, dass undefined zurückkommt:
checkbox.onclick = () => void doSomething();

Hinweis: Bei addEventListener wird der Rückgabewert ignoriert. In alten „DOM-0“-Handlern (onclick="" im HTML) kann ein Rückgabewert false die Default-Aktion verhindern. void sorgt hier für eindeutiges Verhalten.

No-Op-Pattern und garantiertes undefined

const noop = () => void 0; // Kürzeste No-Op-Arrow-Funktion

Das ist prägnant, wenn du bewusst nichts zurückgeben willst – unabhängig von einem evtl. überschatteten undefined-Bezeichner.

„javascript:void(0)“-Fehler: Was dahintersteckt und wie du sie behebst

User melden manchmal „JavaScript void(0) Fehler“. In aller Regel ist void(0) nicht kaputt – sondern JavaScript wird blockiert oder ist deaktiviert. Typische Ursachen und Lösungen:

• JavaScript deaktiviert: In den Browser-Einstellungen wieder aktivieren.
• Script-/Ad-Blocker: Erweiterungen können Inline-Skripte/Events sperren. Website whitelisten oder Regeln prüfen.
• Strenge CSP: javascript:-URLs sind oft untersagt. Lösung: Code in externe Dateien auslagern, Events entkoppeln.
• Proxy/VPN: Fehlkonfigurationen können Skriptladefehler auslösen. Alternativen testen oder konfigurieren.
• Cache/Kekse: Beschädigte Cache-Einträge können Störungen verursachen. Cache und Cookies löschen.
• Pop-up-Blocker: Manche Interaktionen blockiert. Ausnahmeregel hinzufügen.

Für Entwickler bedeutet das: Nutze keine javascript:-URLs, sondern setze auf robuste, CSP-freundliche Event-Handling-Strategien.

Unterschiede: void vs. undefined vs. null

Zentrale Unterschiede der drei Konzepte

Konzept	Art	Bedeutung	Kann überschrieben werden?	Typische Verwendung
void	Operator	Wertet Ausdruck aus, liefert immer undefined	Nein (Operator)	Wert verwerfen, garantiertes undefined
undefined	Primitiver Wert, globale Eigenschaft	„Nicht definiert“ oder nicht initialisiert	Global seit ES5 nicht beschreibbar (read-only), lokal überschattbar	Uninitialisierte Variablen, fehlende Properties
null	Primitiver Wert	„Absichtlich leer“ / „kein Wert“	–	Explizite Leere, z. B. „kein Objekt“

// Beispiele
let a;
console.log(a);            // undefined (nicht initialisiert)
console.log({}.x);         // undefined (Property fehlt)

let b = null;              // absichtliche Leere
console.log(b === null);   // true

// Vergleiche:
console.log(null == undefined);  // true  (abstrakter Vergleich)
console.log(null === undefined); // false (strikter Vergleich)

// Garantiertes undefined, selbst wenn "undefined" überschattet wäre:
console.log(void 0 === undefined); // true

Sicherheit und CSP: Warum javascript: problematisch ist

Eine starke CSP verhindert XSS, indem sie die Ausführung unsicherer Skripte unterbindet. javascript:-URLs gelten als Inline-Code und können unter strengen script-src-Richtlinien blockiert werden. Das bricht <a href="javascript:void(0)"> zuverlässig – genau das, was du in produktiven Umgebungen willst.

• Problem: javascript:-URLs sind schwer auditierbar und fördern Anti-Patterns (Code im Markup).
• Lösung: Saubere Trennung von Markup, Skript und Stil. Externe JS-Dateien, entkoppelte Events, kein Inline-Code.

Best Practice: Setze eine restriktive CSP (kein 'unsafe-inline'), verzichte auf javascript:-URLs und Inline-Handler. Kapsle Aktionen in JS-Module und binde sie über addEventListener an.

Tooling & Frameworks: Linting, Build, React

• ESLint:
  • no-script-url: Verbietet javascript:-URLs.
  • no-void: Unterbindet void standardmäßig, da es Code schwerer lesbar macht. Du kannst es gezielt erlauben (z. B. nur für No-Op oder Rückgabeverwerfung).
• React: React warnt vor javascript:-URLs („security precaution“). Verwende stattdessen echte Buttons oder onClick mit preventDefault() bei Links.
• Minifier (Terser, Uglify): Komprimieren undefined häufig zu void 0, weil’s kürzer ist. Das ist ok – es ist eine Build-Optimierung, kein Pattern für deinen Quellcode.
• TypeScript: Verwechsle den void-Operator nicht mit dem void-Typ. Der TS-Typ void beschreibt Funktionen ohne Rückgabewert; der JS-void-Operator gibt beim Auswerten eines Ausdrucks undefined zurück.

Performance & Wartbarkeit

• „void 0 ist kürzer als undefined“: Stimmt, aber in gzip/Brotli-Setups marginal. Wichtiger ist Lesbarkeit. Lass den Minifier entscheiden.
• Wartbarkeit: void-Einsatz ist für viele Devs ungewohnt. Kommentiere es, wenn du es nutzt – oder vermeide es zugunsten expliziterer Patterns.
• Barrierefreiheit und UX sind wichtiger als ein paar Bytes. Buttons statt Pseudo-Links zahlen sich aus.

Bookmarklets: Wo void legitim bleibt

Ein valider Sonderfall: Bookmarklets. Hier ist javascript: der Mechanismus, um Code im Kontext der aktuellen Seite auszuführen. Viele Bookmarklets enden mit void(0), um zu verhindern, dass der Rückgabewert die aktuelle Seite ersetzt:

javascript:(function(){ alert('Hallo aus dem Bookmarklet'); return; })(), void(0);

Beachte aber: Moderne CSPs in Seiten können Bookmarklets beeinträchtigen. In privaten Workflows sind sie weiterhin nützlich, im Produktiv-Web solltest du sie vermeiden.

Best Practices: Was du heute konkret tun solltest

• Für Aktionen: Nutze <button type="button"> statt Links.
• Für echte Links: Nutze ein sinnvolles href und ggf. event.preventDefault(), wenn du Navigation per JS steuerst (SPA).
• Kein javascript: im href. Setze Linting-Regeln durch (no-script-url).
• Keine Inline-Events (CSP, Wartbarkeit). Entkopple Events per addEventListener.
• Setze CSP restriktiv und plane sie früh ein (script-src ohne 'unsafe-inline').
• Nutze void gezielt: z. B. um implizite Rückgaben zu unterdrücken oder garantierte undefined-Werte zu erzeugen. Lass es ansonsten weg.
• Kommentiere Spezialfälle, wenn du void bewusst einsetzt. Das verbessert Teamverständnis.

Praxis-Patterns: Von „früher“ zu „heute“

Von javascript:void(0) zu Button + Listener

<!-- Alt -->
<a href="javascript:void(0)" onclick="toggleMenu()">Menü</a>

<!-- Neu -->
<button type="button" aria-expanded="false" id="menuToggle">Menü</button>
<script>
  const btn = document.getElementById('menuToggle');
  btn.addEventListener('click', () => {
    const open = btn.getAttribute('aria-expanded') === 'true';
    btn.setAttribute('aria-expanded', String(!open));
    toggleMenu();
  });
</script>

Von Inline-Return zu expliziter Verhinderung

<!-- Alt (DOM-0) -->
<a href="/download" onclick="if(!hasAccess()) return false;">Download</a>

<!-- Neu -->
<a href="/download" id="downloadLink">Download</a>
<script>
  document.getElementById('downloadLink').addEventListener('click', (e) => {
    if (!hasAccess()) {
      e.preventDefault();
      showNoAccessMessage();
    }
  });
</script>

Häufige Missverständnisse rund um Void(0)

• „Das ist eine Funktion“: Nein, void ist ein Operator.
• „href="# ist gleichwertig“: Nein, es kann scrollen und ist semantisch schwach.
• „In React ist javascript: okay, wenn ich’s brauche“: React warnt absichtlich – verwende Buttons oder eventgesteuerte Links.
• „void 0 brauche ich nicht mehr“: In normalem Code meistens nicht. Minifier setzen es intern oft dennoch ein.
• „void ist gefährlich“: Nicht per se. Es ist ein legitimer Operator – problematisch ist die veraltete Link-Nutzung.

Mini-Referenz: void-Operator in der Praxis

Wann void nützlich ist – und wann nicht

Szenario	Beispiel	Bewertung
No-Op/garantiertes undefined	const noop = () => void 0;	Okay – prägnant und eindeutig.
Rückgabe bei Arrow verwerfen	handler = () => void doThing();	Okay – wenn implizite Rückgaben stören.
IIFE erzwingen	void function(){...}();	Historisch – nutze Klammern stattdessen.
Links blockieren	<a href="javascript:void(0)">	Nicht mehr zeitgemäß – vermeide es.

Fazit

Der void-Operator ist ein kleines, aber präzises Werkzeug: Er wertet einen Ausdruck aus und gibt immer undefined zurück. Das macht ihn nützlich, um Rückgabewerte gezielt zu verwerfen oder garantiertes undefined zu erzeugen – etwa in kompakten No-Op-Helfern oder bestimmten Event-Handlern.

Die historische Praxis javascript:void(0) in Links ist dagegen veraltet und kollidiert mit moderner Webentwicklung: Sie steht quer zu CSP-Richtlinien, Barrierefreiheit, Semantik, Wartbarkeit und Framework-Empfehlungen. Setze stattdessen auf echte Buttons für Aktionen, sauberes Event-Handling mit preventDefault() für Links mit realem Ziel und eine klare Trennung von Markup und Logik. Für Bookmarklets bleibt void legitim; im App-Code gehört es jedoch dosiert und bewusst eingesetzt.

Kurz: Verstehe void, nutze es gezielt – aber ersetze javascript:void(0) in deiner UI durch moderne, zugängliche und sichere Patterns.

FAQ

Ist Void(0) noch zeitgemäß?

Nein – nicht in UI-Links. javascript:void(0) war ein Workaround aus der Frühzeit des Webs. Heute sind Buttons, entkoppelte Events und preventDefault() die richtige Wahl. void selbst bleibt als Operator nützlich, z. B. um Rückgaben zu verwerfen.

Was ist der Unterschied zwischen void, undefined und null?

void ist ein Operator, der immer undefined zurückgibt. undefined signalisiert „nicht initialisiert“ oder „nicht vorhanden“. null ist „absichtlich leer“. null == undefined ist true, aber null === undefined ist false.

Warum war void 0 früher wichtig?

Weil der globale Bezeichner undefined in alten Umgebungen überschrieben werden konnte. void 0 garantiert echtes undefined. Heute ist das global nicht mehr überschreibbar, aber lokales Überschatten ist möglich – void 0 bleibt daher formal sicher.

Kann ich href="#" als Ersatz nutzen?

Nur eingeschränkt. Ohne preventDefault() scrollt es nach oben, und semantisch bleibt es schwach. Besser: Nutze Buttons für Aktionen oder echte Links mit sinnvollem Ziel plus JS-Intercept (Progressive Enhancement).

Warum warnt React vor javascript:-URLs?

Aus Sicherheitsgründen. javascript:-URLs gelten als Inline-Skript, was CSP-konträr ist und XSS-Risiken begünstigt. Nutze stattdessen onClick mit Event-Handlern und semantisch passende Elemente.

Darf ich void in Arrow-Funktionen verwenden?

Ja. Es kann sinnvoll sein, implizite Rückgaben zu unterdrücken, z. B. () => void doSomething(). Übertreib es nicht – die meisten Event-Listener ignorieren Rückgabewerte ohnehin. Nutze preventDefault() für Kontrolle über Standardaktionen.

Was tun bei „javascript:void(0)“-Fehlern bei Nutzern?

Typisch: JavaScript ist deaktiviert, durch CSP oder Erweiterungen blockiert, oder der Cache ist defekt. Empfiehl das Aktivieren von JS, das Whitelisten der Seite, das Leeren von Cache/Cookies oder die Prüfung von Proxy/Blockern. Besser: Entferne javascript: aus deinem Code – dann verschwinden diese Fehlerursachen von selbst.

Ist void function(){}() noch sinnvoll?

Es funktioniert, ist aber stilistisch veraltet. Nutze (function(){})() oder (() => {})() – das ist gängiger und verständlicher.

Was sagt ESLint zu void?

Mit no-script-url sind javascript:-Links tabu. no-void verbietet void oft generell; du kannst es konfigurieren, wenn du void als Statement oder gezielt zum Verwerfen benutzt. Prüfe Teamkonventionen.

Wann ist void in Produktionscode okay?

• Als kurzes No-Op (const noop = () => void 0).
• Zum bewussten Verwerfen von Rückgaben (() => void doThing()).
• Nicht als Navigationsziel in Links.