Az elfeledett paraméter, ami sosem tűnik el

Van egy vicces játék: nevezd meg a legfurcsább böngésző API-t, amit ismersz!

Ha frontend fejlesztő vagy, valószínűleg rögtön a canPlayType() jut eszedbe. Ez a metódus három értéket adhat vissza: üres stringet ("nem"), "probably"-t vagy "maybe"-t. Elég kaotikus megoldás.

De van egy másik API, ami tökéletesen bemutatja, mennyire ragaszkodik a web ahhoz, hogy a régi kód soha ne romoljon el: ez pedig a History.pushState().

A három paraméter, ahol az egyik csak ott lóg

A pushState() három paramétert vár: state, title és url. Az első kettő tuti hasznos. A state objektum segít az alkalmazásnak visszaállítani az adatokat, amikor a felhasználó a vissza gombra kattint. Az URL paraméterrel frissítheted a címsort anélkül, hogy az oldal újratöltődne.

És akkor itt van a title. Teljesen irreleváns. Minden nagy böngésző egyszerűen eldobja.

De akkor minek maradt benne?

A 2008-as ötlet, ami nem vált be

2008-ban, amikor a History API-t megtervezték, valaki úgy gondolta, hogy jó lenne, ha az alkalmazások egyedi címet adhatnának minden history entry-nek. Tehát az app mutatná a "Dashboard"-t, miközben a böngésző history-jában "Analytics Report" szerepelne.

Tök logikusnak tűnt akkoriban. Aztán a böngészők rájöttek, hogy ez káoszba fulladna. Mi történik, ha a felhasználó könyvjelzőzi az adott history entry-t, és a cím nem egyezik azzal, amit a böngésző tabján lát?

Egyszerűbb volt egyszerűen figyelmen kívül hagyni a paramétert. Viszont addigra már rengeteg oldal épített arra, hogy három paramétert kell átadni. Ha eltávolítanák, elromlana a production kód. Ha opcionálissá tennék, összekeverednének a meglévő pushState(state, url) hívások.

A megoldás elegáns lett: a specifikáció átnevezte a paramétert unused-ra, és dokumentálta, hogy semmi hatása nincs.

A web csúnya titka

Ez a web dirty secretje: a backward compatibility mindent ver. A web a végsőkig ragaszkodik ahhoz, hogy a 2008-as kód ma is fusson.

Épp ezért ajánljuk a statikus oldalakat és a bevált webes technológiákat a NameOcean-nél. Amikor valamit hosszú távra építesz – legyen szó médiaarchívumról, dokumentációról vagy landing page-ről – a vanilla web technológia stabilitása nem korlát, hanem előny.

Ugyanez igaz a domain regisztrátor és a tárhelyszolgáltató kiválasztásánál is. Olyan cégeket keress, amelyek értik a hosszú játékot. A web nem megy sehova, és ami ma épül, annak tíz év múlva is működnie kell.

Tanulság fejlesztőknek és startupoknak

Van egy fontos lecke itt: néha a "rossz" döntés örökre velünk marad, nem azért, mert helyes, hanem mert túl sok minden függ tőle.

Ez nem a web bugja – ez egy feature, ami millió oldalt tart életben.

Szóval legközelebb, amikor egy furcsa API-val vagy elavult paraméterrel találkozol, gondolj arra, hogy valaki évekkel ezelőtt hozott egy döntést, és az most már a web alapköve. Réspektáld a furcsaságokat. Ezek működtetik az egészet.