What the Browser Platform Gained Since React Launched

React launched in May 2013. JavaScript itself changed on one track since then, TC39’s yearly ECMAScript editions, already covered in full. The browser platform moved on an entirely separate track, through WHATWG and W3C rather than TC39, and its story has a different shape: a rocky, fragmented start, a real standard settling in over several years, and then, in just the last eighteen months, a genuine wave of new primitives landing back to back, several of them doing natively what used to require a library or framework.

Rundown

• Web Components took years, and a failed first attempt, to actually arrive. Chrome shipped an early, non-standardized version in 2014 that never got adopted by other browsers. The real, cross-browser standard, Custom Elements v1 and Shadow DOM v1, shipped in Chrome in 2016 and reached other engines by around 2018.
• The Fetch API (2015) and native ES modules in browsers (2017) both replaced patterns that used to require a library, XMLHttpRequest wrappers and script-loader tricks, respectively.
• IntersectionObserver (Chrome 51, 2016) and ResizeObserver (Chrome 64, roughly 2018) gave the platform a native way to react to visibility and size changes, replacing hand-rolled scroll and resize listeners.
• Declarative Shadow DOM, solving Web Components’ biggest server-rendering gap, reached Baseline across all three major browser engines on August 5, 2024.
• Import maps, which let a bare specifier like import React from 'react' resolve directly in the browser with no bundler at all, reached full cross-browser support in 2023 once Safari 16.4 shipped last, closing the gap Chrome had held alone since version 89.
• Three genuinely new platform primitives shipped in rapid succession most recently: the Popover API (Baseline January 2025), the View Transitions API for same-document transitions (Baseline October 2025), and the Navigation API (Baseline January 2026), each replacing a category of problem that used to mean reaching for a library.

The timeline, at a glance

Two tries before Web Components actually landed

Chrome shipped an early version of Web Components, Shadow DOM v0, Custom Elements v0, and HTML Imports, in 2014. None of it was adopted by other browser engines, and Chrome formally deprecated and removed all three in 2019. The real, standardized versions, Custom Elements v1 and Shadow DOM v1, shipped in Chrome in 2016 and reached Firefox by late 2018, alongside native ES modules (2017), which gave the platform a real way to replace HTML Imports as a loading mechanism. That’s a four-year gap between Chrome shipping something called Web Components and Web Components actually becoming a cross-browser standard, worth knowing if an old post or tutorial references the v0 APIs.

The Observer family

IntersectionObserver shipped in Chrome 51 in 2016, with Firefox committing to implementation the same year, giving the platform a native, asynchronous way to answer whether an element is visible without polling scroll position. ResizeObserver followed a similar path, discussed at a 2016 web standards meeting, shipping in Chrome 64 a couple of years later, and now sitting at roughly 96% global browser support. Both replaced a specific, common pattern: hand-rolled scroll or resize event listeners, throttled and debounced by hand, that existed purely because the platform had no native way to ask the question directly.

Declarative Shadow DOM closes the server-rendering gap

Shadow DOM’s biggest practical limitation for years was server-side rendering: there was no way to express a shadow root in HTML generated on the server, which meant using Shadow Dom with SSR either meant a client-side flash of unstyled content or avoiding the feature entirely. Declarative Shadow DOM solves this directly, and reached Baseline Newly Available across Chrome, Firefox, and Safari on August 5, 2024, after being available in Chrome alone since version 90 (2021) and going through a spec rename along the way (shadowroot became shadowrootmode in a 2023 revision). It’s specifically an answer to the server-rendering case, not a requirement for Web Components generally, regular, imperative Shadow DOM (element.attachShadow()) has worked fine since the 2016–2018 standardization on its own.

Import maps close the bare-specifier gap

Before import maps, using a third-party module by name in the browser meant either a bundler or a CDN willing to rewrite bare specifiers on the fly. Import maps close that gap directly: a <script type="importmap"> block maps a name like react to an actual URL, and every import React from 'react' in the page’s modules resolves against it, no bundler, no build step, no CDN-specific rewriting trick required. Chrome and Edge supported it from version 89 (2021); Firefox followed at 108 (2022); Safari was the last major engine, shipping it in 16.4 (2023), which is when import maps became a genuinely cross-browser feature rather than a Chromium-only one.

Shopify, which manages a large volume of theme and app scripts, contributed patches to both Chrome and WebKit specifically to support multiple import maps coexisting on a single page, a real engineering investment from a company with a direct, practical reason to want bare-specifier imports working reliably at scale. Ruby on Rails added first-class framework support for import maps as its own default JavaScript approach. Both are concrete evidence the feature is already load-bearing in real production systems.

Three new primitives, back to back

The most recent stretch is where the platform’s pace picks up noticeably. The Popover API reached Baseline Newly Available in January 2025, giving the platform a native way to build overlays and dropdowns, top-layer rendering with no z-index fights, optional light-dismiss behavior, and automatic focus management, all without a positioning library. The View Transitions API reached Baseline for same-document transitions in October 2025, letting a page animate between DOM states with document.startViewTransition() instead of an animation library. Cross-document transitions, animating between two separate full page loads rather than states within one, are a harder coordination problem and still Chromium-only as of this writing; Firefox and Safari haven’t shipped that part yet, which is why the same-document case landed first.

The Navigation API is the newest of the three, reaching Baseline Newly Available in January 2026. It’s a direct, purpose-built replacement for the decades-old History API, which had real, widely acknowledged problems: it couldn’t detect every kind of navigation, offered no way to read or edit the full history stack, and its popstate event didn’t reliably fire when pushState or replaceState were called programmatically. Ian Hickson, the former HTML spec editor, once called pushState() his “favourite mistake.” The Navigation API’s single navigate event handles both link clicks and form submissions through one consistent model, the kind of primitive client-side routers have always had to build for themselves, though it’s a lower-level building block a router can be built on rather than a router itself; popular SPA routers have open discussions about adopting it as a backend for their own logic, but none had shipped that integration as of this research.

None of this makes the browser platform a framework replacement on its own, the same caveat that applies to the language side applies here too. Three genuinely significant primitives, Popover, View Transitions, and Navigation, reached Baseline within about twelve months of each other, each replacing a specific category of problem a library used to own.

Related reading

Everything vanilla JavaScript has gained since React launched covers the same window from the language’s side, ECMAScript’s own yearly editions through TC39, standardized through an entirely separate process from everything covered here.