30 ans du web racontés à travers la balise `<br>`

• Un article qui retrace comment le développement web a évolué, du web statique des années 1990 au web centré sur JavaScript des années 2010, jusqu’au web de l’ère de l’IA dans les années 2020
• Le web, qui a commencé avec la balise <br> et le FTP, s’est rapidement étendu via PHP et MySQL pour devenir une plateforme que tout le monde peut créer
• À partir de Rails, Git et Heroku dans les années 2000, le développement web s’est réorganisé en une industrie structurée, automatisée et centrée sur la collaboration, posant les bases de l’ère du cloud et du mobile
• Dans les années 2010, l’arrivée de React, des build chains, de Docker et de l’écosystème Node a installé le web non plus comme un ensemble de documents, mais comme une véritable plateforme applicative
• Dans les années 2020, ChatGPT et Copilot ont changé la manière d’écrire du code, marquant un nouveau tournant où l’IA démultiplie la productivité du développement
• Tous ces changements, au prix d’une complexité accrue, ont conduit à un processus de démocratisation du web permettant à davantage de personnes de construire des choses plus ambitieuses

---

The Static Web - l’ère du web statique

> "View Source was how you learned"

• À la fin des années 1990 (late 90s), le web était une terre pionnière dont personne ne savait vraiment ce qu’elle deviendrait, et cette incertitude même faisait partie de son attrait
• Les sites personnels ne commençaient pas au sein d’une entreprise ou d’une organisation, mais à l’échelle d’un serveur personnel et de simples dossiers
  • Avec un répertoire personnel sur un serveur Unix, des fichiers HTML et un client FTP, on pouvait déjà avoir son propre espace sur Internet
  • Il était possible d’écrire avec un simple éditeur de texte comme Notepad et de publier immédiatement
• Le web de cette époque était un espace de création sans censeurs ni procédures d’approbation
  • On y publiait librement autour de ses centres d’intérêt : cuisine, dinosaures, chansons, etc.
  • Une structure qui permettait de mettre en ligne immédiatement « ce qui vous intéressait cette semaine »
• L’apprentissage reposait entièrement sur une méthode d’observation et d’imitation directe
  • Les tutoriels YouTube et Stack Overflow n’existaient pas
  • Quand un autre site intriguait, clic droit → View Source était l’outil d’apprentissage par défaut
  • Pour aller plus loin, on apprenait dans de vrais livres papier
• Il était courant d’apprendre avec de gros ouvrages techniques de plusieurs centaines de pages comme Core Java, en alternant entre le code et le livre
  • Une expérience d’apprentissage lente, mais dont les connaissances restaient durablement
• Le HTML mélangeait structure et style
  • Les balises <table>, <font>, <center> servaient à la fois à la mise en page et au style
  • On ajustait les espacements avec des GIF transparents 1x1 (spacer GIF)
  • C’était brut et inefficace, mais ça fonctionnait
• Le CSS existait, mais n’était de fait pas dominant
  • La plupart des styles étaient gérés via des attributs inline ou directement par les balises HTML
  • La mise en page se faisait avec des tableaux imbriqués
• Les fonctionnalités dynamiques avaient une barrière d’entrée extrêmement élevée
  • Même des fonctions de base comme un livre d’or ou un compteur de visites nécessitaient des scripts CGI
  • Il fallait les écrire en Perl ou en C, et traiter ne serait-ce qu’un seul paramètre d’URL demandait déjà beaucoup de code
  • Cette complexité a fortement limité la diffusion du web dynamique
• Le problème des layouts communs avait très peu de solutions
  • Il fallait copier-coller le header, la navigation et le footer dans chaque fichier HTML
  • Au moindre changement, il fallait modifier tous les fichiers
  • Il existait aussi une méthode consistant à insérer des éléments communs avec <iframe>, mais avec de nombreux effets de bord
• La compatibilité navigateur était déjà un problème majeur
  • Netscape Navigator (1994) et Internet Explorer (1995) produisaient des rendus différents
  • Il fallait réellement afficher des avertissements indiquant le navigateur et la résolution recommandés
• Malgré cela, le web de cette époque exerçait une forte attraction
  • Il permettait de publier au monde entier sans équipement d’impression ni de diffusion
  • Le web concrétisait pour la première fois la démocratisation des moyens d’expression
• Des services d’hébergement gratuits comme GeoCities (1994) et Angelfire (1996) ont offert un espace de création à des millions de personnes
  • Les sites de fans et les communautés se reliaient via des web rings
  • Un écosystème chaotique, mais vivant, s’est ainsi formé
• Dans les entreprises, la notion même d’« équipe web » n’existait presque pas encore
  • Quand un site web existait, il avait le plus souvent été créé par « la personne qui s’y connaissait en informatique »
  • C’était l’étape juste avant que le développeur web ne s’impose comme un métier
• Les outils étaient rudimentaires et les sites maladroits, mais
  • l’idée fondamentale d’un espace que tout le monde peut créer et partager s’est enracinée à cette époque
• Cette époque, portée à bout de bras par la balise <br> et la passion, a constitué le point de départ de toute l’évolution ultérieure du web

La pile LAMP et le Web 2.0

