Smashing Podcast Episodio 21 con Chris Ferdinandi: le best practice moderne sono dannose per il Web?

Oggi ci chiediamo se le best practice moderne siano dannose per il web? Le strutture moderne ci stanno portando sulla strada sbagliata? Parlo con Chris Ferdinandi, esperto di Lean Web, per scoprirlo.

Mostra note

• Pagina di Chris con link e note per il podcast
• Il libro del web snello
• Chris Ferdinandi sul web
• Chris su Twitter
• Il podcast di Vanilla JavaScript

Aggiornamento settimanale

• "Tradurre i wireframe di progettazione in HTML/CSS accessibili"
  di Harris Schneiderman
• "Creazione di app desktop con Electron e Vue"
  di Timi Omoyeni
• "Tecniche CSS moderne per migliorare la leggibilità"
  di Edoardo Cavazza
• "Come utilizzare i componenti in stile in reazione"
  di Adebiyi Adedotun Lukman
• "Come creare una Porsche 911 con schizzo"
  di Nikola Lazarevic

Trascrizione

Drew McLellan: È l'autore di Vanilla JS Pocket Guide Series, creatore del Vanilla JS Academy Training Program e conduttore del Vanilla JS Podcast. Ha sviluppato una newsletter Tips, che viene letta da quasi 10.000 sviluppatori ogni giorno della settimana. Ha insegnato agli sviluppatori in organizzazioni come Chobani e The Boston Globe. E i suoi plugin JavaScript sono stati utilizzati da organizzazioni come Apple e Harvard Business School. Soprattutto, ama aiutare le persone a imparare Vanilla JavaScript. Quindi sappiamo che preferirebbe scegliere Vanilla JavaScript su un framework, ma sapevi che una volta è stato scelto in una formazione di polizia come la persona che ha meno probabilità di aver commesso il crimine? I miei amici Smashing, per favore diamo il benvenuto a Chris Ferdinandi. Ciao, Cris. Come stai?

Chris Ferdinandi: Oh, sto distruggendo. Grazie per avermi.

Drew: Volevo parlarti oggi di questo concetto di Lean Web, che per te è una specie di passione, vero?

Chris: Sì, molto.

Drew: Perché non ci prepari la scena? Quando si parla di Lean Web, qual è il problema che stiamo cercando di risolvere?

Chris: Sì, ottima domanda. Proprio come un avvertimento per tutti gli ascoltatori, questo episodio potrebbe far urlare un vecchietto al cloud. Cercherò di evitarlo. Quando osservo il modo in cui costruiamo per il web oggi, mi sembra un po' come un pasticcio gonfio e troppo ingegnerizzato. Sono arrivato a credere che molte di quelle che oggi consideriamo come le migliori pratiche potrebbero effettivamente peggiorare il web.

Chris: Il Lean Web è un approccio allo sviluppo web incentrato sulla semplicità, sulle prestazioni e sull'esperienza dello sviluppatore oltre... Mi dispiace, non l'esperienza dello sviluppatore. Piuttosto l'esperienza dell'utente, rispetto all'esperienza dello sviluppatore, e la facilità di costruire le cose dal punto di vista del team, che è ciò che penso su cui ci concentriamo molto oggi e come probabilmente entreremo nella nostra conversazione.

Chris: In realtà ho scoperto che molte di queste cose che pensiamo possano migliorare l'esperienza degli sviluppatori lo fanno per un sottoinsieme di sviluppatori, ma non necessariamente per tutti coloro che stanno lavorando alla cosa che stai costruendo. Quindi c'è anche un sacco di problemi con questo, che possiamo approfondire. Ma in realtà, il Lean Web consiste nel concentrarsi sulla semplicità e sulle prestazioni per l'utente e nel dare davvero priorità o focalizzare l'attenzione sulle persone che usano le cose che produciamo piuttosto che su noi, le persone che le producono.

Drew: Man mano che il web matura come piattaforma di sviluppo, sembra esserci questa spinta sempre maggiore verso la specializzazione.

Chris: Sì.

Drew: Persone che coprivano Full Stack, e poi ci siamo divisi in front-end e back-end. E poi quel front-end si è diviso in persone che si occupano di sviluppo CSS o JavaScript. E poi sempre più all'interno di JavaScript, diventa più specializzato. Qualcuno potrebbe considerarsi e commercializzarsi come uno sviluppatore React o uno sviluppatore Angular, e la sua intera identità e prospettiva si basa su un framework particolare in cui sono altamente qualificati. È questa dipendenza dai framework, il fulcro del nostro lavoro sul web, una brutta cosa?

Chris: È sfumato. Ero molto fortemente nel campo del sì, sempre. Penso in generale, mi sento ancora come se sì, la nostra ossessione come settore per i framework e gli strumenti in generale è potenzialmente un po' a nostro danno. Non penso che i framework siano intrinsecamente cattivi. Penso che siano utili per un sottoinsieme molto ristretto di casi d'uso. E finiamo per usarli per quasi tutto, comprese molte situazioni in cui non sono necessariamente la scelta migliore per te o per il progetto.

Chris: Quando penso a molti dei problemi che abbiamo oggi sul web, il nucleo di questi problemi inizia davvero con la nostra eccessiva dipendenza dai framework. Tutto il resto che viene dopo è in molti modi, perché lanciamo così tanto non solo i framework che sono JavaScript in generale, sul web. Lo dico come qualcuno che insegna professionalmente alle persone come scrivere e usare JavaScript. È così che guadagno i miei soldi. E sto qui dicendo che penso che usiamo troppo JavaScript, il che a volte è una cosa un po' strana.

Drew: Prima che nascessero i grandi framework, costruivamo interfacce utente e cose con jQuery o altro. E poi sono arrivati ​​i framework e ci hanno fornito più di questo concetto di interfaccia utente basata sullo stato.

Chris: Sì.

Drew: Ora, questo è un pezzo di ingegneria abbastanza complesso che devi mettere in atto. Lavorare con meno JavaScript esclude l'uso di qualcosa del genere o devi implementarlo di nuovo da solo? Stai solo creando un boilerplate caricato?

Chris: Molto dipende da cosa stai facendo. Se hai un'interfaccia non modificabile, puoi creare un'interfaccia utente basata sullo stato con... non so, forse una dozzina circa di righe di codice. Se si dispone di un'interfaccia non modificabile, direi onestamente un'interfaccia utente basata sullo stato. Non è necessariamente l'approccio giusto. Ci sono probabilmente altre cose che puoi fare invece. Pensa ai generatori di siti statici, ad alcuni markup pre-renderizzati, persino a un sito WordPress o PHP della vecchia scuola.

