Nel febbraio del 2011, poco dopo che Gawker Media lanciò un redesign unificato delle sue varie proprietà (Lifehacker, Gizmodo, Jezebel, etc.), gli utenti che visitavano questi siti venivano accolti da una pagina vuota, senza alcun contenuto. Cos’era successo? JAvaScript era successo. O meglio, JavaScript non era successo.¹

Lifehacker durante l’inconveniente JavaScript del 2011.

Nella creazione dell’architettura delle sue nuove piattaforme, Gawker Media ha adottato JavaScript come metodo di delivery per i propri contenuti. Manda un guscio HTML vuoto al browser e poi carica l’effettivo contenuto della pagina via JavaScript. La saggezza popolare dice che questo approccio rende questi siti più “simili alle app” e ”moderni”. Ma nel giorno del lancio, un unico errore nel codice JavaScript su cui gira la piattaforma ha messo in ginocchio il sistema. Quell’unico errore solitario ha causato un lungo ”blackout” (uso questo termine deliberatamente perché i server in realtà stavano funzionando) per ogni proprietà di Gawker e ha fatto perdere all’azienda innumerevoli page views e impressions.

Vale la pena notare che, negli anni a seguire, Gawker Media ha aggiornato i suoi siti affinché inviino contenuto in assenza di JavaScript.

■ ■ ■

Una sera del gennaio 2014, molto tardi, il “parental filter” usato da Sky Broadband, uno dei maggiori ISP (Internet Service Providers) del Regno Unito cominciò a classificare code.jquery.com come un sito web di “malware e phishing”.² Il CDN (content delivery network) di jQuery si trova proprio a quell’URL. Nessun problema, jQuery è solo la libreria JavaScript su cui fanno affidamento i tre quarti dei 10000 top siti web al mondo per far funzionare le proprie pagine!

Con il dominio caratterizzato in maniera così errata, il firewall di Sky si mise in azione e cominciò a “proteggere” la gran parte dei propri clienti da codice “malicious”. Tutto a un tratto, grandi porzioni del Web hanno smesso all’improvviso di funzionare per ogni cliente di Sky Broadband che non aveva disabilitato esplicitamente tale protezione. Ogni sito che si basava su una copia di jQuery di quel CDN per caricare il proprio contenuto, mostrare pubblicità o permettere delle interazioni era morto, anche se non per colpa sua.

■ ■ ■

Nel settembre del 2014, Art Technica ha rivelato che Comcast stava facendo inject di pubblicità auto-promozionali nei siti web che passavano dai suoi hotspot Wi-Fi.³ Tali injection costituiscono a tutti gli effetti un attacco “man-in-the-middle”⁴, creando una situazione che aveva il potenziale di far smettere di funzionare un sito. L’esperto di sicurezza Dan Kaminsky ne ha parlato in questi termini:

Tu sviluppatore del sito non sai più esattamente che codice il browser là fuori sta facendo girare. Non l’hai mandato tu, ma i tuoi clienti l’hanno ricevuto.

Comcast non è la sola organizzazione a fare queste cose. Gli hotel, gli aeroporti e altri provider di Wi-Fi “gratis” fanno regolarmente injection di pubblicità e di altro codice nei siti web che passano sulle proprie reti.

■ ■ ■

Molti web designer e developer pensano a torto che il supporto per JavaScript sia un dato di fatto o che le questioni legate a JavaScript stiano scomparendo con il declino di IE 8, ma queste tre storie sono tutte recenti e nessuna di queste riguardava un problema di supporto da parte di un browser. Se queste storie ci dicono qualcosa è che dovete sviluppare la Chrysler Imperial del 1964⁵ dei siti web: siti che continuano a funzionare anche quando vengono presi a pugni da tutte le parti. Dopo tutto, device, browser, plugin, server, network e perfino i router che fondamentalmente mandano in giro i vostri siti hanno tutti diritto di parola sul modo in cui il contenuto (e su quale contenuto) arriva effettivamente ai vostri utenti.

