Smashing Podcast Episodio 45 con Jeremy Wagner: cos'è JavaScript responsabile?

Questo episodio è stato gentilmente supportato dai nostri cari amici di Wix, la piattaforma per i professionisti per creare siti di clienti, gestire progetti complessi e far crescere le attività online. Grazie!

In questo episodio parliamo di JavaScript responsabile. Cosa significa per il codice essere responsabile e come dovremmo affrontare i progetti in modo diverso? Ho parlato con l'esperto Jeremy Wagner per scoprirlo.

Mostra note

• Sito Web JavaScript responsabile
• Acquista il libro da Un libro a parte
• Il sito personale di Jeremy
• Jeremy su Twitter

Aggiornamento settimanale

• Fitts' Law In The Touch Era scritto da Steven Hoober
• Web Design Fatto bene: Perfettamente inutile scritto da Frederick O'Brien
• Tutto quello che vuoi sapere sulla creazione di interfacce utente vocali scritte da Nick Babich e Gleb Kuznetsov
• Implicazioni dell'adesione di WordPress al protocollo Block scritto da Leonardo Losoviz
• Pensieri su Markdown scritto da Knut Melvar

Trascrizione

Drew McLellan: È uno scrittore tecnico, nerd di prestazioni web, sviluppatore e oratore, attualmente lavora in Google. Ha scritto per A List Apart, CSS-Tricks e Smashing Magazine, ed è l'autore di un nuovo titolo, Responsible JavaScript per A Book Apart. Quindi sappiamo che è un abile tecnico e comunicatore, ma sapevi che vuole circumnavigare il globo su una tavola da paddle standup? Miei formidabili amici, vi prego di dare il benvenuto a Jeremy Wagner. Ciao Jeremy, come stai?

Jeremy Wagner: Sto distruggendo. Come stai?

Drew: Sto molto bene. Grazie. Volevo parlarti oggi di questa idea di JavaScript responsabile. Si tratta di una sorta di nuovo approccio o tecnica o stai letteralmente parlando di utilizzare JavaScript in modo responsabile?

Jeremy: Sto letteralmente parlando di usare JavaScript in modo responsabile. Quindi, secondo l'archivio HTTP, abbiamo visto un aumento medio di quasi il 58% della quantità di JavaScript scaricato dai dispositivi mobili da circa 290 kilobyte a quasi 500 kilobyte nell'ultimo anno.

Drew: Wow.

Jeremy: Quindi, quando parlo di usare JavaScript in modo responsabile, è il primo tipo di approccio dell'utente a dire... valutare criticamente cosa stiamo costruendo ed è l'obiettivo di ciò che stiamo costruendo servito dalle moderne pratiche di sviluppo web, quindi parlare. E immagino che sia una specie di... forse non ironico, ma non stavo prendendo un colpo allo sviluppo web moderno, ma un sottoprodotto dello sviluppo web moderno è che è molto facile aggiungere dipendenze ai progetti. Tutto è a un'installazione MPM e ogni installazione MPM ha un costo, che varia. Ma quello che vediamo è che in quei dati di archivio HTTP, il 95° percentile... significa il 5% di esperienze che sono le più lente... o non le più lente, ma che spediscono più JavaScript, che è aumentato nell'ultimo anno di circa 875 kilobyte a circa 1,4 megabyte.

Drew: Wow.

Jeremy: Quindi è un'enorme quantità di JavaScript che viene trasferita e ha implicazioni sia sulle prestazioni di caricamento che sulle prestazioni di runtime.

Drew: Quindi hai menzionato la performance lì. Sembra che l'esperienza web moderna dal mio punto di vista sia come il 10% di HTML e CSS e il 90% di JavaScript. E ci devono essere una sorta di considerazioni sulle prestazioni a questo. Voglio dire, hai parlato della quantità di dati che stiamo trasferendo, ma ci sono altre considerazioni sulle prestazioni con un sacco di JavaScript.

Jeremy: Giusto. Quindi, avendo una connessione Internet lenta e sai... dove vivo negli Stati Uniti, se vai abbastanza lontano da una grande città, diventa un po' difficile a seconda di dove vai... per far fronte alla lentezza di Internet può essere sorta di queste aree rurali ed è significativo per le persone che vivono in aree come questa. E quindi l'aspetto delle prestazioni di caricamento è già abbastanza impegnativo quando inizi a spedire megabyte di JavaScript, ma potresti anche avere a che fare con qualcuno che non ha un iPhone ... come un iPhone X o come un iPhone 13.

Jeremy: Potrebbero essere semplicemente su un telefono con funzionalità o semplicemente come un telefono Android economico, solo cercando di navigare nella vita. Voglio dire, pensa a cose come l'online banking, l'assistenza alla disoccupazione o altra assistenza governativa, portali del genere per le domande. L'apprendimento online, ci sono solo molti posti in cui JavaScript eccessivo può davvero avere un effetto dannoso per le persone che potrebbero non essere abbastanza fortunate da vivere in grandi aree metropolitane o anche in aree metropolitane che non sono ben servite da Internet a banda larga e quelle su dispositivi più lenti . In un certo senso, come sviluppatori, abbiamo questa tendenza a guardare... acquistiamo MacBook o questi dispositivi di fascia alta e a volte non vediamo davvero dove possono sorgere questi problemi quando utilizziamo JavaScript in modo eccessivo.

Drew: E più o meno come hai detto lì, a volte sono le persone che hanno il tipo di posizione più da perdere per non essere in grado di accedere a un servizio che vengono penalizzate da questo genere di cose. Quelle persone senza connessioni dati veloci o senza dispositivi molto capaci a volte accedono a servizi che significano tutto per... significa tutto per loro a cui sono in grado di accedere. Quindi in qualche modo diventa quasi una questione di diritti umani.