Chris: Ma il punto in cui questo inizia a diventare interessante è quando entri in interfacce più dinamiche e interattive. Non solo app. So che le persone adorano tracciare questa linea di confine tra siti Web e app, e penso che ci sia questa strana miscela tra loro due e la linea non è sempre così chiara. Quando inizi ad approfondire, l'utente fa cose, qualcosa cambia. L'interfaccia utente basata sullo stato diventa un po' più importante. Ma non hai ancora bisogno di tonnellate di codice per farlo accadere.

Chris: Guardo qualcosa come React o Vue, che sono pezzi di ingegneria assolutamente incredibili. Non voglio togliere nulla alle persone che ci lavorano. Sono finito come un esercizio di apprendimento, costruendo il mio mini-quadro solo per avere un'idea migliore di come funzionano queste cose sotto il cofano. È davvero difficile tenere conto di tutti i diversi pezzi in movimento. Quindi ho un enorme rispetto per le persone che costruiscono e lavorano su questi strumenti. Ma React e Vue sono entrambi a circa 30 kilobyte dopo aver minimizzato e gzippato. Quindi, una volta disimballate, sono sostanzialmente più grandi di così.

Chris: Non tutto, ma una buona parte di quel peso è dedicata a questa cosa chiamata DOM virtuale. Esistono alternative che utilizzano API o approcci simili. Per React, hai Preact, che è 2,5 kilobyte o circa 3 kilobyte invece di 30. È un decimo della dimensione. Per Vue, invece, hai Alpine JS, che è di circa 7 kilobyte. Tuttavia, sostanzialmente più piccolo. La grande differenza tra quelli e le loro controparti del fratello maggiore è che hanno perso il DOM virtuale. Potrebbero abbandonare un metodo o due. Ma in generale, è lo stesso approccio e lo stesso tipo di API nel modo di lavorare con il codice, e sono sostanzialmente più piccoli.

Chris: Penso che molti degli strumenti che usiamo siano potenzialmente sopraffatti per le cose che stiamo cercando di fare. Se hai bisogno di un'interfaccia utente basata sullo stato e hai bisogno di dati reattivi e di queste interfacce dinamiche, è fantastico. Penso che una delle grandi cose di cui cerco di parlare oggi non sia... non usare mai strumenti. Per me, Vanilla JS non è scrivere a mano ogni singola riga di codice e ogni singolo progetto che fai. Questa è follia. Non potrei farlo, non lo faccio. Ma è essere più selettivi riguardo agli strumenti che utilizziamo. Scegliamo sempre il multiutensile, il coltellino svizzero che contiene tutte queste cose. E a volte, tutto ciò di cui hai veramente bisogno è un paio di forbici. Non hai bisogno di tutte le altre cose, ma le abbiamo comunque.

Chris: Che è davvero una lunga strada per... mi dispiace, di rispondere alla tua domanda. Che a volte è più codice di quello che potresti o vorresti scrivere da solo, ma non è così tanto codice come penso che pensiamo che richieda. Quando dico che non hai bisogno di un framework, ricevo un sacco di respingi intorno a questa idea che: "Beh, se non usi un framework, fondamentalmente stai scrivendo il tuo". Poi questo arriva con i suoi problemi. Penso che ci sia un posto tra l'uso di React o Vue e la scrittura del proprio framework, e forse è scegliere qualcosa che è un po' più piccolo. A volte ci sono ragioni per cui scrivere il tuo framework potrebbe effettivamente essere la chiamata giusta, a seconda di cosa stai cercando di fare. È tutto molto fluido e soggettivo.

Drew: È piuttosto interessante che, come esercizio di apprendimento, tu abbia implementato la tua struttura basata sullo stato. Ricordo che in passato pensavo che ogni volta che cercavo una biblioteca o qualcosa del genere, mi piaceva pensare di poterla implementare da solo.

Chris: Certo, certo.

Drew: Ma raggiungere la libreria mi ha risparmiato il fastidio di farlo. Sapevo che se avessi dovuto scrivere questo codice da solo, sapevo quale approccio avrei adottato per farlo. E questo era vero fino all'uso di cose come jQuery e cose. In questi giorni, penso che se dovessi scrivere la mia versione di Vue o React, non ho quasi idea di cosa stia succedendo ora in quella libreria, in tutto quel codice.

Drew: Per quelli di noi che non hanno familiarità, quando dici qualcosa come Preact elimina il DOM virtuale e rende tutto molto più piccolo, cosa ci offre quel DOM virtuale?

Chris: Per rispondere a questa domanda, voglio fare solo un piccolo passo indietro. Una delle cose più belle che ti danno i framework e altre librerie basate sullo stato è la differenza di DOM. Se in realtà non stai aggiornando molto l'interfaccia utente, potresti cavartela dicendo: "Ecco una stringa di come dovrebbe apparire il markup. In HTML, metterò tutto questo markup in questo elemento." Quando devi cambiare qualcosa, fallo di nuovo. Questo è un po' costoso per i browser, perché attiva un ridisegno.

Chris: Ma penso che potenzialmente più importante di così, uno dei problemi nel farlo è che hai qualsiasi tipo di elemento interattivo lì dentro, un campo di forma, un collegamento su cui qualcuno si è concentrato. Quel focus è perso perché l'elemento... anche se hai una cosa nuova che sembra simile, non è lo stesso elemento letterale. Pertanto, se si perde lo stato attivo, si può creare confusione per le persone che utilizzano le utilità per la lettura dello schermo. C'è solo un sacco di problemi con quello.

Chris: Qualsiasi cosa dell'interfaccia utente basata sullo stato che valga il suo peso implementerà alcune differenze DOM, dove dicono: "Ecco come dovrebbe apparire l'interfaccia utente. Ecco come appare in questo momento nel DOM. Cosa c'è di diverso?" E andrà a cambiare quelle cose. Sta effettivamente facendo le cose che faresti semplicemente aggiornando manualmente l'interfaccia utente, ma lo sta facendo per te sotto il cofano. Quindi puoi semplicemente dire: "Ecco come voglio che assomigli". E poi la libreria o il framework lo capiscono.

Chris: Le cose più piccole come Preact o Alpine, in realtà lo fanno direttamente. Stanno convertendo la stringa che fornisci loro di come dovrebbe apparire l'interfaccia utente in elementi HTML. E poi stanno confrontando ogni elemento con il suo pezzo corrispondente nel DOM letterale. Quando si finisce con UI che diventano sempre più grandi, ciò può avere un'implicazione sulle prestazioni perché interrogare il DOM più e più volte diventa costoso. Se vuoi avere un'idea del tipo di interfaccia in cui questo diventa un problema, fai clic con il pulsante destro del mouse e controlla l'elemento sul pulsante "Preferiti" su Twitter o sul pulsante "Mi piace" su Facebook. E dai un'occhiata alla nidificazione dei div che ti porta a quell'elemento. È molto, molto profondo. È come una dozzina di div, annidati uno dentro l'altro solo per quel singolo tweet.

