Au-delà des Frameworks : Faites Confiance aux Primitives du Web

Chaque fois que vous ajoutez une dépendance de framework, vous pariez que cette bibliothèque survivra à votre projet. Pendant ce temps, la plateforme web propose des fonctionnalités que les navigateurs s’engagent à supporter indéfiniment. L’écart entre ce que fournissent les frameworks et ce que gèrent désormais les API natives des navigateurs s’est considérablement réduit.

Cet article examine des primitives spécifiques de la plateforme web qui réduisent la dépendance aux frameworks—et comment évaluer leur maturité en utilisant Baseline comme référence.

Comprendre les Fonctionnalités Web Baseline

Avant d’adopter une API native de navigateur, vous avez besoin d’un moyen fiable d’évaluer la compatibilité multi-navigateurs. Baseline fournit exactement cela. Une fonctionnalité atteint le statut « nouvellement disponible » lorsqu’elle est implémentée dans les dernières versions stables de Chrome, Edge, Firefox et Safari. Après une période soutenue de disponibilité sur ces navigateurs (environ 30 mois), elle devient « largement disponible ».

Cela compte pour les décisions d’amélioration progressive. Baseline vous indique quand une fonctionnalité peut être utilisée en toute sécurité comme implémentation principale plutôt que comme une expérience améliorée de secours.

Vous pouvez vérifier l’état actuel de compatibilité multi-navigateurs de n’importe quelle fonctionnalité web sur le tableau de bord Web Platform Status à l’adresse https://webstatus.dev, qui suit la classification Baseline et la compatibilité des navigateurs en un seul endroit.

API Natives des Navigateurs Remplaçant les Patterns de Frameworks

L’API Popover pour les Patterns de Modales et d’Info-bulles

Les développeurs React utilisent souvent des bibliothèques comme Radix ou Headless UI pour créer des popovers accessibles. L’API Popover, désormais une fonctionnalité Baseline nouvellement disponible, gère cela nativement :

<button popovertarget="menu">Open Menu</button>
<div id="menu" popover>
  <p>Menu content here</p>
</div>

Le navigateur gère le piégeage du focus, le comportement de fermeture légère et le rendu en couche supérieure. Aucun JavaScript requis pour les fonctionnalités de base. La détection de fonctionnalité est simple :

if ('popover' in HTMLElement.prototype) {
  // Use native popover
} else {
  // Fall back to framework solution
}

View Transitions pour les Animations de Pages

Les applications monopage existent en partie parce que la navigation multi-pages semblait abrupte. L’API View Transitions change cette équation en permettant des transitions fluides entre états du DOM :

document.startViewTransition(() => {
  updateDOMSomehow();
});

Pour les transitions entre documents, le CSS seul peut activer les pages :

@view-transition {
  navigation: auto;
}

La famille View Transitions est désormais Baseline nouvellement disponible pour les transitions au sein d’un même document. Les navigateurs sans support ignorent simplement l’animation.

L’API Navigation pour le Routage Côté Client

Les routeurs de frameworks comme React Router existent parce que l’API History était maladroite. L’API Navigation fournit un modèle plus propre pour intercepter la navigation :

navigation.addEventListener('navigate', (event) => {
  event.intercept({
    handler() {
      return loadContent(event.destination.url);
    }
  });
});

L’API Navigation est désormais Baseline nouvellement disponible, mais cela ne signifie pas que vous devriez supprimer votre routeur dès demain. Cela signifie que vous pouvez commencer à évaluer où les primitives de navigation natives peuvent simplifier votre stack—en particulier pour les expériences plus légères de type « application ».

Fonctionnalités CSS Modernes Éliminant le JavaScript

Positionnement par Ancrage (Anchor Positioning)

Le positionnement d’info-bulles et de menus déroulants par rapport aux éléments déclencheurs nécessitait traditionnellement des calculs JavaScript. Le positionnement par ancrage CSS gère cela de manière déclarative :

.trigger {
  anchor-name: --trigger;
}

.tooltip {
  position: absolute;
  position-anchor: --trigger;
  top: anchor(bottom);
  left: anchor(center);
}

Cette fonctionnalité n’est pas encore disponible Baseline sur tous les navigateurs majeurs, utilisez-la donc strictement comme amélioration progressive avec des solutions de secours JavaScript si nécessaire.

Container Queries et :has()

Les requêtes de conteneur sont largement disponibles et permettent aux composants de répondre à la taille de leur conteneur plutôt qu’au viewport—éliminant beaucoup de logique de mise en page JS fragile.

Le sélecteur :has() est nouvellement disponible et débloque des patterns qui forçaient auparavant la « conscience parentale » basée sur JS et la réflexion d’état. Comme il n’est pas encore largement disponible, il peut encore justifier de la prudence selon votre audience—mais c’est désormais une option réelle sur laquelle construire avec des solutions de secours mesurées.

Shadow DOM Déclaratif pour les Web Components SSR

Le rendu côté serveur des Web Components nécessitait auparavant une gymnastique d’hydratation. Le Shadow DOM déclaratif résout ce problème :

<my-component>
  <template shadowrootmode="open">
    <style>/* scoped styles */</style>
    <slot></slot>
  </template>
</my-component>

Le shadow DOM existe dans la charge HTML initiale—aucune exécution JavaScript nécessaire pour le premier rendu. Ceci est désormais nouvellement disponible et utilisable dans les navigateurs modernes, mais les anciennes versions de Safari en particulier peuvent nécessiter des solutions de secours.

L’Amélioration Progressive comme Architecture

Le pattern ici n’est pas « abandonner les frameworks ». C’est reconnaître que les primitives de la plateforme web gèrent désormais des problèmes spécifiques qui nécessitaient auparavant des couches d’abstraction.

La détection de fonctionnalités permet cette approche :

1. Vérifier si l’API native existe
2. L’utiliser lorsqu’elle est disponible
3. Basculer vers des solutions de frameworks lorsqu’elle ne l’est pas

Cela suit les principes de longue date de l’amélioration progressive et réduit la taille du bundle pour les navigateurs capables tout en maintenant la fonctionnalité partout.

Conclusion

Auditez vos dépendances de frameworks par rapport aux fonctionnalités Baseline actuelles. L’API Popover, les View Transitions, les capacités CSS modernes et le Shadow DOM déclaratif résolvent de vrais problèmes qui justifiaient du code de framework il y a seulement deux ans.

La plateforme web évolue lentement mais de manière permanente. Les fonctionnalités qui atteignent le statut Baseline représentent un terrain stable. Construisez sur cette fondation, et augmentez uniquement là où la plateforme présente réellement des lacunes.

FAQ

Gain Debugging Superpowers

Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.