"Everything was PHP and MySQL"

• Même après l’éclatement de la bulle Internet en 2000, le web a continué à croître, et cette période a marqué un tournant où la barrière à l’entrée a brutalement baissé pour celles et ceux qui voulaient créer quelque chose
• La plus grande percée de l’ère du web statique a été PHP (1995)
  • À une époque où il fallait écrire des centaines de lignes en C ou en Perl pour le CGI, pouvoir lire un paramètre d’URL avec une seule ligne comme $_GET['name'] a constitué un changement décisif
  • Sans compilation, sans gestion de la mémoire, sans messages d’erreur obscurs : on enregistrait, on rafraîchissait, et ça fonctionnait
  • XAMPP (2002) a radicalement simplifié la mise en place d’un environnement de développement local en permettant d’installer Apache, MySQL et PHP d’un seul coup
  • PHP a été le premier à vraiment résoudre le problème de la réutilisation des layouts hérité de l’ère du web statique
    • Une seule ligne, include 'header.php', permettait de gérer des en-têtes et pieds de page communs
    • L’expérience de modifier une fois pour voir toute une série de pages changer suscitait un véritable enthousiasme
  • Malgré ses défauts de langage, la force de PHP résidait dans son accessibilité
    • Même si le HTML et la logique s’y mélangeaient, que les noms de fonctions manquaient de cohérence et que les API de sécurité étaient rudimentaires
    • On pouvait l’apprendre en un week-end et créer un vrai service
    • Avec l’hébergement mutualisé (5 $/mois), cPanel (1996) et phpMyAdmin (1998) fournis par défaut, la barrière d’entrée pour se lancer en ligne est devenue historiquement basse
• La base de données qui allait de fait avec PHP était MySQL (1995)
  • Presque tous les tutoriels, hébergeurs et CMS étaient conçus en partant de MySQL
  • Fonctionnellement, c’était suffisant, mais pour le traitement des textes internationalisés, c’était une suite ininterrompue de souffrances
  • L’encodage par défaut était latin1, et pour utiliser correctement l’UTF-8, il fallait
    • aligner la configuration de la base de données, l’encodage de la connexion et la déclaration du charset HTML
  • Le problème du « ä au lieu de ä » est resté comme un traumatisme emblématique de cette époque
• WordPress (2003) a transformé la nature même du web
  • Même sans savoir coder, il suffisait d’une installation de 5 minutes pour publier immédiatement
  • Il était possible de faire vivre un site simplement en choisissant un thème et en écrivant des articles
  • Il a concrètement rendu possible la démocratisation de la création de sites web
  • Pour les utilisateurs non techniques, WordPress a été une forme de libération
    • Blogueurs, petits commerçants, artistes, restaurants : tout le monde pouvait désormais avoir un site web
    • Une nouvelle identité, celle de « blogueur », est apparue
    • Son interface d’administration s’est diffusée au point d’être perçue comme l’« éditeur de site web » par excellence
  • Pour les développeurs, WordPress est devenu un outil presque universel
    • Blog, portfolio, site d’entreprise, communauté, e-commerce : tout passait par WordPress
    • Avec WooCommerce (2011), il a aussi absorbé l’e-commerce
    • En contrepartie de la rapidité d’implémentation, les plugins proliféraient et une dette technique fondée sur la personnalisation des thèmes s’accumulait
• L’événement qui a fondamentalement redéfini les possibilités du web a été le lancement de Gmail (2004)
  • À l’époque où Hotmail et Yahoo Mail n’offraient que quelques Mo de stockage
  • 1 Go de stockage gratuit a été un chiffre sidérant
  • Le message « ne supprimez pas, recherchez » proposait une nouvelle manière d’utiliser le mail
  • La véritable innovation de Gmail n’était pas le stockage, mais l’expérience
    • Une interface permettant de lire, rédiger et changer de message sans recharger la page
    • Un recours massif aux communications asynchrones basées sur AJAX (XMLHttpRequest)
    • La preuve que le web pouvait devenir non pas un document, mais une application
• Google Maps (2005) a poussé cette possibilité encore plus loin
  • Déplacement de la carte par clic et glisser-déposer
  • Interaction naturelle avec chargement des tuiles en arrière-plan
  • C’est à ce moment-là que le terme Web 2.0 s’est véritablement imposé
  • Interface sans rafraîchissement, coins arrondis, dégradés et ombres sont devenus le langage de base du web
• Des changements décisifs ont aussi suivi dans les médias et le social
  • Côté vidéo, YouTube (2005) a bouleversé le paysage
    • Fin de l’enfer des plugins comme RealPlayer, QuickTime ou Windows Media Player
    • Basé sur Flash, certes, mais avec une expérience où « on clique et ça lit tout de suite »
    • La vidéo n’était plus un problème technique, mais un moyen d’expression
  • Twitter (2006) a introduit une nouvelle manière de communiquer avec le microblogging en 140 caractères
  • Facebook (2006) s’est ouvert au grand public, faisant basculer les réseaux sociaux dans le courant dominant
  • Le web est passé d’un média de consommation à une plateforme participative
    • Une structure dans laquelle chacun pouvait devenir à la fois éditeur et créateur
