Cours 01 — Histoire du Web : De l'Hypertexte aux Micro-Frontends

1. 1990 : L'invention du World Wide Web

1.1 Le contexte

En 1989, Tim Berners-Lee travaille au CERN (Organisation Européenne pour la Recherche Nucléaire). Le problème : les chercheurs du CERN utilisent des systèmes d'information incompatibles (FTP, Usenet, Archie, WAIS). Chaque protocole a son interface, son format, sa syntaxe. Partager un document entre deux équipes est un cauchemar.

1.2 La proposition

En mars 1989, Berners-Lee soumet un document intitulé "Information Management: A Proposal" qui décrit un système de gestion d'information basé sur l'hypertexte. Le concept d'hypertexte n'est pas nouveau (Vannevar Bush, 1945 ; Ted Nelson, 1960), mais personne ne l'a implémenté à grande échelle.

Les trois innovations clés :

HTML : Un langage de balisage pour structurer les documents avec des liens
HTTP : Un protocole de transfert simple (GET/POST)
URL : Un système d'adressage universel

Diagramme en cours de génération...

1.3 Pourquoi ça a marché

Le succès du web de Berners-Lee tient à trois décisions architecturales :

Décentralisation : Pas de contrôle central, tout le monde peut créer un serveur
Simplicité : Le protocole HTTP tient sur une page, HTML a une vingtaine de balises
Gratuité : Aucune licence, aucune redevance

Leçon pour l'ingénieur moderne : Les technologies qui dominent sont celles qui réduisent la friction. La simplicité bat la sophistication.

2. 1993-1994 : Les premiers navigateurs

2.1 Mosaic (1993)

Marc Andreessen et Eric Bina développent Mosaic au NCSA (National Center for Supercomputing Applications). C'est le premier navigateur à :