Prendete confidenza con i potenziali problemi così da poterli evitare#section1

Sembra quasi che una settimana sì e una no esca un nuovo framework JavaScript, che cerca di proporre un nuovo approccio che “rivoluzionerà” il modo in cui creiamo siti web. Framework come Angular, Ember, Knockout e React eliminano il modello tradizionale dei browser che navigano da pagina a pagina di contenuto generato dal server. Al contrario, questi framework sostituiscono completamente il browser e gestiscono tutte le richieste al server, solitamente facendo il fetch di un tot di pezzi di contenuto alla volta per controllare l’intera esperienza dall’inizio alla fine. Basta refresh di pagina. Basta attese.

C’è solo un problema: senza JavaScript, non succede niente di tutto ciò.

No, non sono qui a dirvi che non dovreste usare JavaScript⁶. Io penso che JavaScript sia uno strumento incredibile e sono fermamente convinto che possa migliorare le esperienze degli utenti… Quando è usato saggiamente.

Comprendere il medium#section2

Agli albori del Web, i “veri” software developer scartavano JavaScript. Molti lo vedevano come un linguaggio “giocattolo” (e la pensavano allo stesso modo per HTML e CSS). Secondo loro, non era potente come Java o Perl o C, quindi non valeva la pena impararlo. Negli anni a seguire, però, JavaScript è cambiato tanto.

Molti di questi developer hanno cominciato a prestare attenzione a JavaScript a metà degli anni 2000, quando Ajax è diventato popolare, ma sono dovuti passare altri anni prima che cominciassero a portare a frotte il proprio talento sul web, attirati dai framework JavaScript e dalla loro promessa di un’esperienza di sviluppo per il web più tradizionale. Questa, tutto sommato, è una buona cosa: c’è bisogno di più persone che lavorino sul web per migliorarlo. L’unico problema che io ho visto, però, è la fondamentale disconnessione che gli sviluppatori di software tradizionali sembrano avere con il modo in cui funziona il deploy del codice sul web.

Nello sviluppo software tradizionale, potete dire la vostra sull’ambiente di esecuzione. Sul Web, non potete. Mi spiego: se sto scrivendo del software server-side in Python o Rails o addirittura in PHP, una di queste due cose è vera:

• io controllo l’ambiente server, incluso il sistema operativo, le versioni del linguaggio e i package.
• Io non controllo l’ambiente server, ma lo conosco e posso creare il mio programma di conseguenza, così che verrà eseguito secondo le aspettative.

Nel mondo più tradizionale del software installato, potete controllare in maniera simile l’ambiente mettendo certe restrizioni su quali sistemi operativi sono supportati dal vostro codice e quali dependencies potete avere (come lo spazio disco o la RAM disponibili). Fornite subito questa informazione e i vostri potenziali utenti possono scegliere il vostro software o un prodotto concorrente basandosi su quello che funziona per loro.

Sul Web, tuttavia, non valgono più queste premesse. Il Web è ovunque. Il Web è disordinato e, per quanto io voglia controllare fino al pixel l’esperienza di un utente, comprendo che non succederà mai perché non è così che funziona il Web. La frustrazione che sento a volte per via della mancanza di controllo è anche incredibilmente liberatoria e mi spinge a trovare approcci più creativi. Sfortunatamente, gli sviluppatori software tradizionali che hanno poca esperienza del web non sono ancora scesi a patti con questo. È comprensibile: ci sono voluti un po’ di anni anche per me.

Non si controlla l’ambiente in cui viene eseguito il proprio codice JavaScript, interpretato il proprio HTML o applicato il CSS. Gli utenti controllano il device (e, di conseguenza, la velocità del suo processore, la sua RAM, etc.). A seconda del device, gli utenti potrebbero scegliere il sistema operativo, il browser e la versione del browser che utilizzano. Gli utenti possono decidere quali add-on usare nel browser. Gli utenti possono rimpicciolire o ingrandire i font utilizzati per visualizzare il vostro sito. E gli Internet provider si mettono tra voi e gli utenti, dettando legge sulla velocità di rete, regolando la latency e in fin dei conti controllando in che modo (e che parte del) vostro contenuto arriva al loro browser. Tutto quello che potete fare è realizzare un’esperienza convincente, che si sappia adattare e poi incrociare le dita e sperare per il meglio.

