JavaScript è nato in dieci giorni e non ce lo togliamo più

Ogni volta che apro un progetto ereditato da qualcun altro, prima o poi trovo un == dove doveva esserci un ===. Il bug che ne esce è sempre lo stesso tipo di bug, e ha la stessa età del linguaggio.

Quel doppio uguale non è lì per pigrizia di qualcuno. È lì perché toglierlo romperebbe pagine che nessuno può più ricompilare. Ed è la stessa ragione per cui JavaScript, messo insieme in dieci giorni nel 1995, è ancora l'unico linguaggio che il browser esegue davvero.

Dieci giorni, e un nome scelto dal marketing

Brendan Eich lo scrive in Netscape nel 1995. Il primo prototipo nasce in circa dieci giorni, e non doveva servire a costruire applicazioni: doveva far muovere qualcosa dentro una pagina. Validare un campo, aprire un menu. Nient'altro.

Si chiamava Mocha, poi LiveScript, poi JavaScript. L'ultimo nome è una scelta commerciale per agganciarsi a Java, che in quel momento andava forte e con cui non c'entra niente. È il primo pasticcio del linguaggio, e trent'anni dopo mi tocca ancora spiegare a qualcuno che sono due cose diverse.

I difetti non sono stati corretti, e non è una dimenticanza

Alcune cose che JavaScript fa ancora oggi, esattamente come le faceva allora:

typeof null      // 'object'
0.1 + 0.2        // 0.30000000000000004
[] == false      // true
'5' - 2          // 3
'5' + 2          // '52'

Sui decimali è onesto dire che non è colpa sua: quello è lo standard IEEE 754 e lo fanno quasi tutti i linguaggi. Gli altri invece sono roba sua. typeof null che risponde "object" è un bug del 1995, riconosciuto come tale, mai sistemato.

Il motivo si riassume in una frase che in TC39, il comitato che decide lo standard, vale più di qualsiasi eleganza: non rompere il web. Se domani typeof null iniziasse a rispondere correttamente, da qualche parte si spegnerebbe un modulo scritto nel 2004 che nessuno mantiene più e che però serve a qualcuno. Il web non ha un deploy: non puoi ricompilare tutte le pagine che esistono.

Questa è la parte che trovo interessante. I difetti di JavaScript non sono il prezzo della fretta del 1995. Sono il prezzo di una promessa mantenuta per trent'anni.

Hanno provato tutti a sostituirlo

E non sono stati tentativi timidi:

• VBScript di Microsoft, che funzionava solo in Internet Explorer.
• Gli applet Java, morti di lentezza e problemi di sicurezza.
• Flash, che per anni ha fatto girare mezzo web e ha chiuso definitivamente nel 2020.
• Dart, per cui Google voleva mettere una macchina virtuale dentro Chrome, e ha rinunciato: oggi Dart compila in JavaScript.

Il caso più istruttivo è TypeScript, perché ha vinto. Solo che non sostituisce JavaScript: ci compila dentro. Anche WebAssembly, che è veloce e serio, non lo tocca il DOM: per muovere un pixel deve comunque chiamare JavaScript. È un compagno, non un erede.

Il 2015 è l'anno in cui è diventato un linguaggio serio

ES2015 porta let e const, i moduli, le classi, le promise, le arrow function. Da lì in poi c'è un rilascio all'anno e un processo a stadi per proporre modifiche. Prima si scriveva JavaScript nonostante il linguaggio, con librerie che tappavano i buchi; da lì si è cominciato a scriverlo con il linguaggio.

In mezzo, nel 2009, era già arrivato Node: lo stesso linguaggio anche sul server. Il che è comodo e allo stesso tempo è la porta da cui è entrato il problema di oggi, che non è più la sintassi ma la quantità.

Cosa c'entra questo con il tuo sito

Se stai facendo fare un sito, questa storia ti riguarda in tre punti concreti.

Il primo: tutto quello che si muove in una pagina passa da JavaScript. Non è una preferenza di chi lo sviluppa, è l'unico linguaggio che il browser sa eseguire. Chiedere "si può fare senza JavaScript" quasi mai ha senso; chiedere "quanto ne arriva all'utente" ha molto senso.

Il secondo: la retrocompatibilità che tiene in vita typeof null è la stessa che permette al sito di un'azienda di aprirsi ancora dieci anni dopo. È una garanzia che nessun'altra piattaforma ti dà.

Il terzo, ed è quello che vedo sbagliare più spesso: siccome aggiungere una libreria costa un comando, se ne aggiungono troppe. Ogni libreria è peso che l'utente scarica, e quel costo non lo paga chi sviluppa dal suo portatile — lo paga chi apre il sito in 4G mentre cammina. Quando facciamo un progetto di sviluppo web è la prima voce che guardiamo: quanto JavaScript arriva davvero al browser, e cosa si vede se non arriva.

La mia posizione

JavaScript non lo difendo perché è elegante, perché non lo è. Lo difendo perché è l'unico pezzo grosso di infrastruttura che ha deciso di non rompere niente, e ha tenuto la parola. Il conto di quella scelta lo paghiamo in bug del 1995 che ci portiamo dietro per sempre.

Mi sembra un affare. Un linguaggio progettato meglio, in dieci giorni, non lo avremmo avuto comunque. Un web in cui le pagine vecchie si aprono ancora, invece, ce lo siamo tenuto.