MDN hat React gekillt. Das haben sie stattdessen verwendet.

Seit Jahren verlassen sich Webentwickler auf MDN Web Docs Web Docs als die unbestrittene Bibel der offenen Webplattform. Sie dient nicht nur als Dokumentationsseite, sondern als die maßgebliche Instanz, die Best Practices vorgibt, Standards definiert und unzählige architektonische Entscheidungen in der gesamten Branche leitet. Ihre technischen Entscheidungen haben daher ein beispielloses Gewicht und signalisieren Verschiebungen in den Grundfesten dessen, wie wir für das Internet entwickeln.

Dieser Einfluss machte die Ankündigung zu einem nichts weniger als einem seismischen Ereignis: MDN Web Docs Web Docs hat React offiziell aufgegeben. Dies war keine leise Abkündigung oder ein kleines Refactoring; es war eine umfassende Ablehnung des Frameworks, das sein gesamtes Frontend, Yari, antrieb, eine React SPA, die aus Create React App mit einer „crazy webpack config“ ausgeworfen wurde und sogar auf `dangerouslySetInnerHTML` setzte. Der Schritt sandte eine Schockwelle durch die Entwicklergemeinschaft, vergleichbar damit, dass ein großer Cloud-Anbieter plötzlich die Unterstützung für seine Flaggschiff-Datenbank einstellt.

Diese Entscheidung geht über einen einfachen Unternehmensumbau hinaus; sie ist eine tiefgreifende Aussage über die zukünftige Ausrichtung der Webplattform selbst. MDN Web Docs Web Docs, die Entität, die HTML, CSS und JavaScript dokumentiert, setzt sich nun für das Bauen mit diesen intrinsischen Technologien ein. Sie haben ihr gesamtes Frontend von Grund auf neu aufgebaut und dabei Web Components mit Lit und benutzerdefinierte Server-Komponenten eingesetzt, ein starker Kontrast zu ihrer früheren React-basierten Single Page Application.

MDN Web Docs Web Docs hat einen mutigen, bewussten Schritt weg vom vorherrschenden SPA-für-alles-Trend gemacht. Ihre neue Architektur integriert benutzerdefinierte Elemente direkt in den Inhalt, wodurch die Notwendigkeit eines Wrappers entfällt und ungenutztes JavaScript reduziert wird. Dieses Engagement für schlanke, standardkonforme Entwicklung zeigt sich in Funktionen wie ihrem Hauptseiten-Dropdown, das jetzt vollständig mit CSS läuft, bevor JavaScript geladen wird, und sich dann progressiv verbessert. Die Startzeit der Entwicklungsumgebung sank von 2 Minuten auf 2 Sekunden, was die greifbaren Vorteile ihres neuen, performanten Ansatzes demonstriert.

MDN Web Docs Web Docs setzte einst auf Yari, eine React-basierte Single Page Application (SPA), die als ihr Frontend diente. Dies war keine einfache React-Implementierung; das Team hatte Yari aus Create React App ausgeworfen, was einen tiefen Einblick in benutzerdefinierte, hochkomplexe Konfigurationen signalisierte. Das Auswerfen bedeutete, die verwaltete Einfachheit von Create React App zugunsten einer granularen Kontrolle aufzugeben, eine Entscheidung, die oft im Laufe der Zeit zu erheblichen Wartungsaufwänden führt.

Zentral für Yaris wachsende technische Schuld war seine „crazy webpack config“. Dieses komplizierte Setup, ein Zeugnis jahrelanger Anpassungen, Patches und Workarounds, behinderte die Entwicklergeschwindigkeit und die Build-Effizienz erheblich. Die ausufernde Konfiguration machte Debugging und Updates zu einem Albtraum und schuf eine langsame, anfällige Entwicklungserfahrung. Entwickler sahen sich mit quälend langen Wartezeiten konfrontiert, wobei die Startzeiten der Entwicklungsumgebung auf schmerzhafte zwei Minuten anstiegen – ein erheblicher Hemmschuh für ein Projekt, das auf schnelle Iteration und umfassende Dokumentation sich entwickelnder Webstandards ausgerichtet ist.

