industry insights

MDN Killed React. Here's What They Used Instead.

The web's most trusted documentation site just threw out its entire React frontend. Their new stack is a radical bet on native browser technology that could change how we build websites.

Stork.AI
Hero image for: MDN Killed React. Here's What They Used Instead.
💡

TL;DR / Key Takeaways

The web's most trusted documentation site just threw out its entire React frontend. Their new stack is a radical bet on native browser technology that could change how we build websites.

The Day React Lost Its Biggest Advocate

For years, web developers have relied on MDN Web Docs Web Docs as the undisputed bible of the open web platform. It stands not merely as a documentation site, but as the definitive authority dictating best practices, defining standards, and guiding countless architectural decisions across the industry. Its technical choices, therefore, resonate with an unparalleled weight, signaling shifts in the very foundation of how we build for the internet.

That influence made the announcement nothing short of a seismic event: MDN Web Docs Web Docs officially abandoned React. This wasn't a quiet deprecation or a minor refactor; it was a full-scale repudiation of the framework that powered its entire frontend, Yari, a React SPA ejected from Create React App with a "crazy webpack config" and even relying on `dangerouslySetInnerHTML`. The move sent a shockwave through the developer community, akin to a major cloud provider suddenly dropping support for its flagship database.

This decision transcends a simple company rebuild; it is a profound statement about the future direction of the web platform itself. MDN Web Docs Web Docs, the very entity that documents HTML, CSS, and JavaScript, now champions building with those intrinsic technologies. They rebuilt their entire frontend from the ground up, embracing Web Components with Lit and custom server components, a stark contrast to their previous React-based Single Page Application.

MDN Web Docs Web Docs made a bold, deliberate move away from the prevailing SPA-for-everything trend. Their new architecture integrates custom elements directly into the content, eliminating the need for a wrapper and reducing unused JavaScript. This commitment to lean, standards-aligned development is evident in features like their main site dropdown, which now runs entirely on CSS before JavaScript loads, then progressively enhances. The development environment startup time plummeted from 2 minutes to 2 seconds, showcasing the tangible benefits of their new, performant approach.

Inside Yari: The 'Crazy' Stack MDN Had to Kill

Illustration: Inside Yari: The 'Crazy' Stack MDN Had to Kill
Illustration: Inside Yari: The 'Crazy' Stack MDN Had to Kill

MDN Web Docs Web Docs once relied on Yari, a React-based Single Page Application (SPA) that served as its frontend. This wasn't a simple React implementation; the team had ejected Yari from Create React App, signaling a deep dive into custom, highly complex configurations. Ejecting meant forsaking the managed simplicity of Create React App for granular control, a choice that often leads to significant maintenance burdens over time.

Central to Yari's mounting technical debt was its "crazy webpack config." This intricate setup, a testament to years of customization, patching, and workarounds, severely hampered developer velocity and build efficiency. The sprawling configuration made debugging and updates a nightmare, creating a slow, brittle development experience. Developers faced agonizingly long waits, with development environment startup times ballooning to a painful two minutes – a significant drag for a project focused on rapid iteration and comprehensive documentation of evolving web standards.

Adding to the complexity and illustrating the stack's inherent awkwardness, Yari frequently employed `dangerouslySetInnerHTML` to render content. For a documentation site, where the primary goal is to present trusted information securely, this practice carried substantial security risks, opening avenues for cross-site scripting (XSS) vulnerabilities. It also felt inherently clunky, requiring manual content sanitization and bypassing React's declarative rendering model, a stark indicator of the difficult compromises the team made.

Ultimately, Yari represented a powerful tool fundamentally misapplied. A heavy SPA, designed for highly interactive, dynamic applications with complex state management, proved ill-suited for MDN Web Docs Web Docs' core mission: delivering largely static, standards-aligned documentation. The stack shipped substantial amounts of unused JavaScript to every page load, contributing to slower page renders and an inefficient user experience. This architecture directly contradicted the web performance principles MDN Web Docs Web Docs itself advocates, a critical misalignment that pushed the team towards a radical overhaul.

The Radical Bet on Native Browser Tech