• Malgré tous ces changements, JavaScript restait toujours pénible
  • Débogage sans fin à cause des différences d’implémentation du DOM, des événements et d’AJAX entre navigateurs, ainsi que des problèmes de compatibilité avec IE6
  • jQuery (2006) a pratiquement mis fin à ce chaos
    • $('#el').hide() fonctionnait de la même manière dans tous les navigateurs
    • $.ajax() simplifiait les communications asynchrones
    • Pour beaucoup de développeurs, jQuery était en pratique JavaScript lui-même
      • En même temps, il jouait aussi un rôle de couche tampon qui évitait d’avoir à comprendre directement le fonctionnement des navigateurs
  • Les problèmes de cette époque n’ont été reconnus comme tels que plus tard
    • SQL Injection et XSS étaient omniprésents jusque dans les tutoriels
    • Du code reliant directement les entrées utilisateur aux requêtes était courant
• En gestion de versions, Subversion (2000) dominait
  • Les commits étaient lourds et les branches mal vues
  • Des noms de dossiers comme final_final_REAL faisaient partie du quotidien
• Absence de standardisation des environnements d’exécution
  • En local : Windows + XAMPP
  • En serveur : Linux + une autre version de PHP
  • Le « works on my machine » se répétait sans cesse
• La notion même de gestionnaire de paquets était absente
  • En JS, on téléchargeait des ZIP puis on les gérait à la main dans le dossier /js
  • Les bibliothèques PHP reposaient sur la copie de fichiers
• La structure des équipes et les processus de développement étaient très informels
  • Presque pas de rôles de PM ou d’EM
  • Pas de code review
  • Mise en production directement après upload par FTP
  • En cas d’incident, on corrigeait à chaud directement sur le serveur de production
• Malgré cela, l’énergie de cette époque était intense
  • Avec PHP et un hébergement bon marché, n’importe qui pouvait déployer
  • L’idée qu’avec AJAX, on pouvait créer de “vraies apps” s’est largement diffusée
  • Avec les plateformes sociales, tout le monde pouvait avoir une audience
• C’est le moment où la professionnalisation et la structuration du développement web commencent tout juste
  • Ruby on Rails (2004), avec « Convention over Configuration », annonçait l’époque suivante, plus structurée
• Les développeurs de cette période construisaient le web avec la pile LAMP, des plugins jQuery et,
  • avec l’attente de « créer le prochain grand service »

La guerre des frameworks

"Rails changed everything, then everyone copied it"

• Fin des années 2000 (late 2000s) : à mesure que les applications web prenaient de l’ampleur, les scripts PHP traditionnels et les structures centrées sur le travail manuel atteignaient leurs limites

• La réponse de cette époque a été l’essor du développement centré sur les frameworks, et l’acteur qui a défini ce mouvement fut Ruby on Rails (2004)

  • L’influence réelle de RoR a vraiment commencé à se faire sentir vers 2007–2008
  • Avec la philosophie « Convention over Configuration », le framework décidait à la place du développeur de la structure des fichiers, du nommage et des connexions
  • Les développeurs n’avaient plus qu’à suivre les règles, et cela a été perçu non comme une contrainte, mais comme une libération qui faisait gagner en vitesse

• Rails a ensuite présenté d’un seul coup tout un ensemble de concepts devenus la grammaire de base du développement web

  • Les migrations pour gérer les changements de base de données dans le code
  • Un ORM réduisant fortement la dépendance au SQL
  • Un flux de développement avec les tests inclus par défaut
  • La standardisation concrète de l’architecture MVC (Model–View–Controller)
  • MVC était un concept issu du Smalltalk des années 1970, mais c’est via Rails qu’il s’est imposé comme forme de base du développement web
  • Après le succès de Rails, presque tous les écosystèmes de langage ont repris cette formule
    • Django (2005) en Python et Laravel (2011) en PHP ont installé une structure à la Rails dans leurs écosystèmes respectifs
    • CakePHP (2005) et CodeIgniter (2006) se sont eux aussi développés dans la même dynamique
  • Le gain de productivité n’avait rien d’exagéré
    • Ce qu’un développeur solo pouvait construire en un week-end relevait autrefois du travail d’une équipe
    • Dans l’environnement startup, c’était l’outil idéal pour expérimenter et itérer rapidement
  • Plusieurs services emblématiques ont effectivement grandi sur Rails
    • Basecamp (2004), Twitter (2006), GitHub (2008), Shopify (2006), Airbnb (2008)
    • Rails a vite été perçu comme un symbole de la vitesse des startups

• Les frameworks ont fait bondir la productivité, mais le déploiement restait un goulet d’étranglement

  • À l’époque de PHP, le déploiement se faisait généralement par upload FTP, dans un modèle où une seule erreur pouvait casser le service
  • Même dans les meilleurs cas, il fallait gérer manuellement des opérations comme SSH + SVN pull + redémarrage d’Apache
  • Entre répertoires de release séparés et bascule de liens symboliques, tout le processus restait custom et fragile

