Vanilla JavaScript und native DOM-APIs als Alternative zu React und anderen Frameworks

Vanilla JavaScript bezeichnet die Nutzung von JavaScript und Browser-APIs ohne zusätzliche UI-Bibliothek. Bei einem kleinen Rechner, einer Statusanzeige oder einem unabhängigen Seitenwerkzeug kann dieser Ansatz Abhängigkeiten und übertragene Daten verringern. Bei Anwendungen mit gemeinsamem Zustand, Routing und vielen abgestimmten Ansichten kann ein Framework hilfreiche Struktur liefern. Entscheidend sind Oberfläche und Wartungsbedarf, keine allgemeine Rangliste der Geschwindigkeit.

Rendering-Kosten benötigen Messungen

React berechnet beim Rendern die gewünschte Oberfläche und übernimmt die nötigen DOM-Änderungen. Layout und Zeichnen bleiben Aufgaben des Browsers. React, Angular und Vue verwenden keine identische Aktualisierungstechnik. Hydratisierung verbindet clientseitiges Verhalten mit bereits serverseitig erzeugtem HTML; nicht jede Anwendung verwendet Hydratisierung.

Große Skripte und lange synchrone Aufgaben können Interaktionen bei beiden Architekturen verzögern. Auch direkte DOM-Zugriffe können aufwendige Layoutberechnungen auslösen, besonders bei abwechselndem Lesen und Ändern des Layouts. Der Wegfall einer Bibliothek beseitigt nicht die Arbeit der Anwendung.

LCP beschreibt den Zeitpunkt, an dem das größte berücksichtigte sichtbare Inhaltselement gerendert wird. Serverantwort, Bilder, Schriften, CSS und JavaScript können den Wert beeinflussen. INP beschreibt die Reaktionsfähigkeit bei Interaktionen während des Seitenbesuchs. Kleinere Pakete können helfen; weder die Zahl der Abhängigkeiten noch CSS Grid garantieren gute Werte. Ein Vergleich benötigt gleiche Funktionen, repräsentative Geräte, Labordiagnose und Messungen aus realen Seitenbesuchen.

Native Bausteine

• Semantisches HTML: native Schaltflächen, Formularfelder und aufklappbare Bereiche bilden einen brauchbaren Ausgangspunkt vor eigenem JavaScript.
• Custom Elements: wiederverwendbare Elemente können auf Einbindung und Attributänderungen reagieren. Shadow DOM grenzt optional einen inneren Baum und dessen Stile ab; Custom Elements benötigen keinen Shadow DOM.
• Templates: ein gewöhnliches <template> hält ein inaktives Fragment zum Klonen bereit. Das Klonen und Einfügen großer Bäume benötigt weiterhin Zeit.
• Event Delegation: ein Container kann passende aufsteigende Ereignisse von Kindelementen verarbeiten. Nicht aufsteigende Ereignisse und Shadow-Grenzen benötigen gesonderte Behandlung.

Diese Funktionen gehören zu den Webstandards HTML und DOM. ECMAScript definiert die Sprache JavaScript, nicht das gesamte Komponentenmodell des Browsers.

Statusanzeige mit klarer Zustandsbehandlung

Die folgende Light-DOM-Komponente verwaltet den eigenen Kindinhalt und akzeptiert nur idle, ready und error. Unbekannte Werte ergeben idle. Attributänderungen aktualisieren den sichtbaren Text auch nach dem Einfügen; erneutes Einbinden behält die vorhandenen Knoten.

class CustomStatusBadge extends HTMLElement {
  static observedAttributes = ['data-status'];

  connectedCallback() {
    if (!this.badge) {
      this.badge = document.createElement('span');
      this.dot = document.createElement('span');
      this.dot.className = 'dot';
      this.dot.setAttribute('aria-hidden', 'true');
      this.label = document.createElement('span');
      this.label.className = 'label';
      this.badge.append(this.dot, this.label);
      this.replaceChildren(this.badge);
    }
    this.render();
  }

  attributeChangedCallback() {
    if (this.badge) this.render();
  }

  render() {
    const raw = this.getAttribute('data-status');
    const status = ['idle', 'ready', 'error'].includes(raw) ? raw : 'idle';
    this.badge.className = 'badge badge-' + status;
    this.label.textContent = 'Status: ' + status.toUpperCase();
  }
}
customElements.define('status-badge', CustomStatusBadge);

Die Registrierung erfolgt einmalig, vorzugsweise aus einem externen Modul. Beispiel-Markup: <status-badge data-status="ready">Status: READY</status-badge>. Der Ersatztext bleibt vor Ausführung des Moduls verfügbar. Die Gestaltung von .badge, .dot und den Statusklassen hängt von der Anwendung ab. Englische Beispielbeschriftungen benötigen in einer mehrsprachigen Oberfläche eine Lokalisierung.

Der DOM-Aufbau vermeidet das Parsen eines HTML-Strings; textContent fügt Text ein. Die Werteliste verhindert zusätzlich fremde CSS-Klassen durch beliebige Statuswerte. Das ist eine lokale Komponentenregel, kein vollständiges Sicherheitskonzept: URLs, formatiertes HTML und weitere Ausgabekontexte benötigen passende Behandlung. Der dekorative Punkt bleibt für assistive Technik verborgen; Text vermittelt den Zustand unabhängig von Farbe. Automatische Ansagen bei Änderungen benötigen eine bewusst gestaltete und getestete Live-Region.