MDN Web Docs Web Docs' frontend rebuild hinged on a radical philosophy: building *with the platform*, not merely on top of it. They consciously rejected the abstraction layers of traditional frameworks, embracing native browser capabilities directly. This meant a full pivot to Web Components, specifically leveraging Lit for implementation.

Web Components offer a powerful suite of web standards for creating custom, reusable, and encapsulated HTML tags. Their benefits are profound: true encapsulation via Shadow DOM prevents style or script conflicts, they provide framework-agnostic reusability, and ensure seamless interoperability across diverse frontend environments. This approach allows components to live directly in content, eliminating wrapper complexities and shipping unused JavaScript.

This strategic shift prioritizes future-proofing the documentation site. By relying on foundational web standards like Custom Elements, Shadow DOM, and HTML Templates, MDN Web Docs Web Docs invested in technologies with lifespans vastly exceeding any single JavaScript framework. Standards evolve slowly and predictably, ensuring long-term stability and reducing the risk of obsolescence.

Contrast this starkly with the rapid churn and ecosystem lock-in prevalent in the framework-heavy world. Frameworks often dictate development patterns, introduce frequent breaking changes, and compel constant refactors and dependency updates. MDN Web Docs Web Docs explicitly sidestepped this cycle, choosing stability over transient trends.

The new stack, featuring Web Components built with Lit and custom server components, delivers tangible performance gains. The development environment startup time plummeted from an agonizing 2 minutes to a mere 2 seconds. This lean architecture ensures only the exact CSS and JavaScript a page needs loads, dramatically reducing shipped code and enhancing initial page load times. For a deeper dive into the technical specifics of this transformation, readers can consult Under the hood of MDN Web Docs's new frontend - MDN Web Docs Web Docs.

Meet Lit: The Anti-Framework Powerhouse

Shedding React meant MDN Web Docs Web Docs embraced a philosophy of building with the platform, not just on it. This radical shift found its ideal partner in Lit, a simple library for constructing fast, lightweight web components. Lit is not a sprawling framework but a focused tool, providing just enough abstraction to make native Web Components a joy to work with, without dictating an entire application architecture.

Lit’s appeal lies in its minimal footprint, often measured in kilobytes, and exceptional runtime performance. It offers a developer-friendly API that elegantly smooths the rough edges of native browser APIs, simplifying reactive templating and state management with intuitive decorators and declarative rendering. This approach ensures components remain incredibly lean, fast, and inherently aligned with web standards.

Crucially, Lit enables custom elements to live directly within the HTML, eliminating the need for cumbersome wrapper components or complex rendering trees. This drastically reduces boilerplate code and ensures that components are truly native, residing seamlessly alongside standard HTML elements. MDN Web Docs Web Docs' previous React SPA, Yari, an ejected Create React App, often relied on a "crazy webpack config" and even `dangerouslySetInnerHTML` to inject content, illustrating the significant friction in integrating dynamic elements within its complex structure.

Lit offered a pragmatic middle-ground for MDN Web Docs Web Docs, striking a balance between raw browser APIs and a full-fledged framework. It provided significantly more structure and maintainability than vanilla JavaScript, yet carried a fraction of React's overhead and opinionation. This allowed the team to leverage the power of modern web standards without the burden of a large, complex dependency tree. The result is a frontend stack that is not only performant – dropping development environment startup times from 2 minutes to a mere 2 seconds – but also incredibly intuitive for future development, perfectly aligning with their mission to document and embody the open web platform.

MDN's Secret Weapon: Homegrown Server Components

Illustration: MDN's Secret Weapon: Homegrown Server Components
Illustration: MDN's Secret Weapon: Homegrown Server Components

MDN Web Docs Web Docs engineered its own server components, a prescient move that anticipated the industry's shift towards server-driven UI long before React Server Components gained widespread attention. This proprietary architecture targets extreme efficiency, ensuring every page delivers only the essential code for a blazing-fast user experience. The team prioritized minimizing client-side overhead, a direct response to the bloat associated with their previous Create React App-based Yari frontend.

These custom server components render Lit components directly to HTML on the server, a process that significantly reduces the client's workload. Utilizing NodeJS, MDN Web Docs Web Docs' backend processes the Lit code, transforming interactive web components into static HTML strings before they even reach the browser. This robust pre-rendering capability eliminates client-side rendering delays, delivering fully formed content immediately and bypassing the complexities of a traditional client-side SPA.

