Web Components Adoption

I kept running into web components in the wild long before I understood the adoption story. Then I looked up the actual timeline: full cross-browser support didn't arrive until 2020. That nine-year gap -- from the 2011 proposal to ubiquitous support -- explains almost everything about why most teams avoided them and why that calculation looks different now.

ExpandWeb components timeline: 2011 proposal to 2020 full browser support

The four pillars were specified long before they worked everywhere. Teams that skipped web components during that window weren't wrong. Browser support wasn't there, the authoring story was verbose, and the framework ecosystem had already pulled everyone in a different direction.

Nine Years to Full Support

Here is the actual timeline:

• 2011: Web components first proposed
• 2013: First implementation ships in Chrome
• 2016: Safari ships a V0 implementation
• 2018: Firefox adds support after a full rendering engine overhaul
• 2020: Edge switches to Chromium -- all major browsers now support the V1 spec

And in the middle of those nine years, Mozilla killed HTML imports -- one of the original four pillars. The spec landed without it. ES modules became the replacement import story.

The community fractured a bit. The future felt uncertain.

Most teams that skipped web components weren't wrong to skip them. The calculation looks different in 2026.

Who Never Stopped Building

A partial list of companies actively shipping web components in production: Apple, Google, GitHub, YouTube, Adobe, NASA, Salesforce, IBM, Red Hat.

The common thread is not company size. It's scope.

GitHub serves a Rails app. YouTube ships React. Adobe's Photoshop sits alongside Lightroom and the rest of Creative Cloud -- all on different stacks.

When your design system has to work across a Rails app, a React app, a Vue app, and a WordPress site simultaneously, you cannot build it in React.

A React component library lives inside React. It cannot render in a Vue app without a rewrite. Web components are HTML elements -- they work anywhere HTML works.

That's the sell.

The cost of not having this compounds the moment a team wants to move stacks. Rebuilding every component, with matching behavior and passing tests, in a different framework is exactly as expensive as it sounds.

This is what people in design systems work call the million-dollar button. Not the button itself -- the bill for reimplementing it in the next framework.

Wordle and Photoshop

Wordle -- the word game that sold to the New York Times for seven figures -- is built entirely with web components. Open developer tools and look at the source: <game-app> at the root, a shadow DOM full of child components, game state managed inside custom elements.

Photoshop's web-based client is built with web components, using Lit as the component library. The image processing runs in WebAssembly -- compiled C++ on a separate thread. The web component is just the interface that talks to the binary -- a separation that's hard to achieve inside a framework.

These two examples are useful because they sit at opposite ends of the complexity scale. One is a toy game. One is professional creative software. Web components handled both.

The React Question

React is the notable outlier in web component compatibility. The issue has always been how React handles attributes.

In HTML, there is a meaningful distinction: an attribute is a string in the HTML source; a property is a JavaScript value set directly on the DOM object. React collapsed that distinction and spread everything as props. That caused problems with custom events and complex values on web components.

React 19 closes most of this gap. It adds first-class custom element support, handling the attribute-vs-property distinction according to the HTML spec. For teams using web components inside a React application, the friction should be significantly lower from here.

For teams that need a bridge today, Lit ships a createComponent wrapper in its labs package. You import your web component, wrap it, and the result behaves like a normal React component -- including forwarding custom events correctly through the React event system.

That wrapper also opens a different direction. createComponent lets you wrap existing React components into custom elements -- you build the sidecar, not a replacement.

Teams on Vue or Svelte get the web component version. The React system doesn't change.

File Size

Lit is about 7KB. React with ReactDOM is about 100KB.

That's not a complete comparison -- React does more. But if your main reason for reaching for React in a given project is "I need composable UI components," that 93KB gap is worth noticing.

The trade in the other direction: React's component model is opinionated in ways that reduce architectural decisions. Web components hand you low-level primitives. You make more choices -- for teams that want that control, the tradeoff is favorable.

Browser Compatibility Today

The V1 spec is solid in all major browsers. The gaps are in newer additions -- declarative shadow DOM, element internals, things the community is still advocating for.

Mobile Safari warrants attention. The WebKit team doesn't broadcast their roadmap -- features land without advance notice. A capability check with a graceful fallback is still the safest approach for anything newer than the V1 spec on iOS.

Chrome on Android tracks the desktop version closely. The Samsung browser lags a few versions behind -- worth testing if you have significant Samsung traffic.

Understanding browser API maturity tiers matters here. The core web components spec is green-tier; some community additions are still experimental. Knowing which is which before you ship saves a lot of debugging.

In the next post, I look at web components you can drop into any project today without writing a single line of component code -- no build step, no framework setup required.

The Essentials

1. Web components landed in all major browsers in 2020 when Edge switched to Chromium. Before that, full cross-browser support did not exist.
2. The main adoption driver for large companies is framework independence: one component library that works in React, Vue, Svelte, Rails, and WordPress at the same time.
3. Wordle and Photoshop's web client are both built with web components. Photoshop uses Lit as the component library, with WebAssembly handling image processing on a separate thread.
4. React 19 adds first-class custom element support, resolving the attribute-vs-property mismatch that caused compatibility problems in earlier React versions.
5. Lit is around 7KB. React with ReactDOM is around 100KB. Web components do not require Lit, but Lit significantly reduces the verbosity of the native API.
6. The V1 spec is fully supported. Newer additions like declarative shadow DOM are Chromium-stable but not yet in all browsers.

Further Reading and Watching

• Web Components Crash Course -- Traversy Media, practical build with vanilla JS
• open-wc.org -- community tooling, testing guides, and best practices for web components