Chris: Quando inizi a scendere di così tanti livelli, inizia a incidere davvero sulle prestazioni. Quello che fa il DOM virtuale è invece di controllare il DOM reale ogni volta, crea una mappa basata su oggetti di come appare l'interfaccia utente in JavaScript. E poi fa la stessa cosa per l'interfaccia utente con cui vuoi sostituire quella esistente e confronta quei due. In teoria sono molte più prestazioni che nel vero DOM. Una volta ottenuto un elenco delle cose che deve cambiare, scappa e apporta quelle modifiche. Ma deve attaccare il DOM solo una volta. Non sta controllando ogni singolo elemento, ogni singola volta. Se hai interfacce come Twitter o Facebook o QuickBooks o qualcosa del genere, il DOM virtuale probabilmente ha molto senso.

Chris: La sfida è... la differenza tra Preact e React è di 27 kilobyte prima di decomprimere il tutto nella sua effettiva ondata di codice. Il download grezzo, il tempo di decompressione e compilazione su questo solo può aggiungere un po' di latenza al carico iniziale su un'interfaccia utente. Ciò diventa ancora più pronunciato se i tuoi utenti non utilizzano gli ultimi dispositivi Apple. Anche un dispositivo Android di un paio di anni fa o un feature phone, o se hai persone nei paesi in via di sviluppo, è davvero... il tempo per iniziare è più lento. E poi, per di più, il tempo interattivo effettivo è più lento a causa dell'astrazione extra.

Chris: Quindi non è solo che lo carichi e sono paragonabili in velocità. Ogni micro interazione che qualcuno fa e le modifiche che devono avvenire possono anche essere leggermente più lente solo a causa di tutto quel codice extra lì dentro. Se si dispone di un'interfaccia utente davvero molto complessa con molti elementi nidificati e molti dati, le prestazioni del DOM virtuale superano il peso del codice aggiuntivo. Ma qualsiasi interfaccia utente tipica per un'app tipica per la quale la maggior parte di ciò per cui vedo gli sviluppatori che usano React o Vue, il vantaggio che ottieni dal DOM virtuale non è lì e starebbero meglio. Anche se vuoi mantenere la stessa comodità di React, usa Preact. È una frazione delle dimensioni, funzionerà esattamente allo stesso modo e sarà più performante. Questo è il genere di cose per cui tendo a discutere.

Chris: Dobbiamo essere più bravi a scegliere lo strumento giusto per il lavoro. Se segui un approccio del genere, se arrivi a un punto in cui un DOM virtuale ha effettivamente un senso, è molto più facile portare Preact in React che se avessi lanciato il tuo. Questa è la situazione. Se sei davvero preoccupato per questo, ottieni anche un sistema a prova di futuro.

Drew: Alcuni potrebbero dire che potrebbero sostenere che questi framework, cose come Vue, React sono così altamente ottimizzati per le prestazioni che ottieni così tanti vantaggi lì che sicuramente semplicemente accoppiandoli con un gestore di pacchetti in un bundler per assicurarti di ' stai solo inviando il codice che desideri. Sicuramente, sei già molto avanti solo facendo questo?

Chris: Sì. Non sono d'accordo. Non ho davvero molto altro da approfondire oltre a... immagino forse, ma non proprio. Anche con un bundler, hai ancora bisogno di quel core React. Anche con il raggruppamento, sarà comunque più grande dell'utilizzo di qualcosa come Preact.

Chris: Drew, apprezzo davvero che tu abbia guidato la domanda su questo. Perché una delle altre cose di cui parlo nel mio libro, The Lean Web, e nel mio discorso con lo stesso nome, è come questi strumenti... Hai menzionato il bundling, per esempio. Una delle cose che facciamo per aggirare il calo delle prestazioni che prendiamo dall'utilizzo di tutto questo JavaScript è lanciare ancora più JavaScript nel front-end per tenerne conto. Uno dei modi in cui lo facciamo sono i gestori di pacchetti e i bundle di moduli.

Chris: Come hai accennato a... per quelli di voi che non lo sanno, questi sono strumenti che... compileranno tutti i vostri piccoli singoli bit JavaScript in un unico grande file. Quelli più nuovi e quelli più... non li voglio definire premurosi. Ma i più recenti utilizzeranno una funzione chiamata tremore dell'albero, in cui si sbarazzano di qualsiasi codice che non è effettivamente necessario. Se quel codice ha alcune dipendenze che non vengono utilizzate per le cose che hai effettivamente fatto, elimineranno alcune di quelle cose per rendere i tuoi pacchetti il ​​più piccoli possibile. In realtà non è un'idea terribile, ma si traduce in questa cosa che in genere chiamo salute delle dipendenze in cui hai questo castello di carte davvero delicato delle dipendenze in cima alle dipendenze in cima alle dipendenze.

Chris: L'impostazione del processo richiede tempo. E chiunque abbia mai eseguito un'installazione NPM e poi abbia scoperto che un sacco di dipendenze non erano aggiornate e ha dovuto passare un'ora a cercare di capire quali dovevano essere riparate e oh, in realtà è una dipendenza in una dipendenza e tu non Non ho la capacità di aggiustarlo da solo. È una cosa intera. Forse funziona per te, ma preferirei passare il mio tempo senza scherzare cercando di mettere insieme le mie dipendenze.

Chris: Ho iniziato a raccogliere tweet da persone in cui si lamentano del tempo sprecato nel loro flusso di lavoro. Uno dei miei preferiti, Brad Frost un paio di anni fa, parlava della deprimente consapevolezza che la cosa che hai sgobbato nel moderno JS avrebbe potuto prenderti 10 minuti in jQuery. Non sono davvero un fan di jQuery, ma sento quel dolore quando si tratta di lavorare con i framework.

Chris: L'altro problema con molti di questi strumenti è che iniziano a diventare guardiani. Non so quanto tu voglia davvero immergerti in questo o no, Drew. Ma uno dei miei grandi respingimenti contro JS, tutte le cose in un flusso di lavoro. Soprattutto quando inizi a dire "Beh, se stiamo già usando JS per l'HTML, perché non usarlo anche per CSS?" Inizi a escludere molte persone davvero talentuose dal processo di sviluppo. È solo una grande perdita per il progetto per la comunità nel suo insieme.

Drew: Beh, certamente lo sono... Ho iniziato a raccogliere React all'inizio del 2020, aggiungendolo al mio set di abilità. Lo faccio ormai da quasi sette mesi. Devo dire che una parte in cui sono meno fiducioso è l'impostazione degli strumenti per avviare un progetto.

