Waarom pushState() een parameter heeft die niets doet

Speel even mee: noem de raarste browser API die je kent.

Als frontend developer denk je waarschijnlijk meteen aan canPlayType(). Deze methode retourneert drie mogelijke waarden: een lege string (nee), "probably" (waarschijnlijk) of "maybe" (misschien). Best cryptisch, eerlijk gesagt.

Maar er is een andere API die laat zien hoezeer het web ernaar streeft om bestaande code nooit te breken: History.pushState().

De mysterieuze derde parameter

Wanneer je pushState() aanroept, geef je drie parameters mee: state, title en url. De state-object dat wel logisch—hiermee kan je app data herstellen wanneer gebruikers op de back-knop drukken. En de URL-parameter is handig: hiermee update je de adresbalk zonder de pagina te herladen.

Maar die titel-parameter? Die wordt volledig genegeerd. Alle grote browsers gooien hem zonder pardon weg.

Dus waarom bestaat hij?

Een goed idee dat niet werkte

In 2008, toen de History API werd ontworpen, dacht iemand dat browsers apps de mogelijkheid moesten geven om een eigen titel mee te geven aan elk history-item. Het idee: je SPA toont "Dashboard" aan de gebruiker, terwijl "Analytics Rapport" in de browser-history wordt opgeslagen.

Het klonk destijds redelijk. Maar browsers kwamen al snel tot de conclusie dat dit verwarrende situaties zou opleveren. Stel je voor: een gebruiker bookmarkt een history-entry en de titel komt niet overeen met wat ze in hun browsertabs zien?

In plaats van zich met die problematiek bezig te houden, kozen browserontwikkelaars ervoor om de parameter simpelweg te negeren. Tegen die tijd hadden echter al ontelbare sites hun apps gebouwd met drie parameters. Hem verwijderen zou productiesites breken. Hem optioneel maken zou verwarring veroorzaken bij bestaande pushState(state, url)-aanroepen.

Dus wat deed de specificatie? Ze hernoemde de parameter elegant naar unused en documenteerde dat deze geen enkel effect heeft.

De vuile geheim van het web

Dit is precies waar het web voor staat: backward compatibility boven vrijwel alles anders. Het web zal zich dubbel en dwars buigen om ervoor te zorgen dat code uit 2008 gewoon blijft werken in de browsers van vandaag.

Deze filosofie is dan ook precies waarom wij bij NameOcean pleiten voor statische sites en bewezen webtechnologieën. Wanneer je iets bouwt dat jaren moet meegaan—media-archieven, documentatie, landingspages—dan is de stabiliteit van vanilla webtechnologie geen beperking. Het is een feature.

Kies voor het lange spel

Hetzelfde geldt wanneer je een domeinregistrar of hostingprovider kiest. Je wilt bedrijven die het lange-termijnspel begrijpen. Het web gaat nergens heen, en de technologieën waar je vandaag op bouwt, moeten over tien jaar nog steeds functioneren.

Er zit een belangrijke les in dit verhaal, voor developers én startups: soms wordt een "verkeerde" beslissing permanent niet omdat hij correct is, maar omdat er te veel van afhangt. Dat is geen bug in het web—het is een feature die miljoenen sites soepel laat draaien.

Dus de volgende keer dat je een quirky API of een deprecated parameter tegenkomt, denk hieraan: ergens heeft iemand jaren geleden een oordeel geveld, en nu is het uitgebeiteld in de fundering van het web. Respecteer de eigenaardigheden. Ze zorgen ervoor dat alles blijft werken.