Jeremy: Sì. Voglio dire, tendiamo a vedere le prestazioni web inquadrate in termini di valore aziendale. Ero un consulente di prestazioni per alcune e-com e come una grande azienda alimentare, una grande e-com... come un negozio, come un punto vendita di elettronica ed è molto allettante farlo, giusto? Perché quando lavori per un'azienda, voglio dire, ovviamente vuoi che i dati finanziari siano sani e le prestazioni web hanno un ruolo in questo penso. Penso che ci siano una serie di casi di studio che lo dimostrano. Tuttavia, c'è quell'aspetto umano e anche per le aziende, come per esempio i negozi di alimentari e quel genere di cose. Sì, sono guidati dalle entrate. Vogliono avere finanze sane e quindi le prestazioni web ne fanno parte, ma soddisfano anche un'esigenza fondamentale, giusto? Come se dovessi mangiare, giusto?

Jeremy: E come se alcune persone potrebbero essere costrette a casa per un motivo o per l'altro. Potrebbero non essere in grado di salire facilmente in macchina. Potrebbero non avere una macchina. Quindi fanno affidamento su questi servizi per ottenere sostentamento, ma più di questo, assistenza se ne hanno bisogno e soprattutto come l'intervento in caso di crisi e quel tipo di cose. Non credo sia terribilmente inverosimile dire che un partner che è stato maltrattato e cacciato da casa potrebbe rivolgersi al proprio smartphone e, e colpire Google per cercare di trovare un portale per l'intervento e l'assistenza in caso di crisi. E in qualche modo JavaScript può intralciare questi tipi di obiettivi e soddisfare quei bisogni umani. Quando abbiamo la tendenza ad appoggiarci un po' troppo.

Drew: Voglio dire, abbiamo visto una sorta di barlume di ciò negli ultimi 18 mesi circa con il COVID e le persone che sono andate in isolamento e, come dici tu, hanno bisogno di ordinare la spesa da consegnare. Il web diventa un'ancora di salvezza per loro a quel punto. Si sentono in difficoltà, non possono lasciare il loro alloggio perché si stanno isolando e devono procurarsi il cibo e le provviste essenziali. Quindi sì, è una parte sempre più importante della vita di tutti i giorni per tutti noi, penso.

Jeremy: Esattamente. E tornando al tipo di storia del dispositivo, Tim Kadlec ha scritto un pezzo straordinario un paio di anni fa, penso che fossero due anni, forse tre anni fa, ma si chiamava Prioritizing the Long Tail of Performance. E quando lo guardi... quindi nel gergo delle prestazioni web, parliamo di dati di laboratorio rispetto a dati sul campo. E i dati di laboratorio sono come quando stai eseguendo il faro o stai lanciando un sito Web a un test di una pagina Web per vedere come sta andando. Questi sono tutti strumenti davvero utili, ma quando guardi quei dati sul campo, inizi davvero a ottenere un quadro più ampio e una visione più ampia di chi è veramente il tuo pubblico. E in questo articolo, Tim Kadlec parla di cosa significa dare la priorità alla coda lunga delle prestazioni. Significa tutti questi dispositivi che... forse non sono così robusti e potenti come i dispositivi che potremmo avere noi sviluppatori.

Jeremy: E l'idea alla base di quell'articolo è che se possiamo concentrarci su quel 90° o 95° percentile siamo... e migliorare quell'esperienza per quelle persone, stiamo costruendo un web più veloce per tutti, compresi quelli su dispositivi veloci. E attacca un punto dati su questo negli Stati Uniti e questo proviene proprio da come statcounter.com. Qualcosa come 28 punti... circa il 28% delle persone utilizza un dispositivo iOS che questo strumento acquisisce. E circa il 21% di loro sono Android. E Android tende a rappresentare una buona parte di quella lunga coda di dispositivi, perché Android non è monolitico. Diversi produttori di dispositivi producono telefoni Android, ma in un certo senso in contrasto con il mondo, poiché il mondo è più degli Stati Uniti, sono circa il 16% delle persone che usano iOS e circa il 41% delle persone che usano Android. Quindi vale davvero la pena dare la priorità a quelle esperienze più lente o potenzialmente più lente.

Drew: Ho letto nel tuo libro sulla limitazione termica del dispositivo, che non è qualcosa che non avevo mai considerato prima. Quali sono le preoccupazioni?

Jeremy: Le preoccupazioni ci sono, e non sono affatto un esperto di microprocessori. Sono solo lo sviluppatore web che probabilmente scrive un po' troppo, ma... quindi l'idea alla base del throttling termico e questo esiste in tutti i sistemi, non solo come telefoni e tablet, è che un microprocessore... quando assume carichi di lavoro eccessivi o in realtà solo carichi di lavoro in generale, il prodotto di scarto di quel lavoro è il calore. E quindi i dispositivi hanno modi per mitigare questo. Come se il tuo laptop avesse un dispositivo di raffreddamento attivo e passivo.

Jeremy: Quindi come un dispositivo di raffreddamento passivo è come un dissipatore di calore o una specie di dissipatore di calore. E la parte attiva è come una ventola per disperdere il calore in modo più efficiente. Alcune build come PC personalizzate potrebbero usare come il raffreddamento a liquido, che è una specie di esempio più relativamente estremo, ma un telefono cellulare non lo ha perché dove inserirai davvero una ventola in tutto questo, se la portabilità è un po' tua cosa, giusto?