Was die Komplexität noch erhöhte und die inhärente Ungeschicklichkeit des Stacks verdeutlichte, verwendete Yari häufig `dangerouslySetInnerHTML`, um Inhalte zu rendern. Für eine Dokumentationsseite, deren Hauptziel es ist, vertrauenswürdige Informationen sicher zu präsentieren, barg diese Praxis erhebliche Sicherheitsrisiken und eröffnete Angriffsflächen für Cross-Site Scripting (XSS)-Schwachstellen. Es wirkte auch von Natur aus klobig, erforderte eine manuelle Bereinigung der Inhalte und umging Reacts deklaratives Rendering-Modell – ein deutlicher Hinweis auf die schwierigen Kompromisse, die das Team einging.

Letztendlich war Yari ein leistungsstarkes Werkzeug, das grundlegend falsch angewendet wurde. Eine schwere SPA, die für hochinteraktive, dynamische Anwendungen mit komplexem State Management konzipiert war, erwies sich als ungeeignet für die Kernaufgabe von MDN Web Docs: die Bereitstellung weitgehend statischer, standardkonformer Dokumentation. Der Stack lieferte bei jedem Seitenaufruf erhebliche Mengen ungenutzten JavaScripts aus, was zu langsameren Seiten-Rendern und einer ineffizienten Benutzererfahrung führte. Diese Architektur widersprach direkt den Web-Performance-Prinzipien, die MDN Web Docs selbst vertritt – eine kritische Fehlstellung, die das Team zu einer radikalen Überarbeitung drängte.

Der Frontend-Neuaufbau von MDN Web Docs basierte auf einer radikalen Philosophie: *mit der Plattform* zu bauen, nicht nur darauf. Sie lehnten bewusst die Abstraktionsschichten traditioneller Frameworks ab und nutzten native Browserfunktionen direkt. Dies bedeutete eine vollständige Umstellung auf Web Components, insbesondere unter Nutzung von Lit für die Implementierung.

Web Components bieten eine leistungsstarke Suite von Webstandards zur Erstellung benutzerdefinierter, wiederverwendbarer und gekapselter HTML-Tags. Ihre Vorteile sind tiefgreifend: Echte Kapselung über Shadow DOM verhindert Stil- oder Skriptkonflikte, sie bieten Framework-agnostische Wiederverwendbarkeit und gewährleisten nahtlose Interoperabilität in verschiedenen Frontend-Umgebungen. Dieser Ansatz ermöglicht es Komponenten, direkt im Inhalt zu leben, wodurch Wrapper-Komplexitäten und das Ausliefern ungenutzten JavaScripts entfallen.

Diese strategische Verlagerung priorisiert die Zukunftssicherheit der Dokumentationsseite. Durch die Nutzung grundlegender Webstandards wie Custom Elements, Shadow DOM und HTML Templates investierte MDN Web Docs in Technologien mit einer Lebensdauer, die die jedes einzelnen JavaScript-Frameworks bei Weitem übertrifft. Standards entwickeln sich langsam und vorhersehbar, was langfristige Stabilität gewährleistet und das Risiko der Veralterung reduziert.

Dies steht in starkem Kontrast zu dem schnellen Wandel und der Ökosystem-Bindung, die in der Framework-lastigen Welt vorherrschen. Frameworks diktieren oft Entwicklungsmuster, führen häufig Breaking Changes ein und erzwingen ständige Refactorings und Abhängigkeitsaktualisierungen. MDN Web Docs umging diesen Zyklus explizit und wählte Stabilität statt kurzlebiger Trends.

