JSX Ist Nicht HTML: Die wahren Kompromisse Hinter Component Markup
Verstehen, was man aufgibt, wenn Markup zu JSX wird – von Werkzeugen und Parsing bis hin zu Formularen, Barrierefreiheit und Portabilität – sowie die Muster, mit denen man den größten Teil davon zurückgewinnen kann.
Fast jedes React-Tutorial versichert Anfängern, dass JSX „im Grunde HTML innerhalb von JavaScript“ ist. Die Ähnlichkeit besteht tatsächlich, doch diese Versicherung verdeckt eine Reihe von Nachteilen, die sich später in den Build-Prozessen, der Größe der Pakete, der Eingabelatenz sowie bei Zugänglichkeitsprüfungen zeigen. Im Folgenden erfahren Sie, was JSX tatsächlich hinter seiner Oberfläche ist, welche Funktionen sich ändern, wenn Markup vom Parser des Browsers in eine JavaScript-Laufzeitumgebung übergeht, und welche konkreten Muster den größten Teil dessen wiederherstellen können, was verloren geht, ohne auf Komponenten zu verzichten.
Eine vertraute Ansicht auf einer anderen Maschine
JSX übernimmt nahezu vollständig die Oberfläche von HTML. Elemente beginnen mit <button>, enden mit </button> und sind wie seit den 1990er Jahren üblich verschachtelt. Diese Vertrautheit hat es einer ganzen Generation von Entwicklern erheblich erleichtert, auf Single-Page-Anwendungen umzusteigen:
// It looks like HTML...
function UserCard({ name, role }) {
return (
<div className="card">
<h3>{name}</h3>
<p>{role}</p>
</div>
);
}
Tatsächlich handelt es sich bei diesen beiden Technologien um unverwandte Konzepte. HTML ist eine deklarative Markup-Sprache, die von Browser-Engines direkt mit stark optimiertem natives Code verarbeitet wird. JSX hingegen ist eine Syntax, die von einem Compiler in verschachtelte JavaScript-Funktionsaufrufe umgeschrieben wird: React.createElement bei der klassischen Transformation oder Hilfsfunktionen wie _jsx() im modernen automatischen Laufzeitumfeld. Der <div> in einer Komponente ist überhaupt keine Markup-Struktur; es handelt sich dabei um eine Argumentliste.
Durch den Einsatz von JSX erhält man viele Vorteile: Komponentenbäume, die durch Daten gesteuert werden, automatische Synchronisierung zwischen Zustand und DOM sowie Typüberprüfung der Templates. Jede Abstraktion hat jedoch ihren Preis. Der Ersatz eines nativen Browserformats durch eine JavaScript-Schicht bedeutet Abhängigkeit von Build-Tools, höheren Speicherverbrauch zur Laufzeit sowie das Umgehen mehrerer Resilienzfunktionen, die die Plattform kostenlos bietet. Keiner dieser Kosten ist ein Grund, JSX zu vermeiden – doch jeder sollte bei der Entwicklung einer Anwendung berücksichtigt werden.
Die Kosten für die Tools
Verlust des Doppelklick-Workflows
Das Erste, was verschwindet, ist die einfache, abhängigkeitsfreie Struktur der Webplattform. Eine einfache HTML-Seite benötigt nichts weiter als einen Editor und einen Browser. Man kann index.html auf einem Offline-Computer erstellen, darauf doppelklicken – und der Browser rendernt sie sofort über eine file://-URL.
Kein JavaScript-Engine, egal ob V8, JavaScriptCore oder SpiderMonkey, versteht <div className="box"> als Code. Bevor irgendetwas auf dem Bildschirm angezeigt wird, benötigt JSX eine Kompilierkette:
- einen Compiler wie Babel, SWC oder esbuild
- einen Bundler wie Vite, Webpack, Rollup oder Turbopack
- npm, pnpm oder yarn zur Installation von Abhängigkeiten
- Node.js oder Bun zur Ausführung dieser Tools
- eine
node_modules-Ordner, der in der Regel Hunderte von Megabyte an Voreinstellungen, Parsern, Plugins und Polyfills enthält
(Für schnelle Experimente existieren Babel-Kompilierungen direkt im Browser, doch diese sollten nicht in der finalen Version verwendet werden.) Der Weg vom Quellcode bis zu den Pixeln sieht wie folgt aus:
HTML Workflow:
[index.html] ----------> Directly parsed by Browser Engine (Instant)
JSX Workflow:
[Component.jsx]
└─> AST Parsing
└─> Transpilation (_jsx() calls)
└─> Bundling & Minification
└─> Network Download
└─> JS Parse & Compile
└─> Runtime Virtual DOM
└─> DOM Mutation
Der Wartungsaufwand
Die Verknüpfung von Markup mit einem Compiler erzeugt anhaltende Kosten:
- Rote Toolchain. Ein Projekt, an dem drei Jahre lang niemand gearbeitet hat, weigert sich oft, kompiliert zu werden, weil die zugrunde liegenden Pakete, erforderliche Node.js-Versionen oder Bundler-APIs weiterentwickelt wurden.
- Brüchigkeit der Quellkarten. Das Debuggen in der Produktion bedeutet, die minifizierten Ausgabeversionen wieder auf die ursprünglichen Komponenten zurückzuverfolgen. Wenn Quellkarten fehlen oder falsch sind, zeigen Stack-Traces anonyme Laufzeitaufrufe anstelle des eigenen Codes.
- Zögerliche Build-Antwortzeit. Moderne Bundler, die in Rust oder Go geschrieben sind, sind äußerst schnell, doch in sehr großen Codebasen führt die kontinuierliche Neukompilierung immer noch zu Verzögerungen, die bei der Bearbeitung von rohem Markup einfach nicht auftreten.
Syntaxbeschränkungen, die aus JavaScript übernommen wurden
Weil JSX als JavaScript interpretiert wird, erbt es die reservierten Wörter sowie die strengere Grammatik von JavaScript und verliert dadurch die Nachsicht des HTML.
Reservierte Wörter werden in neue Eigenschaftsnamen umgewandelt
Ein HTML-Attribut ist eine Zeichenkette, die an einen DOM-Node gebunden ist. Eine JSX-Eigenschaft ist ein Schlüssel in einem Objekt, das an eine Funktion übergeben wird. Da class und for in JavaScript Reservierter Wörter sind, verwendet JSX andere Namen. Die Standard-HTML-Form:
<!-- Native, standards-compliant HTML -->
<label for="username">Username</label>
<div class="profile-card" tabindex="0"></div>
wird in JSX wie folgt dargestellt. Beachten Sie außerdem, dass tabIndex eine numerische Ausdrucksform statt einer Zeichenkette erhält:
// JSX equivalents forced by JavaScript engine constraints
<label htmlFor="username">Username</label>
<div className="profile-card" tabIndex={0}></div>
Groß-/Kleinschreibung und Style-Objekte
Die Namen von HTML-Attributen sind unempfindlich gegenüber Groß- und Kleinschreibung, während JSX-Props empfindlich sind und meist im camelCase-Format vorliegen: onClick, strokeWidth, autoComplete, tabIndex. Eine Korrektur einer gängigen Annahme: Die Attribute aria-* und data-* bilden die Ausnahme und behalten in JSX ihre mit Bindestrichen verbundenen Namen bei, sodass aria-label genauso geschrieben wird wie in HTML.
Inline-Stile verändern sich grundlegender. In HTML ist ein Stil einfach ein String, den der Browser parsen muss:
<!-- HTML: Zero runtime allocation -->
<div style="background-color: red; margin-top: 10px;"></div>
In JSX handelt es sich um ein JavaScript-Objektliteral, und ein solches Literal, das innerhalb der Render-Ausgabe geschrieben wird, wird jedes Mal neu erstellt, wenn die Komponente gerendert wird:
// JSX: Allocates a new JavaScript object on every single render pass
<div style={{ backgroundColor: 'red', marginTop: '10px' }} />
Für die meisten Komponenten ist dies vernachlässigbar. In Komponenten, die sehr häufig neu gerendert werden – wie große Datentabellen oder von Zeigern gesteuerte Canvas-Überlagerungen – führen Tausende kurzlebiger Stilobjekte zu einem erhöhten Druck auf die Garbage Collection, was sich in Verzögerungen äußern kann. Durch das Herausnehmen statischer Stilobjekte aus der Komponente oder die Verwendung von Klassennamen lässt sich dies vermeiden.
Straffe Schließregeln
HTML5 toleriert absichtlich leere Elemente ohne schließende Schrägstriche: <input>, <img>, <br> und <hr> sind alle in dieser Form gültig. JSX hingegen folgt den XML-Regeln. Vergisst man den selbstschließenden Schrägstrich oder ein Schließtag, stoppt der Compiler mit einem Syntaxfehler, sodass die Kompilierung fehlschlägt anstatt sanft weiterzuarbeiten.
Ausführungskosten: natives Parsing versus virtueller DOM
Wenn der Browser HTML erhält, tokenisiert er die ankommenden Bytes und erstellt schrittweise DOM-Node, wobei dabei seit Jahrzehnten optimierter natives Code genutzt wird und ein spekulativer Vorauslade-Scanner dabei hilft, Ressourcen frühzeitig zu entdecken. Wenn eine Anwendung vollständig über JSX gerendert wird, wird dieser native Weg größtenteils umgangen und stattdessen die Ausführung von JavaScript bevorzugt:
Standard HTML Processing:
Network Bytes ──> Tokenizer ──> DOM Tree ──> Render Tree ──> Paint
JSX / Virtual DOM Processing:
Network Bytes ──> JS Parse/Compile ──> JS Execution ──> Component Tree
──> VDOM Allocation ──> VDOM Diffing (Reconciliation)
──> DOM Patching ──> Render Tree ──> Paint
Speicher und Abfallsammlung
Zur Berechnung von Aktualisierungen speichert React eine Beschreibung der Benutzeroberfläche im JavaScript-Speicher, die gemeinhin als virtueller DOM bezeichnet wird. Der Ablauf funktioniert im Großen und Ganzen wie folgt:
- Durch die erste Renderung wird ein Baum aus JavaScript-Objekten erstellt, der jedes Element sowie dessen Eigenschaften und Kinder beschreibt.
- Wenn sich der Zustand ändert, werden die betroffenen Komponenten erneut ausgeführt und liefern eine neue Beschreibung ihres Teils des Baums.
Bemerken Sie, dass React den Unterbaum unterhalb der Komponente, deren Zustand sich geändert hat, neu rendernt – und nicht die gesamte Anwendung –, doch das Prinzip bleibt dasselbe: Der Browser speichert bereits den echten DOM in seiner eigenen internen Speicherung, und der JavaScript-Heap enthält außerdem eine parallele Darstellung. Diese zusätzliche Speicherzuweisung erhöht den Speicherverbrauch sowie die Häufigkeit der Garbage Collection, was insbesondere auf Geräten mit schwacher Leistung auffällig ist.
Die Kosten der Hydratierung
Serverseitiges Rendering in Frameworks wie Next.js oder Remix sendet echtes HTML, sodass die erste Anzeige schnell erfolgt. Bevor die Seite jedoch auf Eingaben reagiert, muss der Browser das JavaScript für die darauf enthaltenen Komponenten herunterladen, es ausführen, den internen Baum von React neu aufbauen und Ereignishandler an den vorhandenen DOM anhängen. Dieser Hydratierungsprozess belegt den Hauptthread, und bei aufwendigen Seiten zeigt sich dies in einer hohen Gesamtblokkierzeit (Total Blocking Time, TBT) sowie einem niedrigen Interaktionswert zum ersten Anzeigen (Interaction to Next Paint, INP).
Streaming und Fehlertoleranz
HTML wurde nach zwei Prinzipien entworfen, die JSX-basierte Single-Page-Apps oft untergraben: schrittweises Streaming und Toleranz gegenüber Fehlern.
Wenn das Streaming verschwindet
Ein Browser beginnt mit der Darstellung eines Dokuments, bevor es vollständig heruntergeladen wurde. Angenommen, der Server hat bislang den <head> sowie 50 KB einer insgesamt 200 KB großen Seite übermittelt; der Browser kann bereits Stylesheets und Schriftarten anfordern sowie den Header und die Navigation anzeigen, während der Rest noch unterwegs ist.
Eine rein clientseitig rendernde JSX-App funktioniert anders:
- der Browser erhält eine fast leere Struktur, die nur
<div id="root"></div>enthält - er lädt das JavaScript-Bundle herunter
- er analysiert und führt dieses Bundle aus
- die Komponenten laufen, bauen das DOM auf und zeigen schließlich den Inhalt an
Bei einer langsamen 3G-Verbindung oder einem schwach ausgestatteten Telefon sieht der Benutzer während dieser gesamten Abfolge eine leere Seite. Das ist alles, womit der Browser zunächst arbeiten muss:
<!-- What the browser sees initially in a standard JSX SPA -->
<!DOCTYPE html>
<html>
<head>
<title>App</title>
</head>
<body>
<div id="root"></div>
<script src="/static/bundle.8f9b2c.js"></script>
</body>
</html>
Wenn Fehler nicht mehr toleriert werden
Der HTML-Parser ist berühmt für seine Toleranz. Geben Sie ihm fehlerhaften Markup wie dieses ein:
<div>
<p>Unclosed paragraph
<div>Nested incorrectly</b>
</div>
und er versagt nicht. Der Parsing-Algorithmus schließt und neu verschachtelt Elemente gemäß gut definierten Wiederherstellungsregeln und zeigt den Inhalt dennoch an.
React ist bei der Laufzeit weitaus weniger nachsichtig. Wenn die Darstellung fehlschlägt – beispielsweise weil eine Ausdruck wie {user.profile.name} eine Eigenschaft von undefined abruft – deinstalliert React den gesamten Baum, wenn kein Error Boundary den Fehler auffängt, wodurch ein leeres Bildschirmbild entsteht. React liefert kein fertiges <ErrorBoundary>-Komponente mit; Sie schreiben eine solche als Klassenkomponente (oder verwenden eine kleine Bibliothek) und platzieren sie absichtlich um gefährdete Bereiche herum.
Formulare und Ereignisse
Seit den Anfängen des Internets haben HTML-Formulare Eingaben, Validierung und Absendung nativ abgebildet. Typische JSX-Muster ersetzen diese Grundfunktionen oft durch JavaScript-Implementierungen.
Kontrollierte versus native Eingaben
Eine einfache <input>-Element bleibt in ihrem eigenen Zustand. Das Eintippen aktualisiert sofort den internen Puffer des Browsers, ohne dass ein Skript involviert ist. Das übliche React-Muster hingegen macht die Eingabe kontrolliert, sodass der React-Zustand zur Quelle der Wahrheit wird:
// Every keystroke triggers a state change, a re-render, and a VDOM diff
function SearchInput() {
const [value, setValue] = useState("");
return (
<input
type="text"
value={value}
onChange={(e) => setValue(e.target.value)}
/>
);
}
Jeder Tastendruck durchläuft nun das Ereignissystem, setzt den Zustand, ruft die Komponentenfunktion erneut auf, bringt alles in Einklang und gibt den Wert anschließend wieder in das DOM zurück. Das ist für eine kleine Komponente in Ordnung. Wenn der Hauptthread mit Datenverarbeitung oder aufwendigen Animationen beschäftigt ist oder wenn die Eingabe innerhalb eines großen Komponentenbaums liegt, der zusammen mit ihr neu gerendert wird, können Benutzer erkennen, dass Zeichen deutlich nach dem Eintippen sichtbar werden.
Synthetische Ereignisse
React umhüllt die nativen Browser-Ereignisse mit seinem eigenen synthetischen Ereignissystem, ursprünglich um Inkonsistenzen zwischen älteren Browsern auszugleichen. Diese Abstraktion führt jedoch zu einigen versteckten Problemen:
- Die Ausbreitung der Ereignisse durch Reacts Baum kann sich von der Ausbreitung über native DOM-Listener unterscheiden, was Code verwirrt, der beides verwendet
Accessibilität und semantischer Verfall
JSX kann perfekt zugängliches, semantisches HTML erzeugen. Die von ihm geförderten Muster neigen jedoch im Laufe der Zeit dazu, die Semantik zu untergraben.
„Div-Suppe“ durch Komponentenumhüllungen
Eine Komponente muss einen einzigen Wurzelknoten zurückgeben. Fragmente (<Fragment> oder <>) lösen dieses Problem ohne zusätzliches DOM, doch viele Codebasen umhüllen ihre Kinder aus Gewohnheit oder zur Layout-Steuerung weiterhin in <div>-Container. Die Struktur, die Sie erzeugen wollten, sieht wie folgt aus:
<!-- What you intended to build -->
<main>
<article>
<h1>Article Title</h1>
<p>Content goes here...</p>
</article>
</main>
Während schichtweise Wrapper-Komponenten oft etwas Ähnliches darstellen:
<!-- What JSX component wrapping often generates in the actual DOM -->
<div class="AppWrapper">
<div class="LayoutContainer">
<main>
<div class="ArticleWrapper">
<article>
<div class="HeadingGroup">
<h1>Article Title</h1>
</div>
<div class="ParagraphContainer">
<p>Content goes here...</p>
</div>
</article>
</div>
</main>
</div>
</div>
Die zusätzlichen Schichten machen den DOM schwerer, erschweren die CSS-Layout-Planung und fügen Störungen zwischen den wichtigsten Elementen hinzu. Allgemeine <div>-Elemente ohne Rollen werden in der Regel von Assistenztechnologien ignoriert, doch tiefe Wrapper-Ketten erschweren weiterhin das Verständnis der Markup-Struktur und führen leicht zu Fehlern – beispielsweise wenn ein Wrapper versehentlich eine Liste- oder Überschriftenstruktur stört.
Tastaturverhalten, das man kostenlos bekommt – bis es plötzlich nicht mehr funktioniert
Eingebettete interaktive Elemente wie <button>, <a>, <select> und <details> verfügen über ein Verhalten, das man leicht als selbstverständlich hinnimmt:
- sie sind standardmäßig in der Tab-Reihenfolge fokussierbar
- Enter und Leerzeichen aktivieren sie automatisch
Weil JSX es einfach macht, einem beliebigen Element einen Klick-Handler zuzuweisen – wie in <div onClick={handleClick}> – erstellen Teams regelmäßig benutzerdefinierte Steuerelemente aus nicht-semantischen Elementen und vergessen dabei die Tastatur-Handler, tabIndex sowie die ARIA-Rollen, die diese nativen Elemente automatisch bereitstellen. Unsere Übersicht zu versteckten Fallen bei React-Komponenten behandelt weitere dieser Probleme.
Standards, Interoperabilität und Lock-in
HTML ist ein offener Standard, der von WHATWG gepflegt wird, wobei das W3C historisch beteiligt war. Seiten, die 1997 geschrieben wurden, laufen weiterhin in aktuellen Browsern. JSX hingegen ist kein Web-Standard. Es verfügt über eine inoffizielle Spezifikation und wird von mehreren Bibliotheken unterstützt, darunter React, Preact und Solid, doch jede Verwendung hängt von einem Compiler sowie vom Laufzeitumfeld ab, auf das der kompilierte Code ausgerichtet ist. Das stellt eine mildere Form des Lock-ins dar als ein proprietäres Format, ist aber dennoch ein Lock-in.
Kundenelemente und das eigene Komponentenmodell der Plattform
Browser bieten bereits ein Komponentenmodell: Custom Elements zusammen mit Shadow DOM. Einfaches HTML verwendet sie direkt:
<user-avatar src="avatar.jpg" size="large"></user-avatar>
React hat historisch aus zwei Gründen mit Kundenelementen schlecht umgegangen:
- es übertrug alle Eigenschaften an unbekannte Kleinbuchstaben-Elemente als Zeichenkettenattribute, sodass Objekte und Arrays nicht als Elementeigenschaften übergeben werden konnten
new CustomEvent('user-select') gesendet werden, wurden nicht auf eine Eigenschaft wie onUserSelect abgebildet, wodurch Wrapper-Komponenten oder manuelle Zuhörer über refs erforderlich wurden.React 19 hat einen Großteil dieses Problems gelöst, indem es Eigenschaften auf Custom-Elements setzt, sobald das Element sie definiert, und Custom-Event-Handler unterstützt. Überprüfen Sie daher vorab, für welche React-Version Sie arbeiten, bevor Sie davon ausgehen, dass diese Einschränkungen weiterhin gelten.
Portabilität der Markup-Sprache
Ein Design-System, das in Standard-HTML und CSS geschrieben ist, kann von überall genutzt werden: WordPress, Django, Ruby on Rails, Go-Templates, Vue, Angular, Svelte oder einfache statische Seiten. Ein Design-System, das als JSX-Komponenten geschrieben ist, ist an das JavaScript-Ecosystem gebunden. Die Verwendung davon aus einem nicht-JavaScript-basierten Backend erfordert einen Node.js-Rendering-Dienst oder eine separate Implementierung jeder Komponente.
HTML und JSX nebeneinander
Zusammenfassung der Kompromisse:
- Ausführung: HTML wird vom Browser nativ interpretiert; JSX wird zu JavaScript-Funktionsaufrufen kompiliert, die zur Laufzeit ausgeführt werden.
- Werkzeuge: HTML benötigt einen Editor und einen Browser; JSX benötigt einen Compiler, einen Bundler, einen Paketmanager sowie eine Build-Laufzeitumgebung.
- Syntax: HTML ist unempfindlich gegenüber Groß- und Kleinschreibung und tolerant; JSX ist großschreibensensitiv, verwendet umbenannte Eigenschaften und erfordert ein Schließen im XML-Stil.
- Ausgabe: HTML streamt und zeichnet schrittweise; clientseitig ausgegebener JSX wartet darauf, dass der Bundle heruntergeladen und ausgeführt wird.
- Fehler: HTML kann sich von fehlerhafter Markup-Struktur erholen; ein unerkannter Render-Fehler führt zum Entfernen des React-Baums.
- Formulare: Native Eingabefelder behalten ihren eigenen Zustand bei; kontrollierte Eingabefelder werden bei jeder Tastenbetätigung neu gerendert.
Was verloren ging, zurückgewinnen
Nichts davon spricht dafür, die componentbasierte Entwicklung aufzugeben. Es geht vielmehr darum, bewusst zu entscheiden, wo die Abstraktion ihren Aufwand rechtfertigt. Das Ecosystem entwickelt sich genau in diese Richtung – mit Mustern, die die Geschwindigkeit und Widerstandsfähigkeit des nativen HTML wiederherstellen, während gleichzeitig ein deklaratives Erstellungsmodell beibehalten wird.
Server-first Rendering wählen
- React Server Components rendern auf dem Server und senden für nicht interaktive Teile kein Komponenten-JavaScript an den Client.
- Astro verwendet eine Insel-Architektur: Seiten sind standardmäßig statische HTML-Dateien, und nur isolierte interaktive Widgets werden dynamisch geladen.
- Qwik ersetzt das Dynamisieren durch Fortsetzbarkeit, indem es den Anwendungsstatus in das HTML serialisiert, sodass der Code nur dann ausgeführt wird, wenn der Benutzer tatsächlich interagiert.
Lassen Sie den Browser den Formzustand verwalten
Anstatt jeden Tastendruck im Zustand widerzuspiegeln, sollte der native <form>-Element die Werte speichern und diese beim Absenden mithilfe von FormData einmal abrufen:
// Clean, native, performant HTML-first form submission
function LoginForm() {
function handleSubmit(event) {
event.preventDefault();
const data = new FormData(event.currentTarget);
const email = data.get("email");
// Send payload...
}
return (
<form onSubmit={handleSubmit}>
<input type="email" name="email" required />
<button type="submit">Sign In</button>
</form>
);
}
Die Eingabe aktualisiert sich in nativer Geschwindigkeit, das required-Attribut bietet eingebaute Validierung, und das Komponente wird nur einmal gerendert – nicht bei jedem Tastendruck. Neuere React-Versionen bauen auf derselben Idee mit Form-Aktionen auf, die FormData direkt akzeptieren.
Bewahren Sie strenge Semantik bei
Betrachten Sie JSX als Möglichkeit, semantisches HTML zu erzeugen – nicht als Freibrief, um Container übereinander anzuhäufen:
- Ersetzen Sie Wrapper
<div>-Elemente durch Fragmente (<></>), wo der Wrapper keine gestalterische Funktion hat - Verwenden Sie native interaktive Elemente wie
<button>,<dialog>,<details>und<summary>anstelle selbst erstellter Widgets - Fügen Sie
eslint-plugin-jsx-a11yzur kontinuierlichen Integration hinzu, damit fehlende Beschriftungen, Rollen und Tastatursteuerungen den Build verhindern
Zusammenfassung
JSX hat die Frontend-Entwicklung verändert, indem es zeigte, dass Schnittstellen am besten als vorhersehbare Funktionen von Daten beschrieben werden können, und es löste echte Probleme bei der Synchronisierung großer, dynamischer Benutzeroberflächen mit dem Zustand. Es handelt sich weiterhin um eine JavaScript-Abstraktion, nicht um eine neuere Version von HTML. Die Wahl davon bedeutet, dass man auf natives Streaming, erstellungsfreies Erstellen von Inhalten, Fehlertoleranz sowie langfristige Standardsstabilität verzichtet, um Komposition und reaktive Ergonomie zu gewinnen. Das ist oft ein guter Tausch. Die ingenieurtechnische Fähigkeit besteht darin, genau zu wissen, was man aufgegeben hat, und serverseitiges Rendering, native Formulare sowie semantische Elemente zu nutzen, wo immer man diese Funktionen kostenlos zurückgewinnen kann.
Verwandte Artikel
- REST vs GraphQL: Die tatsächlichen Kompromisse hinter jeder Architektur — Erklärt die spezifischen Probleme, die REST und GraphQL jeweils lösen, ihre internen Mechanismen sowie die versteckten Kompromisse, die bei der Auswahl für Ihre API berücksichtigt werden müssen.
- Zehn versteckte Fallstricke bei React-Komponenten, die moderne Anwendungen verlangsamen — Lernen Sie zehn häufige Fehler bei React-Komponenten – von semantischen Lücken im HTML bis hin zum Fehlen der Memoisierung – sowie die notwendigen Lösungen, um Anwendungen im Jahr 2026 schnell, zugänglich und fehlerfrei zu halten.