Drew: Sembra che ci sia un sacco di lavoro per ottenere qualcosa in Hello World, e c'è ancora di più che devi sapere per renderlo pronto per la produzione. Ciò deve rendere più difficile iniziare lo sviluppo se questo viene proposto come ciò che dovresti fare nel 2020 per imparare a essere uno sviluppatore web. Qualcuno che si avvicina per la prima volta avrà un vero problema. Sarà una vera barriera all'ingresso, vero?

Chris: Assolutamente. L'altro pezzo qui è che gli sviluppatori JavaScript non sono sempre le uniche persone che lavorano su una base di codice o contribuiscono in modo significativo a quella base di codice. Più rendiamo la conoscenza di JavaScript un requisito per lavorare con una base di codice, meno è probabile che queste persone siano in grado di partecipare effettivamente al progetto.

Chris: Un esempio di questo, di cui mi piace parlare è WordPress, che è stato recentemente... Non dovrei dire di recente a questo punto. Sono passati un paio d'anni ormai. Ma hanno spostato il loro stack di back-end sempre di più su JavaScript, lontano da PHP, il che non è intrinsecamente una cosa negativa. Il loro nuovo editore, Gutenburg, è basato su React.

Chris: Nel 2018, il principale consulente per l'accessibilità di WordPress, Rian Rietveld, il cui nome quasi certamente ho massacrato... si è dimessa molto pubblicamente dalla sua posizione e ha documentato il perché in un articolo molto dettagliato. Il nocciolo del problema era che lei e il suo team avevano il compito di controllare questo editore per assicurarsi che fosse accessibile. WordPress comprende ora il 30% del web. Il loro obiettivo è democratizzare l'editoria, quindi l'accessibilità è una parte davvero importante di questo. Dovrebbe essere una parte importante di qualsiasi progetto web. Ma per loro in particolare, è estremamente importante. L'intero lavoro del suo team è assicurarsi... L'intero lavoro del suo team era assicurarsi che questo editor fosse accessibile. Ma poiché né lei né nessun altro membro del suo team aveva esperienza di React e poiché non riuscivano a trovare volontari nella comunità dell'accessibilità con quell'esperienza, è stato davvero difficile per lei e il suo team svolgere il proprio lavoro.

Chris: Storicamente, potevano identificare gli errori e poi andare a correggerli. Ma con il nuovo flusso di lavoro basato su React, sono stati ridotti all'identificazione dei bug e quindi all'archiviazione dei ticket. Sono stati aggiunti a un backlog insieme a tutte le altre richieste di sviluppo di funzionalità su cui stavano lavorando gli sviluppatori JavaScript. Molte cose che avrebbero potuto essere facilmente risolte non sono arrivate alla prima versione.

Chris: Nel maggio del 2019, circa un anno dopo le dimissioni di Rian, è stato condotto un audit dettagliato sull'accessibilità a Gutenburg. Il rapporto completo era di 329 pagine. Il solo sommario esecutivo era di 34 pagine. Ha documentato 91 bug relativi all'accessibilità in modo abbastanza dettagliato. Molti di questi erano davvero... Non voglio chiamarli semplici frutti a bassa quota, ma molti di loro erano cose basilari che il team di Rian avrebbe potuto sistemare e avrebbe consentito agli sviluppatori di concentrarsi sullo sviluppo delle funzionalità. Alla fine è quello che sembra che abbiano finito per fare, dedicare molto tempo allo sviluppo delle funzionalità e rimandare queste cose a più tardi. Ma quel team è estremamente importante per il progetto e all'improvviso sono stati esclusi dal processo a causa di una scelta tecnica.

Chris: Alex Russell è uno sviluppatore del team di Chrome. Ha scritto questo articolo un paio di anni fa intitolato The Developer Bait and Switch, dove parlava dell'argomento dell'uomo di paglia dei framework. L'idea che questi strumenti ti consentano di muoverti più velocemente e, per questo motivo, puoi scorrere più velocemente e offrire esperienze migliori. È questa l'idea che una migliore esperienza per gli sviluppatori significhi una migliore esperienza per l'utente. Penso che questo sia un esempio molto chiaro di come questa argomentazione non funzioni sempre nel modo in cui la gente crede. È un'esperienza migliore forse per alcune persone, non per tutti.

Chris: Gli sviluppatori CSS, le persone che lavorano sui sistemi di progettazione, la loro capacità di creare strumenti che altri possono utilizzare a volte è limitata anche da queste scelte di strumenti. Nella mia esperienza, ero più bravo nei CSS. È cambiato molto negli ultimi anni e non sono neanche lontanamente bravo come una volta. Nella mia esperienza, le persone che sono sviluppatori CSS davvero avanzati... e lo intendo nel vero senso della parola. Le persone che lavorano su CSS sono veri e propri sviluppatori web che lavorano su un linguaggio di programmazione. È una cosa molto speciale, o può essere una cosa molto specializzata. Le persone che sono eccezionalmente brave in questo, secondo la mia esperienza, non sono sempre anche molto brave in JavaScript perché finisci per immergerti davvero in profondità in una cosa e scivoli un po' su altre cose. Anche la loro capacità di lavorare con queste tecnologie viene ostacolata, il che è un peccato perché prima non era così.

Chris: Quando lo stack era più semplice, era più facile per le persone di più discipline partecipare al processo di sviluppo. Penso che sia a scapito delle cose che costruiamo e della comunità in generale, quando non è più così.

Drew: Ho trovato di recente in un progetto la ricerca di modi per affrontare alcuni dei problemi CSS, problemi di flusso di lavoro, stiamo lavorando in più sul progetto e le dimensioni del pacchetto stanno aumentando e il vecchio CSS non viene mai rimosso. Era un progetto React, quindi stavamo esaminando alcuni di questi approcci CSS in JavaScript per vedere cosa sarebbe stato meglio usare per risolvere i problemi che avevamo. Ciò che è diventato subito evidente è che non c'è solo una soluzione per farlo. Ci sono dozzine di modi diversi per farlo.

Drew: CSS in JS è un approccio generale, ma potresti passare da un progetto all'altro ed è completamente influenzato in un modo completamente diverso. Anche se sei una persona CSS e impari un approccio particolare su un progetto, quelle abilità potrebbero non essere comunque trasferibili. È molto difficile vedere come qualcuno dovrebbe investire troppo tempo nell'apprendimento se non si sente particolarmente a suo agio con JavaScript.

Chris: Sì. L'altra cosa interessante che penso che tu sia appena uscito un po' è che quando ne parlo, uno dei più grandi respingimenti che ricevo è che i framework applicano le convenzioni. Stai usando Vanilla JavaScript, hai questo campo verde-cielo blu, puoi fare qualsiasi cosa tu voglia tipo di progetto. Con React, c'è un modo React di fare le cose.