Der neue Stack, bestehend aus Web Components, die mit Lit und benutzerdefinierten Serverkomponenten erstellt wurden, liefert spürbare Leistungssteigerungen. Die Startzeit der Entwicklungsumgebung sank von quälenden 2 Minuten auf lediglich 2 Sekunden. Diese schlanke Architektur stellt sicher, dass nur das exakte CSS und JavaScript geladen wird, das eine Seite benötigt, wodurch der ausgelieferte Code drastisch reduziert und die anfänglichen Ladezeiten der Seite verbessert werden. Für einen tieferen Einblick in die technischen Details dieser Transformation können Leser Under the hood of MDN Web Docs's new frontend - MDN Web Docs Web Docs konsultieren.

Das Ablegen von React bedeutete, dass MDN Web Docs Web Docs eine Philosophie des Bauens mit der Plattform, nicht nur darauf, annahm. Dieser radikale Wandel fand seinen idealen Partner in Lit, einer einfachen Bibliothek zum Erstellen schneller, leichter Web Components. Lit ist kein ausuferndes Framework, sondern ein fokussiertes Tool, das gerade genug Abstraktion bietet, um die Arbeit mit nativen Web Components zu einem Vergnügen zu machen, ohne eine gesamte Anwendungsarchitektur vorzuschreiben.

Die Attraktivität von Lit liegt in seinem minimalen Fußabdruck, oft in Kilobytes gemessen, und seiner außergewöhnlichen Laufzeitleistung. Es bietet eine entwicklerfreundliche API, die die rauen Kanten nativer Browser-APIs elegant glättet und reaktives Templating und Zustandsverwaltung mit intuitiven Decorators und deklarativem Rendering vereinfacht. Dieser Ansatz stellt sicher, dass Komponenten unglaublich schlank, schnell und von Natur aus mit Webstandards übereinstimmen.

Entscheidend ist, dass Lit es ermöglicht, dass benutzerdefinierte Elemente direkt im HTML leben, wodurch die Notwendigkeit umständlicher Wrapper Components oder komplexer Rendering-Bäume entfällt. Dies reduziert den Boilerplate-Code drastisch und stellt sicher, dass Komponenten wirklich nativ sind und nahtlos neben Standard-HTML-Elementen existieren. Die frühere React SPA von MDN Web Docs Web Docs, Yari, eine ausgeworfene Create React App, verließ sich oft auf eine "crazy webpack config" und sogar `dangerouslySetInnerHTML`, um Inhalte einzufügen, was die erhebliche Reibung bei der Integration dynamischer Elemente in ihre komplexe Struktur verdeutlicht.

Lit bot einen pragmatischen Mittelweg für MDN Web Docs Web Docs, der ein Gleichgewicht zwischen rohen Browser-APIs und einem vollwertigen Framework herstellte. Es bot deutlich mehr Struktur und Wartbarkeit als Vanilla JavaScript, trug aber nur einen Bruchteil des Overheads und der Meinung von React. Dies ermöglichte es dem Team, die Leistungsfähigkeit moderner Webstandards zu nutzen, ohne die Last eines großen, komplexen Abhängigkeitsbaums. Das Ergebnis ist ein Frontend-Stack, der nicht nur performant ist – die Startzeiten der Entwicklungsumgebung sanken von 2 Minuten auf nur 2 Sekunden – sondern auch unglaublich intuitiv für die zukünftige Entwicklung, perfekt abgestimmt auf ihre Mission, die offene Webplattform zu dokumentieren und zu verkörpern.

MDN Web Docs Web Docs entwickelte eigene Server Components, ein vorausschauender Schritt, der die Verlagerung der Branche hin zu servergesteuerten UIs lange bevor React Server Components breite Aufmerksamkeit erlangten, vorwegnahm. Diese proprietäre Architektur zielt auf extreme Effizienz ab, um sicherzustellen, dass jede Seite nur den wesentlichen Code für ein blitzschnelles Benutzererlebnis liefert. Das Team priorisierte die Minimierung des clientseitigen Overheads, eine direkte Reaktion auf die Überladung, die mit ihrem früheren auf Create React App basierenden Yari-Frontend verbunden war.