Jeremy: Quindi, affinché questi dispositivi possano far fronte a questi carichi di lavoro pesanti, possono ridurre artificialmente la velocità del processore, come ridurre la frequenza di clock fino a quando il dispositivo non entra in uno stato in cui tale frequenza di clock può essere aumentata. E questo ha delle implicazioni perché se stai masticando tonnellate e tonnellate e tonnellate e tonnellate di JavaScript, hai come questi grossi pezzi che arrivano giù per il filo, beh, questo dà il via all'elaborazione, giusto? Quindi è un sacco di elaborazione attraverso la valutazione e l'analisi nella compilazione e quindi nell'esecuzione. E se lo stai facendo con uno o due megabyte di JavaScript e hai molti altri processi in corso in background come schede diverse, quel tipo di cose che possono mettere il tuo stato ... ciò aumenta la probabilità che il dispositivo potrebbe entrare in uno stato di limitazione termica, il che significa che sarà meno in grado di svolgere quel lavoro extra.

Drew: Quindi è una sorta di ciclo di feedback negativo. Non è vero? Dai al dispositivo molto lavoro da fare. Diventa molto caldo e quindi è meno in grado di eseguire effettivamente quel lavoro perché deve rallentare.

Jeremy: Giusto. E ancora, non sono un esperto di microprocessori. Sono sicuro che se, se, se un ingegnere che fosse davvero intimamente familiare con questo, potrebbe probabilmente correggermi su alcuni dettagli, ma l'idea generale è che sì, all'aumentare della pressione ambientale, il dispositivo è meno in grado di far fronte a questi pesanti carichi di lavoro fino a quando la pressione non diminuisce.

Drew: quindi stiamo scrivendo JavaScript per l'intero tipo di gamma di dispositivi dell'ultimo Apple M1 Max è il nuovo processore, vero? Dai laptop fino ai dispositivi che hanno a malapena una quantità sufficiente di RAM funzionante per eseguire il rendering di una pagina Web. Ma il web non è iniziato così, gli ascoltatori più giovani potrebbero essere interessati a sapere che costruivamo esperienze web interattive senza alcun JavaScript. La nostra grande e pesante struttura sarà la nostra rovina.

Jeremy: Direi che i framework hanno un tempo e un luogo e coloro che in qualche modo leggono estratti da questo libro possono avere l'idea che io sia anti-framework. E sono decisamente critico nei confronti di diversi framework, ma servono a uno scopo ed è possibile utilizzarli in un modo che preserva una buona esperienza utente o può risultare in una buona esperienza utente. Ma quello che non penso che facciamo abbastanza è una sorta di valutazione critica di questi framework in termini di come danneggiano... le prestazioni a tempo di esecuzione, giusto? Quindi il tipo di cose di cui sto parlando, in cui se fai clic su un pulsante e il dispositivo impiega circa un secondo forse due per rispondere a quell'input, perché c'è così tanto da fare in background. Hai roba JavaScript di terze parti come la raccolta di analisi e poi hai come altre cose in esecuzione sui thread.

Jeremy: E che se non valuti in modo critico le prestazioni di runtime di un framework, potresti lasciare alcune opportunità sul tavolo per servire meglio i tuoi utenti. Quindi un buon esempio, che mi piace sempre usare, è reagire contro pre-agire. È da un po' che suono questo tamburo. Qualche tempo fa ho scritto un articolo per CSS-Tricks che profilava un'interazione di clic di base per come un menu di navigazione mobile. E sembra banale, ma quello che trovi è che su tutti i dispositivi reagisce offre migliori prestazioni di runtime, ma ha sostanzialmente la stessa API. Ci sono differenze, ci sono alcune piccole differenze e cose che possono essere tamponate con la compatibilità pre-act, ma è semplice... e non dovrei dire una scelta semplice, ma quella scelta, quella scelta fondamentale può fare la differenza tra un'esperienza che funziona davvero bene per tutti gli utenti o almeno per la maggior parte degli utenti, o un'esperienza che funziona bene solo per alcuni. Spero che questo abbia un senso.]

Drew: Voglio dire, con tutti i framework e gli strumenti di costruzione, sembra che stiano migliorando continuamente nel fare cose come lo scuotimento degli alberi e l'ottimizzazione dei pacchetti che spediscono e come vengono poi consegnati al browser. Quando si utilizzano framework di grandi dimensioni, c'è un punto critico in cui si sta scrivendo un'applicazione così grande, così tanto codice tutto tuo, che il framework ti consente di spedire meno codice a causa di tutta la sua astrazione?

Jeremy: È una domanda difficile a cui rispondere. Un aspetto di ciò è che il framework stesso rappresenta una quantità di codice che non puoi mai ottimizzare. Quindi avere una struttura sottile, come un pre-atto o un numero qualsiasi di simili... O come un incantesimo per esempio, questo aiuta molto. Ma il problema che ho riscontrato e penso che i dati dell'archivio HTTP supportino questo punto è che sembra che ogni volta che abbiamo questi progressi nei microprocessori e nelle reti che diventano più veloci tendiamo a consumare quel guadagno, giusto?

Jeremy: Tendiamo semplicemente a stare su questo tapis roulant in cui non avanziamo mai davvero. E non so, come se non fossi chiaroveggente su quale sia la storia di... o scusa, come sarà il futuro dei framework. Sono sicuro che ci sono alcuni guadagni di efficienza che possono essere raccolti. Ma quello che vediamo sul campo in termini di quanto è come JavaScript grezzo ... viene utilizzata solo la quantità grezza di JavaScript. Non mi dice che questo è un problema da cui possiamo automatizzare la via d'uscita. Penso che dobbiamo... dobbiamo essere esseri umani e intervenire e prendere decisioni che siano nel migliore interesse degli utenti. Altrimenti, non ci vedo scendere da questo tapis roulant, non nella mia carriera forse, ma non lo so.

Drew: Nel libro parli di siti Web e app Web e di come capire la differenza e con quale stai lavorando ti aiuta a scegliere la tua strategia per come sviluppare e ottimizzare. Raccontaci un po' di questo.

