Créer des systèmes de design durables avec les Progressive Web Components

Dans le monde des bibliothèques de composants pour gros projets, on connaît tous ce tiraillement. Les web components promettent une vraie liberté : ils marchent partout, sans dépendre d'un framework précis. Mais en pratique ? Des sauts de mise en page avant le chargement du JS, des pièges d'accessibilité avec le Shadow DOM, et un SSR qui demande des astuces.

Le vrai souci ? On les complique trop.

Le paradoxe des web components

Imaginez : une équipe se lance dans un design system basé sur web components. Ils codent des Custom Elements, intègrent un framework costaud, et hop, des kilos d'octets de JS pour un simple bouton. Le HTML arrive nu, le JS reprend tout, et l'utilisateur voit un flash moche. Les lecteurs d'écran patinent sur l'isolation du Shadow DOM. Le SSR ? Un cauchemar.

Ce n'est pas la faute des web components. C'est notre façon de les coder.

Et si on repartait des bases ?

Les meilleures idées semblent évidentes après coup. Et si les composants s'affichaient d'abord en HTML et CSS purs ? Et si le JS n'était qu'un bonus ?

C'est l'essence des Progressive Web Components : une philosophie, pas un framework. Deux couches bien distinctes.

La couche de base : HTML et CSS only. Ça s'affiche direct dans le navigateur, sans JS. Contenu visible, styles appliqués, page stable.

La couche d'enrichissement : JS pour l'interactivité, les events, la réactivité. Activé seulement si besoin.

Les trois types de composants

Tous les composants ne se valent pas. Voici les trois variantes :

Composants composites : ils emballent du HTML existant. Un dropdown sur un <select> natif, un système d'onglets avec des listes. Light DOM pour l'accessibilité et la compatibilité totale.

Composants primitifs : autonomes. Un date picker ou un slider qui sort son HTML de base d'entrée. JS ajoute l'interaction après.

Composants Declarative Shadow DOM : Shadow DOM natif, avec SSR. Idéal pour encapsuler les styles sans sacrifier le serveur.

Choisissez selon vos besoins. Pas de règles rigides, juste une approche en couches.

Le défi de l'implémentation

Comprendre, c'est bien. Appliquer sur des dizaines de composants, c'est autre chose. Une lib progressive gère :

• Sync des props et attributs entre frameworks
• Délégation d'événements sans Shadow DOM obligatoire
• Hydratation sans re-rendu inutile
• Scoping CSS sans JS lourd
• Accessibilité intégrée dès le départ
• SSR sans logique serveur spéciale

La plupart des libs vous laissent galérer. Résultat : du boilerplate partout, et le JS devient indispensable même pour l'essentiel.

Repenser l'architecture

Une approche progressive, ça change les priorités :

Envoyez du HTML en premier. État initial en HTML sémantique, stylé au CSS, accessible. JS seulement pour l'interactif.

JS facultatif. Un formulaire valide sans JS. Un menu nav accessible en HTML brut. Les plus-values interactives en bonus.

Suivez la plateforme. Custom Elements, Shadow DOM (si besoin), Slots, Declarative Shadow DOM : tout natif.

Multi-frameworks. HTML-first = compatible React, Vue, Angular, Svelte ou vanilla. Pas d'adaptateurs.

SSR natif. HTML/CSS de base = rendu serveur facile. Outils optionnels pour l'état complexe.

Quelle taille pour une lib de composants ?

Combien de JS une lib doit-elle vraiment charger ? Les populaires pèsent 50 KB+. Avec Progressive Web Components, tout le framework fait 2,6 KB. Le reste, ce sont vos composants.

Ça compte pour les perfs réelles. Moins de poids = téléchargements rapides, parsing fluide, exécution immédiate. Sur mobile, 3 secondes au lieu de 8 pour interagir.

SSR simplifié

Le SSR demande souvent du code serveur dédié. Les Progressive Web Components inversent : HTML/CSS first = SSR par défaut.

Composites et déclaratifs s'affichent direct sur serveur, sans effort. Pour la réactivité, HTML initial + hydratation client.

Adieu, gros headache du SSR avec web components.

Des libs de composants qui durent

Pour un design system scalable, les Progressive Web Components offrent la portabilité rare : sans compromis.

Pas de bundle React, pas d'écosystème Vue. Vos composants marchent avec le framework d'aujourd'hui... et celui de demain.

Ça demande de la discipline : moins de JS partout, plus d'HTML sémantique, CSS soigné. Mais le gain ? Réutilisabilité, perfs, accessibilité au top.

Le mot de la fin

Les web components ne sont pas nuls. On les a traités comme des frameworks JS, alors qu'ils sont des éléments HTML. Les Progressive Web Components reviennent aux fondamentaux : plateforme web d'abord, couches intelligentes, résultat léger, portable, performant.

Pour les équipes en design systems, c'est du solide.