Chris: Ma una delle cose che ho scoperto è che ci sono approcci Reacty, ma non c'è un modo corretto di fare le cose con React. È una delle cose che la gente ama. È un po' più flessibile, puoi fare le cose in un paio di modi diversi se vuoi. Lo stesso con Vue. Puoi usare quella cosa basata su HTML in cui hai le tue proprietà direttamente nell'HTML e Vue le sostituisce, ma puoi anche usare un tipo di sintassi di modelli più simile a JSX se preferisci.

Chris: Ho sentito molte persone lamentarsi quando stanno imparando React, uno dei grandi problemi è che tu cerchi su Google come fare X in React e ricevi una dozzina di articoli che ti dicono una dozzina di modi diversi in cui potresti fare quella cosa. Questo non vuol dire che non mettano dei guardrail a un progetto. Non credo sia così netto come: “Ho scelto un framework. Ora questo è il modo in cui costruisco con esso. Ad essere onesto, non so che sia necessariamente qualcosa che vorrei neanche io. Non credo che vorresti che quelli strettamente confinati... alcune persone lo fanno, forse. Ma se lo stai pubblicizzando come un vantaggio, non penso che sia così pronunciato come le persone a volte lo fanno sembrare.

Chris: Sei entrato in una cosa interessante anche se proprio lì, dove stavi menzionando il CSS che non è più necessario. Penso che sia una delle cose legittimamente interessanti che qualcosa come CSS e JS ... o legare in qualche modo i tuoi CSS ai componenti JavaScript è che se quel componente cade, anche il CSS in teoria, se ne va. Molto di questo per me sembra gettare l'ingegneria ai problemi delle persone. Invariabilmente, dipendi ancora dalle persone da qualche parte lungo la linea. Questo non vuol dire che non usi mai questi approcci, ma non sono certamente l'unico modo per risolvere questo problema.

Chris: Ci sono strumenti che puoi usare per controllare il tuo HTML ed estrarre gli stili che non vengono utilizzati anche senza usare CSS e JavaScript. Puoi scrivere CSS "alla vecchia maniera" e continuare a eliminare gli stili inutilizzati. Esistono approcci di creazione ai CSS che ti danno un CSS in un output simile a JS e mantengono piccolo il tuo foglio di stile senza sputare questi nomi di classi illeggibili umani incomprensibili che a volte ottieni con CSS e JS. Come X2354ABC, o solo queste parole senza senso che vengono sputate fuori.

Chris: È qui che comincio ad entrare davvero nel vecchio uomo che urla al cloud tipo di cose. Sto davvero mostrando la mia età da sviluppatore qui. Ma sì, non è necessariamente che queste cose siano cattive e sono costruite per risolvere problemi legittimi. A volte mi sembra che ci sia un po' di un... se è abbastanza buono per Facebook, è abbastanza buono per noi tipo di cose che accadono con questi. Bene, Facebook usa questo strumento. Se siamo un vero programma di ingegneria... team, dipartimento, organizzazione, dovremmo farlo anche noi. Non penso necessariamente che sia il modo giusto di pensarci. È perché Facebook si occupa di problemi che tu non hai e viceversa. La dimensione e la scala di ciò su cui lavorano sono semplicemente diverse, e va bene.

Drew: Esattamente. Vedo che alcune di queste cose come CSS e JavaScript sono quasi come un polyfill. Abbiamo problemi legittimi, abbiamo bisogno di un modo per risolverli. La tecnologia non ci sta ancora fornendo un modo per risolverlo. Forse mentre aspettiamo che la piattaforma web si evolva e risolva il problema, questa cosa che facciamo in questo momento con JavaScript in qualche modo ci porterà a termine e andrà tutto bene. Sappiamo che è brutto. Sappiamo che non è un'ottima soluzione, ma ci aiuta in questo momento. E si spera che nel frattempo possiamo estrarlo e utilizzare la soluzione nativa.

Chris: È davvero divertente che tu ne parli. Perché letteralmente ieri sera stavo guardando un discorso di Jeremy Keith dell'anno scorso sulle app web progressive. Ma stava parlando di come un paio di decenni fa, stava cercando di convincere le persone a usare JavaScript. Il che sembra ridicolo all'epoca, ma JavaScript era questa cosa nuova. Ha mostrato alle persone come potresti fare cose interessanti come cambiare il colore di un link al passaggio del mouse con questo nuovo... Sembra assurdo che tu abbia bisogno di JavaScript per quello ora, perché è quello che fa per te CSS. Ma cose come l'attributo focus o la proprietà semplicemente non esistevano in quel momento.

Chris: Una delle cose che ha detto nel discorso che penso mi abbia davvero colpito è che JavaScript in molti modi spiana le strade delle vacche. È questo linguaggio molto flessibile e aperto che possiamo usare per creare o inserire funzionalità che non esistono ancora. E poi, alla fine, i browser recuperano e implementano queste funzionalità in un modo più nativo. Ma ci vuole tempo. Capisco perfettamente quello che stai dicendo a riguardo. Non è la soluzione perfetta, ma è quella che abbiamo in questo momento.

Chris: Penso che per me la differenza più grande tra i polyfill e alcune di queste soluzioni sia che i polyfill sono progettati per essere strappati. Se ho una funzionalità che voglio implementare che il browser non supporta ancora, ma c'è una sorta di specifica per essa e scrivo un polyfill... una volta che i browser recuperano, posso strappare quel polyfill e non devo cambiare qualcosa. Ma quando si utilizza alcuni di questi strumenti, strapparli significa riscrivere l'intera base di codice. È davvero costoso e problematico. Questo non vuol dire che non li usi mai, ma sono fermamente convinto che dovremmo pensare alla scelta di strumenti che possono essere facilmente estratti in seguito. Se non ne abbiamo più bisogno o la piattaforma recupera, non è necessaria un'enorme riscrittura per estrarli.

Chris: Quindi, arrivando a questo, abbiamo un sacco di stili che non usiamo più, ecco perché personalmente preferirei una tecnologia di strumenti di costruzione che controlla il tuo CSS rispetto al markup renderizzato ed estrae le cose che non ti servono. Perché lungo la strada, se una piattaforma raggiunge il ritardo, puoi estrarre quel pezzo dello strumento di costruzione senza dover cambiare tutto. Sta solo aumentando ciò che hai già, mentre CSS e JS non ti danno lo stesso tipo di vantaggio. Sto solo scegliendo quello, ma penso a molte di queste tecnologie in modo più ampio.