Diese benutzerdefinierten Server Components rendern Lit Components direkt auf dem Server zu HTML, ein Prozess, der die Arbeitslast des Clients erheblich reduziert. Unter Verwendung von NodeJS verarbeitet das Backend von MDN Web Docs Web Docs den Lit-Code und wandelt interaktive Web Components in statische HTML-Strings um, bevor sie überhaupt den Browser erreichen. Diese robuste Vor-Rendering-Fähigkeit eliminiert clientseitige Rendering-Verzögerungen, liefert sofort vollständig geformten Inhalt und umgeht die Komplexität einer traditionellen clientseitigen SPA.

Entscheidend ist, dass MDN Web Docs Web Docs Declarative Shadow DOM nutzt, eine leistungsstarke Webplattform-Funktion, die noch immer breitere Akzeptanz findet. Diese Technologie bettet das Shadow DOM einer Komponente und die zugehörigen Stile direkt in die anfängliche HTML-Nutzlast ein, anstatt sich auf JavaScript zu verlassen, um es nach dem Laden zu konstruieren. Browser, die Declarative Shadow DOM unterstützen, können die gekapselte Struktur und das Styling der Komponente sofort rendern, sobald das HTML ankommt, ohne auf eine einzige Zeile JavaScript zum Parsen oder Ausführen zu warten. Dies sorgt für einen entscheidenden visuellen Schub.

Dieser innovative Ansatz bedeutet, dass Benutzer eine vollständig gestylte, funktionale Komponente sehen, sobald der HTML-Code eintrifft, was die wahrgenommene Leistung drastisch verbessert und den Cumulative Layout Shift reduziert. Nur das JavaScript, das zur Hydration und Interaktivität von Komponenten *tatsächlich auf der Seite vorhanden* ist, wird heruntergeladen. Unbenutztes JavaScript von Komponenten, die sich nicht auf einer bestimmten Seite befinden, erreicht niemals den Client, ein starker Kontrast zur alten Yari SPA, die große Bündel potenziell unnötigen Codes über jede Route versendete.

Die Server-Komponenten von MDN Web Docs Web Docs liefern eine unglaublich schlanke, optimierte Payload, die die anfänglichen Ladezeiten und den Bandbreitenverbrauch für ihre riesige Dokumentationsbibliothek drastisch reduziert. Diese strategische Investition in Server-Side Rendering, gepaart mit nativen Browser-Funktionen, zeigt ein tiefes Engagement, mit der Plattform zu bauen und nicht nur darauf. Das Ergebnis ist eine Dokumentationsseite, die nicht nur Webstandards erklärt, sondern auch genau die Leistungs- und Effizienzstandards vorlebt, die sie vertritt, und eine überzeugende Alternative bietet.

Die Transformation der Frontend-Architektur von MDN Web Docs Web Docs hatte ihren dramatischsten Einfluss auf die Entwicklerproduktivität. Wo Ingenieure einst über zwei Minuten auf den Start ihrer lokalen Entwicklungsumgebung warteten, bootet der neue Stack nun in nur zwei Sekunden. Diese erstaunliche Reduzierung der Startzeit um 98% verändert den Entwicklungsworkflow grundlegend und setzt unzählige Stunden für Feature-Arbeit und Bugfixes frei, anstatt in Kompilierungswarteschlangen zu verbringen.

Diese neu gewonnene Effizienz reicht weit über interne Entwicklungszyklen hinaus und kommt jedem Benutzer zugute, der auf die Dokumentation zugreift. Besucher erleben jetzt deutlich schnellere Seitenladezeiten, verbrauchen weniger Daten und genießen eine wesentlich reaktionsfreudigere Benutzererfahrung auf ganzer Linie. Die Architektur priorisiert die Leistung und stellt sicher, dass MDN Web Docs Web Docs auch bei langsameren Netzwerkverbindungen oder ressourcenbeschränkten Geräten zugänglich und reaktionsschnell bleibt und ein inklusives Web verkörpert.