Crucially, MDN Web Docs Web Docs leverages Declarative Shadow DOM, a powerful web platform feature still gaining broader adoption. This technology embeds a component's shadow DOM and associated styles directly within the initial HTML payload, rather than relying on JavaScript to construct it post-load. Browsers supporting Declarative Shadow DOM can instantly render the component's encapsulated structure and styling the moment the HTML arrives, without waiting for a single line of JavaScript to parse or execute. This provides a critical visual boost.

This innovative approach means users see a fully styled, functional component the moment the HTML arrives, drastically improving perceived performance and reducing cumulative layout shift. Only the JavaScript necessary to hydrate and add interactivity to components *actually present* on the page ever downloads. Unused JavaScript from components not on a specific page never touches the client, a stark contrast to the old Yari SPA which shipped large bundles of potentially unneeded code across every route.

MDN Web Docs Web Docs' server components deliver an incredibly lean, optimized payload, drastically reducing initial load times and bandwidth consumption for its vast library of documentation. This strategic investment in server-side rendering, coupled with native browser capabilities, showcases a profound commitment to building with the platform, not just on top of it. The result is a documentation site that not only explains web standards but also exemplifies the very performance and efficiency standards it champions, offering a compelling alternative.

From 2 Minutes to 2 Seconds: The Real-World Impact

The transformation in MDN Web Docs Web Docs' frontend architecture delivered its most dramatic impact in developer productivity. Where engineers once waited over two minutes for their local development environment to start, the new stack now boots in a mere two seconds. This staggering 98% reduction in startup time fundamentally reshapes the development workflow, freeing up countless hours for feature work and bug fixes instead of compilation queues.

This newfound efficiency extends far beyond internal development cycles, directly benefiting every user accessing the documentation. Visitors now experience significantly faster page loads, consume less data, and enjoy a far snappier user experience across the board. The architecture prioritizes performance, ensuring MDN Web Docs Web Docs remains accessible and responsive even on slower network connections or resource-constrained devices, embodying an inclusive web.

Consider the main site dropdown menu, a prime example of this performance-first philosophy. It now functions entirely with CSS before any JavaScript loads, then progressively enhances once necessary scripts become available. This native-first approach delivers instant interactivity and responsiveness, showcasing the power of building with the web platform rather than layering heavy frameworks on top.

These remarkable gains stem directly from the architectural decision to drastically reduce JavaScript payloads and fully embrace browser-native features. The elimination of the heavy React Single Page Application (SPA) overhead, combined with the strategic use of Web Components, has stripped away unnecessary complexity. Libraries like Lit provide a lean foundation for these components, while MDN Web Docs Web Docs' homegrown server components ensure only the exact CSS and JavaScript a page needs ever reaches the client.

Ultimately, this shift represents a profound commitment to the very web standards MDN Web Docs Web Docs documents. Moving from a complex, ejected Create React App to a streamlined stack built on native browser capabilities has not only supercharged performance but also set a new benchmark for how influential web platforms can operate, proving that less JavaScript often means more speed.

Progressive Enhancement: When JavaScript is Optional

MDN Web Docs Web Docs’ new stack embraces Progressive Enhancement, a foundational principle prioritizing a solid, functional baseline for all users. This approach begins with core content and functionality delivered via robust HTML and CSS, layering JavaScript only as an optional enhancement. The site remains fully usable even if scripts fail, are blocked, or have not yet loaded.

Consider the site’s main navigation dropdown, a critical interface element. It operates perfectly using only CSS, responding to user interactions without a single line of JavaScript. Only after the necessary JavaScript loads does it receive additional enhancements, such as improved keyboard navigation or dynamic state management. This ensures immediate usability and a consistent experience across diverse network conditions.

This architectural choice yields significant advantages: enhanced resilience, broad accessibility, and dramatically faster perceived performance. Users on slow connections or older devices still access a fully functional site, never encountering a broken interface. The core content and navigation are always available, providing a robust foundation.

Such a strategy stands in stark contrast to many modern Single Page Application (SPA) architectures. Often, an SPA delivers a nearly blank page, requiring a large JavaScript bundle to download, parse, and execute before any content becomes visible or interactive. This introduces critical points of failure and significant delays for users.

