Le monde du développement web a passé une bonne partie de la décennie à se convaincre que le navigateur devait faire le gros du travail

Le monde du développement web a passé la majeure partie d'une décennie à se convaincre que le navigateur devait faire le plus gros du travail. Nous avons commencé avec des documents et des formulaires, puis nous avons progressivement migré chaque opération concevable vers le client. Le routage, la gestion d'état, la récupération de données, la logique de rendu, et même l'orchestration des requêtes de base de données via GraphQL — tout a été transféré dans des bundles JavaScript qui devenaient de plus en plus lourds à chaque version. Les frameworks se sont multipliés, les pipelines de build se sont complexifiés, et ce qui avait commencé comme un moyen de rendre les applications réactives s'est transformé en une architecture où une page ne pouvait afficher un seul pixel significatif avant que des mégaoctets de code n'aient été téléchargés, analysés et exécutés.

Ce changement a résolu de vrais problèmes. Les pages rendues côté serveur avec une pincée de jQuery peinaient à offrir les transitions fluides, semblables à celles d'une application, que les utilisateurs attendaient. Les Single Page Applications nous ont apporté une navigation instantanée, un état persistant et des interactions riches. Mais le coût s'est accumulé. Les équipes doivent désormais gérer des stores d'état client complexes, manipuler des bundles JavaScript massifs, maintenir des couches de synchronisation de données capricieuses et déboguer des pipelines de build qui ressemblent parfois à un emploi à plein temps. Nous avons échangé un ensemble de problèmes contre un autre, et de nombreux développeurs se demandent aujourd'hui si chaque application doit réellement payer cette taxe.

Deux développements permettent de répondre plus facilement à cette question.

HTMX et le retour de l'hypermédia

Le premier est HTMX. En apparence, il ressemble à une petite bibliothèque, mais ses implications architecturales sont majeures. HTMX traite l'HTML comme le format natif de la logique applicative, au lieu de le considérer comme une coquille statique qui doit être gonflée par JavaScript.

Voici ce qui change en pratique. Traditionnellement, lorsqu'un utilisateur clique sur un bouton pour charger plus de commentaires, le frontend lance une requête fetch, reçoit une charge utile JSON, la normalise dans un store côté client, la fait passer par un template de composant, calcule la différence du DOM virtuel et finit par appliquer les modifications à la page. HTMX court-circuite cette chaîne. Le bouton lui-même contient des attributs qui indiquent au navigateur où envoyer la requête et quel élément de la page remplacer. Le serveur renvoie un fragment HTML — juste les nouveaux commentaires, enveloppés dans une div. Le navigateur l'échange. Il n'y a pas de JSON, pas d'arbre d'état frontend, pas d'algorithme de réconciliation, et pas de JavaScript impératif pour maintenir l'interface utilisateur synchronisée avec le serveur.

Il ne s'agit pas d'un rejet du développement moderne, mais d'un rejet de l'abstraction inutile. HTMX prouve que l'hypermédia, le style architectural qui a propulsé le web des débuts, peut encore supporter des interfaces sophistiquées lorsqu'il est associé à une ergonomie moderne. N'importe quel élément peut émettre des requêtes, pas seulement les formulaires et les liens. N'importe quel événement peut déclencher une mise à jour. Le serveur reste la source de vérité tant pour les données que pour la présentation.

Les mises à jour partielles déclaratives de Chrome

Le second changement est plus récent et réside au cœur même du navigateur. Chrome introduit les Declarative Partial Updates, ou DPU. Cette fonctionnalité permet à un navigateur de diffuser du HTML et de l'insérer directement dans des parties ciblées d'une page à mesure que les octets arrivent.

Avant le DPU, si vous vouliez diffuser des données en direct dans une page web, vous aviez généralement recours aux WebSockets, aux Server-Sent Events ou au long-polling, couplés à une manipulation manuelle du DOM. Le frontend devait gérer la connexion, analyser la charge utile et décider exactement comment et où injecter le balisage. Le DPU change la donne en rendant le processus déclaratif. Le développeur spécifie un conteneur cible, et le navigateur s'occupe du reste : recevoir le flux, analyser le fragment et le placer exactement là où il doit être, avant même que la réponse complète ne soit clôturée.

Pensez à un tableau de bord de surveillance affichant des journaux de serveur ou à une file d'attente de support se mettant à jour en temps réel. Avec le DPU, le backend envoie des morceaux de HTML brut au fur et à mesure qu'ils sont générés. Le navigateur les diffuse dans le corps d'un tableau ou dans un conteneur de flux sans une seule ligne de logique de streaming côté client. L'assemblage se fait nativement.

Le modèle Server-First

En combinant HTMX et le DPU, on obtient une architecture cohérente où le serveur possède l'état et génère l'interface utilisateur, tandis que le navigateur gère l'affichage et les entrées utilisateur. Les frameworks backend comme Rails, Laravel, Django, les templates Go ou ASP.NET redeviennent la couche d'interface principale. Le frontend n'est pas une application distincte qui consomme une API. C'est l'interface hypermédia produite par le serveur.

This model fits a surprisingly wide slice of software. Consider the typical SaaS application. It is dashboards with sortable tables. It is admin panels with forms and filters. It is internal tools that move records from one state to another. It is CRUD workflows that show a list, expose a detail view, and let the user edit fields. It is even AI interfaces where a language model streams tokens back to the user, and each token or paragraph can be wrapped in HTML and appended to the conversation thread. For all of these, a thick JavaScript client is often overkill.

The benefits are immediate and practical. Initial page loads are faster because the first meaningful paint arrives as HTML, not after a hydration cycle completes. JavaScript payloads shrink because there is no virtual DOM, no client-side router, and no state management library to ship. Search engines see complete content without executing bundles, so SEO works by default. Complexity drops because one codebase handles routing, business logic, and rendering. Debugging gets easier. When something looks wrong, you inspect the Network tab and see exactly what HTML the server sent. There is no opaque client-side state object to reverse-engineer.

What About React and Heavy Clients?

None of this means React is dead, or that SPAs are a mistake. Complex, editor-grade applications still need a thick client. Figma runs a C++ engine compiled to WebAssembly inside the browser because server round-trips would make drawing impossible. Canva manipulates the canvas at sixty frames per second with client-side geometry. Google Docs uses operational transforms to resolve editing conflicts in milliseconds. These tools are essentially desktop applications delivered through a browser tab. They are not going back to server-rendered forms.

But most software is not Figma. Most software is not a real-time graphics editor. Most software is a reporting screen, a configuration panel, a booking flow, or a content management form. For that long tail of applications, shipping hundreds of kilobytes of JavaScript framework just to toggle a modal or fetch a list of records never made much sense. The economics of the stack are shifting. We are rediscovering that the server can be close to the user thanks to the edge, and that the browser itself has grown capable enough to update fragments without a framework intermediating every byte.

The Pendulum Finds a Balance

The arc of web architecture is swinging back toward simplicity, but it is not a naive return to the nineties. The browser is becoming smarter. Features like DPU do not replace developer ingenuity; they absorb the patterns we used to implement by hand — streaming, partial updates, targeted DOM insertion — into the platform itself. HTMX gives us the vocabulary to express those behaviors without reconstructing a miniature operating system in the frontend.

You no longer have to choose between a simple architecture and a responsive user experience. You can have both. The server can drive the interface, the browser can assemble it, and the JavaScript you write can focus on genuine interactivity rather than plumbing.

For the next generation of dashboards, admin tools, and AI-powered interfaces, the smartest client might be the one that does less.