Betrachten Sie das Dropdown-Menü der Hauptseite, ein Paradebeispiel dieser Performance-First-Philosophie. Es funktioniert jetzt vollständig mit CSS, bevor JavaScript geladen wird, und wird dann progressiv verbessert, sobald die notwendigen Skripte verfügbar sind. Dieser Native-First-Ansatz liefert sofortige Interaktivität und Reaktionsfähigkeit und zeigt die Leistungsfähigkeit des Bauens mit der Webplattform, anstatt schwere Frameworks darüberzulegen.

Diese bemerkenswerten Vorteile resultieren direkt aus der architektonischen Entscheidung, JavaScript-Payloads drastisch zu reduzieren und Browser-native Features vollständig zu nutzen. Die Eliminierung des schweren React Single Page Application (SPA)-Overheads, kombiniert mit dem strategischen Einsatz von Web Components, hat unnötige Komplexität beseitigt. Bibliotheken wie Lit bieten eine schlanke Grundlage für diese Komponenten, während die hauseigenen Server-Komponenten von MDN Web Docs Web Docs sicherstellen, dass nur das exakte CSS und JavaScript, das eine Seite benötigt, den Client erreicht.

Letztendlich stellt diese Umstellung ein tiefes Engagement für genau die Webstandards dar, die MDN Web Docs Web Docs dokumentiert. Der Wechsel von einer komplexen, ausgeworfenen Create React App zu einem optimierten Stack, der auf nativen Browser-Funktionen basiert, hat nicht nur die Leistung enorm gesteigert, sondern auch einen neuen Maßstab dafür gesetzt, wie einflussreiche Webplattformen funktionieren können, und beweist, dass weniger JavaScript oft mehr Geschwindigkeit bedeutet.

Der neue Stack von MDN Web Docs Web Docs setzt auf Progressive Enhancement, ein grundlegendes Prinzip, das eine solide, funktionale Basis für alle Benutzer priorisiert. Dieser Ansatz beginnt mit Kerninhalten und -funktionen, die über robustes HTML und CSS bereitgestellt werden, wobei JavaScript nur als optionale Erweiterung hinzugefügt wird. Die Website bleibt vollständig nutzbar, selbst wenn Skripte fehlschlagen, blockiert sind oder noch nicht geladen wurden.

Man betrachte das Hauptnavigations-Dropdown der Website, ein kritisches Schnittstellenelement. Es funktioniert perfekt nur mit CSS und reagiert auf Benutzerinteraktionen ohne eine einzige Zeile JavaScript. Erst nachdem das notwendige JavaScript geladen ist, erhält es zusätzliche Verbesserungen, wie eine verbesserte Tastaturnavigation oder dynamisches Zustandsmanagement. Dies gewährleistet sofortige Nutzbarkeit und eine konsistente Erfahrung unter verschiedenen Netzwerkbedingungen.

Diese architektonische Entscheidung bietet erhebliche Vorteile: verbesserte Resilienz, breite Zugänglichkeit und eine dramatisch schnellere wahrgenommene Leistung. Benutzer mit langsamen Verbindungen oder älteren Geräten greifen weiterhin auf eine voll funktionsfähige Website zu und stoßen nie auf eine fehlerhafte Oberfläche. Die Kerninhalte und die Navigation sind immer verfügbar und bilden eine robuste Grundlage.

Eine solche Strategie steht in starkem Kontrast zu vielen modernen Single Page Application (SPA)-Architekturen. Oft liefert eine SPA eine nahezu leere Seite, die ein großes JavaScript-Bundle herunterladen, parsen und ausführen muss, bevor Inhalte sichtbar oder interaktiv werden. Dies führt zu kritischen Fehlerquellen und erheblichen Verzögerungen für die Benutzer.

