Hrajme si: Které API prohlížeče je nejdivnější?

Pokud pracuješ jako frontend vývojář, pravděpodobně ti hned vytane canPlayType(). Tahle metoda na HTMLMediaElement vrací tři možné hodnoty: prázdný řetězec (ne), "probably" (pravděpodobně) nebo "maybe" (možná). Je to v podstatě probabilistická odpověď zabalená do vágního jazyka a upřímně řečeno, trochu chaos.

Ale existuje ještě jedno API, které skutečně ukazuje, jak moc je web oddán tomu, aby nikdy nezlomil stávající kód: History.pushState().

Když voláš pushState(), měl bys mu předat tři parametry: state, title a url. Objekt state dává smysl – umožňuje aplikaci obnovit data, když uživatelé kliknou na tlačítko zpět. Parametr url je užitečný pro aktualizaci adresního řádku prohlížeče bez toho, aby se stránka znovu načetla.

Ale ten parametr title? Ten je úplně ignorován. Všechny hlavní prohlížeče ho zcela zahodí.

Tak proč vlastně existuje?

V roce 2008, když se History API poprvé navrhovalo, někdo si myslel, že prohlížeče by měly umožňovat aplikacím nastavit vlastní titulek pro každou položku historie. Myšlenka byla, že tvůj SPA by mohl zobrazovat "Dashboard" v aplikaci, zatímco v historii prohlížeče by se ukládalo "Analytics Report".

Zvnějšku to znělo rozumně. Ale prohlížeče rychle pochopily, že by to vytvořilo matoucí situace – co se stane, když uživatel uloží záložku a titulek neodpovídá tomu, co vidí v záložkách prohlížeče?

Místo řešení tohoto problému prohlížeče jednoduše parametr ignorovaly. Do té doby už ale bezpočet stránek postavilo své aplikace s očekáváním tří parametrů. Kdyby ho odstranily, rozbily by produkční weby. Kdyby ho udělaly nepovinným, způsobily by zmatek v existujících voláních pushState(state, url).

Takže specifikace udělala něco elegantního: přejmenovala parametr na unused a zdokumentovala, že nemá žádný efekt.

To je špinavé tajemství webu – upřednostňujeme zpětnou kompatibilitu téměř před čímkoli jiným. Web se překrucuje (někdy doslova), aby zajistil, že kód z roku 2008 stále běží v dnešních prohlížečích.

Tato filozofie je přesně důvod, proč u NameOcean prosazujeme statické stránky a osvědčené webové technologie. Když stavíš něco, co má vydržet – mediální archivy, dokumentaci, vstupní stránky – stabilita vanilla webových technologií není omezení; je to funkce.

Stejný princip platí, když vybíráš registrátora domén nebo poskytovatele hostingu. Chceš firmy, které rozumí dlouhodobé hře. Web nikam nezmizí a technologie, na kterých dnes stavíš, by měly fungovat i za deset let.

Pro vývojáře i startupy tu je lekce: někdy se "špatné" rozhodnutí stane trvalým ne proto, že je správné, ale protože na něm závisí příliš mnoho. To není chyba webu – je to funkce, která udržuje v chodu miliony stránek.

Až příště narazíš na podivné API nebo zastaralý parametr, vzpomeň si: někdo, někde, udělal před lety rozhodnutí a teď je to vytesané do základů webu. Respektuj tu divnost. Drží to věci v chodu.