Web Components have been “the future” for nearly a decade, which is long enough that many developers have written them off entirely. That would be a mistake. While they haven’t replaced React or Vue as some early advocates predicted, Web Components have found their niche, and it’s a surprisingly useful one.

The Quick Primer

Web Components are a set of browser-native APIs for creating reusable custom elements. The three core technologies are:

Custom Elements: Define new HTML elements with their own behaviour. A <date-picker> element that works like any built-in HTML element.

Shadow DOM: Encapsulate styles and markup so they don’t leak into or out of the component. Your component’s CSS won’t affect the host page, and the host page’s CSS won’t affect your component.

HTML Templates: Define markup fragments that aren’t rendered until you clone them into the DOM.

A basic Web Component looks like this:

class GreetingCard extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({ mode: 'open' });
  }

  connectedCallback() {
    const name = this.getAttribute('name') || 'World';
    this.shadowRoot.innerHTML = `
      <style>
        .card {
          padding: 16px;
          border: 1px solid #ddd;
          border-radius: 8px;
        }
      </style>
      <div class="card">
        <h2>Hello, ${name}!</h2>
        <slot></slot>
      </div>
    `;
  }
}

customElements.define('greeting-card', GreetingCard);

Where Web Components Excel

Design systems that span frameworks. This is the strongest use case. If your organisation uses React in one product, Vue in another, and plain HTML in marketing pages, Web Components let you build a single component library that works everywhere. Companies like Adobe (Spectrum), SAP (UI5), and Microsoft (FAST) use Web Components for exactly this reason.

Third-party embeddable widgets. If you’re building something that gets embedded on other people’s websites — chat widgets, payment forms, analytics dashboards — Web Components with Shadow DOM provide the style isolation you need. Your widget won’t be broken by the host site’s CSS reset.

Progressive enhancement. Web Components can extend existing HTML elements, adding behaviour without replacing content. A <auto-save-form> component can wrap a standard <form> element and add automatic saving without changing how the form works without JavaScript.

Where They Fall Short

Reactive state management. The native APIs don’t include reactivity. Updating a component’s internal state and reflecting that in the DOM requires manual work. Libraries like Lit paper over this, but you’re adding a dependency to compensate for a missing native capability.

Server-side rendering. Declarative Shadow DOM has improved this situation significantly, but SSR support for Web Components is still more complex than with framework components. If server-rendered HTML is critical for your use case, framework components remain easier.

Developer ergonomics. Writing raw Web Components is verbose compared to React or Svelte. The lifecycle callbacks (connectedCallback, disconnectedCallback, attributeChangedCallback) are lower-level than framework equivalents. Again, Lit helps, but the baseline developer experience is rougher.

Lit: The Practical Path

For most developers who want to use Web Components, Lit is the right starting point. It’s a lightweight library (around 5KB) that adds reactive properties, declarative templates, and a clean component model on top of native Web Components.

import { LitElement, html, css } from 'lit';

class TaskItem extends LitElement {
  static properties = {
    text: { type: String },
    done: { type: Boolean }
  };

  static styles = css`
    :host { display: block; padding: 8px; }
    .done { text-decoration: line-through; }
  `;

  render() {
    return html`
      <label class=${this.done ? 'done' : ''}>
        <input
          type="checkbox"
          .checked=${this.done}
          @change=${this._toggle}
        />
        ${this.text}
      </label>
    `;
  }

  _toggle() {
    this.done = !this.done;
    this.dispatchEvent(new CustomEvent('toggle', { detail: { done: this.done } }));
  }
}

customElements.define('task-item', TaskItem);

Lit components are standard Web Components — they work in any framework, any page, any context. Lit just makes them pleasant to write.

Interop With Frameworks

Using Web Components inside React, Vue, or Angular has gotten significantly easier. React 19 improved its handling of custom element properties and events, resolving long-standing issues. Vue and Angular have supported Web Components well for years.

The interop isn’t perfect. Passing complex objects as properties (rather than string attributes) still requires some ceremony in React. Event handling conventions differ across frameworks. But for most practical use cases, it works.

My Recommendation

Don’t replace your framework components with Web Components. If you’re building an application in React, keep using React components. The DX is better and the ecosystem is richer.

Do consider Web Components when you need to share components across frameworks, build embeddable widgets, or create a design system for a multi-framework organisation. These are the scenarios where native browser interop gives Web Components a genuine advantage.

The Web Components platform isn’t competing with frameworks anymore. It’s occupying a complementary space, and in that space, it’s increasingly effective.