Das Engagement von MDN Web Docs Web Docs für Progressive Enhancement unterstreicht seine Philosophie: mit der Plattform zu bauen, nicht nur darauf. Indem das Team zuerst native Browserfunktionen nutzte, lieferte es ein Weberlebnis, das von Natur aus robuster, zugänglicher und leistungsfähiger für alle ist, die auf die definitive Quelle für Webstandards zugreifen.

Über den tiefgreifenden architektonischen Wandel hinaus enthüllte MDN Web Docs Web Docs auch eine dramatische Überarbeitung der Benutzeroberfläche. Dies war nicht nur eine Neufassung des Backend-Codes; es stellte eine komplette Neukonzeption dar, wie Entwickler mit der wichtigsten Dokumentation des Webs interagieren. Das neue Frontend bot eine ausgefeilte, intuitive Erfahrung, die das zugrunde liegende Engagement für moderne Webstandards und einen benutzerzentrierten Ansatz direkt widerspiegelt.

Besucher bemerkten sofort eine sauberere, konsistentere Ästhetik auf der gesamten Plattform. Das Team verfeinerte akribisch die Typografie, verbesserte die Lesbarkeit mit sorgfältig ausgewählten Schriftarten sowohl für Prosa- als auch für Codebeispiele und machte lange Artikel weniger ermüdend. Eine neue, dedizierte Code-Schriftart verbesserte die Lesbarkeit der Syntax drastisch, ein entscheidendes Detail für eine Website, die sich auf Programmierung und technische Genauigkeit konzentriert.

Spezifische UI-Elemente erhielten erhebliche Aufmerksamkeit und veränderten die täglichen Interaktionen. MDN Web Docs Web Docs wechselte zu gestochen scharfen Lucide icons und ersetzte ältere Assets durch ein skalierbares, konsistentes Set, das die visuelle Klarheit verbesserte. Die Sucherfahrung erfuhr ein leistungsstarkes Redesign, das ein intuitiveres und funktionsreicheres Modal einführte, das die Entdeckung von Dokumentation optimierte, oft der erste Interaktionspunkt für Benutzer. Sogar die Top-Navigation wurde umfassend überarbeitet und bietet klarere Wege zu wesentlichen Inhalten.

Entscheidend ist, dass die neue, mit Lit erstellte component-based architecture diese visuellen Verbesserungen direkt ermöglichte. Durch die Nutzung der leichtgewichtigen web components von Lit etablierte MDN Web Docs Web Docs ein kohärentes Designsystem, das es erheblich einfacher machte, Konsistenz über Hunderttausende von Seiten hinweg zu wahren und gleichzeitig schnelle Entwicklungszyklen zu gewährleisten. Dieser modulare Ansatz stellte sicher, dass UI-Elemente wiederverwendbar, performant und konsistent gestaltet waren, wodurch das gesamte Benutzererlebnis der zugrunde liegenden technischen Leistungsfähigkeit entsprach.

Die radikale Neuausrichtung von MDN Web Docs Web Docs wirft unweigerlich eine einzige Frage unter Entwicklern auf: Deutet dies das Ende der Dominanz von React oder sogar der Single Page Application (SPA) era selbst an? Die Antwort ist nuanciert, keine definitive Erklärung der Überflüssigkeit. React bleibt ein leistungsstarkes Werkzeug, unverzichtbar für hochinteraktive, komplexe Anwendungen, bei denen ein reichhaltiges client-seitiges Zustandsmanagement von größter Bedeutung ist.

