L'API pushState() et ce paramètre oublié qui a changé le web

Tu sais ce moment où tu découvres une API bancale et tu te demandes comment ça a pu arriver jusqu'à toi ?

En tant que dev frontend, tu connais sûrement canPlayType(). Cette méthode qui te répond "peut-être", "probablement" ou... rien du tout. Un cauchemar pour les tests.

Mais moi, ce qui me fascine le plus, c'est History.pushState().

Trois paramètres, un qui ne sert à rien

Le principe est simple : tu appelles pushState(state, title, url) avec trois arguments. Le premier, state, c'est pour restaurer des données quand l'utilisateur clique sur Précédent. Le troisième, url, met à jour la barre d'adresse sans recharger la page.

Et le deuxième ? Le titre ? Aucun navigateur ne s'en sert.

Zéro. Nada. Ignoré.

Pourquoi ça existe alors ?

Retour en 2008. Quelqu'un chez les spec writers se dit : ce serait cool qu'une SPA puisse définir un titre personnalisé pour chaque entrée d'historique. Tu navigues dans ton app, tu vois "Tableau de bord", mais dans l'historique du navigateur, ça stocke "Rapport analytique".

L'idée semblait intelligente.

Sauf que les navigateurs ont vite compris le bazar que ça allait créer. Un utilisateur enregistre un favori, puis l'ouvre dans un nouvel onglet : le titre ne correspond plus à ce qu'il voit. Bordel de merde.

La solution élégante : ne rien faire

Plutôt que de gérer ce chaos, les navigateurs ont simplement zappé le paramètre.

Sauf qu'à ce stade, des milliers de sites utilisaient déjà pushState(state, title, url). Supprimer le paramètre aurait cassé des prod. Le rendre optionnel aurait créé des bugs dans tout le code existant.

Donc la spec a trouvé l'approche parfaite : elle a renommé le paramètre en unused et a documenté qu'il n'a aucun effet.

CQFD.

Le secret du web

Ce que cette anecdote révèle, c'est une vérité fondamentale du développement web : la rétrocompatibilité passe avant tout.

Le web va se plier en quatre pour qu'un code de 2008 fonctionne encore sur les navigateurs d'aujourd'hui. C'est parfois absurde. Mais c'est ce qui permet à des millions de sites de continuer à tourner.

C'est exactement pour ça que chez NameOcean, on milite pour les sites statiques et les technologies web éprouvées. Quand tu construis quelque chose qui doit durer — une archive média, de la documentation, une landing page — la stabilité du web vanilla n'est pas une contrainte. C'est une force.

Le même principe pour ton registrar

Quand tu choisis un registrar de domaine ou un hébergeur, cherche des acteurs qui comprennent le jeu long. Le web ne va nulle part. Les technologies sur lesquelles tu construis aujourd'hui doivent encore fonctionner dans dix ans.

Pour les devs et les startups : parfois, une "mauvaise" décision devient permanente, non pas parce qu'elle était bonne, mais parce que trop de choses en dépendent.

Ce n'est pas un bug du web. C'est une fonctionnalité qui maintient des millions de sites à flot.

La prochaine fois que tu tombes sur une API bancale ou un paramètre useless, dis-toi que quelqu'un a fait un choix il y a des années. Et maintenant, ça fait partie des fondations du web.

Respecte le bordel. C'est ce qui fait que tout fonctionne.