Ce qui est arrivé au frontend pendant que vous ne regardiez pas

kciter1 · 2026-07-20T02:12:58+09:00

Un article qui explique les changements des 20 dernières années aux développeurs ayant quitté le frontend vers 2008 Sa thèse générale : tous les outils sont du tissu cicatriciel formé sur de vrais problèmes (des blessures), et les solutions de chaque couche ont créé les problèmes de la couche suivante, en s’empilant les unes sur les autres Tout au long de l’article, un simple sert d’échantillon pour suivre la façon dont les boutons ont évolué à chaque époque Layer I — jQuery (2006–2010) Tout est parti du besoin de modifier seulement une partie d’une page sans la recharger entièrement jQuery a gommé les différences entre navigateurs et popularisé AJAX, mais les données se sont retrouvées à la fois dans des variables JS et à l’écran, ce qui a créé le problème de devoir les synchroniser manuellement Cette manipulation manuelle du DOM est le « péché originel » que toutes les couches suivantes tenteront de résoudre Layer II — frameworks (2010–2015) UI déclarative : au lieu de décrire la procédure de mise à jour de l’écran, on décrit l’apparence de l’écran en fonction des données, et le framework se charge des mises à jour React a dominé cette période avec composants + JSX + Virtual DOM, suivi par Vue/Angular/Svelte/Solid Aujourd’hui, tous les frameworks convergent vers le concept de signal, qui suit les dépendances pour ne mettre à jour que ce qui est nécessaire Il existe aussi un camp qui revient à l’envoi de HTML depuis le serveur, avec htmx, Alpine.js, Hotwire, etc. Layer III — build (2012–2018) Comme JS n’avait pas de système de modules, CommonJS et ES Modules se sont affrontés ; pour assurer la compatibilité avec les anciens navigateurs, la transpilation avec Babel et le bundling avec webpack sont devenus nécessaires Le build inclut la minification, le tree-shaking, le découpage du code et la génération de source maps En contrepartie, node_modules est apparu, et même un projet de démarrage vide installe environ 250 000 fichiers Layer IV — course à l’outillage (2018–2024) Une époque où l’on a résolu les builds lents et la complexité de configuration de webpack en réécrivant les outils en Go/Rust esbuild (Go) a rendu le bundling 10 à 100 fois plus rapide, et SWC (Rust) a remplacé Babel Vite s’est imposé comme outil par défaut, tandis que le bundler de production est en cours de remplacement par Rolldown, basé sur Rust ; la stack associée est en train d’être consolidée sous VoidZero (récemment acquis par Cloudflare) Les gestionnaires de paquets suivent la même tendance, avec pnpm, Bun, etc. Layer V — le retour du rendu serveur (2014–2026) Dans une SPA, le serveur n’envoie qu’une div vide, ce qui provoquait un écran vide au chargement initial et une page vide du point de vue des moteurs de recherche La solution consiste à rendre de nouveau le HTML côté serveur, un retour à la méthode de 2008 SSR (rendu à chaque requête), SSG (prérendu au moment du build) et ISR (SSG mis à jour automatiquement) sont apparus, pris en charge par des méta-frameworks comme Next.js, Astro, SvelteKit et Nuxt Le coût de l’hydration, qui consiste à « réanimer » le HTML serveur dans le navigateur, est devenu un nouveau problème ; Islands (Astro), Resumability (Qwik) et React Server Components sont apparus comme moyens de réduire cette hydration Layer VI — outils d’ingénierie (2015–2026) TypeScript a apporté la stabilité du refactoring grâce à son système de types et est devenu de fait un standard Tailwind a imposé le styling par classes utilitaires, tandis que le CSS natif a lui aussi progressé avec le nesting, les variables, les container queries, etc., réduisant le besoin d’outillage existant shadcn/ui a popularisé l’idée de copier et posséder le code source des composants plutôt que de les installer, tandis que TanStack Query, Zustand, Zod, Vitest et Playwright constituent le vocabulaire de base d’une application en 2026 Layer VII — déploiement (2015–2026) Au lieu d’uploader via FTP, on connecte un dépôt Git à Vercel/Netlify/Cloudflare : chaque push déclenche automatiquement build et déploiement, et chaque PR génère une URL de prévisualisation live Les concepts de fonctions serverless et d’edge (exécution du code dans des centaines de datacenters proches des utilisateurs) se sont imposés Layer VIII — IA (2023–2026) En décrivant en langage naturel ce que l’on veut à v0, Lovable ou Bolt, on obtient un frontend fonctionnel, tandis que Cursor, Claude Code et Copilot écrivent le code à votre place Les ingénieurs backend/systèmes peuvent désormais créer un frontend en une journée, ce qui brouille les frontières entre disciplines d’ingénierie Mais le code généré suppose de connaître les 8 couches ci-dessus, et l’objectif de l’article est de combler cet écart Bedrock — conclusion En 2026, la direction de pointe consiste à rendre le HTML sur le serveur, à envoyer très peu de JS et à tirer parti de la plateforme Web L’article conclut qu’après avoir décrit un grand cercle pendant 20 ans, l’industrie est revenue à un point qui ressemble aux fichiers que l’on mettait en ligne par FTP