MDN Web Docs Web Docs fungiert jedoch grundlegend als Content-Delivery-Plattform. Ihre Hauptfunktion ist es, Dokumentation effizient bereitzustellen, nicht komplexe Benutzerinteraktionen zu verwalten, die eine vollständige SPA erfordern. Der frühere Yari stack, eine ausgeworfene Create React App, wurde zu einer 'overkill'-Lösung, belastet durch eine "crazy webpack config" und erforderte sogar `dangerouslySetInnerHTML`, um Inhalte zu integrieren. MDN Web Docs Web Docs benötigte einfach nicht das umfangreiche JavaScript-Bundle oder den client-seitigen Routing-Overhead, der einer traditionellen SPA eigen ist.

Dieser Schritt von MDN Web Docs Web Docs spiegelt einen breiteren, sich beschleunigenden Branchentrend weg von der 'SPA-by-default'-Mentalität wider. Entwickler suchen zunehmend nach nuancierteren Architekturlösungen, die auf spezifische Anwendungsfälle zugeschnitten sind. Beispiele hierfür sind Frameworks und Bibliotheken wie: - Astro - Qwik - Moderne server-side rendering (SSR) frameworks

Diese aufkommenden Lösungen befürworten Konzepte wie partial hydration und islands architecture, die nur das JavaScript liefern, das für interaktive Komponenten notwendig ist. Sie priorisieren die anfängliche Seitenladeleistung und nutzen server-side rendering, um eine schnelle, inhaltsreiche Basis zu bieten. Diese Philosophie stimmt perfekt mit dem neuen Stack von MDN Web Docs Web Docs überein, der Lit für Web Components und benutzerdefinierte Serverkomponenten verwendet, um nur das exakte CSS und JavaScript zu laden, das eine Seite benötigt.

Die Frontend-Entwicklung ist in eine neue Phase der Reife eingetreten, die den Fokus von universellen Frameworks auf gezielte Effizienz verlagert. Die Ära der blinden Übernahme des neuesten gehypten Frameworks für jedes Projekt verblasst. Stattdessen schätzt das Ökosystem nun pragmatische Entscheidungen, die von realen Leistungsmetriken und Eignung angetrieben werden, und erfordert einen überlegteren Ansatz bei der Tooling-Auswahl.

Die dramatischen Gewinne von MDN Web Docs Web Docs – ein Start einer Entwicklungsumgebung, der von über 2 Minuten auf nur 2 Sekunden sank – unterstreichen diesen Wandel. Ihre Entscheidung bestätigt eine Zukunft, in der das Bauen mit der Plattform, die Priorisierung von Effizienz und die Nutzung von progressive enhancement über monolithische client-seitige Frameworks für inhaltsorientierte Erlebnisse triumphieren. Dies ist nicht der Tod von React, sondern ein klares Signal für eine durchdachtere, performantere Frontend-Landschaft.

Die dramatische Abkehr von MDN Web Docs Web Docs von React dient als Meisterkurs für jedes Team, das sein nächstes Webprojekt plant. Entwickler und technische Leiter müssen nun lang gehegte Annahmen über die Frontend-Architektur kritisch neu bewerten. Dies ist nicht nur die Geschichte von MDN Web Docs Web Docs; es ist ein wirkungsvoller Entwurf für den Aufbau effizienter, widerstandsfähiger Weberlebnisse ohne unnötige Komplexität.

Erstens, hinterfragen Sie Ihren tatsächlichen Bedarf an einem vollständigen clientseitigen Framework für eine ganze Website. Der frühere Yari-Stack von MDN Web Docs Web Docs, ein ausgeworfenes Create React App, wurde zu einer Last komplexer webpack-Konfigurationen und erforderte sogar `dangerouslySetInnerHTML`, um Inhalte zu rendern. Dieses Maß an framework overhead liefert oft abnehmende Erträge für inhaltsgetriebene Websites, verbraucht erhebliche Entwicklerzeit und liefert Megabytes ungenutzten JavaScript aus. Bewerten Sie, ob eine vollständige SPA wirklich für jede Seite unerlässlich ist.

