Article

Web Components: A Practical Way to Build Once and Use Everywhere

Web Components: A Practical Way to Build Once and Use Everywhere

Web Components

Here’s a simple way to think about a recurring challenge in frontend development: we build interfaces inside specific frameworks, but our projects don’t always stay inside those boundaries. A team might create a polished React component library, only to take on a new initiative that depends on Vue. Or an element crafted in Angular suddenly needs to live inside a legacy jQuery application.

This is where web components offer real clarity. They provide a standardized way to build UI elements that work across frameworks — a quiet but meaningful solution to a long-standing portability problem.

What Are Web Components?

At the core, web components are browser-native APIs that let you create reusable, encapsulated HTML elements. They rely on three key technologies:

  1. Custom Elements — your own HTML tags with custom behavior
  2. Shadow DOM — scoped markup and styles that stay neatly contained
  3. HTML Templates — reusable markup that can be stamped as needed

A useful way to see this is: instead of being limited to built-in tags like <div> or <button>, you can extend the language of the web itself. Elements like <my-carousel> or <data-table> become first-class citizens in your project, regardless of the tools around them.

The Framework Conversation

One reason web components continue to gain traction is their neutrality. They aren’t tied to React, Vue, Angular, Svelte, or any other framework. They belong to the platform.


In large organizations — or any environment with mixed codebases — this matters. A component created once by a design system team can be used by multiple frontend stacks without rewriting logic or styling. Even older applications benefit because a web component is still just an HTML element.

Shoelace: A Strong Example of the Approach

Libraries like Shoelace show what’s possible when web components are thoughtfully designed. Shoelace offers a wide suite of components that can drop into almost any project with minimal overhead.

A few details that stand out:

  • Accessibility is built in from the start
  • Theming is handled with CSS custom properties
  • Framework guides help teams integrate smoothly where needed
  • No build step is required — they work straight from a CDN

<!-- It's really this simple -->
<script type="module" src="https://cdn.jsdelivr.net/npm/@shoelace-style/shoelace@2.12.0/cdn/shoelace.js"></script>
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@shoelace-style/shoelace@2.12.0/cdn/themes/light.css" />

<sl-button variant="primary" size="large">
  <sl-icon slot="prefix" name="download"></sl-icon>
  Download Now
</sl-button>

How Web Components Compare to Traditional UI Tools

Here’s a straightforward breakdown of how they differ from more familiar approaches.

Web Components vs. CSS Frameworks (Tailwind, Bootstrap)

Utility-first systems like Tailwind and layout-oriented systems like Bootstrap focus on styling, not behavior.

  • Tailwind gives styling primitives
  • Bootstrap provides CSS plus light JavaScript
  • Web components bundle markup, behavior, and styles into a single element

They can complement one another — you can absolutely style web components with Tailwind or combine them with Bootstrap’s grid.

Web Components vs. Component Libraries (Material UI, Ant Design)

This comparison shows clearer trade-offs:

Traditional Libraries:

  • Built directly for a single framework
  • Deep ecosystem support
  • Tight integration with routing, state, and lifecycle patterns
  • Larger bundles but well-optimized

Web Component Libraries:

  • Framework-independent
  • Smaller ecosystems but broader applicability
  • Compatible with any state management pattern
  • Typically lighter on a per-component basis

Evaluating the Trade-offs

Web components excel when:

  • Teams need cross-framework portability
  • A design system must serve multiple codebases
  • Long-term maintainability matters
  • Micro-frontends or distributed architectures are in use

Traditional frameworks may be better when:

  • You rely on deep framework features
  • You want large ecosystems and tooling
  • Your application is tightly scoped to one framework
  • You need access to cutting-edge framework patterns

Real-World Adoption

Many well-known platforms use web components extensively, not as experiments but as practical infrastructure:

  • GitHub
  • YouTube
  • Adobe
  • Microsoft

These examples show that web components are already supporting large, complex systems in production.

A Simple Example

Here’s a small component to illustrate how the pieces fit together:

class SimpleCounter extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({ mode: 'open' });
    this.count = 0;
  }

  connectedCallback() {
    this.render();
    this.shadowRoot.querySelector('button').addEventListener('click', () => {
      this.count++;
      this.render();
    });
  }

  render() {
    this.shadowRoot.innerHTML = `
      <style>
        :host {
          display: inline-block;
          padding: 1rem;
          border: 2px solid #007acc;
          border-radius: 8px;
        }
        button {
          background: #007acc;
          color: white;
          border: none;
          padding: 0.5rem 1rem;
          border-radius: 4px;
          cursor: pointer;
        }
      </style>
      <div>Count: ${this.count}</div>
      <button>Increment</button>
    `;
  }
}

customElements.define('simple-counter', SimpleCounter);

Once defined, <simple-counter></simple-counter> works anywhere — plain HTML, React, or even an older codebase.

The Path Forward

Web components aren’t meant to replace modern frameworks. They focus on a different layer of the stack: reusable UI elements that work across environments. As browser support improves and libraries mature, they offer a steady middle ground — stable components plus flexible application logic.

This isn’t an all-or-nothing shift. You can pair web components with your existing framework or adopt them gradually. The real benefit is having UI building blocks that remain consistent, portable, and future-friendly.

In many ways, the future of frontend development isn’t about choosing sides. It’s about understanding when each tool fits. And for cross-framework components, web components provide a clear, reliable option.