Chris: Sento che cose come React o Vue stanno probabilmente aprendo alcune strade che i browser alla fine raggiungeranno e probabilmente utilizzeranno approcci simili se non gli stessi, quindi potrebbero esserci meno riscritture. Molte delle cose dell'ecosistema che vengono collegate in giro potrebbero esserlo di meno.

Drew: Penso sia giusto, vero, che la piattaforma web si muova lentamente e con attenzione. Pensi che se cinque anni fa, tutti noi stessimo mettendo JavaScript Carousels sulle nostre pagine. Erano ovunque. Tutti stavano implementando caroselli JavaScript. Se la piattaforma web fosse saltata e implementato una soluzione Carousel per soddisfare tale esigenza, non sarebbe rimasta lì senza che nessuno la utilizzasse perché le persone non lo fanno più con Carousels. Perché era solo una moda passeggera, una moda del design. Per contrastare ciò e impedire che la piattaforma stessa si gonfi e diventi un problema che deve essere risolto, deve muoversi a un ritmo molto più costante. The upshot of that is HTML that I wrote in 1999 still works today because of that slow process.

Drew: One of the other areas where things seem to be bloating out on the web is… I guess it's related to the framework conversation. But it's the concept of a single-page app. I feel like that a lot of promises are made around single-page apps as to their performance, like you're getting all this benefit because you're not reloading the entire page framework. I feel like they don't always make good on those performance promises. Saresti d'accordo con quello?

Chris: Yes. Although I will confess, despite having a very lengthy chapter in my book on this and talking about that a lot in talks and conversations with people, I don't think single-page apps are always a terrible thing. But I do think this idea that you need one for performance is overstated. You can oftentimes get that same level of performance with different approaches.

Chris: I think one of the bigger challenges with single-page apps is… For anybody who's unfamiliar with those. When a single-page app, instead of having separate HTML files or if you're using something like a database driven site like WordPress, even though you don't have actual physical HTML files for each page in your WordPress site, WordPress is creating HTML files on the fly and sending them back to browsers when URLs are requested. For purposes of this conversation, instead of having separate HTML files for every view in your app, a single-page app has a single HTML file. That's what makes it a single-page app. JavaScript handles everything. Rendering the content, routing to different URL paths, fetching new content if it needs to from an API or something like that.

Chris: One of the spoken benefits of these or stated benefits of these is that only the content on the page changes. You don't have to re-download all the JS and the CSS. Oh, and you can do those fancy page transitions that designers sometimes love. In theory, this is more performant than having to reload the whole page.

Chris: The problem with this approach from my perspective is that it also breaks a bunch of stuff that the browser just gives you for free out-of-the-box, and then you need to recreate it with more JS. You have an app that's slow because it has a lot of JS. So you throw even more JavaScript at it to improve that performance and in doing so, you break a bunch of browser features and then have to re-implement those with even more JS too.

Chris: For example, some things that the browser will do for free with a traditional website that you need to recreate with JavaScript when you go the single-page app. You need to intercept clicks on links and suppress them from actually firing, with your JavaScript. You then need to figure out what you actually need to show based on that URL, which is normally something that would get handled on the server or based on the file that goes with that URL path. You need to actually update the URL in the address bar without triggering a page reload. You need to listen for forward and back clicks on the browser and update content again, just like you would with clicks on links. You need to update the document title.

Chris: You also need to shift focus in a way that announces the change in page to people who are using screen readers and other devices so that they're not confused about where they are or what's going on. Because they can't see the change that's happening, they're hearing it announced. If you don't actually shift focus anywhere, that announcement doesn't happen. These are all things that the browser would do for you that get broken with single-page apps.

Chris: On top of that, because you have all this extra JavaScript, this is complicated. So most people use frameworks and libraries to handle this sort of thing. Because of all this extra JavaScript to support this approach, you end up with potentially slower initial page load than you would have otherwise. Depending on the content you have, this approach I think sometimes can make sense. If you have an app that is driven by API data where you don't necessarily know what those URL paths are going to look like ahead of time.

Chris: Just an example here. You have an animal rescue where you have some adoptable animals, and that data comes from Petfinder, the animal adoption website. You have a bunch of animals there. Petfinder manages that, but you want to display them on your site with the Petfinder API. When your website's being built, it doesn't always necessarily have visibility to what pets are available in this exact moment and what kind of URL paths you're going to need. A single-page app can help you there because it can dynamically on the fly, create these nice URLs that map with each dog or cat.

Chris: Something like Instagram with lots of user created content, maybe that also makes sense. But for a lot of things, we do know where those URLs are going to be ahead of time. Creating an HTML file that has the content on it already is going to be just as fast as… sometimes even faster than the JavaScript based single-page app approach, especially if you use some other techniques to keep your overall CSS and JavaScript size down. I use this approach on a course portal that I have. The page loads feel instantaneous because HTML is so easy for browsers to render compared to other parts of the stack. It feels like a single-page app, but it's not.

Drew: Especially when you consider hosting solutions like a Jamstack approach of putting HTML files out in a CDN so it's being served somewhere physically close to the user.

Chris: Yep.

Drew: Loading those pages can just be so, so quick.

Chris: Yes. Assolutamente. Assolutamente. One of the other arguments I think people used to make in favor of single-page apps is offline access. If someone loads it and then their network goes down, the app is already up and all the routes are handled just with the file that's already there. So there's no reloading, they don't lose any work. That was true for a long time. Now with service workers and progressive web apps, that is I think less of a compelling argument, especially since service workers can fetch full HTML files and cache them ahead of time if needed.

Chris: You can literally have your whole app available offline before someone has even visited those pages if you want. It just happens in the background without the user having to do anything. It's again, one of those technologies that maybe made sense for certain use cases a few years ago a little less compelling now.

Drew: It reminds me slightly of when we used to build websites in Flash.

Chris: Yes.

Drew: And you'd have just a rectangle embedded in an HTML page which is your Flash Player, and you'd build your entire site in that. You had to reimplement absolutely everything. There was no back button. If you wanted a back button, you had to create a back button, and then you had to create what the concept of a page was. You were writing code upon code, upon code to reimplement just as you are saying things that the browser already does for you. Does all this JavaScript that we're putting into our pages to create this functionality… is this going to cause fragility in our front-ends?

Chris: Yes. This is almost certainly from my mind, one of the biggest issues with our over-reliance on JavaScript. JavaScript is just by its nature, is a scripting language, the most fragile part of the front-end stack.

Chris: For example, if I write an HTML element that doesn't exist, I spell article like arcitle instead of article and the browser runs across that, it's going to be like, “Oh, I don't know what this is. Whatever, I'll just treat it like a div.” And it keeps going. If I mistype a CSS property… Let's say I forget the B in bold, so I write old instead, font way old. The browser's going to be, “I don't know what this is. Whatever, we'll just keep going.” Your thing won't be bold, but it will still be there.

