What Is a Web Component?

The three standards

Custom Elements let JavaScript define a new element name, containing a hyphen to avoid clashing with built-in tags, and a class describing its behaviour: what happens when it is created, added to the page, removed, or when its attributes change. Once registered, <user-avatar> works like any other tag: in HTML, created by scripts, styled by CSS.

Shadow DOM gives an element a private subtree, with its own markup and its own styles, that the page's CSS does not reach and whose CSS does not leak out. The element's internal structure is hidden from the page the way a native <video> element's controls are.

HTML templates (<template> and <slot>) declare inert markup that the element clones into its shadow tree, and slots let the page pass content into designated places inside it.

Together they produce an element that is self-contained: its behaviour, structure and styling travel with it, and dropping it into a page is enough.

A minimal example

class HelloBadge extends HTMLElement {
  connectedCallback() {
    const root = this.attachShadow({ mode: "open" });
    root.innerHTML = `
      <style>span { padding: .25em .5em; background: #eef; border-radius: 4px; }</style>
      <span>Hello, <slot>stranger</slot></span>`;
  }
}
customElements.define("hello-badge", HelloBadge);

Then <hello-badge>Erjon</hello-badge> renders a styled badge in any page, framework or none, with the styling isolated from the page's CSS.

Custom ElementsDefine a new tag and its behaviour in JavaScript.

Shadow DOMA private subtree, with its own markup and styles.

HTML templatesInert markup, with slots for content.

What they are good for

Design systems shared across stacks. An organisation with a React product, a Vue marketing site and a WordPress blog can ship one set of components that work in all three. This is the strongest case, and it is why design-system tooling such as Lit and Stencil exists.

Embeddable widgets. A chat launcher, a booking form, a payment element dropped into customers' pages, where the host page's CSS and JavaScript are unknown and isolation is essential.

Long-lived components. Frameworks come and go; the browser's standards persist. A component written to the platform outlasts the framework churn around it.

Progressive enhancement. A custom element can wrap existing HTML and add behaviour, degrading to the plain markup if JavaScript fails, which fits the progressive enhancement approach naturally.

Framework-free sites. Small, dependency-free interactivity on a static site without adopting a framework for a few widgets.

The pain points

Verbosity. The raw APIs are low-level; a component that takes five lines in a framework takes twenty. Libraries such as Lit add reactive properties and templating to fix this while remaining standards-based.

Styling. Shadow DOM's isolation cuts both ways: the page cannot style the component's internals except through CSS custom properties and the ::part() selector the component exposes. Design tokens as custom properties are the answer, and it takes planning.

Forms. Custom form controls need the ElementInternals API to participate in form submission and validation; older approaches did not, and it remains fiddly.

Server rendering. Components define themselves in JavaScript, so on the server there is nothing to render until recently; Declarative Shadow DOM, now supported in all major browsers, allows the shadow tree to be sent as HTML, and frameworks such as Lit support it. It is workable but newer than framework SSR.

Accessibility. Shadow DOM complicates some ARIA relationships across the boundary; native form elements inside a component and careful labelling are needed.

Ecosystem. Smaller than React's; fewer ready-made components, less tooling, and framework integration that varies. React's support for custom elements improved substantially in version 19, removing the largest friction.

Relationship to frameworks

Web components are not a framework replacement. Frameworks manage application state, routing, data and rendering; web components define reusable elements. They combine: a React or Vue application can render web components as it would native tags, and a design system built as web components can be consumed by any application. The library-versus-framework distinction applies: web components are a platform capability, and Lit is a small library over it.

When to use them

When components must work across different stacks or in pages you do not control; when longevity beyond the current framework matters; when shipping widgets into third-party pages; or when adding contained interactivity to a site without a framework. When building a single application in one framework, that framework's own components are usually simpler and better integrated.

The practical path is Lit or Stencil for authoring, custom properties for theming, Declarative Shadow DOM where server rendering matters, and a test in every host environment the components will live in. If you are building a design system for more than one stack, book a call; web components are usually the right foundation for it.

Common questions