Il problema fondamentale del dare JavaScript per scontato, che è quello che fanno questi framework, è che crea l’illusione del controllo. È facile razionalizzare questa prospettiva quando avete accesso all’hardware più recente e più performante e ad una connessione a internet stabile e veloce. Se non avete mai guardato fuori dalla bolla del nostro settore, potreste pensare che tutti i vostri utenti siano così ben equipaggiati. Ovviamente, se state creando una web app interna, potreste essere in grado di decidere la combinazione OS/browser per tutti i vostri utenti e bloccare le loro macchine così che non possano modificare alcuna impostazione, ma questa non è la realtà dell’open Web. Il fatto è che non potete assolutamente fare affidamento sulla disponibilità di una qualsiasi tecnologia specifica quando dovete mandare il vostro sito web nel mondo.

È di importanza vitale realizzare le esperienze del proprio sito web perché funzionino in qualunque situazione riflettendo a priori sul modo in cui si usano specifiche tecnologie, come JavaScript. Sfruttate i loro benefici ma contemporaneamente dovete capire che la loro disponibilità non è scontata. Questo è il progressive enhancement.

La storia del Web è costellata di storie di disastri legati a JavaScript. Questo non vuol dire che non dovreste usare JavaScript o che sia intrinsecamente pessimo. Semplicemente vuol dire che dovete adottare un approccio “smart” al suo utilizzo. Dovete creare esperienze robuste che permettano agli utenti di fare quello di cui hanno bisogno rapidamente e facilmente, anche se le vostre interfacce ”JavaScript-driven” attentamente realizzate e incredibilmente ben progettate non funzionano.

Perché niente JavaScript?#section3

Spesso, il termine progressive enhancement è sinonimo di “niente JavaScript”. Se avete letto fin qua, spero capiate che questa è solo una piccola parte del puzzle. Milioni di utenti Web hanno JavaScript, è supportato dalla maggior parte dei browser e pochi utenti lo disabilitano. Potete – in realtà dovete – usare JavaScript per creare esperienze spettacolari e coinvolgenti sul web.

Se è così onnipresente, potreste anche chiedervi perché ci si debba addirittura curare dello scenario “no JavaScript”. Spero che le storie che ho condiviso prima abbiamo fatto un po’ di luce sulla questione, ma se non foste ancora convinti di aver bisogno di una strategia “no JavaScript”, considerate questo: il GDS (Government Digital Service) del Regno Unito ha condotto un esperimento per determinare quanti dei suoi utenti non avevano ricevuto gli enhancement basati su JavaScript e ha scoperto che il numero si attesta al 1.1%, ossia a 1 utente su 93⁷, ⁸. Per un sito di e-commerce come Amazon, questo numero si traduce in 1,75 milioni di persone al mese: un numero veramente grande⁹. Tuttavia, questa non è la parte interessante.

Primo, vediamo un attimo la metodologia seguita da GDS: ha svolto l’esperimento su una pagina ad alto traffico con un pubblico vasto, quindi si è trattato di un esempio live più rappresentativo del quadro reale, il che vuol dire che i numeri non erano alterati dalla raccolta di informazioni provenienti solo da una sottosezione della sua user base. L’esperimento stesso si riduceva a tre immagini:

• un’immagine di riferimento inclusa in un elemento img
• un’img contenuta in un elemento noscript
• un’immagine che sarebbe stata caricata via JavaScript

L’elemento noscript, se non lo conoscete, ha come scopo l’incapsulamento di contenuto che volete mostrare quando JavaScript non è disponibile. È un modo pulito per offrire un’esperienza alternativa negli scenari “no JavaScript”. Quando JavaScript è disponibile, il browser ignora completamente il contenuto dell’elemento noscript.

