De ce parametrul title din pushState() nu face absolut nimic?

Hai să jucăm un joc: care e cea mai ciudată API din browser pe care o știi?

Dacă lucrezi în frontend, probabil te-ai gândit imediat la canPlayType(). Acea metodă care întoarce un string gol, "probably" sau "maybe". E ciudată, recunosc.

Dar astăzi vreau să-ți arăt altă API care demonstrează cât de mult ține web-ul la compatibilitatea inversă: History.pushState().

Când apelezi pushState(), trebuie să pasezi trei parametri: state, title și url. Primii doi au sens. State-ul îți permite să restaurezi date când utilizatorul dă click pe back. URL-ul actualizează bara de adrese fără reload.

Dar parametrul title? E ignorat complet. Toate browserele majore îl aruncă la gunoi.

De ce există atunci?

Prin 2008, când History API a fost prima oară schițat, cineva a avut ideea că browserele ar trebui să lase aplicațiile să seteze un titlu personalizat pentru fiecare intrare din istoric. Gândește-te: aplicația ta afișează "Dashboard", dar în istoricul browserului se salvează "Raport Analytics".

Suna logic pe hârtie. Dar browserele au realizat rapid că asta ar crea situații bizare. Ce se întâmplă când un user pune bookmark pe o pagină și titlul nu se potrivește cu ce vede în tab-uri?

În loc să se ocupe de această problemă, browserele au făcut un lucru simplu: au ignorat parametrul. Doar că până atunci, mii de site-uri deja construiseră aplicații care foloseau cei trei parametri. Dacă îl eliminau, stricau codul de producție. Dacă îl făceau opțional, introduceau confuzie pentru apelurile existente de pushState(state, url).

Așa că specificația a făcut ceva elegant: a redenumit parametrul în unused și a documentat că nu are niciun efect.

Asta e secretul murdar al web-ului — prioritizăm compatibilitatea inversă peste aproape orice altceva. Web-ul va face acrobații (literal uneori) doar ca să se asigure că un cod din 2008 încă rulează în browserele de azi.

Această filozofie e exact motivul pentru care la NameOcean recomandăm site-urile statice și tehnologiile web dovedite. Când construiești ceva care trebuie să reziste — arhive media, documentație, landing pages — stabilitatea tehnologiilor vanilla nu e o limitare; e un avantaj.

Același principiu se aplică și când alegi un registrar de domenii sau un hosting provider. Vrei companii care înțeleg jocul lung. Web-ul nu dispare, iar tehnologiile pe care le folosești azi ar trebui să funcționeze și peste un deceniu.

Există o lecție aici, atât pentru dezvoltatori, cât și pentru startup-uri: uneori decizia "greșită" devine permanentă nu pentru că e corectă, ci pentru că prea multe depind de ea. Asta nu e un bug în web — e o funcționalitate care ține milioane de site-uri să ruleze fără probleme.

Data viitoare când dai de o API ciudată sau un parametru depreciat, amintește-ți: cineva, undeva, a luat o decizie acum ani, și acum e sculptată în fundația web-ului. Respectă ciudățenia. Tocmai asta ține totul în funcțiune.