MDN Web Docs Web Docs’ commitment to Progressive Enhancement underscores its philosophy: build with the platform, not just on top of it. By leveraging native browser capabilities first, the team delivered a web experience that is inherently more robust, accessible, and performant for everyone accessing the definitive source for web standards.

More Than Code: A Total UI Overhaul

Illustration: More Than Code: A Total UI Overhaul
Illustration: More Than Code: A Total UI Overhaul

Beyond the profound architectural shift, MDN Web Docs Web Docs also unveiled a dramatic user interface overhaul. This wasn't merely a backend code rewrite; it represented a complete re-envisioning of how developers interact with the web's most critical documentation. The new frontend delivered a polished, intuitive experience, directly reflecting the underlying commitment to modern web standards and a user-first approach.

Visitors immediately noticed a cleaner, more consistent aesthetic across the entire platform. The team meticulously refined typography, enhancing readability with carefully chosen fonts for both prose and code examples, making long-form articles less fatiguing. A new, dedicated code font drastically improved the legibility of syntax, a crucial detail for a site centered on programming and technical accuracy.

Specific UI elements received significant attention, transforming daily interactions. MDN Web Docs Web Docs transitioned to crisp Lucide icons, replacing older assets with a scalable, consistent set that improved visual clarity. The search experience saw a powerful redesign, introducing a more intuitive and feature-rich modal that streamlined discovery of documentation, often the first point of interaction for users. Even the top navigation underwent a comprehensive refresh, offering clearer pathways to essential content.

Crucially, the new component-based architecture built with Lit directly facilitated these visual enhancements. By embracing Lit's lightweight web components, MDN Web Docs Web Docs established a cohesive design system, making it far easier to maintain consistency across hundreds of thousands of pages while ensuring rapid development cycles. This modular approach ensured that UI elements were reusable, performant, and consistently styled, elevating the entire user experience to match the underlying technical prowess.

Does This Signal the End of the SPA Era?

MDN Web Docs Web Docs' radical pivot inevitably sparks a singular question among developers: Does this signal the end of React's dominance, or even the Single Page Application (SPA) era itself? The answer is nuanced, not a definitive declaration of obsolescence. React remains a powerful tool, indispensable for highly interactive, complex applications where rich client-side state management is paramount.

MDN Web Docs Web Docs, however, operates fundamentally as a content delivery platform. Its primary function is to serve documentation efficiently, not to manage intricate user interactions requiring a full SPA. The previous Yari stack, an ejected Create React App, became an 'overkill' solution, burdened by a "crazy webpack config" and even requiring `dangerouslySetInnerHTML` to integrate content. MDN Web Docs Web Docs simply did not need the hefty JavaScript bundle or the client-side routing overhead inherent to a traditional SPA.

This move by MDN Web Docs Web Docs reflects a broader, accelerating industry trend away from the 'SPA-by-default' mentality. Developers increasingly seek more nuanced architectural solutions tailored to specific use cases. Examples include frameworks and libraries such as: - Astro - Qwik - Modern server-side rendering (SSR) frameworks

These emerging solutions champion concepts like partial hydration and islands architecture, delivering only the JavaScript necessary for interactive components. They prioritize initial page load performance and leverage server-side rendering to provide a fast, content-rich baseline. This philosophy aligns perfectly with MDN Web Docs Web Docs' new stack, which uses Lit for Web Components and custom server components to load only the exact CSS and JavaScript a page requires.

Frontend development has entered a new phase of maturity, shifting focus from universal frameworks to targeted efficiency. The era of blindly adopting the latest hyped framework for every project is fading. Instead, the ecosystem now values pragmatic choices driven by real-world performance metrics and suitability, demanding a more deliberate approach to tooling.

MDN Web Docs Web Docs' dramatic gains — a developer environment startup plummeting from over 2 minutes to just 2 seconds — underscore this shift. Their decision validates a future where building with the platform, prioritizing efficiency, and embracing progressive enhancement triumph over monolithic client-side frameworks for content-first experiences. This isn't the death of React, but a clear signal for a more thoughtful, performant frontend landscape.