Chris: With JavaScript, if you mistype a variable name or you try to use a property, you try to call a variable that doesn't exist or a myriad of other things happen… your minifier messes up and pulls one line of code to the one before it without a semicolon where it needs one, the whole app crashes. Everything from that line on stop working. Sometimes even stuff that happens before that doesn't complete, depending on how your app is set up. You can very quickly end up with an app that in a different approach, one where you rely a lot more on HTML and CSS, it would work. It might not look exactly right, but it would still work… to one that doesn't work at all.

Chris: There's an argument to be made that in 2020, JavaScript is an integral and important part of the web and most people don't disable it and most people are using devices that can actually handle modern JavaScript. That's true, but that's not the only reason why JavaScript doesn't work right, even if you have a linter there for example and you catch bugs ahead of time and things. There's plenty of reasons why JavaScript can go horribly awry on you. CDNs fail.

Chris: Back in July of last, a year ago this month… at least, when we're recording this… a bad deploy took down Cloudflare. Interestingly as we're recording this, I think a week or two ago, Cloudflare had another massive outage that broke a whole bunch of things, which is not a knock on Cloudflare. They're an incredibly important service that powers a ton of the web. But CDNs do sometimes go down. They are a provider used by 10% of Fortune 1,000 companies. If your JS is served by that CDN and it breaks, the JavaScript file never loads. And if your content is dependent on that JS, your users get nothing instead of getting something just not styled the way you'd like.

Chris: Firewalls and ad blockers get overly aggressive with what they block. I used to work at a company that had a JavaScript white list because they were extremely security conscious, they worked with some government contract stuff. They had a list of allowed JavaScript, and if your site or if your URL wasn't part of that, no JavaScript. You have these sites. I remember going to a site where it had one of the hamburger kind of style menus on every view whether it was desktop or mobile, and I could not access any page other than the homepage because no JavaScript, no hamburger, that was it.

Chris: Sometimes connections just timeout for reasons. Either the file takes a while or someone's in a spotty or slow connection. Ian Feather, an engineer at BuzzFeed, shared that about 1% of requests for JavaScript on the site fail which is 13 million requests a month. Or it was last year, it's probably even more now. That's a lot of failed JavaScript. People commuting go through tunnels and lose the internet. There's just all sorts of reasons why JavaScript can fail and when it does, it's so catastrophic.

Chris: And so we built this web that should be faster than ever. It's 2020, 5G is starting to become a thing. I thought 4G was amazing. 4G is about as fast as my home wifi network. 5G is even faster, which is just bonkers. Yet somehow, we have websites that are slower and less performant than they were 5 or 10 years ago, and that makes no sense to me. It doesn't have to be that way.

Drew: How do we get out of this mess, Chris?

Chris: Great question. I want to be really clear. I know I've hammered on this a couple times. I'm not saying all the new stuff is bad, never use it. But what I do want to encourage is a little bit more thoughtfulness about how we build for the web.

Chris: I think the overlying theme here is that old doesn't mean obsolete. It doesn't mean never embrace new stuff, but don't be so quick to just jump on all the shiny new stuff just because it's there. I know it's one of the things that keeps this industry really exciting and makes it fun to work in, there's always something new to learn. But when you pick these new things, do it because it's the right tool for the job and not just because it's the shiny new thing.

Chris: Un'altra cosa di cui non ci siamo occupati tanto quanto avrei voluto, ma penso sia davvero importante, è che la piattaforma ha raggiunto un grande successo negli ultimi anni. Abbracciarlo il più possibile si tradurrà in un'esperienza web per le persone che è più veloce, meno fragile, più facile da creare e mantenere perché richiede meno dipendenze come l'utilizzo di ciò che il browser ti offre fuori -la scatola. Avevamo bisogno di jQuery per selezionare cose come le classi. Ora i browser hanno modi nativi per farlo. Alla gente piace JSX perché ti consente di scrivere HTML in JavaScript in un modo più semplice. Ma abbiamo anche valori letterali modello in JavaScript Vanilla che ti danno lo stesso livello di facilità senza la dipendenza aggiuntiva. Lo stesso HTML ora può sostituire molte cose che prima richiedevano JavaScript, il che è assolutamente sorprendente.

Chris: Abbiamo parlato un po' di... questa è una cosa CSS, ma passa il mouse sopra i link e come questo richiedeva JavaScript. Ma utilizzando elementi come i dettagli e gli elementi di riepilogo, puoi creare informazioni, come espandere e ridurre o elementi a fisarmonica in modo nativo senza bisogno di script. Puoi eseguire input di completamento automatico usando solo un... Non dovrei dire solo, odio quella parola. Ma utilizzando un semplice elemento di input e quindi un elemento dell'elenco di dati che viene associato ad esso, con alcune opzioni. Se sei curioso di sapere come funziona una di queste cose su vanillajstoolkit.com, ho un sacco di roba JavaScript che ti offre la piattaforma. Ma ho anche usato alcuni per richiedere JavaScript e ora non ci sono cose che potrebbero essere interessanti se vuoi che alcuni esempi di codice vadano d'accordo con questo.

Chris: Per quanto riguarda i CSS, il mio plugin Vanilla JS più popolare di sempre è questa libreria che ti consente di animare lo scorrimento verso il basso fino ai link di ancoraggio. È molto grande. È il pezzo di codice più difficile che abbia mai dovuto scrivere. E ora è completamente sostituito con una singola riga di CSS, il comportamento di scorrimento è fluido. È più performante. È più facile scrivere. È più facile modificarne il comportamento. È solo una soluzione generale migliore.

Chris: Un'altra cosa che vorrei che facessimo di più è appoggiarsi alle app multipagina. Mi sento un po' vendicato qui, perché di recente ho visto un articolo di qualcuno di Google che spinge per questo approccio anche adesso. Ho pensato che fosse piuttosto interessante, dato questo enorme angolo e poi struttura... tutte le cose, boom, che Google ha avviato alcuni anni fa. È bello vederli tornare su questo. Utilizzando elementi come generatori di siti statici e servizi straordinari come Netlify e la memorizzazione nella cache CDN, puoi creare esperienze Web incredibilmente veloci per le persone che utilizzano singoli file HTML per tutte le tue diverse visualizzazioni. Così come fare affidamento su alcune di queste cose fuori dagli schemi.