• Ce qui a fondamentalement changé ce problème, c’est Heroku (2007), qui a commencé à se diffuser sérieusement vers 2009–2010

  • Une simple ligne git push heroku main permettait de terminer le déploiement
  • La plateforme prenait en charge la configuration serveur, le redémarrage du serveur web et le scaling
  • Heroku a ensuite imposé dans les faits le concept qui serait appelé PaaS (Platform as a Service)
    • Les développeurs sont passés d’un rôle centré sur l’infrastructure à un rôle centré uniquement sur le code
    • En popularisant les principes du Twelve-Factor App (2011), Heroku a diffusé une façon de penser cloud-friendly : processus stateless, configuration par variables d’environnement, logs en flux, etc.

• À la même époque, une transformation majeure des méthodes de collaboration était également en cours

  • Git (2005) a introduit un modèle de gestion de versions distribué permettant des commits, branches et merges libres en local ; le coût des branches devenant quasi nul, expérimenter et revenir en arrière sont devenus des gestes du quotidien
  • Le Subversion (2000) existant reposait sur une architecture centralisée, avec des branches lourdes et des merges vécus comme une source de peur, si bien que beaucoup d’équipes dépendaient d’un développement centré sur le trunk
  • Git a été une innovation au niveau de l’outil, mais c’est GitHub (2008) qui l’a transformée en culture en combinant exploration de dépôts publics, développement basé sur les forks et collaboration centrée sur les Pull Requests
  • GitHub a standardisé la culture de la code review
    • Avant de fusionner une PR, quelqu’un devait forcément relire le code
    • Cette pratique s’est ensuite diffusée au développement interne des entreprises
    • La fin d’une époque où le code partait directement en production
  • La contribution open source est passée d’un modèle où l’on envoyait des patches sur des mailing lists à un modèle où l’on soumettait une PR en cliquant sur un bouton, ce qui a fortement abaissé la barrière à l’entrée

• Dans la seconde moitié de cette période, des changements ont aussi commencé à ébranler l’identité même du web

  • Avec le lancement de l’iPhone (2007) et de l’App Store (2008), les applications natives ont connu un essor fulgurant
  • Le web mobile était alors très médiocre. On essayait de consulter de force des sites desktop réduits, en enchaînant scroll horizontal et zoom avant/arrière
    • Certains ont bien créé des sites mobiles séparés du type m.example.com, mais leurs limites étaient évidentes
  • Les applications natives étaient rapides, fonctionnaient hors ligne, proposaient des notifications push, et le slogan « There’s an app for that » leur donnait une allure de futur
  • Les développeurs web ont commencé à traverser une crise d’identité : fallait-il continuer sur le web ? Apprendre Objective-C ? Le web allait-il disparaître ?

• La réponse à ce chaos est venue avec le Responsive Web Design (2010)

  • Ethan Marcotte (2010) a proposé une approche utilisant les media queries CSS pour ajuster la mise en page selon la taille de l’écran, ouvrant la voie à l’unification du mobile et du desktop dans une seule base de code
  • Au début, l’adoption a été lente à cause d’outils encore immatures et de la charge de travail supplémentaire, mais la direction que le web devait prendre était devenue claire

• Bootstrap (2011) a été le déclencheur qui a rendu le responsive réellement utilisable sur le terrain

  • Né comme outil interne chez Twitter, il fournissait d’un coup un système de grille, une typographie de base et des styles de formulaires, offrant une UI immédiatement exploitable même aux développeurs sans designer
  • Résultat : le web a commencé à se ressembler de plus en plus, mais pour beaucoup de développeurs, Bootstrap a été à la fois leur première bibliothèque de composants et leur première expérience de design system
  • Cette dynamique a ensuite conduit à la diffusion de design systems plus structurés, comme Material Design (2014)

• L’infrastructure aussi a connu une transformation rapide à la même époque

  • On est passé d’un modèle où l’on achetait ou louait à l’avance des serveurs physiques à une structure centrée sur les serveurs virtuels (VPS), permettant de créer des ressources serveur à la demande
  • AWS (2006) est arrivé le premier, mais sa complexité et son orientation enterprise le rendaient lourd pour les développeurs indépendants
  • DigitalOcean (2011), avec ses droplets à 5 $, son UI intuitive et son expérience de création rapide de serveurs, a fortement abaissé la barrière d’accès à l’infrastructure et permis aux développeurs solo d’obtenir une flexibilité proche de celle des grandes entreprises

• Le problème du stockage de fichiers a été pratiquement résolu par Amazon S3 (2006)

  • Il offrait un stockage scalable indépendamment du nombre de serveurs, avec un modèle simple renvoyant directement une URL après l’upload
  • Les questions d’uploads utilisateurs, de sauvegarde et de gestion des fichiers dans des environnements multi-serveurs se sont trouvées réglées d’un coup

• Node.js (2009) a provoqué un autre choc chez les développeurs web

  • Basé sur le moteur V8 de Chrome, il permettait d’exécuter JavaScript côté serveur ; cela apparaissait comme une option séduisante pour les développeurs frontend, tout en suscitant des réactions sceptiques chez les backend engineers
  • Son modèle d’I/O non bloquantes montrait des forces pour les applications temps réel, et la plupart des tutoriels finissaient par prendre la forme d’une application de chat
  • À cette époque, Node relevait encore davantage de la curiosité que d’un choix dominant en production ; les services réels restaient centrés sur Rails, Django et PHP, et l’écosystème npm n’en était qu’à ses débuts
  • Mais la véritable influence de Node se révélera ensuite d’abord dans les build tools et comme base d’exécution des environnements de développement, plus que côté serveur