What MDN's Gambit Means For Your Next Project

MDN Web Docs Web Docs’ dramatic pivot from React serves as a masterclass for any team charting their next web project. Developers and tech leads must now critically re-evaluate long-held assumptions about frontend architecture. This isn't just MDN Web Docs Web Docs' story; it’s a potent blueprint for building efficient, resilient web experiences without unnecessary complexity.

First, scrutinize your actual need for a full client-side framework across an entire site. MDN Web Docs Web Docs’ previous Yari stack, an ejected Create React App, became a burden of complex webpack configurations and even required `dangerouslySetInnerHTML` to render content. That level of framework overhead often delivers diminishing returns for content-driven sites, consuming significant developer time and shipping megabytes of unused JavaScript. Evaluate if a full SPA is truly essential for every page.

Second, stop sleeping on Web Components. They are a mature, powerful platform primitive offering a robust path away from the perpetual churn of JavaScript frameworks. MDN Web Docs Web Docs embraced Lit to build custom elements that live directly in their content, eliminating the need for wrapper components and drastically reducing shipped code. This approach delivers lasting stability, exceptional performance, and a future-proof foundation built directly on web standards.

Third, re-embrace progressive enhancement as a foundational principle for building robust and fast web experiences. MDN Web Docs Web Docs’ new stack exemplifies this, where core UI elements like the main site dropdown function purely with CSS before JavaScript loads. Layering enhancements ensures a solid, accessible baseline for all users, regardless of network conditions or browser capabilities, making JavaScript an optional layer, not a dependency.

When deciding on your next project's architecture, consider the nature of your application. For highly interactive, data-intensive web applications requiring complex state management and frequent client-side updates—think dashboards or real-time editors—a full SPA like React still offers potent advantages. However, for most content-heavy websites, documentation portals, or marketing sites, MDN Web Docs Web Docs demonstrates the profound benefits of a lighter, component-based approach with server-rendered HTML and targeted JavaScript. This strategy prioritizes initial page load speed, resilience, and long-term maintainability over unnecessary client-side complexity. Their developer environment startup time plummeting from over 2 minutes to just 2 seconds underscores this impact.

Frequently Asked Questions

Why did MDN replace its React frontend?

MDN replaced its React SPA, named Yari, to eliminate technical debt, improve performance, and align its own site with the web standards it documents. The old stack had a complex configuration and shipped unnecessary JavaScript for a content-heavy site.

What is MDN's new tech stack?

MDN's new stack is built on native Web Components using the Lit library. It also features custom-built server components and emphasizes progressive enhancement, allowing core features to work with just CSS before JavaScript loads.

What is Lit and why did MDN choose it?

Lit is a lightweight library for building fast Web Components. MDN chose it because it's simple, extremely performant, and leverages browser-native technology, avoiding the overhead and lock-in of larger frontend frameworks.

How did the new stack improve MDN's performance?

The new architecture significantly improved performance by only loading the exact CSS and JavaScript a page needs. It also improved the developer experience, cutting the development environment startup time from over 2 minutes to just 2 seconds.

Frequently Asked Questions

Why did MDN replace its React frontend?
MDN replaced its React SPA, named Yari, to eliminate technical debt, improve performance, and align its own site with the web standards it documents. The old stack had a complex configuration and shipped unnecessary JavaScript for a content-heavy site.
What is MDN's new tech stack?
MDN's new stack is built on native Web Components using the Lit library. It also features custom-built server components and emphasizes progressive enhancement, allowing core features to work with just CSS before JavaScript loads.
What is Lit and why did MDN choose it?
Lit is a lightweight library for building fast Web Components. MDN chose it because it's simple, extremely performant, and leverages browser-native technology, avoiding the overhead and lock-in of larger frontend frameworks.
How did the new stack improve MDN's performance?
The new architecture significantly improved performance by only loading the exact CSS and JavaScript a page needs. It also improved the developer experience, cutting the development environment startup time from over 2 minutes to just 2 seconds.

Topics Covered

#MDN#React#Web Components#Lit#Performance
🚀Discover More

Stay Ahead of the AI Curve

Discover the best AI tools, agents, and MCP servers curated by Stork.AI. Find the right solutions to supercharge your workflow.

Back to all posts