Chris: In situazioni in cui non è realistico per te, in cui hai bisogno di più JavaScript, hai bisogno di una sorta di libreria, magari dando un'occhiata agli approcci più piccoli e modulari prima invece di andare solo per i colossi del settore. Invece di React, Preact funzionerebbe? Invece di angolare... Voglio dire, invece di Vue, Alpine JS funzionerebbe? C'è anche questo pre-compilatore davvero interessante là fuori ora chiamato Svelt, che ti offre un'esperienza simile a un framework e quindi compila tutto il tuo codice in Vanilla JavaScript. Quindi ottieni questi pacchetti davvero minuscoli che hanno proprio ciò di cui hai bisogno e nient'altro. Invece di CSS e JavaScript, potresti inserire qualche linter CSS di terze parti che confronterà il tuo HTML con il tuo CSS ed eliminerà le cose che sono state lasciate lì per caso? Un modo diverso di creare il tuo CSS, come il CSS orientato agli oggetti di Nicole Sullivan, funzionerebbe invece? Non siamo riusciti a parlarne, ma è una cosa davvero interessante che la gente dovrebbe controllare.

Chris: E poi penso che forse il terzo e più importante pezzo qui, anche se è un approccio meno specifico e più solo una cosa che vorrei che più persone tenesse a mente, è che il web è per tutti. Molti degli strumenti che utilizziamo oggi funzionano per le persone che hanno buone connessioni Internet e dispositivi potenti. Ma non funzionano per le persone che utilizzano dispositivi meno recenti, hanno connessioni Internet irregolari. Non si tratta solo di persone nelle aree in via di sviluppo. Si tratta anche di persone nel Regno Unito, in alcune parti degli Stati Uniti dove abbiamo connessioni Internet assolutamente pessime. Il centro del nostro paese ha Internet molto lento. So che ci sono posti in una parte di Londra in cui non possono collegare una nuova banda larga per ragioni storiche, quindi ti rimangono queste vecchie connessioni Internet che sono davvero pessime. Ci sono posti del genere in tutto il mondo. L'ultima volta che sono stato in Italia, stessa cosa. Internet era orribile. Non so se è cambiato da allora.

Chris: Le cose che costruiamo oggi non sempre funzionano per tutti, ed è un peccato. Perché la visione del web, la cosa che amo di esso, è che è una piattaforma per tutti.

Drew: Se gli ascoltatori vogliono saperne di più su questo approccio, hai approfondito un sacco di dettagli nel tuo libro, The Lean Web. E questo è disponibile online. È un libro fisico o un libro digitale?

Chris: È un po' di entrambi. Beh no. Non è sicuramente un libro fisico. Vai su leanweb.dev. Puoi leggere tutto gratuitamente online. Puoi anche se vuoi, ci sono versioni EPUB e PDF disponibili per una piccola somma di denaro, non ricordo quanto ora. Non lo guardo da un po'. Il tutto è gratuito online se lo desideri. Puoi anche guardare un discorso su questo argomento in cui entro in maggiori dettagli, se lo desideri.

Chris: Ma ho anche creato una pagina speciale solo per gli ascoltatori di Smashing Podcast su gomakethings.com/smashingpodcast, perché sono molto creativo con i nomi delle cose. Ciò include un sacco di risorse oltre al libro, su cose di cui abbiamo parlato oggi. Si collega a molte delle diverse tecniche che abbiamo trattato, ad altri articoli che ho scritto che approfondiscono alcuni di questi argomenti e ampliano un po' il mio pensiero. Se la gente vuole saperne di più, quello sarebbe probabilmente il miglior punto di partenza.

Drew: È fantastico. Grazie. Ho imparato tutto sul Lean Web. Cosa stai imparando ultimamente, Chris?

Chris: Sì, un paio di cose. Ho accennato a questo un po' prima guardando il video di Jeremy sulle app web progressive. Ho rimandato l'apprendimento di come scrivere effettivamente la mia app web progressiva per un paio d'anni perché non avevo un bisogno specifico di nulla con cui stavo lavorando. Di recente ho appreso da uno dei miei studenti che si trova in Sud Africa, che hanno avuto a che fare con blackout continui a causa di alcune cose che stavano succedendo laggiù. Di conseguenza, non è in grado di lavorare su alcuni dei progetti che stiamo facendo insieme regolarmente, perché la corrente si interrompe e non può accedere al portale di apprendimento e seguire.

Chris: Per me, ora costruire un'esperienza in cui funzioni anche se qualcuno non ha Internet è diventata una priorità più alta di... Mi sono reso conto che forse lo era prima, quindi ho iniziato a scavare e spero di metterlo insieme le prossime settimane. Vedremo. Tuttavia, le risorse di Jeremy Keith su questo sono state un vero toccasana. Sono contento che esistano.

Chris: Lo so, Drew, hai menzionato uno dei motivi per cui ti piace fare questa domanda è mostrare che le persone, non importa quanto siano esperte, imparano sempre. Solo un piccolo aneddoto correlato. Sono stato uno sviluppatore web per credo, circa otto anni. Devo ancora cercare su Google la proprietà CSS da usare per rendere le cose in corsivo, letteralmente ogni volta che la uso. Per qualche ragione, il mio cervello usa per impostazione predefinita la decorazione del testo anche se non è quella giusta. Proverò un paio di combinazioni di cose diverse e sbaglio sempre una parola ogni volta. A volte scrivo anche corsivo invece di corsivo. Sì. Se mai qualcuno si sente come se, oh, non imparerò mai queste cose... sappi solo che non importa quanto sei esperto, c'è sempre qualcosa di veramente basilare che cerchi su Google più e più volte.

Drew: Sono uno sviluppatore web da 22, 23 anni e devo ancora cercare su Google le diverse proprietà di Flexbox, ogni volta. Anche se lo uso da 23 anni. Ma sì, alcune cose solo... probabilmente ce ne saranno altre man mano che invecchierò.

Chris: Sì. Onestamente, ho finito per costruire un intero sito Web di cose che ho cercato su Google più e più volte, solo per avere un riferimento copia-incolla più semplice perché era più facile di Google.

Drew: Non è una cattiva idea.

Chris: Questo è il tipo di pigro che sono. Costruirò un intero sito Web per salvarmi come tre secondi di Google.

Drew: Se tu, l'ascoltatore, desideri saperne di più da Chris, puoi trovare il suo libro sul Web all'indirizzo leanweb.dev e la sua newsletter sui suggerimenti per gli sviluppatori e altro ancora su gomakethings.com. Chris è su Twitter da Chris Ferdinandi. E puoi dare un'occhiata al suo podcast su vanillajspodcast.com o ovunque tu di solito trovi i tuoi podcast. Grazie per esserti unito a noi oggi, Chris. Hai qualche parola d'addio?

Chris: No. Grazie mille per avermi ospitato, Drew. Mi sono divertito moltissimo. Questo è stato un sacco di divertimento. Apprezzo molto l'opportunità di venire a chattare.