• Côté bases de données, la vague NoSQL a émergé

  • MongoDB (2009) a attiré l’attention avec son modèle de données orienté document, sa flexibilité de schéma et sa structure compatible JSON
  • Il avait des atouts pour le prototypage rapide, la scalabilité et l’affinité avec la stack JavaScript, mais il ne convenait pas à tous les services
  • Il était aussi fréquent qu’on le choisisse en se disant « on aura peut-être besoin de scaler un jour », avant de se heurter aux limites des transactions au stade de quelques milliers d’utilisateurs

• L’écosystème startup est alors véritablement entré dans une phase de croissance

  • Avec la déclaration « Software is eating the world » de Marc Andreessen (2011) et la diffusion de la méthode Lean Startup (2011), le cycle MVP → mesure → itération s’est imposé

• La maturité des outils a commencé à rendre réellement opérationnelle la compétitivité des petites équipes

• Le processus de développement a lui aussi évolué

  • Avec la popularisation de l’Agile Manifesto (2001) et de Scrum, les stand-up, sprints et rétrospectives ont été adoptés comme des standards
  • De nombreuses équipes n’en ont gardé que la forme, plutôt que les principes
  • Les revues de code et les tests automatisés sont passés du statut de recommandation à celui d’attente de base, et les systèmes de CI exécutaient les tests à chaque commit, accélérant la professionnalisation et la spécialisation du développement logiciel

• Cela dit, des rôles aujourd’hui considérés comme évidents n’étaient pas encore bien établis

  • En 2012, il était courant de voir des équipes sans engineering manager, product manager, ni gestion structurée du backlog ou des tickets
  • Les petites équipes et les structures organisationnelles plates étaient la norme, et il n’était pas rare qu’un « développeur senior » n’ait que trois ans d’expérience

• Vers 2013, le web avait complètement changé de visage

  • Des frameworks puissants, des déploiements faciles, la collaboration sociale autour du code, l’adaptation au mobile, une infrastructure peu coûteuse et la généralisation totale de JavaScript sont arrivés en même temps
  • Après avoir surmonté la crise du mobile, le web en est ressorti encore plus fort, prêt à entrer dans l’étape suivante : l’ère où JavaScript allait tout dominer

Renaissance de JavaScript

"Everything is a SPA now"

• Autour de 2013, le web avait déjà prouvé, avec des exemples comme Gmail et Google Maps, qu’il pouvait prendre en charge de “vraies applications”, mais l’approche traditionnelle jQuery + rendu côté serveur se heurtait de plus en plus à ses limites :contentReference[oaicite:0]{index=0}
• Le problème central était la gestion de l’état (state)
  • Dans une architecture où le serveur génère le HTML et où jQuery ajoute les interactions, il devenait rapidement très difficile de maintenir les données et l’UI de manière cohérente à plusieurs endroits
  • Plus un même état devait se refléter dans plusieurs interfaces, comme les commentaires, compteurs ou badges de notification, plus le code s’enchevêtrait jusqu’à devenir une structure spaghetti
• La conclusion commune a été de déplacer entièrement le rendu côté client
  • Le serveur était réduit à un rôle d’API renvoyant du JSON
  • Une architecture SPA (Single Page Application), dans laquelle JavaScript pilote l’ensemble de l’UI dans le navigateur, a alors émergé
• Les premiers frameworks SPA sont apparus à cette période
  • Backbone.js(2010) apportait un minimum de structure avec les concepts de modèle et de vue
  • Angular(2010) introduisait le data binding bidirectionnel et l’injection de dépendances, avec une approche orientée entreprise
  • Ember.js(2011) proposait des règles fortes avec l’ambition d’être le “Rails du JavaScript”, en intégrant routage, données et templates
  • Ces frameworks représentaient un net progrès, mais ils ne résolvaient pas totalement le problème commun de la complexité de synchronisation entre le DOM et les données
    • En particulier, le binding bidirectionnel rendait le flux des mises à jour difficile à suivre et augmentait le coût du débogage
• Le tournant a été l’arrivée de React(2013)
  • Quand Facebook l’a publié en open source, la syntaxe JSX a suscité du rejet, car elle semblait revenir en arrière sur la séparation des responsabilités
  • Mais React a introduit une nouvelle façon de penser l’interface : non pas manipuler directement le DOM, mais décrire de façon déclarative le résultat de l’UI en fonction de l’état
  • Le cœur de React repose sur le modèle déclaratif et le Virtual DOM
    • Quand l’état change, React calcule et applique uniquement le minimum de modifications nécessaires dans le DOM
    • Les développeurs peuvent ainsi se concentrer sur la gestion de l’état sans se soucier de la manipulation du DOM
  • Le concept de composant a lui aussi été déterminant
    • L’UI se construit en assemblant de petites unités comme Button, UserAvatar ou CommentList
    • Chaque composant peut être pensé indépendamment et réutilisé
  • React s’est diffusé progressivement avant de s’imposer comme courant dominant vers 2015
    • Vue.js(2014) a émergé comme alternative en proposant des concepts similaires avec une syntaxe plus familière
    • La guerre des frameworks est alors entrée dans une nouvelle phase