Jeremy: Questa è davvero una bella domanda. E ne scrivo nell'articolo dal titolo omonimo che ho scritto per A List Apart chiamato JavaScript responsabile, parte prima, che è una specie di preludio a questo libro. È che carichiamo molto in questa terminologia. Come uno scrittore tecnico, vedo che i due vengono usati in modo intercambiabile. Quello che vedo è con i siti web, l'implicazione è che è una specie di esperienza multi-età, giusto? È una raccolta di documenti. Ora un documento... quei documenti potrebbero avere funzionalità incorporate come queste piccole isole, come è stato il termine ultimamente, queste piccole isole di funzionalità che consentono alle persone di fare le cose.

Jeremy: Ma poi ci sono app Web e app Web che hanno in qualche modo questa connotazione di funzionalità nativa come app. Quindi stiamo parlando di applicazioni a pagina singola, stiamo parlando di grandi quantità di JavaScript per guidare l'interattività complessa. E ci sono momenti in cui il modello dell'app web ha senso. Ad esempio, Spotify ne è un buon esempio. Funziona meglio come app web. Non vorresti davvero provare a usarlo o progettarlo come un'applicazione multipagina. Come un sito Web tradizionale, ma penso che non sia un'impostazione predefinita sostenibile perché quando l'impostazione predefinita per ogni progetto è dire: "Beh, tutto ciò di cui abbiamo bisogno per spedire un'applicazione a pagina singola, come un router lato client e un framework pesante e scaricare tutto di questa elaborazione di rendering da come il server al client. Penso che sia lì che inizi a raggiungere un punto in cui stai escludendo gli utenti, anche se involontariamente, ma escludendoli comunque.

Drew: C'è un grande abisso, pensi tra le persone che adottano l'approccio che pubblicheremo un sito Web e potrebbe avere qualsiasi funzionalità interattiva e quelli che dicono: "Siamo una società di software, siamo realizzare un prodotto, un prodotto software e la nostra piattaforma attraverso la quale lo consegneremo è il web, piuttosto che applicazioni native per più piattaforme". È probabile che stiano affrontando il problema in modi completamente diversi? Le considerazioni sono diverse a seconda della tua prospettiva a quel punto?

Jeremy: Questa è una domanda difficile. Così-

Drew: È stato difficile per me dirlo.

Jeremy: Direi che un'azienda che... quindi un buon esempio sarebbe come una notizia, giusto? Sono ben serviti dal tipo di modello di sito Web, perché letteralmente è una raccolta di documenti, articoli. E le persone che svilupperanno queste esperienze probabilmente avranno un set di competenze diverso rispetto a un'azienda come Spotify o un'azienda che ha una grande applicazione web come Envision o quel tipo di cose. E quindi sì, penso che arriveranno a questo da diverse angolazioni. Il modo in cui l'ho visto è che c'è un segmento... o almeno questo è il modo in cui ho percepito la comunità di sviluppo web in generale è che c'è un segmento di persone, di sviluppatori web che provengono dallo sviluppo di software non tradizionale sfondi, giusto? E io sono una di queste persone, stavo armeggiando con il web quando ero un po' come un bambino, giusto?

Jeremy: Come alle scuole medie e facendo stupide pagine di fan per tutti come i videogiochi all'epoca che mi piacevano davvero. E non ho mai avuto quel tipo di educazione informatica. Ci sono concetti di informatica che ho raccolto lungo la strada. Poi c'è anche un segmento di sviluppatori, in particolare penso che negli ultimi 5-10 anni si sono avvicinati a questo in un modo più orientato all'informatica. E penso che questo... quelle differenze ed esperienze porteranno ciascuno di quei gruppi a trarre le proprie conclusioni su come sviluppare al meglio per il web. Ma penso che l'unico modo in cui puoi davvero... Sviluppare in modo sostenibile per il Web è valutare criticamente ciò che stai costruendo e cercare di allinearti attorno a un approccio che serva al meglio gli utenti di quei prodotti. Ed è questo il punto in cui il sito Web e i modelli di app Web si trovano nella mia testa quando valuto queste cose.

Drew: Sì. È interessante. Voglio dire, nel libro, in realtà citi alcuni dei miei lavori. Grazie mille. E la mia scelta di tecnologie noiose su Apache fondamentalmente notato da PHP e una spolverata di JavaScript arrotolato a mano possono creare un'esperienza utente molto scattante per impostazione predefinita, senza la necessità di eseguire alcuna ottimizzazione particolare. Penso che ciò renda un'esperienza utente eccezionale per i visitatori del front-end che arrivano e visualizzano i contenuti sul sito.

Drew: Ma in realtà, mi sento come quell'ambiente per la creazione di contenuti un po' il rovescio della medaglia, una volta che hai effettuato l'accesso e le tue pubblicazioni sul sito. Penso che soffra un po' per essere stato costruito con un approccio al sito Web, piuttosto che una sorta di approccio più pesante per app Web JavaScript, tanto che sto pensando ... o forse deve essere entrambi. Devo continuare a pubblicare il front-end in HTML e CSS statici piacevoli e piccoli frammenti di JavaScript. Ma il back-end in cui voglio fornire un'esperienza di creazione di contenuti, forse una scelta tecnologica diversa sarebbe migliore. È piuttosto interessante perché non deve essere sempre una cosa o l'altra no? Non è una scelta binaria. È più di uno spettro, diresti?

Jeremy: Sì assolutamente. E penso che stiamo iniziando a vedere più discussioni nella comunità sul fatto che lo sviluppo web sia uno spettro del genere. Per essere sincero per le persone che potrebbero essere interessate al mio libro, viene sicuramente dal sito web dello spettro. E ancora, perché sento che è sempre una buona impostazione predefinita. Se non sai come vuoi costruire qualcosa, probabilmente è meglio provare a costruirlo in un modo che riduca al minimo l'uso di JavaScript e riduca al minimo il carico di lavoro sul client. Detto questo, penso che notato sia un'esperienza eccellente. Penso che queste tecnologie ben usurate e un po' "noiose" funzionino davvero bene per il compito da svolgere. E lo fa in un modo che è come una sorta di apertura e abilitazione per lo sviluppatore, giusto?

