Den mærkelige API, der aldrig blev til noget

Lad os lege en leg: Hvad er den mest bizarrer browser-API, du kender?

Hvis du arbejder med frontend, tænker du sikkert straks på canPlayType(). Den metode returnerer tre værdier: en tom streng, "probably" eller "maybe". Det er svar baseret på sandsynlighed indpakket i vage formuleringer – og ærligt talt, det er rodet.

Men der findes en anden API, der virkelig viser websitet's forpligtelse til aldrig at bryde eksisterende kode: History.pushState().

Når du kalder pushState(), skal du egentlig sende tre parametre med: state, title og url. State-objektet giver mening – det lader din app gendanne data, når brugere klikker på tilbage-knappen. URL-parameteren er nyttig til at opdatere adresselinjen uden at udløse en sideopload.

Men den der title-parameter? Den bliver fuldstændig ignoreret. Alle store browsere smider den væk.

Så hvorfor eksisterer den overhovedet?

Tilbage i 2008, da History API'et blev udkastet, forestillede nogen sig, at browsere burde lade apps sætte en brugerdefineret titel på hver historikpost. Ideen var, at din single-page app kunne vise "Dashboard" i appen, mens den gemte "Analyserapport" i browserens historik.

Det lød fornuftigt dengang. Men browsere indså hurtigt, at det ville skabe forvirrende situationer. Hvad sker der, når en bruger bogmærker en historikpost, og titlen ikke matcher det, de ser i deres faneblade?

I stedet for at rode med det problem, valgte browsere bare at ignorere parameteren. På det tidspunkt havde utallige sider dog allerede bygget deres apps med forventning om tre parametre. At fjerne det ville bryde produktionssites. At gøre det valgfrit ville skabe forvirring i eksisterende pushState(state, url)-kald.

Så specifikationen gjorde noget elegant: den omdøbte parameteren til unused og dokumenterede, at den ikke har nogen effekt.

Det er websitet's beskidte hemmelighed – vi prioriterer bagudkompatibilitet over næsten alt andet. Nettet vil bøje sig i alle retninger (nogle gange bogstaveligt talt) for at sikre, at kode fra 2008 stadig kører i dagens browsere.

Den filosofi er præcis grunden til, at vi hos NameOcean går ind for statiske sider og velafprøvede webteknologier. Når du bygger noget, der skal holde – mediearkiver, dokumentation, landingssider – så er stabiliteten i standard webteknologi ikke en begrænsning. Det er en funktion.

Det samme gælder, når du vælger en domain registrar eller hostingudbyder. Du vil have virksomheder, der forstår det lange spil. Nettet forsvinder ikke, og de teknologier du bygger på i dag, bør stadig virke et årti fra nu.

Der er en lære her for udviklere og startups: nogle gange bliver den "forkerte" beslutning permanent, ikke fordi den er korrekt, men fordi for meget afhænger af den. Det er ikke en fejl i nettet – det er en funktion, der holder millioner af sider kørende problemfrit.

Næste gang du støder på en quirky API eller en forældet parameter, så husk: Nogen derude traf en beslutning for år siden, og nu er den hugget ind i nettets fundament. Respektér det mærkelige. Det er det, der holder tingene i gang.