• L’essor des SPA a signifié une explosion de la quantité de JavaScript
  • Le problème, c’est que le JavaScript que les développeurs voulaient écrire n’était pas celui que les navigateurs comprenaient
• ES6 / ES2015(2015) a introduit d’importantes évolutions du langage, comme les fonctions fléchées, les classes, les modules et les promesses
  • Avec la disparition du callback hell et du pattern var self = this, JavaScript a enfin commencé à ressembler à un langage moderne
• Mais le support des navigateurs restait à la traîne, et un déploiement en l’état était impossible
• Babel(2014) a résolu ce problème en tant que transpileur convertissant le JavaScript moderne en ES5
  • En contrepartie, une étape de build est devenue incontournable dans le développement JavaScript
  • C’en était fini de l’époque où modifier un fichier puis recharger la page suffisait
• Dans ce processus, Node.js(2009) a conquis toutes les machines de développeurs non pas comme serveur, mais comme environnement d’exécution des outils de développement
  • Même sans utiliser Node pour le backend, son installation est devenue obligatoire à cause des outils de build
• La chaîne des outils de build a elle aussi évolué rapidement
  • Grunt(2012) permettait, en tant que task runner, de gérer des étapes de build complexes via des fichiers de configuration
  • Gulp(2013) a tenté de simplifier cela avec des pipelines définis en code, mais la complexité restait élevée
• Le changement décisif a été Webpack(2014)
  • Ce n’était pas un simple task runner, mais un module bundler capable de comprendre un graphe de dépendances
  • JavaScript, CSS, images et polices y étaient tous traités comme des modules
  • Il a introduit des concepts comme le code splitting et le hot module replacement
  • En contrepartie de sa puissance, sa configuration est devenue tristement célèbre
    • La configuration Webpack est devenue un mème, et chaque équipe avait “la seule personne qui comprenait ce truc”
    • Quand cette personne partait, la configuration restait comme un artefact qu’on n’osait plus toucher
• En parallèle, l’écosystème npm a connu une croissance explosive
  • On est passé du téléchargement manuel des bibliothèques à un fonctionnement centré sur npm install
  • moment, lodash, et même des utilitaires minuscules comme left-pad ont été empaquetés
  • L’affaire left-pad(2016) a révélé la fragilité de l’écosystème
    • La suppression d’un package de seulement 11 lignes a fait échouer simultanément les builds de milliers de projets
    • Même React et Babel sont devenus impossibles à installer
    • npm a dû restaurer de force le package, fait sans précédent, pour contenir la crise
  • La praticité est restée, mais tout le monde a alors pris conscience de la réalité de l’enfer des dépendances
• En 2016, la complexité a atteint son sommet
  • Le billet satirique “How it feels to learn JavaScript in 2016” s’est largement diffusé
  • Une fatigue s’est installée face au fait qu’il fallait React, Webpack, Babel, Redux et quantité d’autres outils pour créer une simple page web
  • L’écosystème évoluait si vite que les connaissances apprises devenaient rapidement obsolètes
  • Malgré tout, le résultat était clair
    • Il devenait possible de créer des applications web interactives à un niveau auparavant inaccessible
    • La complexité a été acceptée comme le prix de l’ambition
• De son côté, Docker(2013) a commencé à résoudre un problème totalement différent
  • Le problème du “works on my machine” a été traité grâce aux conteneurs
  • Avec un Dockerfile, il devenait possible de définir l’environnement d’exécution et de l’exécuter de la même manière partout
  • Au début, l’adoption n’a pas été simple à cause des problèmes de performances sur Mac et de la confusion réseau
    • Docker Compose, Docker Swarm, puis Kubernetes(2014) sont apparus, déclenchant la guerre de l’orchestration
    • Vers 2017, une chose au moins était claire : les conteneurs représentaient l’avenir
• En parallèle, la tendance des microservices s’est diffusée
  • Elle apportait les avantages de la séparation des services et des déploiements indépendants
  • Mais elle introduisait en échange de nouvelles complexités : service discovery, load balancing, tracing distribué, etc.
  • Beaucoup d’équipes ont réalisé trop tard qu’elles avaient simplement troqué la complexité du monolithe contre celle des systèmes distribués
• À cette époque, la qualité des applications web a nettement progressé
  • Slack(2013) a remplacé l’e-mail comme outil de collaboration rapide et interrogeable
  • Figma(2016) a empiété sur le territoire des applications desktop avec un outil de design collaboratif dans le navigateur
  • Avec Notion(2016) et d’autres, le web a prouvé qu’il pouvait offrir des logiciels de niveau desktop
  • Ces exemples ont servi de justification à la complexité de React, Webpack et de toute la chaîne de build