Afficher des images dans le texte (pas dans une fenêtre séparée)
Utiliser une interface graphique intuitive (boutons, barre d'adresse)
Être disponible sur Unix, Windows et Mac

Mosaic explose : 2 millions d'utilisateurs en un an.

2.2 Netscape Navigator (1994)

Andreessen co-fonde Netscape et sort Navigator. C'est le premier navigateur commercial. En 1995, Netscape détient 80% du marché.

2.3 La guerre des navigateurs (1995-1998)

Microsoft réalise le potentiel du web et lance Internet Explorer 1.0 en 1995, intégré gratuitement à Windows 95+. C'est le début de la guerre des navigateurs.

Stratégie de Microsoft (Embrace, Extend, Extinguish) :

Embrace : Adopter les standards ouverts
Extend : Ajouter des fonctionnalités propriétaires (marqueurs <blink>, <marquee>)
Extinguish : Les concurrents ne peuvent pas suivre

Résultat : Netscape disparaît, IE atteint 95% de parts de marché en 2002. Mais le web est fragmenté : les sites fonctionnent seulement sur IE (les développeurs utilisaient <!--[if IE]>).

Leçon : La standardisation est cruciale. Sans standards, le web se fragmente, et ce sont les utilisateurs qui paient.

3. 1995 : La naissance de JavaScript

3.1 Le contexte

Netscape veut ajouter de l'interactivité aux pages web (valider des formulaires, faire des animations simples). Les solutions existantes :

CGI (Common Gateway Interface) : Requête au serveur pour chaque action → lent
Java Applets : Technologie Sun, puissante mais lourde (téléchargement d'une VM)
Plugins : Shockwave, RealAudio → propriétaires

3.2 La création en 10 jours

Brendan Eich est embauché chez Netscape en avril 1995. En mai, il crée Mocha (renommé LiveScript, puis JavaScript) en 10 jours. Le langage doit :

Être facile pour les designers et développeurs amateurs
Avoir une syntaxe proche du C/Java (pour la crédibilité)
Être interprété (pas de compilation)
S'intégrer directement dans le navigateur

Conséquences de ce développement express :

Le système de typage est faible et dynamique (conversion implicite : "2" + 2 = "22")
L'héritage est prototypal (Brendan Eich a imité Self, un langage obscur)
Les closures existent mais sont mal comprises
Pas de modules, pas de classes (ajoutés en ES6, 20 ans plus tard)

3.3 L'évolution rapide

1995 : JavaScript 1.0 dans Netscape 2.0
1996 : Microsoft reverse-engineer JScript pour IE3
1997 : ECMAScript 1 (standardisation ECMA-262)
1999 : ECMAScript 3 (try/catch, regex, switch amélioré)
2009 : ECMAScript 5 (strict mode, JSON, array methods)
2015 : ECMAScript 6 (classes, modules, promises, let/const, arrow functions)
2016+ : Mise à jour annuelle (ES7, ES8...)

Diagramme en cours de génération...

3.4 Le problème des premiers JS

// Exemple de code JavaScript de 1996
function validateForm() {
  var name = document.forms[0].name.value;
  if (name == "") {
    alert("Name is required!");
    return false;
  }
}

// Le code est :
// 1. Globale (toutes les fonctions dans window)
// 2. Mélangé avec HTML (<input onsubmit="validateForm()">)
// 3. Non testable
// 4. Fragile (document.forms[0] change si on modifie le HTML)

Leçon : JavaScript a été créé sous une contrainte de temps extrême. Ses "quirks" ne sont pas des bugs mais des décisions de design prises sous pression. Les comprendre permet d'éviter 20 ans d'erreurs.

4. 1996-1998 : CSS, Flash, et le web dynamique

4.1 CSS (1996)

Avant CSS, le style était défini en HTML pur :

<font color="red" size="5">Hello</font>

C'était impossible à maintenir : changer la couleur de tous les titres nécessitait d'éditer chaque page.

CSS résout : La séparation entre contenu (HTML) et présentation (CSS). Un seul fichier .css peut styliser des milliers de pages.

Le problème de l'époque : Les navigateurs implémentent CSS différemment. font-size: 1em n'affiche pas la même taille dans Netscape et IE.

Leçon : La séparation des responsabilités (Separation of Concerns) est un principe intemporel. CSS a introduit ce concept dans le web.

4.2 Flash (1996)

Flash (anciennement FutureSplash, racheté par Macromedia) permet de créer des animations vectorielles riches, des jeux, des vidéos. À une époque où les navigateurs sont limités, Flash est omnipotent :

Typographie avancée (les webfonts n'existent pas)
Animations fluides (CSS animations n'existent pas)
Audio/Vidéo (HTML5 n'existe pas)
Dessin vectoriel (Canvas/WebGL n'existent pas)

Le problème de Flash :

Propriétaire (contrôlé par Adobe)
Lent, gourmand en batterie
Non accessible (lecteurs d'écran)
Non sécurisé (vulnérabilités constantes)
Pas de support mobile (Apple refuse Flash sur iOS en 2007)

Leçon : Les technologies propriétaires qui remplacent des standards ouverts sont toujours des solutions temporaires. Le standard finit toujours par gagner (HTML5 a tué Flash).

5. 2005 : AJAX et le Web 2.0

5.1 Le problème du web pré-2005

Avant 2005, chaque action utilisateur nécessite un rechargement complet de la page :

L'utilisateur clique sur un bouton
Le navigateur envoie une requête HTTP
Le serveur génère une nouvelle page HTML complète
Le navigateur reçoit et affiche la nouvelle page

Conséquence : L'expérience utilisateur est saccadée. Chaque action = flash blanc + rechargement.

5.2 XMLHttpRequest et AJAX

En 1999, Microsoft introduit XMLHttpRequest dans IE5 (via ActiveX). Mais personne ne l'utilise avant 2005.

2005 : Google Maps et Gmail

Google Maps : la carte se déplace sans rechargement de page (les tuiles sont chargées en arrière-plan)
Gmail : interface email réactive sans rechargement

Jesse James Garrett (Adaptive Path) nomme cette approche AJAX (Asynchronous JavaScript and XML).

// AJAX en 2005
function loadPage(url) {
  var xhr = new XMLHttpRequest();
  xhr.open('GET', url, true);
  xhr.onreadystatechange = function() {
    if (xhr.readyState === 4 && xhr.status === 200) {
      document.getElementById('content').innerHTML = xhr.responseText;
    }
  };
  xhr.send(null);
}

5.3 Web 2.0

Le terme "Web 2.0" (Tim O'Reilly, 2005) désigne le passage d'un web de pages statiques à un web d'applications interactives :

Wikis (Wikipedia, 2001)
Réseaux sociaux (MySpace 2003, Facebook 2004, Twitter 2006)
Vidéo (YouTube 2005)
Tags, RSS, mashups

Leçon : AJAX n'a pas inventé la requête asynchrone (XMLHttpRequest existait depuis 1999). Il a inventé le pattern d'utilisation qui a rendu le web interactif. Parfois, l'innovation n'est pas technologique mais conceptuelle.

6. 2006-2008 : jQuery, Chrome et V8

6.1 jQuery (2006)

Le problème : En 2006, JavaScript est un enfer de compatibilité inter-navigateurs.

// Sélection d'éléments en 2005
var element;
if (document.getElementById) {
  element = document.getElementById('foo');
} else if (document.all) {  // IE ancien
  element = document.all['foo'];
}

// Récupération du texte
var text = element.innerText || element.textContent || '';

jQuery résout :

Sélection CSS ($('.class'))
Manipulation du DOM cross-browser
Événements normalisés
Animations simples
AJAX simplifié

// jQuery (2006)
$('#button').click(function() {
  $.get('/api/data', function(data) {
    $('#content').html(data);
  });
});

Le problème que jQuery crée : jQuery résout les problèmes de son époque mais :

Il encourage le code spaghetti (manipulation directe du DOM éparpillée)
Il ajoute ~30KB au poids de la page
Il résout des problèmes que les navigateurs modernes n'ont plus (querySelectorAll, addEventListener)

Leçon : jQuery a été une excellente solution pour son époque mais il a créé une dépendance mentale. Les développeurs ont appris jQuery, pas JavaScript. Quand les navigateurs ont résolu les problèmes de compatibilité, jQuery est devenu une surcharge inutile.

6.2 Chrome et V8 (2008)

Le problème : En 2007, Google Maps et Gmail poussent JavaScript à ses limites. Les navigateurs existants (IE6, Firefox 2, Safari 3) ont des moteurs JavaScript lents qui bloquent sur des applications complexes.

La solution de Google : Créer un navigateur avec un moteur JavaScript radicalement nouveau.

V8 (développé par Lars Bak) introduit :

JIT compilation : Compile JS en code machine au lieu de l'interpréter
Inline caching : Optimise les accès répétés aux propriétés
Génération de code optimisé : Hidden classes, garbage collection précis

Diagramme en cours de génération...

Impact : Chrome passe de 0% à 20% de parts de marché en deux ans. V8 est 10-100x plus rapide que les moteurs existants.

Leçon : Les performances de JavaScript ne sont pas une limite inhérente au langage mais une question d'implémentation du moteur. V8 a transformé JavaScript d'un "jouet" en langage sérieux.

7. 2009-2010 : Node.js, npm, et l'ère SPA

7.1 Node.js (2009)

Ryan Dahl introduit Node.js en 2009. Son idée : utiliser V8 en dehors du navigateur pour exécuter JavaScript côté serveur.

Pourquoi Node.js était révolutionnaire :

JS devient full-stack (même langage client et serveur)
Modèle asynchrone non-bloquant (event-driven, pas de threads)
V8 (performance proche du natif)
npm (écosystème de packages)

// Node.js HTTP server (2009)
var http = require('http');
http.createServer(function(req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World\n');
}).listen(3000);

Le problème que Node.js crée : L'asynchrone est difficile à gérer sans Promises :

// Callback hell (Node.js 2009)
getUser(id, function(user) {
  getPosts(user.id, function(posts) {
    getComments(posts[0].id, function(comments) {
      render(comments);
    });
  });
});

7.2 npm (2010)

npm résout la distribution de packages JavaScript. Avant npm : télécharger jQuery depuis jquery.com, le copier dans le projet. C'est un non-sens en ingénierie.

npm introduit :

package.json (description des dépendances)
Registre central de packages
Semantic Versioning (semver)
npm install

Leçon : npm a standardisé la gestion des dépendances. Mais il a aussi créé le problème des "dépendances aveugles" (left-pad incident, 2016).

7.3 L'ère SPA (Single Page Applications)

Problème : Avec jQuery/AJAX, les applications deviennent complexes. Le code est un mélange de logique, de template, et de manipulation DOM.

Solutions :

Backbone.js (2010) : Structure MVC côté client, collections, événements
AngularJS (2010) : Two-way data binding, dependency injection, directives
Ember.js (2011) : Convention over configuration, routing intégré

// Backbone.js (2010)
var Task = Backbone.Model.extend({
  defaults: { title: '', completed: false }
});

var TaskView = Backbone.View.extend({
  tagName: 'li',
  template: _.template('<%= title %>'),
  render: function() {
    this.$el.html(this.template(this.model.toJSON()));
    return this;
  }
});

Le problème des SPAs : Initialement, les applications SPA :

Chargent tout le JS avant d'afficher quoi que ce soit (First Paint lent)
Sont mauvaises pour le SEO (les crawlers ne voient qu'un <div id="root">)
Sont lourdes (AngularJS 1.x : ~50KB minifié)

Leçon : L'ère SPA a montré que séparer le front-end du back-end améliore l'architecture mais crée de nouveaux problèmes (performance, SEO, bundle size). Ces problèmes ne seront résolus que 10 ans plus tard avec SSR, SSG, et RSC.

8. 2013-2015 : React, ES6, TypeScript

8.1 React (2013)

Le problème : Les frameworks SPA (Backbone, AngularJS) manipulent le DOM directement. Quand l'état change, il faut : (1) trouver les éléments DOM à modifier, (2) les modifier. Plus l'application est grande, plus c'est complexe et source de bugs.

La solution React : La "réconciliation". React ne dit pas "comment" mettre à jour le DOM, il dit "ce qu'on veut voir" (déclaratif).

// React (2013)
var TaskList = React.createClass({
  getInitialState: function() { return { tasks: [] }; },
  render: function() {
    return React.createElement('ul', null,
      this.state.tasks.map(function(task) {
        return React.createElement('li', null, task.title);
      })
    );
  }
});

Innovations de React :

Virtual DOM : Représentation du DOM en mémoire, diffing algorithm
One-way data binding : Les données descendent, les événements remontent
Composants : UI découpée en composants réutilisables
JSX : Syntaxe déclarative (controversée à l'époque)

Pourquoi React a gagné :

Simplicité conceptuelle (pas de templates, pas de binding magique)
Performance (Virtual DOM)
Flexibilité (n'est pas un framework mais une librairie)
Écosystème (Facebook, communauté active)

8.2 ES6 (ECMAScript 2015)

Après 6 ans sans mise à jour majeure (ES5 en 2009), ES6 arrive comme une révolution.

Nouveautés majeures :

let / const (portée de bloc, adieu var)
Arrow functions (pas de this lié)
Classes (sucre syntaxique sur l'héritage prototypal)
Modules (import / export)
Promises (fin du callback hell)
Template literals (`${name}`)
Destructuring (const { name } = obj)
Default parameters, rest/spread (...)

// Avant ES6 (2009)
var name = data.name || 'Guest';
var message = 'Hello ' + name;
function greet(name) {
  if (!name) name = 'Guest';
  return 'Hello ' + name;
}

// Après ES6 (2015)
const { name = 'Guest' } = data;
const message = `Hello ${name}`;
const greet = (name = 'Guest') => `Hello ${name}`;

Leçon : ES6 n'a pas rendu ES5 obsolète du jour au lendemain. La transition a pris des années (support navigateur, Babel). L'innovation en front-end est souvent limitée par la rétrocompatibilité.

8.3 TypeScript (2015)

Le problème : JavaScript est dynamique. Les bugs de type (undefined is not a function, cannot read property 'x' of undefined) sont les plus fréquents et les plus difficiles à debugger.

Solution : TypeScript = JavaScript + types statiques.

Développé par Microsoft (Anders Hejlsberg, créateur de C#)
Compile vers JavaScript (pas d'exécution spéciale)
Types optionnels (on peut migrer progressivement)
Inférence de types (pas besoin de tout typer explicitement)

// TypeScript (2015)
interface User {
  id: number;
  name: string;
  email: string;
}

async function getUser(id: number): Promise<User> {
  const response = await fetch(`/api/users/${id}`);
  if (!response.ok) throw new Error('User not found');
  return response.json();
}

Pourquoi TypeScript a gagné :

Détection des erreurs à la compilation (pas en runtime)
Autocomplétion et refactoring (DX améliorée)
Documentation intégrée (le type est la documentation)
Adopté par Angular 2+, React (via les .tsx), Vue 3, Next.js

Leçon : TypeScript démontre qu'un système de types bien conçu améliore la productivité à long terme malgré le coût initial de typage. C'est un investissement, pas une dépense.

9. 2020+ : WebAssembly, micro-frontends, RSC, Edge

9.1 WebAssembly (Wasm)

Le problème : JavaScript est lent pour certains workloads (jeux, vidéo, 3D, calcul scientifique). Même avec JIT, JS reste limité par son modèle dynamique.

Solution : WebAssembly est un format binaire exécutable dans le navigateur à vitesse native.

// Rust → WebAssembly
#[wasm_bindgen]
pub fn fibonacci(n: u32) -> u32 {
    match n {
        0 => 0,
        1 => 1,
        _ => fibonacci(n - 1) + fibonacci(n - 2),
    }
}

Wasm vs JS :

Wasm : langages compilés (C/C++, Rust, Go), vitesse native
JS : développement rapide, écosystème riche, DOM access
Complémentaires : Wasm pour le calcul lourd, JS pour l'UI

9.2 Micro-frontends

Le problème : Les applications front-end deviennent trop grosses pour une seule équipe. Un monolithe front-end de 500k lignes est impossible à maintenir.

Solution : Micro-frontends = diviser l'application en sous-applications indépendantes, chacune gérée par une équipe.

Approches :

Module Federation (Webpack 5) : Partage de modules à l'exécution
Iframes : Isolation maximale (mais lourde)
Web Components : Standard, indépendant du framework
qiankun / single-spa : Frameworks dédiés

9.3 RSC (React Server Components)

Le problème : Les bundles React sont gros (gzippés : React 6KB, ReactDOM 42KB). De plus, chaque composant doit être chargé côté client même s'il pourrait être rendu sur le serveur.

Solution : Les React Server Components (RSC) séparent les composants en deux catégories :

Server Components : Rendus sur le serveur, jamais envoyés au client, accès direct à la DB/API
Client Components : Hydratés côté client, interactifs

Avantages : Bundle réduit, performance améliorée, accès direct aux données.

9.4 Edge Computing

Le problème : Le cloud central (us-east-1) est loin de l'utilisateur. Une requête depuis le Japon vers un serveur aux USA prend 100-200ms de latence.

Solution : Edge computing = exécuter le code au plus proche de l'utilisateur (CDN + compute).

Acteurs :

Cloudflare Workers (V8 isolates)
Vercel Edge Functions
Deno Deploy

// Cloudflare Worker
export default {
  async fetch(request) {
    const country = request.cf.country;
    return new Response(`Hello from ${country}`, {
      headers: { 'content-type': 'text/plain' },
    });
  }
};

10. Leçons de l'histoire du web

10.1 Les 10 leçons

La simplicité bat la sophistication : Le web a gagné contre les systèmes concurrents (Gopher, WAIS) parce qu'il était plus simple.
Les standards sont cruciaux : Chaque fois qu'un acteur impose un standard propriétaire (Flash, IE-only features), le web en souffre et le standard ouvert finit par gagner.
La backward compatibility est un fardeau et un avantage : JavaScript ne peut pas corriger certains bugs historiques (typeof null === 'object') à cause de la rétrocompatibilité. Mais cette stabilité a permis la croissance du web.
Les frameworks résolvent les problèmes de leur époque : jQuery (compatibilité), AngularJS (data binding), React (DOM management). Un framework qui ne résout plus un problème réel devient obsolète.
La performance est un cycle : On a commencé avec SSR (pages serveur), puis CSR (App shell, SPA), puis SSR (Next.js, RSC). Les cycles reviennent avec des techniques meilleures.
L'innovation vient des contraintes : JavaScript (10 jours), AJAX (bande passante limitée), V8 (Gmail trop lent), React (complexité DOM). Les meilleures solutions naissent des problèmes concrets.
L'écosystème est aussi important que la technologie : React a gagné contre AngularJS sur le plan technique, mais surtout par la force de sa communauté et de son écosystème.
Le front-end n'est plus "le petit frère" : Le front-end moderne est aussi complexe que le back-end. Il mérite les mêmes pratiques d'ingénierie (tests, architecture, monitoring).
TypeScript n'est pas une mode : Le typage statique dans un langage dynamique est une réponse à l'échelle des projets modernes. C'est une tendance de fond.
Le web est la plateforme : Avec PWA, WebAssembly, WebGL, le web n'est plus "juste des pages". C'est une plateforme applicative complète.

10.2 Pour l'ingénieur moderne

Comprendre cette histoire permet de :

Évaluer les nouvelles technologies : Est-ce une vraie innovation ou un éternel retour ?
Choisir ses outils : Tel framework résout-il un vrai problème actuel ?
Anticiper les tendances : Edge computing, RSC, Wasm → où va-t-on ?
Éviter les erreurs du passé : Ne pas reproduire les patterns qui ont échoué

Diagramme en cours de génération...

Chapitre 01 — Histoire du Web