L'API che non fa nulla (e non la puoi rimuovere)

Facciamo un gioco: qual è l'API del browser più assurda che conosci?

Se lavori con frontend, probabilmente hai pensato a canPlayType(). Quel metodo che ritorna una stringa vuota, "probably" oppure "maybe". Una risposta probabilistica in un linguaggio vaghissimo. Onestamente, è un casino.

Ma c'è un'altra API che dimostra quanto il web sia disposto a qualsiasi cosa pur di non rompere il codice esistente: History.pushState().

Quando chiami pushState(), dovresti passare tre parametri: state, title e url. Lo stato ha senso: permette alla tua app di ripristinare dati quando l'utente clicca "indietro". L'URL è utile per aggiornare la barra degli indirizzi senza ricaricare la pagina.

Ma quel parametro title? Viene completamente ignorato. Tutti i browser seri lo scartano e basta.

Allora perché esiste?

Nel 2008, quando l'History API fu提案, qualcuno pensò che i browser dovessero permettere alle app di impostare un titolo personalizzato per ogni voce della cronologia. L'idea era che la tua SPA potesse mostrare "Dashboard" nell'interfaccia mentre "Report Analytics" finiva nella cronologia del browser.

Sembrava ragionevole. Ma i browser capirono presto che sarebbe stato un casino—che succede quando un utente salva un segnalibro e il titolo non corrisponde a quello che vede nelle tab?

Invece di affrontare il problema, i browser decisero semplicemente di ignorare il parametro. Peccato che ormai migliaia di siti avevano già costruito le loro app aspettandosi tre parametri. Rimuoverlo avrebbe rotto produzione. Renderlo opzionale avrebbe creato confusione con le chiamate pushState(state, url) esistenti.

Così la specifica fece qualcosa di elegante: rinominò il parametro in unused e documentò che non ha alcun effetto.

Questo è il segreto sporco del web—prioritiamo la compatibilità all'indietro sopra quasi tutto. Il web si piega in due (a volte letteralmente) per far sì che codice del 2008 funzioni ancora sui browser di oggi.

Questa filosofia è esattamente il motivo per cui promuoviamo i siti statici e le tecnologie web consolidate su NameOcean. Quando costruisci qualcosa che deve durare—archivi multimediali, documentazione, landing page—la stabilità del web vanilla non è una limitazione. È una caratteristica.

Lo stesso principio vale quando scegli un registrar di domini o un hosting provider. Vuoi aziende che capiscano il lungo periodo. Il web non sta andando da nessuna parte, e le tecnologie su cui costruisci oggi dovrebbero funzionare ancora tra un decennio.

C'è una lezione qui, sia per developer che per startup: a volte una decisione "sbagliata" diventa permanente non perché sia corretta, ma perché troppe cose dipendono da essa. Non è un bug del web—è una caratteristica che tiene in piedi milioni di siti.

La prossima volta che incontri un'API strana o un parametro deprecato, ricorda: qualcuno, da qualche parte, ha fatto una chiamata anni fa, e ora è scavata nelle fondamenta del web. Rispetta la stranezza. È quello che tiene tutto in funzione.