Web Components in 2025: Are They Usable Yet?

Every Year Is Supposed to Be "The Year of Web Components"

Expectations for web components have been around since 2018. "Build reusable components without a framework," "it's a standard so it won't die," "no framework lock-in." These claims resurface annually, and annually React keeps winning.

But 2025 felt different enough to warrant actually trying them out.

Custom Elements + Shadow DOM: How Far Have They Come?

I built a button component as a web component. Register with customElements.define, isolate styles with Shadow DOM, accept content via slots.

The code was clean. But the same thing in React would be half the length. Boilerplate is still heavy. connectedCallback, disconnectedCallback, attributeChangedCallback... lifecycle methods managed manually. Made me appreciate React's useEffect all over again.

Is Lit the Game Changer?

Google built Lit, a library that wraps web component creation. It dramatically reduces boilerplate. Supports reactive properties, and you write HTML with template literals.

I spent two weeks building 8 basic design system components with Lit. Button, card, modal, input, dropdown, tabs, toast, accordion. Average 3 hours per day. Total: 42 hours.

Same set in React? Based on experience, about 30 hours. 12-hour gap. Web components still trail in productivity. (But that gap feels like it's shrinking.)

Why the Renewed Interest Now?

Micro frontends. When different teams use different frameworks, web components are nearly the only option for shared common components. React team, Vue team, Svelte team -- all using the same button component.

This scenario became real at my company. Our frontend team uses React, but an internal HR tool runs on Vue. To apply a consistent design system across both? Web components.

What's Still Frustrating

SSR is weak. Declarative Shadow DOM exists, but server-side rendering web components in Next.js or Nuxt remains painful. Hydration issues abound.

Form integration is clunky. Making custom elements behave like native form elements inside <form> requires the ElementInternals API, which isn't intuitive.

Testing tools don't match React Testing Library's level. @open-wc/testing exists but the ecosystem is thin.

Less a Conclusion, More a Current Position

Web components shouldn't be viewed through the "will they replace React?" lens. The right frame is "will they coexist with frameworks, handling the intersection points?" For design systems, micro frontends, and CMS widgets, they're already practical.

Starting a fresh project from scratch? I'd still pick React. But building a shared component library? Web components deserve serious consideration.