Un article qui explique les changements des 20 dernières années aux développeurs ayant quitté le frontend vers 2008
Sa thèse générale : tous les outils sont du tissu cicatriciel formé sur de vrais problèmes (des blessures), et les solutions de chaque couche ont créé les problèmes de la couche suivante, en s’empilant les unes sur les autres
Tout au long de l’article, un simple <button> sert d’échantillon pour suivre la façon dont les boutons ont évolué à chaque époque

Layer I — jQuery (2006–2010)
- Tout est parti du besoin de modifier seulement une partie d’une page sans la recharger entièrement
- jQuery a gommé les différences entre navigateurs et popularisé AJAX, mais les données se sont retrouvées à la fois dans des variables JS et à l’écran, ce qui a créé le problème de devoir les synchroniser manuellement
- Cette manipulation manuelle du DOM est le « péché originel » que toutes les couches suivantes tenteront de résoudre
Layer II — frameworks (2010–2015)
- UI déclarative : au lieu de décrire la procédure de mise à jour de l’écran, on décrit l’apparence de l’écran en fonction des données, et le framework se charge des mises à jour
- React a dominé cette période avec composants + JSX + Virtual DOM, suivi par Vue/Angular/Svelte/Solid
- Aujourd’hui, tous les frameworks convergent vers le concept de signal, qui suit les dépendances pour ne mettre à jour que ce qui est nécessaire
- Il existe aussi un camp qui revient à l’envoi de HTML depuis le serveur, avec htmx, Alpine.js, Hotwire, etc.
Layer III — build (2012–2018)
- Comme JS n’avait pas de système de modules, CommonJS et ES Modules se sont affrontés ; pour assurer la compatibilité avec les anciens navigateurs, la transpilation avec Babel et le bundling avec webpack sont devenus nécessaires
- Le build inclut la minification, le tree-shaking, le découpage du code et la génération de source maps
- En contrepartie, node_modules est apparu, et même un projet de démarrage vide installe environ 250 000 fichiers
Layer IV — course à l’outillage (2018–2024)
- Une époque où l’on a résolu les builds lents et la complexité de configuration de webpack en réécrivant les outils en Go/Rust
- esbuild (Go) a rendu le bundling 10 à 100 fois plus rapide, et SWC (Rust) a remplacé Babel
- Vite s’est imposé comme outil par défaut, tandis que le bundler de production est en cours de remplacement par Rolldown, basé sur Rust ; la stack associée est en train d’être consolidée sous VoidZero (récemment acquis par Cloudflare)
- Les gestionnaires de paquets suivent la même tendance, avec pnpm, Bun, etc.
Layer V — le retour du rendu serveur (2014–2026)
- Dans une SPA, le serveur n’envoie qu’une div vide, ce qui provoquait un écran vide au chargement initial et une page vide du point de vue des moteurs de recherche
- La solution consiste à rendre de nouveau le HTML côté serveur, un retour à la méthode de 2008
- SSR (rendu à chaque requête), SSG (prérendu au moment du build) et ISR (SSG mis à jour automatiquement) sont apparus, pris en charge par des méta-frameworks comme Next.js, Astro, SvelteKit et Nuxt
- Le coût de l’hydration, qui consiste à « réanimer » le HTML serveur dans le navigateur, est devenu un nouveau problème ; Islands (Astro), Resumability (Qwik) et React Server Components sont apparus comme moyens de réduire cette hydration
Layer VI — outils d’ingénierie (2015–2026)
- TypeScript a apporté la stabilité du refactoring grâce à son système de types et est devenu de fait un standard
- Tailwind a imposé le styling par classes utilitaires, tandis que le CSS natif a lui aussi progressé avec le nesting, les variables, les container queries, etc., réduisant le besoin d’outillage existant
- shadcn/ui a popularisé l’idée de copier et posséder le code source des composants plutôt que de les installer, tandis que TanStack Query, Zustand, Zod, Vitest et Playwright constituent le vocabulaire de base d’une application en 2026
Layer VII — déploiement (2015–2026)
- Au lieu d’uploader via FTP, on connecte un dépôt Git à Vercel/Netlify/Cloudflare : chaque push déclenche automatiquement build et déploiement, et chaque PR génère une URL de prévisualisation live
- Les concepts de fonctions serverless et d’edge (exécution du code dans des centaines de datacenters proches des utilisateurs) se sont imposés
Layer VIII — IA (2023–2026)
- En décrivant en langage naturel ce que l’on veut à v0, Lovable ou Bolt, on obtient un frontend fonctionnel, tandis que Cursor, Claude Code et Copilot écrivent le code à votre place
- Les ingénieurs backend/systèmes peuvent désormais créer un frontend en une journée, ce qui brouille les frontières entre disciplines d’ingénierie
- Mais le code généré suppose de connaître les 8 couches ci-dessus, et l’objectif de l’article est de combler cet écart
Bedrock — conclusion
- En 2026, la direction de pointe consiste à rendre le HTML sur le serveur, à envoyer très peu de JS et à tirer parti de la plateforme Web
- L’article conclut qu’après avoir décrit un grand cercle pendant 20 ans, l’industrie est revenue à un point qui ressemble aux fichiers que l’on mettait en ligne par FTP

Ce qui est arrivé au frontend pendant que vous ne regardiez pas

À lire aussi

4 commentaires