#1 - Temps réel, URLs typées, formulaires et toolchain : retour de la MadVue 2026

Le 22 mai 2026, je me suis rendu à Madrid pour la MadVue 2026, la conférence espagnole dédiée à l'écosystème Vue.js. Une journée dense, neuf talks, et une tendance de fond très claire : entre une grosse moitié orientée IA et expérience développeur et une autre consacrée aux fondations qui rendent nos applications soutenables.

Dans cette série de deux articles, je reviens sur l'ensemble des talks. En les lisant, vous aurez l'impression d'y avoir assisté.

Cet article est le premier des deux, vous pourrez retrouver chaque partie de cette série ici :

• Partie 1 - Temps réel, URLs typées, formulaires et toolchain
• Partie 2 - Module Federation et Vue à l'ère de l'IA

Dans ce premier article, on pose les fondations d'une application Vue moderne : on verra comment faire du temps réel proprement, comment en finir avec le parsing manuel des paramètres d'URL, un tout nouveau modèle pour construire ses composants de formulaire, l'avènement d'une toolchain JavaScript unifiée (Oxc, Rolldown), et ce qui nous attend avec Nuxt 5.

Beaucoup de sujets à traiter, alors c'est parti !

Sommaire

• Comment faire du temps réel avec Vue ? - Nico Devs
• Et si l'URL devenait typée de bout en bout ? - Eduardo San Martin Morote
• Un nouveau modèle pour les formulaires en Vue ? - Abdelrahman Awad
• Vers une toolchain JavaScript unifiée : Oxc et Rolldown - Élise Patrikainen
• Que nous réserve Nuxt après la v4 ? - Daniel Roe

Comment faire du temps réel avec Vue ? Nico Devs

Pour ouvrir, Nico Devs nous propose un tour d'horizon très pragmatique des quatre façons de faire du temps réel en Vue, de la plus simple à la plus exotique, avec surtout une réponse à la question qui compte : quand utiliser quoi ?

Le polling, à éviter. On interroge le serveur en boucle, à intervalle régulier. Le souci, c'est que ce n'est jamais vraiment du temps réel, que l'ordre des réponses n'est pas garanti, et qu'on charge le serveur pour rien. À fuir, sauf cas très particulier.

Les Server-Sent Events (SSE). Une connexion HTTP classique qui reste ouverte, mais unidirectionnelle : seul le serveur pousse vers le client. C'est parfait pour un flux de notifications, une progression, un live de scores. Bonne nouvelle : côté serveur, c'est built-in dans Nuxt grâce à Nitro, et côté client on a useEventSource de VueUse. Cerise sur le gâteau, la reconnexion automatique est gérée : le client retente après un délai et renvoie un header last-event-id pour reprendre là où il s'était arrêté.

Les WebSockets. Cette fois la connexion est bidirectionnelle : client et serveur s'envoient des messages dans les deux sens. C'est le choix pour un chat, un éditeur collaboratif, un jeu. Là encore Nitro propose ça nativement côté serveur, et VueUse fournit useWebSocket côté client, avec reconnexion et heartbeat gérés. Si on ne veut pas l'héberger soi-même, des services comme Socket.io ou Pusher existent, et les real-time databases comme Supabase (via son module Nuxt) ou Firebase (via VueFire) embarquent ce mécanisme.

Le WebRTC. Le plus exotique : de la communication pair-à-pair, sans serveur au milieu. On le choisit pour trois raisons précises :

• la latence : le serveur peut être loin, les pairs non.
• la confidentialité : les données restent entre les utilisateurs.
• le coût : pas de bande passante serveur, idéal pour de l'audio/vidéo.

La mécanique est un peu plus velue (découverte des codecs, échange de SDP via un serveur avant de passer en P2P), mais la librairie PeerJS fait disparaître l'essentiel du boilerplate.

Enfin, Nico nous ouvre une porte vers l'horizon : le Local-First. Les applications collaboratives de demain devront fonctionner hors ligne, avec les données stockées sur l'appareil de l'utilisateur et synchronisées sans conflit. La brique magique pour ça s'appelle les CRDTs, avec des librairies comme Yjs, Automerge ou Jazz.

Et si l'URL devenait typée de bout en bout ? Eduardo San Martin Morote

