{"id":651,"date":"2016-08-23T09:31:45","date_gmt":"2016-08-23T07:31:45","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/interazione-enhancement\/"},"modified":"2016-08-23T09:31:45","modified_gmt":"2016-08-23T07:31:45","slug":"interazione-enhancement","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/interazione-enhancement\/","title":{"rendered":"L’interazione \u00e8 un enhancement"},"content":{"rendered":"
\n

Nota degli editori:<\/strong> Siamo lieti di offrirvi questo estratto dal Capitolo 5 del libro di Aaron Gustafson, Adaptive Web Design, Second Edition<\/cite>. Acquistate il libro da New Riders<\/a> con il 35% di sconto utilizzando il codice AARON35.<\/p>\n<\/div>\n

\n

Nel febbraio del 2011, poco dopo che Gawker Media lanci\u00f2 un redesign unificato delle sue varie propriet\u00e0 (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<\/em> successo.1<\/a><\/sup><\/p>\n

\"Screenshot<\/p>\n

Lifehacker durante l’inconveniente JavaScript del 2011.<\/p>\n<\/div>\n

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\u00f9 \u201csimili alle app\u201d e \u201dmoderni\u201d. 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 \u201dblackout\u201d (uso questo termine deliberatamente perch\u00e9 i server in realt\u00e0 stavano funzionando) per ogni propriet\u00e0 di Gawker e ha fatto perdere all’azienda innumerevoli page views e impressions.<\/p>\n

Vale la pena notare che, negli anni a seguire, Gawker Media ha aggiornato i suoi siti affinch\u00e9 inviino contenuto in assenza di JavaScript.<\/p>\n

\u25a0 \u25a0 \u25a0<\/p>\n

Una sera del gennaio 2014, molto tardi, il \u201cparental filter\u201d usato da Sky Broadband, uno dei maggiori ISP (Internet Service Providers) del Regno Unito cominci\u00f2 a classificare code.jquery.com<\/code> come un sito web di \u201cmalware e phishing\u201d.2<\/a><\/sup> Il CDN (content delivery network) di jQuery si trova proprio a quell’URL. Nessun problema, jQuery \u00e8 solo la libreria JavaScript su cui fanno affidamento i tre quarti dei 10000 top siti web al mondo per far funzionare le proprie pagine!<\/p>\n

Con il dominio caratterizzato in maniera cos\u00ec errata, il firewall di Sky si mise in azione e cominci\u00f2 a \u201cproteggere\u201d la gran parte dei propri clienti da codice \u201cmalicious\u201d. 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\u00e0 o permettere delle interazioni era morto, anche se non per colpa sua.<\/p>\n

\u25a0 \u25a0 \u25a0<\/p>\n

Nel settembre del 2014, Art Technica<\/cite> ha rivelato che Comcast stava facendo inject di pubblicit\u00e0 auto-promozionali nei siti web che passavano dai suoi hotspot Wi-Fi.3<\/a><\/sup> Tali injection costituiscono a tutti gli effetti un attacco \u201cman-in-the-middle\u201d4<\/a><\/sup>, 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:<\/p>\n

Tu sviluppatore del sito non sai pi\u00f9 esattamente che codice il browser l\u00e0 fuori sta facendo girare. Non l’hai mandato tu, ma i tuoi clienti l’hanno ricevuto.<\/p><\/blockquote>\n

Comcast non \u00e8 la sola organizzazione a fare queste cose. Gli hotel, gli aeroporti e altri provider di Wi-Fi \u201cgratis\u201d fanno regolarmente injection di pubblicit\u00e0 e di altro codice nei siti web che passano sulle proprie reti.<\/p>\n

\u25a0 \u25a0 \u25a0<\/p>\n

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 \u00e8 che dovete sviluppare la Chrysler Imperial del 19645<\/a><\/sup> 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.<\/p>\n<\/div>\n

\n

Prendete confidenza con i potenziali problemi cos\u00ec da poterli evitare<\/h2>\n

Sembra quasi che una settimana s\u00ec e una no esca un nuovo framework JavaScript, che cerca di proporre un nuovo approccio che \u201crivoluzioner\u00e0\u201d 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.<\/p>\n

C’\u00e8 solo un problema: senza JavaScript, non succede niente di tutto ci\u00f2.<\/p>\n

No, non sono qui a dirvi che non dovreste usare JavaScript6<\/a><\/sup>. Io penso che JavaScript sia uno strumento incredibile e sono fermamente convinto che possa migliorare le esperienze degli utenti\u2026 Quando \u00e8 usato saggiamente.<\/p>\n

Comprendere il medium<\/h3>\n

Agli albori del Web, i \u201cveri\u201d software developer scartavano JavaScript. Molti lo vedevano come un linguaggio \u201cgiocattolo\u201d (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\u00f2, JavaScript \u00e8 cambiato tanto.<\/p>\n

Molti di questi developer hanno cominciato a prestare attenzione a JavaScript a met\u00e0 degli anni 2000, quando Ajax \u00e8 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\u00f9 tradizionale. Questa, tutto sommato, \u00e8 una buona cosa: c’\u00e8 bisogno di pi\u00f9 persone che lavorino sul web per migliorarlo. L’unico problema che io ho visto, per\u00f2, \u00e8 la fondamentale disconnessione che gli sviluppatori di software tradizionali sembrano avere con il modo in cui funziona il deploy del codice sul web.<\/p>\n

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 \u00e8 vera:<\/p>\n