Zweitens, unterschätzen Sie nicht die Web Components. Sie sind ein ausgereiftes, leistungsstarkes Plattform-Primitiv, das einen robusten Weg weg vom ständigen Wechsel der JavaScript-Frameworks bietet. MDN Web Docs Web Docs hat Lit eingesetzt, um benutzerdefinierte Elemente zu erstellen, die direkt in ihren Inhalten leben, wodurch die Notwendigkeit von Wrapper-Komponenten entfällt und der ausgelieferte Code drastisch reduziert wird. Dieser Ansatz bietet dauerhafte Stabilität, außergewöhnliche Leistung und eine zukunftssichere Grundlage, die direkt auf Webstandards aufbaut.

Drittens, nehmen Sie progressive enhancement wieder als grundlegendes Prinzip für den Aufbau robuster und schneller Weberlebnisse an. Der neue Stack von MDN Web Docs Web Docs veranschaulicht dies, indem zentrale UI-Elemente wie das Haupt-Dropdown der Website rein mit CSS funktionieren, bevor JavaScript geladen wird. Die Schichtung von Verbesserungen gewährleistet eine solide, zugängliche Basis für alle Benutzer, unabhängig von Netzwerkbedingungen oder Browserfunktionen, wodurch JavaScript zu einer optionalen Schicht und nicht zu einer Abhängigkeit wird.

Berücksichtigen Sie bei der Entscheidung über die Architektur Ihres nächsten Projekts die Art Ihrer Anwendung. Für hochinteraktive, datenintensive Webanwendungen, die ein komplexes Zustandsmanagement und häufige clientseitige Updates erfordern – denken Sie an Dashboards oder Echtzeit-Editoren – bietet eine vollständige SPA wie React immer noch erhebliche Vorteile. Für die meisten inhaltsreichen Websites, Dokumentationsportale oder Marketingseiten demonstriert MDN Web Docs Web Docs jedoch die tiefgreifenden Vorteile eines leichteren, komponentenbasierten Ansatzes mit serverseitig gerendertem HTML und gezieltem JavaScript. Diese Strategie priorisiert die anfängliche Seitenladegeschwindigkeit, Resilienz und langfristige Wartbarkeit gegenüber unnötiger clientseitiger Komplexität. Die Startzeit ihrer Entwicklungsumgebung, die von über 2 Minuten auf nur 2 Sekunden sank, unterstreicht diese Auswirkung.

Warum hat MDN sein React-Frontend ersetzt?

MDN hat seine React SPA namens Yari ersetzt, um technische Schulden abzubauen, die Leistung zu verbessern und die eigene Website an die Webstandards anzupassen, die sie dokumentiert. Der alte Stack hatte eine komplexe Konfiguration und lieferte unnötiges JavaScript für eine inhaltsreiche Website aus.

Was ist der neue Tech-Stack von MDN?

Der neue Stack von MDN basiert auf nativen Web Components unter Verwendung der Lit-Bibliothek. Er verfügt auch über maßgeschneiderte Serverkomponenten und betont progressive enhancement, wodurch Kernfunktionen nur mit CSS funktionieren, bevor JavaScript geladen wird.

Was ist Lit und warum hat MDN es gewählt?

Lit ist eine leichtgewichtige Bibliothek zum Erstellen schneller Web Components. MDN hat es gewählt, weil es einfach, extrem performant ist und browsernative Technologie nutzt, wodurch der Overhead und die Bindung an größere Frontend-Frameworks vermieden werden.

Wie hat der neue Stack die Leistung von MDN verbessert?

Die neue Architektur verbesserte die Leistung erheblich, indem nur das exakte CSS und JavaScript geladen wurde, das eine Seite benötigt. Sie verbesserte auch die Entwicklererfahrung, indem die Startzeit der Entwicklungsumgebung von über 2 Minuten auf nur 2 Sekunden reduziert wurde.