Jeremy: Non c'è bisogno di avere una profonda conoscenza di come... di negozi di gestione dello stato o strutture di gestione dello stato per realizzare davvero questo tipo di cose. E penso che notato sia ben servito da quel particolare approccio. Ma al tuo punto, penso che ci siano opportunità in qualsiasi sito Web per avvicinarsi alla metà dello spettro senza andare all-in su tutti i routing lato client come framework pesanti che gestiscono tutto sul client e quel tipo di cose. Penso che l'approccio dell'isola stia iniziando a esplorare come appare. E lo ammetto, probabilmente ho fatto involontariamente alcune delle cose tipo isole. Penso che l'abbiamo fatto per un po', ma non gli abbiamo dato un nome. Ma penso che ora che abbiamo identificato come forse un punto intermedio, potremmo iniziare a vedere esperienze Web che offrono una buona esperienza utente, ma sono ancora più interattive. Speriamo che non fosse terribilmente tortuoso.

Drew: È una specie di arpa indietro un po' ai giorni in cui incorporavamo un'isola di Flash o-

Jeremy: Sì.

Drew: Qualcosa in una pagina in cui questa è la nostra piccola sezione interattiva, e il resto scorre in giro.

Jeremy: Sì. Come Flash, oh mio Dio, tre iterazioni del mio portfolio personale dopo il college erano davvero pessime per imitazioni avanzate di Flash e come effetti al passaggio del mouse. E quella roba era davvero, davvero divertente. E a volte mi manca come se ci fosse un'intera ricchezza di contenuti che sta per scomparire perché non usiamo più Flash. E questo fa davvero schifo, ma in un certo senso è stato il precursore di questo genere di isole di cui stiamo parlando. Che è che potresti avere come una pagina web statica e tutto il resto, ma poi avresti questa esperienza davvero riccamente interattiva proprio come se fosse caduta proprio nel mezzo di essa.

Drew: Per molto tempo, il miglioramento progressivo è stato considerato un modo migliore per creare esperienze web. È ancora così, secondo te?

Jeremy: Garantirei che probabilmente... non probabilmente attribuirei più lavoro al miglioramento progressivo perché in un certo senso stai biforcando la tua esperienza di sviluppo. Stai cercando di fornire la funzionalità minima praticabile di un sito Web in un modo che il server possa gestire un po' come queste interazioni chiave. Ma oltre a questo, stai dicendo: "Ok, bene ora voglio facilitare questa interazione per essere un po' più fluida con JavaScript". Penso ancora che sia un modo praticabile per raggiungere i tuoi obiettivi con il tuo sito web, la tua app o il tuo prodotto.

Jeremy: Ma quello che direi è che non consiglierei mai che ogni singola interazione su un sito web debba essere facilitata da questo tipo di schema di navigazione sincrona. Quindi, come un buon esempio potrebbe essere la tua pagina di pagamento per il tuo sito Web econ dovrebbe sicuramente avere un percorso del server. Dovresti avere un percorso del server per aggiungere cose al carrello, e quindi dovresti essere in grado di spruzzare abbastanza JavaScript per renderlo un po' più delizioso in modo che le cose possano essere un po' più veloci e più asincrone.

Drew: Quando si tratta di misurare le prestazioni. Sentiamo molto parlare dei principali elementi vitali del web, principalmente da Google. Quelli sono davvero il punto di riferimento con cui dovremmo misurarci? O è solo ciò che Google vuole farci pensare? Ora mi rendo conto che questa potrebbe essere una domanda difficile che hai iniziato a lavorare in Google.

Jeremy: Sì, sì. Sai, quindi parlo per me stesso qui. Penso che i web vitals siano... i web vitals fondamentali iniziali sono un buon tentativo di definire quali parti dell'esperienza utente sono importanti. Penso che parametri come lo spostamento cumulativo del layout e il più grande disegno Contentful inizino a pensare all'esperienza in modi che non avevamo davvero iniziato a quantificare. Prima di un cambio di layout particolarmente cumulativo, perché se c'è mai stato un momento in cui ti arrabbi tocca è perché a un pulsante piace spostarsi sulla pagina o qualcosa del genere. Voglio dire, penso che sia una cosa utile per misurarlo. È imperfetto. E penso che chiunque lavori sugli elementi vitali del web di base sarebbe d'accordo sul fatto che si desidera un miglioramento in alcune di queste metriche. Ci sono altre metriche con cui non sono necessariamente d'accordo. Come il ritardo del primo input è una metrica su cui è difficile mettere un pin.

Jeremy: Penso che sia davvero utile, giusto? Perché quello che stai letteralmente dicendo è che vogliamo misurare il ritardo e l'interattività su quella prima interazione che l'utente fa, ma manca un po' di contesto, giusto? Perché alcune... molte cose possono influenzarlo perché non necessariamente si collega sempre a JavaScript. Il primo ritardo di input potrebbe rappresentare il ritardo dovuto alla messa a fuoco del campo del modulo, giusto? Quel tipo di cose, cose in HTML. Penso che quelle metriche... tali metriche come il ritardo del primo input possano essere... possono essere utili se puoi contestualizzarle con cose come voci fuori dall'API delle attività lunghe, tempistica degli elementi e questo tipo di cose. In definitiva, penso che il futuro dei principali elementi vitali del web dimostrerà che sarà utile e strumentale nel misurare ciò che rende una buona esperienza utente. Questa è la mia opinione personale.

