La demonizzazione di JavaScript
JavaScript è una barzelletta di linguaggio, dovresti impararne uno vero per poterti definire programmatore
"JavaScript è una barzelletta di linguaggio, dovresti impararne uno vero per poterti definire programmatore."
Se fai frontend, questa frase ti suonerà familiare. Ma al di là del solito sfottò, penso che valga la pena riflettere: i nostri siti web hanno davvero bisogno di tutto questo JavaScript?
Oggi se voglio creare un blog, la mia prima preoccupazione non è l'HTML o il CSS. Penso subito: "Quale framework posso provare?" E non è solo un capriccio. Nel 2025, sviluppare un sito web da zero con solo HTML, CSS e JavaScript? Impensabile. I framework esistono per un motivo: funzionano, sono usati ovunque e hanno problemi già risolti su Stack Overflow.
Ma non è corretto affermare che un framework (che utilizza JavaScript) produca troppo JavaScript, e questo blog (fatto in Astro) ne è un esempio. Sebbene la maggior parte dei componenti sia scritta in JSX, quest'ultimo viene usato principalmente come sistema di templating. Essendo un porting da una "vecchia" app in Next.js, ci sono ancora alcuni script che possono essere gradualmente rimossi - devo solo trovare la voglia di farlo.
Astro infatti è uno di quei framework che si pone come server-first e 0 JS sul client, quindi, a scanso di fraintendimenti i fiumi di JavaScipt servono solo a scrivere il backend.
D'altra parte, ci tengo che quei quattro gatti che stanno leggendo questo articolo lo facciano attraverso l'ennesimo framework che, nell'hero, sbandiera il suo blazing fast™ - sì, perché devono assaporarlo, il frutto della mia FOMO.
Ma a parte Astro che è un unicum, non tutti i framework JavaScript seguono questa filosofia.
Ed ecco il punto: col tempo abbiamo iniziato a inondare il web di JavaScript. Troppo. E forse il mondo se ne sta accorgendo.
Un'evoluzione continua
Lavoro nel frontend dal 2017 e ho visto le tendenze cambiare velocemente. All'inizio, tutto era una SPA: client-side, veloce™. Ma in realtà poche erano davvero robuste. Poi abbiamo capito che le SPA non erano la soluzione universale e siamo tornati al server-side rendering con interattività lato client.
Tuttavia, sebbene il server-side permetta di vedere un contenuto minimo quando il JavaScript si rompe, non garantisce che il resto del sito rimanga minimamente funzionante.
Diciamo che la gente preferisce vedere del contenuto anziché una laconica schermata bianca solo perché il tuo analytics è andato in errore, sempre meglio di niente.
E quindi? Abbiamo capito che la migliore delle SPA è superiore alla migliore delle MPA, ma la media delle SPA è peggiore della media delle MPA. Il risultato? Frustrazione e la necessità di trovare un equilibrio tra i due mondi.
Il progressive enhancement come soluzione
Garantire una funzionalità minima in partenza e migliorare progressivamente l'esperienza utente è un approccio sempre più considerato. Il governo del Regno Unito, ad esempio, lo adotta dal 2016 come requisito per i suoi siti web. Perché? Perché circa l'1% degli utenti non ha JavaScript attivo. Le cause? Errori di rete, estensioni browser, VPN restrittive, CDN malfunzionanti, ISP che iniettano codice. E se l'1% è poco, dipende: per un e-commerce potrebbe significare migliaia di vendite perse.
Certo, non mi sento di dare troppo forza alle mie argomentazioni considerando che parliamo dello stesso paese fautore della Brexit, ma su questo articolo sono inciampato.
Un esempio concreto
Una sera volevo comprare una tastiera. Costosa, forse superflua, ma ero deciso. La metto nel carrello, clicco su checkout… niente. Errori JavaScript in console. Dopo vari tentativi mollo. L'indomani cambio idea: acquisto sfumato. Un piccolo bug, una vendita persa.
Se il sito avesse previsto una modalità minima di funzionamento, magari avrei comprato quella tastiera e loro avrebbero incassato.
In compenso ne ho comprata un'altra, se può interessare.
Il futuro del frontend
JavaScript non scomparirà, ma il suo ruolo è destinato a cambiare. Non deve essere il pilastro su cui si regge tutto il web, ma un miglioramento dell'esperienza utente. A differenza di HTML e CSS, JavaScript non è fault-tolerant: se si rompe, l'intera esperienza crolla.
Passerò come il solito vecchio che urla alle nuvole, ma il progressive enhancement non è un'utopia, ma una necessità. Forse è ora di ripensare al nostro rapporto con JavaScript.
