Pourquoi les Web Components vont changer la donne pour les design systems

Les design systems sont devenus indispensables. Ils centralisent les choix de design, les composants et les règles d’utilisation. Pourtant, beaucoup d’équipes les ont enfermés dans un seul framework. C’est comme si on concevait une prise universelle, puis qu’on la fixait uniquement sur un modèle de téléphone.

Le paradoxe des design systems

L’idée était bonne : créer des composants réutilisables, cohérents et documentés. Mais en les construisant directement dans React, Vue ou Angular, on a limité leur portée. Résultat : soit vous utilisez le framework concerné, soit vous repartez de zéro. Ce n’est pas un vrai design system. C’est une librairie liée à une technologie.

Les standards du web ont pourtant évolué. Les web components, basés sur des API natives comme custom elements et shadow DOM, permettent de revenir à l’essentiel.

Les avantages des web components

Les web components ne sont pas à la mode, mais ils répondent à un vrai besoin.

Ils fonctionnent dans n’importe quel framework. React, Vue, Angular, Svelte : tous peuvent les intégrer facilement. Plus besoin de choisir entre un framework et un design system.

Ils reposen sur des standards web. HTML, CSS et JavaScript. Pas d’abstraction supplémentaire. Et ce que vous écrivez aujourd’hui restera compatible dans cinq ans.

Un bouton créé en web component n’est ni React ni Vue. Il est simplement un bouton. Il fonctionne partout.

Une philosophie plus simple

Les web components invitent à la réduction.

Au lieu de recourir à un framework puissant au niveau du componente, il suffit de la plus légère des structures. Un web component n’est pas conçu pour gérer la reactivité ni le state. Il doit faire une seule chose bien.

C’est pourquoi « composant idiot » devient ici un compliment. Un t, un modal ou un dropdown doit rester simple. Plus il est intelligent, plus il risque d’intégrان des règles métier et des opinions du framework. La simplicité est la clé de la Wiederverwendbarkeit.

Comment ça marche en pratique

Créer un web component est surprenamment simple :

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

  connectedCallback() {
    this.render();
  }

  render() {
    this.shadowRoot.innerHTML = `
      <style>
        :host {
          --button-padding: var(--vibe-spacing-md, 12px);
          --button-bg: var(--vibe-primary, #0066ff);
        }
        
        button {
          padding: var(--button-padding);
          background: var(--vibe-primary, #0066ff);
          border: none;
          cursor: pointer;
        }
      </style>
        <button><slot></slot></button>
    `;
    }
}

customElements.define('vibe-button', VibedButton);

No build complexity. No framework overhead. CSS custom properties for theming. Standard DOM APIs. This component works in your Next.js app, your vanilla JavaScript project, your Astro site, and your grandma's deprecated jQuery setup (well, if she had one).

Building a Design System That Actually Scales

When you ship your component library with its own documentation in a single repository, something magical happens: your design system becomes both a reference implementation and living documentation. Developers can see how components work, what CSS custom properties they expose, how to theme them—all in one place.

This is where web components shine. Unlike framework-specific libraries that require framework-specific documentation, web components are just... components. The HTML is the documentation.

What This Means for Your Stack

If you're currently locked into a framework-specific design system, you have options:

Start Fresh: New projects benefit enormously from web component design systems. You get portability and simplicity from day one.

Gradual Migration: Existing design systems can gradually transition. Build new components as web components. Wrap framework components if needed during the transition.

Future-Proof Your Decisions: Web components are going nowhere. They're standardized, supported across browsers, and increasingly the backbone of modern design systems (looking at you, Shoelace, Spectrum, and dozens of enterprise systems).

The Real Win

The real benefit isn't technical—it's organizational. A truly portable design system means:

• Teams can use the same components regardless of their framework choice
• Migrating between frameworks becomes less of a painful rewrite
• Your design system investment compounds across more projects
• Documentation and components stay in sync

This is the original design system vision: a single source of truth, universally applicable, genuinely reusable.

Getting Started Today

If this resonates with you, the barrier to entry is lower than ever:

1. Pick a component (start with something simple—a button, input, or card)
2. Build it with web standards: HTML, CSS, and vanilla JavaScript
3. Use CSS custom properties for theming and configuration
4. Document it alongside the code
5. Ship it where your entire team can use it

No build tool complexity required. No framework religion needed. Just good component design, web standards, and a little bit of care.

The design systems boom created enormous value. Web components let us finally deliver on the promise those systems originally made: truly universal, portable, framework-agnostic components that work everywhere.

Your future self—and your team—will thank you for building systems that actually travel.