Con questo setup in atto, l’aspettativa era che tutti gli utenti ottenessero due immagini. Gli utenti che ricadevano nel campo “no JavaScript” avrebbero ricevuto le immagini 1 e 2 (i contenuti di noscript sono esposti solo quando JavaScript non è disponibile o off). Gli utenti che potevano usare JavaScript avrebbero ottenuto le immagini 1 e 3.

Quello che il GDS non aveva previsto, però, era un terzo gruppo: gli utenti a cui sarebbe arrivata l’immagine 1 ma nessuna delle altre immagini. In altre parole, avrebbero dovuto ricevere l’enhancement JavaScript (perché noscript non era stato valutato), ma non l’hanno ricevuto (perché la JavaScript injection non è avvenuta). Probabilmente sorprende di più che questo fosse il gruppo rappresentante la gran parte degli utenti “no JavaScript”, lo 0,9% degli utenti (rispetto allo 0,2% di quelli che hanno ricevuto l’immagine 2).

Cosa avrebbe potuto causare ciò? Molte cose:

• errori JavaScript introdotti dagli sviluppatori
• errori JavaScript introdotti da codice di terze parti sulla pagina (e.g., ads, widgets di condivisione e simili)
• errori JavaScript introdotti da add-on del browser controllati dall’utente
• JavaScript bloccato da un add-on del browser
• JavaScript bloccato da un firewall o ISP (o modificato, come nel precedente esempio di Comcast)
• un programma JavaScript mancante o incompleto dovuto a problemi di connessione alla rete (lo scenario del “treno che entra in galleria”)
• un download di JavaScript ritardato a causa della lentezza della velocità di download della rete
• un programma JavaScript mancante o incompleto a causa di un blackout del CDN
• RAM insufficiente per caricare ed eseguire JavaScript¹⁰.

Un device BlackBerry che cerca di navigare verso il sito della campagna Obama for America nel 2012. Ha finito la RAM cercando di caricare 4.2MB di HTML, CSS e JavaScript. Photo credit: Brad Frost

Sono una miriade di potenziali problemi che possono influenzare la ricezione da parte dell’utente della vostra esperienza ”JavaScript-based”. Non li sto sollevando per spaventarvi e non farvi più usare JavaScript, voglio solo essere sicuro che capiate quanti fattori possono influenzare la sua ricezione da parte degli utenti. In verità, la maggior parte dei vostri utenti otterrà i vostri enhancement. Semplicemente, non mettete tutte le vostre uova nel paniere di JavaScript. Diversificate i modi in cui inviate i contenuti e le esperienze: riduce il rischio ed assicura che il vostro sito supporterà il maggior numero di utenti. Ripaga sempre sperare per il meglio e pianificare per il peggio.

Note#section4

• 1. http://perma.cc/B7KR-HWLM
• 2. http://perma.cc/KRX9-V82T
• 3. http://perma.cc/E53Y-LL39
• 4. http://perma.cc/RB97-MENZ
• 5. La Chrysler Imperial del 1964 è una leggenda. È una delle poche auto che è stata completamente bandita dagli eventi “demolition derby” perché era praticamente indistruttibile.
• 6. Sarebbe un capitolo breve se lo scrivessi.
• 7. http://perma.cc/5SBR-58CD
• 8. Uno studio recente di Pew Research ha affermato che la percentuale di persone senza JavaScript che hanno partecipato al suo sondaggio si avvicina al 15%, il che sembra una follia. Tra l’altro, ha anche scoperto che “gli strumenti più vistosi resi possibili da JavaScript non migliorano e anzi potrebbero deteriorare la qualità dei dati”. Si veda http://perma.cc/W7YK-MR3K.
• 9. La statistica più recente che ho visto afferma che Amazon.com ha circa 175 milioni di visitatori unici al mese. Si veda http://perma.cc/ELV4-UH9Q.
• 10. Stuart Langridge ha messo insieme un bellissimo grafico di questi su http://perma.cc/BPN4-5XRR se volete decorare il vostro ufficio.

Illustrazioni: {carlok}