Drew: Immagino sia, è una di quelle cose che puoi sempre misurare con te stesso, misurare i tuoi miglioramenti o se la tua esperienza è peggiorata se il tuo punteggio cambia, non importando così tanto dei semafori, ma preoccupandoti di ciò che sai sul contesto del tuo sito e su come una modifica ha apportato un miglioramento.

Jeremy: Penso che metriche come lo spostamento cumulativo del layout siano eccellenti, ma anche loro potrebbero beneficiare di un piccolo miglioramento. Allo stato attuale, lo spostamento cumulativo del layout misura principalmente gli spostamenti del layout che si verificano durante il carico. E come sappiamo, quando un utente visita una pagina e arriva su una pagina, i cambiamenti di layout possono verificarsi in qualsiasi momento, giusto? Quindi c'è sicuramente del lavoro che penso si possa fare per migliorare il modo in cui osserviamo questo tipo di fenomeno, di sicuro.

Drew: Penso che la stabilità del layout sia una delle cose che in realtà è un po' più difficile da ottenere quando si lavora con il miglioramento progressivo. A volte, quando carichi una pagina sottoposta a rendering del server e poi inizi a migliorarla nel client, può esserci il pericolo di creare quel tipo di cambiamento di layout, vero?

Jeremy: Assolutamente. Ed è qui che l'idratazione dei componenti diventa un po' complicata perché le dimensioni di quel componente possono cambiare per una serie di motivi. Ad esempio, potrebbero esserci contenuti presenti nel componente lato client che semplicemente non vengono visualizzati sul server a causa di uno stato che non viene valutato fino a quando non viene eseguito sul client. È un problema estremamente difficile. Non ho intenzione di sedermi qui e fingere di avere la pallottola d'argento per questo.

Drew: Volevo parlare un po' di una sorta di dinamica delle importazioni e della divisione del codice, essendo entrambe tecniche diverse per il problema del download e dell'esecuzione anticipata di un enorme pacchetto di JavaScript all'inizio dell'esperienza. C'è il rischio di un'ottimizzazione eccessiva con molte piccole richieste, in particolare sui progetti più piccoli più semplici, o è qualcosa che non sono assolutamente dannosi nell'implementare fin dall'inizio una sorta di prevenzione che avrai questi problemi? O dovresti aspettare fino a quando non vedi effettivamente problemi di prestazioni prima di pensare a questo genere di cose?

Jeremy: Quindi consiglierei la parte finale di quello che hai appena detto è un buon modo per iniziare con questo. Non dovremmo cercare di ottimizzare prematuramente a meno che, ovviamente, tali ottimizzazioni non possano essere ottenute molto rapidamente e facilmente, ma se l'ottimizzazione iniziale richiede molti sforzi, quando non ci sono davvero molti problemi di prestazioni, direi che la divisione del codice è probabilmente qualcosa che non deve accadere. Probabilmente puoi semplicemente caricare quella funzionalità in anticipo.

Jeremy: Ma per esempio, ne parlo nel libro. Se hai un'interazione di alto valore che è guidata da un grande pezzo di JavaScript, e per me, un grande pezzo di JavaScript potrebbe significare 20 kilobyte perché sul cavo che è compresso e potrebbe finire per essere un blocco di JavaScript da 60 kilobyte. Quindi, se riesci a estrarlo dal pacchetto principale o da una qualsiasi delle tue miriadi di pacchetti, il tuo sito potrebbe essere spedito, aiuterai le prestazioni dell'avvio.

Jeremy: Ma nel libro parlo di una tecnica per percepire quando... o almeno tentare di percepire quando l'utente potrebbe fare un'interazione di alto valore. Quindi l'esempio che uso è un pezzo di JavaScript. Viene utilizzato per convalidare il contenuto di un modulo perché la convalida del modulo HTML è ottima, ma non è nemmeno modificabile ed è piuttosto semplice. Non c'è molta flessibilità per cose come il tipo è uguale a e-mail, giusto? Lo valuta in un certo modo. Tuttavia, la convalida del modulo sul client è davvero utile perché possiamo anche modellarlo. E possiamo allineare l'aspetto di quella convalida per essere più vicini a cosa sia l'estetica del marchio o qual è l'estetica del sito web. E quindi in questo esempio, quello che ho fatto è stato, ho detto, se un utente si concentra... anche solo focalizzando uno qualsiasi dei campi nel modulo, questo è il punto in cui precarichiamo quel pezzo di JavaScript.

Jeremy: Quindi si spera che per il tempo, e spero perché ci vuole un po' di tempo per compilare un modulo in modo che la rete abbia abbastanza tempo per eliminarlo in modo che quando viene chiamata l'importazione dinamica, possa semplicemente colpire i soldi per ottenere ciò che è già stato precaricato. È qualcosa con cui ho lavorato un po' qua e là, ed è difficile da fare in tutte le situazioni. Ad esempio, non puoi farlo in modo affidabile tutto il tempo al passaggio del mouse perché alcuni dispositivi non hanno un puntatore fine. Hanno... sono... sono gli input di tocco, giusto? Quindi un passaggio del mouse si verifica in un momento diverso rispetto a quando si dispone di un puntatore fine, ad esempio.

Drew: One aspect of responsible JavaScript use is thinking about how we consume our users, available resources, be that sort of battery life or data allowance, if they're on a data plan. Are there techniques that we can lean on here to, to help us think about those things?

Jeremy: Yeah. So currently, or at least historically from the last… I don't know exactly when this feature shipped but Chrome for Android and there used to be a Chrome extension thing for this called Save Data. And what you would do is if in your settings, in Chrome for Android you would say, “Reduce data usage.” I forget exactly what the label is on the check box, but you check it, you turn it on and what that does is it sends this signal as a request header. And it's a request header that's called save data and it only has one token and it's just on. Because if it's off, the header just doesn't get sent. And you can… on the backend, at least, you can look at this header and you can decided, “Well, do I really need to send the styles and the JavaScript for this carousel or can I render this differently?