Eduardo San Martin Morote, mainteneur de Vue Router et de Pinia, nous rappelle une vérité qu'on oublie trop souvent : l'URL, c'est de l'état. Et pas n'importe lequel, de l'état partageable, bookmarkable, indexable par Google. Elle se découpe en trois :

• le path identifie la ressource.
• la query (les ?tri=date&page=2) porte les filtres, le tri, la pagination.
• le hash porte un état purement côté client.

Le problème, c'est qu'une URL n'est jamais qu'une chaîne de caractères. Les path params sont aujourd'hui typables grâce à vue-router/auto-routes. Mais les query params, eux, c'est encore le far west : non typés, mal matchés, et validés à la main avec du code bruyant qu'on réécrit sur chaque page.

La solution qu'Eduardo nous présente, ce sont les Vue Router Resolvers et leurs param parsers. Plus besoin d'adapter toutes ses routes : on active les param parsers sur le routeur expérimental, on déclare ses paramètres, et on peut même écrire ses parsers personnalisés. Le routeur se charge de transformer la string d'URL en données typées et validées.

Au passage, Eduardo insiste sur une distinction de philosophie entre les deux :

• Les path params sont stricts : si le paramètre est invalide, la page ne s'affiche pas (404).
• Les query params sont résilients : la page s'affiche toujours, avec des valeurs par défaut valides si le paramètre est absent ou farfelu.

Quelques rappels utiles glissés dans le talk : une URL doit rester sous les ~2 000 caractères pour la compatibilité entre navigateurs, une URL = une page côté SEO, et il faut soigner ses URLs canoniques en retirant les paramètres purement cosmétiques tout en gardant ceux qui sont signifiants.

Un nouveau modèle pour les formulaires en Vue ? Abdelrahman Awad

Abdelrahman Awad, l'auteur de vee-validate, vient présenter son nouveau projet : Formwerk. Et son constat de départ fait mouche : nos pauvres <input> sont devenus de véritables machines à états. L'accessibilité est rajoutée après coup, les champs conditionnels cassent tout en silence, le support RTL est un cauchemar, et le mot « headless » est galvaudé : la plupart des libs dites headless ont encore une « tête » bien à elles.

Il replace les solutions actuelles sur un axe, du plus headless au plus headful : vuelidate (validation pure), VeeValidate, puis FormKit. Et il montre ce que chacune nous laisse sur les bras :

• Les validateurs purs résolvent le schéma… mais le template, l'a11y et l'i18n restent à votre charge.
• Les UI kits sont jolis, mais le comportement est verrouillé : personnaliser revient à se battre contre la lib.
• Les schema builders génèrent les formulaires depuis du JSON : pratique, jusqu'au moment où vous sortez du DSL et devez tout reconstruire.
• Le « headless » à base de slots finit toujours par fuiter ses hypothèses de template.

La proposition de Formwerk, c'est un composable : useField(props). L'idée est de confier au « cerveau » de la lib les quatre préoccupations pénibles, et de vous laisser 100 % de votre template :

« Four concerns handled. Markup stays yours. »

Pourquoi un composable plutôt qu'un composant avec des slots ? Parce qu'avec un composant à slots, vous héritez d'un arbre HTML que vous n'avez pas écrit, et la forme du slot devient le contrat… et la prison. Un composable qui renvoie des props, lui, ne vous impose aucun arbre : il ne vous donne que des données à spread sur les éléments de votre choix. L'accessibilité, par exemple, sort directement dans les props (aria-labelledby, aria-describedby, aria-invalid, aria-required, role) : un output, pas un contrat ARIA à mémoriser.

Le plus beau, c'est la réutilisation jusqu'au bout de la chaîne. Les champs complexes sont composés de primitives plus petites, partagées entre eux :

• useNumberField = useSpinButton + useNumberParser + useInputValidity + useVModelProxy + useLocale.
• useDateField orchestre des segments de date qui réutilisent… le même useNumberParser que les champs numériques.
• useSlider partage useSpinButton avec useNumberField : même incrément, contrôle visuel différent.

Résultat : un seul et même modèle couvre Text, Number, Radio, Checkbox, ComboBox, Select, Sliders, Switches, Search, Date, Calendars, Time, File, OTP… Les démos qui m'ont marqué : un calendrier qui s'adapte tout seul aux différents systèmes de calendrier et formats de date selon la locale, et un champ fichier avec drop zone où c'est vous qui contrôlez l'aperçu du fichier.