• La structure des organisations a elle aussi évolué vers une phase de maturité
  • Autour de 2016, les rôles de product manager et d’engineering manager se sont imposés comme standards
  • La structure initiale des équipes très plates a progressivement laissé place à des organisations plus centrées sur les processus
  • Scrum et les rituels agiles se sont largement diffusés, devenant selon les équipes tantôt des outils, tantôt un formalisme
• En 2017, l’écosystème est progressivement entré dans une phase de stabilisation
  • React était devenu le vainqueur de fait
  • ES6 était devenu la syntaxe de base
  • Webpack et Docker, bien que douloureux, étaient acceptés comme standards
• L’étape suivante était déjà annoncée
  • L’essor de TypeScript
  • Des méta-frameworks comme Next.js
  • Une expérience de déploiement plus simple
• Mais il y avait une condition préalable
  • Seuls les développeurs ayant traversé le chaos de cette renaissance de JavaScript pouvaient passer à l’étape suivante

L’ère TypeScript

"Types are good, actually"

• Après la Renaissance de JavaScript, TypeScript s’est imposé au moment charnière où la prolifération des outils s’est calmée et où l’écosystème est entré dans une phase de maturité
• TypeScript (2012) a introduit le typage statique dans JavaScript, mais a longtemps été boudé au départ en raison de la philosophie des langages dynamiques et de la charge supplémentaire liée à l’étape de build
  • À mesure que la taille des applications augmentait, les limites du typage dynamique devenaient de plus en plus évidentes
    • augmentation du coût de suivi des appels après modification de signatures de fonctions
    • problèmes de lisibilité du code, car il devenait difficile de comprendre la forme des objets
    • répétition de cas où une simple faute de frappe provoquait un incident en production
  • 2017–2018 a marqué le début d’une adoption rapide de TypeScript
    • sécurisation des refactorings grâce à l’autocomplétion et à l’analyse statique
    • les interfaces jouaient le rôle d’une documentation contrainte synchronisée avec le code
  • l’adoption par les principaux frameworks a servi de point de bascule
    • Angular a adopté une stratégie TypeScript-first
    • avec la maturité des définitions de types pour React et la réécriture de Vue 3 sur une base TypeScript, il a été perçu comme un standard de fait
    • à partir de 2020 environ, les nouveaux projets en JavaScript pur ont quasiment cessé d’être choisis
  • TypeScript a considérablement amélioré l’accessibilité des codebases
    • les nouveaux arrivants pouvaient comprendre le modèle métier rien qu’en lisant les définitions de types
    • la moindre dépendance au savoir implicite a réduit le coût d’agrandissement des équipes
• L’association avec VS Code (2015) a transformé de façon décisive l’expérience de développement
  • autocomplétion intelligente, affichage des erreurs en ligne, refactorings fiables
  • Sublime Text et Atom ont progressivement perdu de leur influence
• Une nouvelle couche d’abstraction s’est formée au-dessus de React
  • React, en tant que bibliothèque UI, n’avait pas de solution par défaut pour le routage, le data fetching ou le SSR
• Next.js a comblé ce vide en tant que meta framework fournissant nativement le routage par fichiers, le rendu côté serveur, les routes API et le code splitting automatique
  • de nombreux frameworks alternatifs sont apparus, comme Nuxt, Remix, SvelteKit ou Gatsby
  • dans l’écosystème React, Next.js s’est imposé comme le choix par défaut de fait
• La diffusion des meta frameworks a fortement atténué la fatigue liée à la fragmentation du tooling propre à l’époque précédente
  • le travail d’assemblage manuel des configurations webpack et Babel a été absorbé par les valeurs par défaut
• L’environnement de déploiement s’est lui aussi radicalement simplifié
  • Vercel et Netlify ont apporté le déploiement automatique et les environnements de preview via une simple connexion à GitHub
  • designers, PM et QA pouvaient vérifier les changements dans un environnement réel avant la fusion
• L’influence de Heroku a diminué, tandis qu’une nouvelle génération de PaaS comme Railway et Render a émergé
• Le concept de Serverless s’est diffusé autour de AWS Lambda (2014)
  • tarification à l’usage et mise à l’échelle automatique
  • ce n’était toutefois pas une solution universelle à cause des cold starts, de la gestion de l’état et des limites du débogage
  • Cloudflare Workers a étendu cela avec un modèle d’exécution en edge
• Une transition plus discrète a aussi eu lieu côté CSS
  • après Sass et Less, puis le CSS-in-JS, Tailwind CSS (2017) a été adopté à grande échelle
  • l’approche fondée sur des classes utilitaires
    • supprimait la charge du nommage des classes
    • réduisait les problèmes de cascade et de spécificité
    • et, au final, aidait à conserver des feuilles de style plus petites
• GraphQL (2015) a attiré l’attention comme solution puissante pour les applications manipulant des structures de données complexes
  • il apportait les avantages de requêtes de données précises, de schémas typés et d’un riche écosystème d’outils
  • mais la complexité ajoutée à la couche serveur et la difficulté du caching en faisaient un choix excessif pour un simple CRUD
  • certaines équipes ont donc conservé REST ou choisi des alternatives plus simples comme tRPC