Jeremy: Or maybe you start thinking about stuff outside of JavaScript where maybe you send lower quality images. There's a lot of opportunities there to reduce data usage. This is evolving though, save data is still around. And I think it will be for the foreseeable future, but now we're converging on a media query called prefers reduced data. So we have stuff like prefers reduced motion, prefers color scheme, it's sort of in that vein where I anticipate that these will be operating system level settings that we can make to say, “I really want websites or apps to use less data with this signal.” And you can match it on the client side, with the prefers reduced data media query using match media in JavaScript.

Jeremy: So then you can use that in JavaScript to say, “maybe this functionality isn't the most important thing. Maybe we don't really need to load this associated video embed if the text serves the purpose.” That type of thing, but it also converges with the save data header, at least this is what I observed is when I turn on the save data feature in Chrome for Android, the prefers reduce dat: reduced media query matches, but it also sends save data so you can still act on this on the back end or the front end.

Drew: That's nice. So in a sort of app context, you might feel.. rendering a big data table, you might only return some very key columns. Out of that, the most commonly referenced, rather than the full data and really sort of reduce the amount of that's sent over the wire.

Jeremy: Right. Or you might say… you might pull APIs less frequently in JavaScript, that type of thing. It's kind of a hack need phrase, but it really is limited to your imagination. There's a huge space where I think that concept can be applied to deliver better user experiences. And I've used it with a client of mine in Wisconsin. In rural Wisconsin it's just like… it is an internet dead zone. Like it's so difficult to… I don't know how people cope with how slow it is. Maybe it's just because of my data plan and I might be roaming or whatever, but I've used this to some effect to say, “You know, maybe they don't need this carousel.” Somebody who's just kind of out there in the sticks who… there's a lot of farmland in Wisconsin, but there's also like a lot of forests and somebody might need some work done in logging, right? It's a logging company. And so maybe all of these images, aren't really crucial to that user experience. And they really just want to get to… the phone number or whatever it is, and they want to get to it as fast as possible.

Drew: One thing many of us do is write JavaScript in sort of new shiny versions of VS script and TypeScript sometimes, and then use build tools to transfer that down to older syntax for browsers that encounter out in the wild. In some ways that feels like an excellent practice because we're building a code base with nice more modern clean code. In the case of TypeScript, perhaps more reliable code, less bugs. But are there consequences of doing this transpilation process that we might need to be aware of?

Jeremy: Anytime you take a new syntax and you have to transform it so that it's more broadly compatible, that's going to generally… I have not done this comprehensive audit of all features, but generally I've observed that, that results in more JavaScript. And that makes sense because for things like default parameters on functions, which are well supported by the way, and probably you can ship… I think you could probably just ship that on transpile and be fine, but it's a good example. When that gets transformed, it has to inject a lot of helper code in the function to look… to evaluate those defaults, right? So you get that equivalent functionality.

Jeremy: Now, JavaScript is evolving all the time and I think for the time being, we're going to be coping with transpilation costs. And it definitely does have an impact. When I worked with an e-com company, we were able to reduce several of their bundles for their pages, anywhere between 10%, maybe even 5%, in some cases, to sometimes 30 or 40% when we used a technique to transpile two sets of bundles, right? I talked about this at smashing comp. The name that got kind of got tacked on it was differential serving where you say, “I'm going to generate these transformed bundles for older browsers and serve it to them.” And I'll generate a different bundle for users on modern browsers or evergreen browsers that will be smaller because there will be less of that transpilation overhead. And when we use that, there was a measurable improvement in the user experience. And there were signals that that engagement was better when we did this. That said, differential serving is an interesting thing because IE11 is kind of now like fading. It's taking time, but it's fading.

Jeremy: But Matt Hobbs who works for the UK government. I think he works on the NHS website. I think, don't quote me on that Matt. But he sent me some data that showed that there was still a fair amount of people who were still on Internet Explorer and not just internet or 11. Like there were some columns or row in this data rather, that showed that some people were still on like IE6 or IE7. And so you have to evaluate when it makes sense to do something like that, because it is a lot of extra work and it takes a lot of effort.

Jeremy: In the case of the NHS or literally any government service, I would say that it's virtually a mandate that you have to preserve a level of functionality that serves literally everybody, because you don't know where they're going to be accessing the web off of, right? The constraints we develop for are incredible, it's really, really hard. It's thousands and thousands of different types of devices and I think it makes a in those cases, but maybe not so much for your regular web app, right? It just depends on what the purpose is.

Drew: So keeping on top of the browsers that you need to support and the features that you need to transpile and keeping your configuration and your build tool up to date is… becomes quite important.

Jeremy: Yeah, for sure. This is sort of the more technical part of how you set up tool chains to do this, but… evaluating what your user base looks like is very important, because if a browser kind of falls out of a certain threshold of usage from significant to relatively insignificant, that might be the point at which you decide to evaluate, “Hey, maybe we need to bump things up in our browser's list configuration, so that we're transpiling bundles to be smaller since we don't need to ship those transforms anymore.” But it is kind of like another added step. And one of the approaches I talk about in the book is that you can write your JavaScript one in a couple ways.

Jeremy: You could decide that your style for using JavaScript will be to rely on older language constructs that are natively well supported. Like I think constant let are supported back to IE11. So it doesn't preclude you from using those types of things, but it allows you to ship less JavaScript. Whereas you… or you could say like the alternate approach might be that you are going to write JavaScript for newer browsers only, and accept that a segment of your users may not have functionality. But again, that depends on the purpose that your website is serving and whether or not it's crucial, right? Or infrastructure.