Vers une toolchain JavaScript unifiée : Oxc et Rolldown — Élise Patrikainen

Changement de registre avec Élise Patrikainen, Frontend Architect, qui est venue défricher pour nous la toolchain de VoidZero. Le point de départ : JavaScript a 31 ans, et son écosystème d'outils a grandi en silos. Ces outils n'ont jamais été conçus pour fonctionner ensemble, d'où un manque d'optimisation et des incohérences. Vite lui-même reposait jusqu'ici sur trois bundlers/compilateurs différents (esbuild, Rollup, SWC), avec à la clé de la complexité et des divergences entre le dev et la prod. esbuild, par exemple, est très rapide (écrit en Go) mais offre un contrôle limité sur le découpage des chunks et le tree-shaking, et une flexibilité de plugins réduite.

Deux options pour s'en sortir : ne plus bundler du tout (ESM natif + HTTP/2, mais c'est coûteux en requêtes), ou… fabriquer ses propres outils. C'est le pari de VoidZero, avec une toolchain cohérente :

• Oxc (JavaScript Oxidation Compiler) : une collection d'outils haute performance écrits en Rust — oxc-minify, oxc-transform, oxc-resolver pour le build, oxlint et oxfmt pour le lint et le format, le tout reposant sur un socle commun, oxc-parser.
• Rolldown : un bundler en Rust, lui aussi bâti sur la toolchain Oxc.

Et ce n'est pas que de la théorie : Turborepo est déjà passé sur oxlint et oxfmt, et Hugging Face comme Lichess les utilisent en production. La mantra de l'équipe résume bien la philosophie :

« JS/TS developers must have control of their tools. »

C'est pour ça que les plugins restent écrits en JavaScript (et non en Rust), grâce à des astuces comme le raw transfer (on saute la sérialisation standard) et la lazy deserialization. Côté intégration, Rolldown arrive dans Vite 8 sous forme d'un mode bundle en dev (encore expérimental), et un futur Vite+ ajoutera un task runner de monorepo avec mise en cache des tâches.

Que nous réserve Nuxt après la v4 ? Daniel Roe

Daniel Roe, à la tête de l'équipe Nuxt, vient parler de la suite. Et il commence par un pas de côté salutaire : avec plus de 1 000 contributeurs, Nuxt est avant tout une affaire de personnes. Sa formule, à l'heure où tout le monde parle d'agents : « CONTRIBUTORS.md > AGENTS.md ». On ne construit pas une communauté avec des LLMs. Les principes du projet restent human-empowering, evidence-based, et experimentation > perfection.

Côté technique, Nuxt 4.5 est un palier mineur mais utile : named views, noms d'environnements, forward preload hints, app.baseURL relatif, passage à unhead v2 et rspack v2, et une consommation mémoire réduite en dev.

Mais le gros morceau, c'est Nuxt 5 et son concept de Progressive JS :

Choisir la stratégie de rendu la moins coûteuse qui fonctionne : statique, islands (server components), Vapor, vDOM…

Comment Nuxt décide ? Par une analyse à la compilation de chaque composant et des heuristiques, avec un opt-out possible composant par composant. S'ajoutent une meilleure intégration de Nitro et l'adoption de la Vite Environment API (un seul serveur de dev, des graphes de modules par environnement), qui réduit encore l'écart entre dev et prod.

À l'horizon : Nuxt comme plugin Vite (expérimental), Module Federation pour Nuxt (on en reparle dans la partie 2 !) et du typed everything. Enfin, Nuxt s'allège par défaut en retirant un paquet de dépendances historiques (dotenv, jiti, citty, cssnano, autoprefixer…), et le prefetch des liens se fait désormais à l'interaction plutôt que dès qu'un lien entre dans le viewport. La sortie dépendra de Nitro v3 et d'une couche de compatibilité pour une montée de version en douceur.

Merci d'avoir lu cette première partie de mon retour sur la MadVue 2026 ! On y a posé les fondations d'une application Vue moderne : temps réel, routing typé, formulaires, toolchain et framework.

Dans la seconde partie, on change d'échelle et d'époque : on verra comment partager des composants entre plusieurs applications Vue avec Module Federation, puis trois talks consacrés à Vue et l'IA — des interfaces générées en direct par un LLM jusqu'à la façon d'apprendre notre métier à l'ère des agents. C'est juste ici : Partie 2 - Module Federation et Vue à l'ère de l'IA.