• La compétition dans l’orchestration de conteneurs s’est soldée, autour de 2018, par la victoire de Kubernetes
  • puissant, mais assorti d’un coût d’apprentissage élevé et d’une grande complexité opérationnelle
  • pour beaucoup d’équipes, c’était une solution excessive, ce qui a favorisé le retour des PaaS
• COVID (2020) a fait exploser la demande en développement web
  • le télétravail, l’e-commerce et les outils de collaboration sont devenus indispensables
  • cela a entraîné une forte hausse de la demande en développeurs et la croissance rapide des entreprises d’outillage pour le développement
• Dans les environnements distants, l’importance de la collaboration asynchrone et de la documentation a grandi
  • la revue de code, les explications de PR et la qualité de la documentation interne sont devenues des éléments clés
• La maturité a aussi progressé au niveau organisationnel
  • mise en place de grilles de niveaux pour les ingénieurs
  • reconnaissance de la légitimité de la filière IC
  • différenciation des rôles de PM, EM et tech lead
• La Developer Experience (DX) a été reconnue comme un domaine d’investissement à part entière
  • les équipes de plateforme interne, la rapidité du CI et l’amélioration de l’onboarding sont devenues des leviers clés de productivité
• Vers 2022, le développement web était devenu complexe, mais gérable
  • TypeScript comme choix par défaut
  • un écosystème centré sur Next.js
  • automatisation des déploiements et outillage arrivé à maturité
• Puis tout a changé : une entreprise appelée OpenAI a lancé quelque chose nommé ChatGPT

Le moment IA

"Wait, I can just ask it to write the code?"

• Avec le lancement de ChatGPT (2022), une nouvelle expérience est apparue : il suffisait de poser une question pour obtenir des explications, du code ou des résultats de débogage, et les règles du développement ont changé
  • de l’explication de la physique quantique au débogage Python, il pouvait intervenir sur des sujets très variés, et le choc venait du fait que, sans être parfait, il était suffisamment utile pour être réellement exploitable
  • les développeurs se sont immédiatement mis à expérimenter, et écrire des composants React, analyser les causes d’erreurs ou convertir du code d’un langage à un autre est devenu possible en quelques secondes, sans fouiller la documentation ni les forums
• GitHub Copilot (2022) a généralisé dans l’éditeur une génération de code sous forme d’autocomplétion, en proposant des implémentations à partir de simples commentaires, avec une expérience d’autocomplétion surpuissante
  • la capacité à évaluer, accepter, modifier ou rejeter rapidement les suggestions de l’IA est devenue une nouvelle méta-compétence au cœur du métier de développeur
• Les tâches répétitives comme le boilerplate, l’écriture de tests ou la gestion des cas limites se sont fortement accélérées, rendant possible un développement sans rupture de flux
• Cursor (2023) a poussé plus loin l’idée avec un IDE intégrant l’IA non comme une fonctionnalité, mais comme un prérequis, permettant de sélectionner du code pour demander un refactoring, de modifier plusieurs fichiers à partir d’explications en langage naturel et de dialoguer avec la codebase
• Ce changement a bousculé le sens même de la séniorité, mais dans les faits il a surtout renforcé l’importance de la capacité à décider quoi construire et à évaluer les exigences, les contraintes et les effets de bord
  • l’IA peut écrire du code, mais elle ne sait pas définir le problème ni choisir la bonne direction
• On a vu apparaître des réactions extrêmes, allant de la « fin de la programmation » à la « mode inutile », mais le résultat réel a été une amplification de la productivité des développeurs qui utilisent l’IA
• La barrière à l’entrée pour les projets personnels et side projects a chuté brutalement, rendant accessibles via un apprentissage conversationnel des domaines auparavant peu tentés, comme le ML, le jeu vidéo ou de nouveaux frameworks
• Ce mouvement a accéléré une orientation de long terme du web : la démocratisation de la création
  • le centre de gravité s’est déplacé de la connaissance du code vers le fait de savoir ce que l’on veut créer
• Des non-développeurs se sont eux aussi mis à participer au prototypage, et PM, designers ou experts métier ont commencé à créer directement des outils, brouillant la frontière entre technique et non-technique
• Avec l’augmentation du nombre d’indie hackers et de solo builders, la perspective de pouvoir créer seul un produit réellement concret est devenue une réalité
• En parallèle, des outils et approches comme React Server Components, htmx, l’amélioration des standards CSS et JavaScript, ou encore Bun, ont renforcé le mouvement consistant à « utiliser davantage la plateforme elle-même »
• Après le boom massif des recrutements de 2022–2023, suivi de restructurations, le marché a été secoué, mais l’IA n’a pas remplacé les développeurs, et la capacité à utiliser l’IA est devenue une attente de base
• En 2025, le développement web connaît la vitesse la plus élevée de son histoire, de l’idée jusqu’au déploiement, et
  • dans un environnement où cloud, frameworks et IA se combinent, les individus sont devenus plus puissants que jamais en tant que créateurs
• La promesse du web née avec la balise <br>, « tout le monde peut créer et partager », se poursuit sous une forme encore plus forte à l’ère de l’IA
• C’est aujourd’hui un très bon moment pour faire du développement web