Drew: The web platform is moving on that at magnificent pace, it seems at the moment and there seem to be all sorts of things being added to CSS. For example, that offer capabilities that we previously have to lean on JavaScript for. It is one way to use JavaScript responsibly to just not use it and to lean on native browser features instead?

Jeremy: I think that also works for JavaScript itself where it makes sense to use an API directly rather than an abstraction of it. Definitely do that. But certainly in the case of HTML and CSS, there are things we can now do or will be able to do in CSS that we just don't need JavaScript for. So an example of this would be… what's the word for it? Truncation of content, right? That's something that we can do in CSS. Whereas I've been in situations or in projects where I've seen libraries or a library get downloaded that does that. And we don't necessarily need to really do that anymore because CSS can handle it.

Jeremy: Or we have access to these layout modes now where we don't really need. If we invest the time to learn these layout modes like grid, we don't really need to fall back on layout libraries to handle these things for us. And we can develop these experiences that are unique. And what's great about that is with layout modes like CSS grid, if they're abstracted, it kind of reduces what you can do with them, because you are only able to take advantage of what the abstraction offers. And if you really want to build some eye-catching layouts that really like push the boundaries of what's possible, I always like to point to Jen Simmons, her experimental layout lab homepage.

Jeremy: I don't know how you would achieve a layout like that if you abstracted it into its own sort of layout library. You almost have to use it… I would think more than almost, you would have to use CSS grid directly in order to accomplish something like that. And that is like zero JavaScript and it's incredible and it's really neat. And I think the web in general would benefit more if we leaned more heavily on CSS and other core web technologies, as much as we do on JavaScript, probably not possible, but one can dream.

Drew: So the book Responsible JavaScript is out now from a book apart. And I really like it, it's full of very practical information. It's very to the point, you know? There's not filler. It's not like reading a recipe online where you have to hear about a trip to Peru before you get to the nitty gritty. It's just like it's all straight in there and it's all very nicely written. Was it a challenge to put that set of information together?

Jeremy: I'll have to ask… if this is the case, but I Think Responsible JavaScript might be the longest book that A Book Apart has put out, but I would have to go and reach into the closet for my copy of a responsible responsive design to see if I beat out Scott Gel on that, because that was a bit of a book, an awesome book, by the way, it was challenging I'm… As your listeners can probably guess I'm sort of a naturally verbose person and, and, and recovering, trying to like be more succinct, but we really packed in as much as we could and kept it as straight to the point while still trying to retain some, some light lively pros. So it didn't like sound mechanical, but the result was that the manuscript is like 42,000 words. So it's a book, it's a chunk of words and we had a great time working on it. People at A Book Apart were fantastic and, and really setting up those guardrails so that we would be successful.

Drew: And it's very much a book that you can sort of dip into various parts. You don't need to read it cover to cover, to gain loads of helpful information. You can just sort of find the bit that's relevant to the problem that you're facing at the moment and dive in there. So I think that's really great about it. So I've been learning all about Responsible JavaScript. And what have you been learning about lately Jeremy?

Jeremy: Una specie di cosa in corso che ho fatto da quando è uscito è pasticciare con l'API di pittura CSS. Mi piace molto l'API di vernice. Voglio dire, è sempre esistito di per sé... come a modo suo, poiché come la tela il contesto 2D è stato una cosa. Perché questo è... per chi non lo sapesse, l'API di dolore CSS è un modo in cui puoi incorporare un contesto di tela 2D e parametrizzarlo e controllarlo con CSS, il che apre molte possibilità davvero interessanti, come puoi animare cose che in precedenza non potevi animare e quel tipo di cose.

Jeremy: E recentemente ho aggiornato il blog. Cioè... sono un grande fanatico di Final Fantasy, come Final Fantasy II l'ho appena rigiocato e quindi ce ne sono tipo 15 e 16 usciranno qualche volta, ma è una specie di campo retrò. Quindi ho utilizzato l'API di pittura CSS per generare un mondo casuale utilizzando tessere diverse. Quindi ci sono fiumi e cose che come correre e tegole d'erba e alberi e quel tipo di cose. E parametrizzandolo in modo tale che se l'utente visita il mio sito Web in modalità oscura... il lavoro di pittura verrà visualizzato come se fosse notte. Avrà solo una sorta di sovrapposizione su di esso e quel tipo di cose.

Jeremy: Ma l'API di pittura è incredibile. Devo dare un grido a Tim Holman. Lui, l'ho visto alla JSConf Australia e ha parlato di arte generativa. È stato davvero giusto, mi ha davvero interessato. E poi Sam Richard, in quello che alla CSSConf il giorno prima ha parlato dell'API di pittura CSS, quando queste due cose si sono unite per me, è stato proprio come "Wow, è così bello". E così in realtà ho fatto una cosa chiamata Paintlets! È un Paintlets.Herokuapp.com se visiti e Chrome e devi, sfortunatamente, perché non è ancora molto ben supportato. Puoi vedere come un mucchio di diverse opere d'arte casuali generate casualmente e... sì, ho solo... è quello che mi è capitato, mi dispiace. Una lunga storia su questo.

Drew: Incredibile. Suona bene.

Jeremy: Sì. Sì.

Drew: Se tu, caro ascoltatore, vorresti sapere di più da Jeremy, puoi trovarlo su Twitter dove è @malchata e trovare le sue presentazioni di scrittura, video e progetti sul suo sito Web personale, jeremy.codes, JavaScript responsabile è ora disponibile da A Prenota a parte. E puoi trovare maggiori informazioni a riguardo su responsabilijs.dev. Grazie per esserti unito a me oggi Jeremy, hai avuto qualche parola d'addio?

Jeremy: Vai avanti e costruisci per il Web nel miglior modo possibile e cerca di tenere a mente l'utente. Questo è un po' il mio mantra e spero che questo libro renda un po' questa cosa.