Smashing Podcast Episodio 32: Recensione dell'anno 2020

In questo episodio, diamo uno sguardo al 2020. Con chi abbiamo parlato nei nostri episodi quest'anno e cosa abbiamo imparato? Riascoltiamo alcune clip per scoprirlo.

Mostra note

Puoi trovare tutti i nostri episodi passati, inclusa una trascrizione completa di ogni intervista su podcast.smashingmagazine.com.

Ci vediamo nel 2021, a tutti!

Trascrizione

Drew McLellan: A gennaio, ho parlato con Amy Hupe del suo lavoro sul sistema di progettazione del governo del Regno Unito e, in particolare, di come il team abbia aumentato l'adozione del sistema da parte dell'organizzazione più ampia incoraggiando i contributi. Ecco Amy.

Amy Hupe: Abbiamo iniziato molto presto. Quindi, molto prima di avere una sorta di sistema di progettazione pubblica, abbiamo iniziato a interagire con persone che pensavamo potessero essere dei contributori interessati. Dovrei menzionare qui che abbiamo avuto un brillante progettista di servizi nel team. Si è unita a noi... Non ho intenzione di ottenere le date corrette in alcun modo al momento, ma penso che abbia lavorato con noi per tutto il 2018 e si chiami Ignacia. Ha semplicemente fatto un lavoro fantastico andando in giro e coinvolgendo le persone. Quindi una delle cose che ha fatto è stata identificare tutti i diversi modelli di governo e tutti i diversi tipi di variazioni di quei modelli. Quindi uscire e in un certo senso dire: "Va bene. Ci sono 10 modi diversi per chiedere un indirizzo nel governo. Diamo un'occhiata a tutti insieme e decidiamo quale riteniamo sia l'approccio più appropriato. Come possiamo consolidarli in uno solo?"

Amy Hupe: Ha condotto un grande seminario per cercare di convincere le persone a guardarli e fare quel tipo di consolidamento come squadra. Penso che sicuramente il suo approccio alla creazione di una collaborazione in un modo molto precedente alla pubblicazione di qualsiasi cosa al pubblico abbia davvero aiutato in questo perché significava che le persone ne avevano già quel tipo di consapevolezza e molte persone avevano già contribuito in qualche modo o un altro prima che lo rendessimo effettivamente pubblico. Quindi eravamo più o meno passati di qualche passo avanti. Quindi penso che sia stato davvero importante e solo perseveranza, molta persistenza da parte di tutto il team nell'aiutare le persone a contribuire.

Amy Hupe: Penso che ci sia un'idea che se fai in modo che le persone contribuiscano a un sistema di progettazione, è un concerto piuttosto carino, perché puoi semplicemente convincere le persone a fare tutto il lavoro per te, e in un certo senso ti siedi lì, e tu fai le tue piccole correzioni al codice e tutti ti stanno davvero dando tutte le cose buone. Ma in realtà, come saprà chiunque abbia lavorato su un sistema di progettazione, è incredibilmente complesso. È molto difficile creare una soluzione centralizzata che funzioni per più team diversi.

Amy Hupe: Davvero, a meno che tu non abbia lavorato su un sistema di progettazione, non è ragionevole aspettarsi che qualcuno capisca davvero cosa ci vuole. Quindi c'è molto tipo di presa in mano. C'è molto lavoro da fare per aiutare i contributori a contribuire. Penso di averlo già detto, ma probabilmente ci vuole più tempo, credo, per aiutare qualcuno a contribuire a un sistema di progettazione di quanto non sarebbe necessario per realizzare la cosa da soli e dal team centralizzato. Ma penso che riconoscere il valore che porta ed essere persistenti nei tuoi sforzi per rendere le persone consapevoli del contributo, aiutarle a farlo, aiutarle a sentirsi in qualche modo motivate a farlo, penso di sì, quella persistenza è stata davvero fondamentale per il nostro successo in quell'area.

Drew: Siamo stati raggiunti da Stephanie Stimac e Aaron Gustafson di Microsoft per parlare di Edge che adotta Chromium come motore di rendering. Ho chiesto ad Aaron del panorama competitivo tra i browser e di dove i browser multipli che si uniscono sullo stesso motore di rendering eliminerebbero quella sana concorrenza e quindi sarebbero dannosi per il web aperto.

Aaron Gustafson: Questo è qualcosa con cui ho sicuramente lottato un po' per essere stato un esperto di standard web per molto tempo. Ho perfettamente la giustificazione commerciale per questo. Dal punto di vista di Microsoft, aveva molto senso. Dal punto di vista dello sviluppatore front-end, è bello non dover soddisfare un mucchio di motori diversi. Voglio dire, nel complesso, quelli di noi che lavorano sul web da molto tempo hanno sicuramente visto molta convergenza in termini di rendering. Non abbiamo tutti i problemi che abbiamo avuto, diciamo in Netscape per sette giorni, dove abbiamo avuto proprio come... Conoscevo aziende che stavano creando fogli di stile unici per ogni diverso browser, il che era semplicemente insostenibile.

Aaron Gustafson: Ma penso che ciò che è un po' diverso ora è che nelle guerre dei browser originali, avevi tutti questi motori proprietari e tutti erano in un certo senso in un gioco di potenziamento in termini di tentativo di fornire nuove funzionalità della piattaforma e nuove funzionalità JavaScript o, nel caso di Microsoft reverse engineering JavaScript per creare JScript e cercare di capire come far combaciare il tutto.

Aaron Gustafson: Ma ora abbiamo la possibilità di lavorare insieme in progetti open source e avere ancora il dialogo e ancora... non lo so. Combattere non è la parola giusta, ma avere discussioni serie sull'impatto dei diversi approcci e non essere d'accordo tra loro e lavorare davvero per rendere le specifiche davvero buone e avere anche approcci in competizione al codice sottostante nel contesto, ad esempio di un Chromium progetto o WebKit o qualcosa del genere o Missoula nello spazio di Firefox.

Aaron Gustafson: Quindi sì. Da un lato, abbiamo perso un altro motore di rendering e ho sentito lo stesso dolore quando l'opera ha deciso di passare a Chromium. Ma mi sento un po' rincuorato ad essere all'interno di Microsoft e vedere quanto siamo impegnati a partecipare effettivamente al progetto Chromium in modo significativo e non solo sedendoci e accettando semplicemente tutto ciò che viene a valle da Chromium, ma in realtà controllando cosa sta succedendo la piattaforma e parteciparvi... Sì.

Aaron Gustafson: Quindi sono un po' rincuorato da questo e sento che non siamo lì solo per prendere da quel progetto e accettare semplicemente tutto ciò che viene tramandato da tutte le diverse persone che hanno un interesse in quel progetto, ma per effettivamente collaborare anche lì.

Drew: A febbraio, ho parlato con Stephanie Walter del lavoro con framework dell'interfaccia utente come Bootstrap e amici e del bilanciamento con le esigenze personalizzate di un'interfaccia utilizzabile. Ho chiesto a Stephanie se fosse possibile creare un'interfaccia utente altamente utilizzabile utilizzando un framework standard o se sarebbe sempre stato un compromesso imbarazzante.

Stephanie Walter: Sì. Penso che sia. Ma dipende anche dal livello di compromesso che sei disposto a fare, e questo compromesso da entrambe le parti. Al momento, sto compromettendo molti pulsanti, ad esempio, perché hai alcuni pulsanti davvero specifici in un'interfaccia utente materiale. Non mi piace molto l'effetto increspatura sul pulsante. Penso che funzioni alla grande sui dispositivi mobili perché sui dispositivi mobili è necessario un tipo di feedback importante quando l'utente fa clic o tocca il pulsante. Ma poi intensificano questo tipo di effetto a catena che arriva fino in fondo sul pulsante. È un po' eccessivo, specialmente quando ci sono molti pulsanti. Ma continueremo comunque a mantenere questo effetto a catena perché sarebbe super complesso rimuoverlo perché è stato integrato nel framework React e per avere un altro effetto hover su questo pulsante, qualcosa di più sottile che non sarebbe questo tipo di cosa cespugliosa qui. Sarebbe super complesso. Quindi questo è il tipo di compromessi che fai.

Drew: Il design etico è stato l'argomento della mia conversazione con Trina Felber e Martin Michael Fredrickson. Ho chiesto se adottare un approccio etico alla progettazione ed evitare schemi oscuri fosse un caso di pensare a lungo termine alla salute e alla crescita di un'azienda piuttosto che solo agli obiettivi di vendita a breve termine. Ecco Martino.

Martin Michael Fredrickson: È perfettamente vero. Penso che tu debba guardare al business che fai online come se avessi un negozio sulla via principale di una città di medie dimensioni, dove devi mantenere intatta la tua reputazione. Se non tratti bene i tuoi clienti, se non tratti bene i tuoi clienti, a lungo termine, finirai l'attività perché le persone andranno in qualche altro negozio o acquisteranno da online. Quindi, qualunque cosa tu faccia online, devi davvero pensare che c'è un effetto a lungo termine e, inoltre, c'è un costo nascosto nel fare cose complesse o manipolabili. Se declutter, come dice Trina, ci sarà un risparmio a lungo termine, che non viene mai calcolato quando si parla di modello di business. Parli sempre di quanti soldi puoi guadagnare. Non parli mai del costo per fare quella somma di denaro.

Drew: A marzo, ho parlato con Eduardo Boucas di uno strumento open source chiamato Sourcebit che raccoglie contenuti da fonti disparate e li rende disponibili per il generatore di siti statici. Ho chiesto a Eduardo se ciò potesse migliorare l'esperienza utente dell'autorizzazione per un SSG consentendo l'integrazione con strumenti come i CMS headless.

Eduardo Boucas: Esatto. Sì. Il modo in cui potrebbe... Vedo due modi diversi di utilizzare lo strumento che può aiutare gli sviluppatori. Uno è rendere Sourcebit parte della tua routine di distribuzione. Quindi, se stai usando una piattaforma di hosting, come Netlify, ad esempio, e configuri i tuoi comandi di distribuzione in modo che siano, non lo so, Hugo build, è il comando build per Hugo o qualcosa del genere, il tipo di comando che genera i file statici per Hugo. Avresti anche un altro comando come parte di quella routine. Sarebbe qualcosa come il recupero di Sourcebit. Quindi, in fase di compilazione, Sourcebit estrarrà tutti gli altri dati, genererà tutti i file di cui Hugo ha bisogno, quindi l'intera distribuzione utilizzerà già quei file e distribuirà tutto il contenuto proveniente dal CMS.

Eduardo Boucas: Quindi questo è un possibile caso d'uso per Sourcebit. L'altro consiste nell'usare Sourcebit come sviluppo locale nel flusso di lavoro di sviluppo locale. Quindi puoi eseguire Sourcebit con qualcosa che chiamiamo modalità orologio. Quindi Sourcebit continua a cercare modifiche nell'origine dati remota, quindi in questo caso, il CMS senza testa. Quindi ogni volta che pubblichi un articolo o modifichi una voce in CMS, Sourcebit lo riconoscerà e rigenererà tutti i file localmente per te.

Eduardo Boucas: Quindi ciò che significa per gli sviluppatori che lavorano localmente è che puoi avere la tua finestra CMS accanto al tuo sito Hugo in esecuzione localmente e quindi puoi vedere i cambiamenti che si verificano in tempo reale. Cambia qualcosa sul CMS e poi puoi vedere che il cambiamento si riflette sul sito locale, cosa che trovo super utile. Quindi questi sono i due modi in cui potresti usare Sourcebit.

Drew: L'ottimizzazione delle conversioni era l'argomento del giorno. Quando ho parlato con il podcaster e consulente veterano, Paul Boag. Abbiamo parlato di alcune delle tecniche che i siti utilizzano per convertire i visitatori in clienti. Ma volevo chiedere a Paul come misuri l'impatto dei cambiamenti che fai. Paolo ha spiegato.

Paul Boag: Sì. Assolutamente. Penso, ancora una volta, che questo sia qualcosa in cui molte organizzazioni sono piuttosto scarse è essere chiari su come misureranno il successo. Ora, sì, il tuo tasso di conversione è una metrica. Dovresti assolutamente seguirlo. Ma anche con la conversione, devi essere un po' più sofisticato di quante persone stanno acquistando. È inoltre necessario prestare attenzione al valore medio dell'ordine. Devi prestare particolare attenzione al lifetime value, giusto? Quindi quanto vale un cliente nel corso della sua intera vita, perché potresti scoprire che stai ottenendo un tasso di abbandono piuttosto elevato di clienti, se usi schemi oscuri e cose del genere. Ma in realtà, la conversione dovrebbe essere solo una delle metriche che stai misurando.

Paul Boag: Ci sono anche cose come devi prestare attenzione al coinvolgimento, quanto sono coinvolte le persone con i tuoi contenuti, perché questo fa una grande differenza se alla fine si convertiranno. Quindi stai guardando cose come, quanto costano i tuoi video, guardano, quanto tempo trascorrono sul tuo sito e cosa guardano mentre lo fanno? Si stanno impegnando sui social media e su questo genere di cose? Poi l'ultimo aspetto è ovviamente l'usabilità. È necessario misurare la velocità con cui qualcuno può completare un'attività particolare sul proprio sito Web e quanto è facile trovare il sistema da utilizzare e vari altri criteri diversi.

Paul Boag: Ci sono un sacco di meccanismi che puoi usare per misurare queste cose diverse. Ci sono alcuni ottimi strumenti là fuori e anche alcune buone metriche che puoi adottare. Quindi, ad esempio, con l'usabilità, c'è qualcosa chiamato scala di usabilità del sistema che può essere una metrica molto utile da misurare. Ma allo stesso modo, ci sono strumenti come maze.design è uno che uso spesso, che misurerà il tempo impiegato da qualcuno per effettuare un acquisto, ad esempio, per completare la cassa. Quindi sì. Avendo quel tipo di ampia gamma di metriche, non ti stai concentrando solo su, quante vendite abbiamo realizzato in questo trimestre? Devi guardare il quadro più grande.

Drew: Ad aprile, ho parlato con Laura Kalbag di Better Blocker sulla privacy online. Abbiamo parlato dei confini sempre più sottili tra ciò che è considerato pubblico e ciò che è privato e di come le cose che consideriamo private potrebbero non essere viste in questo modo dalle aziende a cui affidiamo i nostri dati. Ecco Laura.

Laura Kalbag: Ho un classico esempio di questo che mi è successo qualche anno fa. Quindi ero su Facebook, mia madre era appena morta e ricevevo annunci per i direttori di pompe funebri. Ho pensato che fosse davvero strano perché nessuno della mia famiglia aveva detto nulla su una piattaforma di social media a quel punto. Nessuno della mia famiglia aveva detto nulla su Facebook perché eravamo d'accordo sul fatto che nessuno volesse scoprire questo genere di cose su un amico o un familiare tramite Facebook. Quindi non ne avevamo parlato.

Laura Kalbag: Così ho chiesto ai miei fratelli: "Oh, qualcuno ha detto qualcosa su Facebook che potrebbe causare questo strano". Perché di solito ricevo solo annunci per trucco e vestiti e test di gravidanza e tutte quelle cose divertenti di cui amano parlare. Sono le donne di una certa età. Invece, mia sorella è tornata da me. Ha detto: "Beh, sì. Il mio amico vive in Australia”. Così le ho mandato un messaggio su Facebook Messenger e le ho detto che nostra madre era morta. Ovviamente Facebook sapeva che siamo sorelle. Ha quella connessione di relazione che puoi scegliere di aggiungere lì. Voglio dire, potrebbe probabilmente indovinare che eravamo sorelle comunque, dai luoghi in cui siamo stati insieme, dal fatto che condividiamo un cognome e abbiamo deciso: "Oh, è una pubblicità appropriata da mettere nei suoi piedi".

Drew: È sconfortante, non è vero, pensare che la tecnologia stia prendendo queste decisioni per noi, che in realtà colpisce le persone potenzialmente in questo esempio in un momento piuttosto sensibile o vulnerabile?

Laura Kalbag: Sì. Diciamo che è inquietante. Molte volte le persone dicono: "Oh, è quasi come se il microfono del mio telefono o il mio laptop mi stessero ascoltando perché stavo solo conversando su questo particolare prodotto e all'improvviso appare nel mio feed ovunque". Penso che ciò che in realtà fa paura sia il fatto che la maggior parte di loro non ha accesso al tuo microfono. Ma è il fatto che i tuoi altri comportamenti, la tua ricerca, il fatto che sa con chi stai parlando a causa della tua vicinanza e della tua posizione sui tuoi dispositivi. Può collegare tutte quelle cose che potremmo non collegare insieme per dire solo: "Oh, forse saranno interessati a questo prodotto perché probabilmente ci stavano pensando, ne stavano già parlando".

Drew: Quando la pandemia di coronavirus ha colpito e molte nazioni sono entrate in una qualche forma di blocco, ho parlato con Rachel Andrew di come Smashing stesse adattando la sua conferenza di persona programmata per tenersi online. Avendo dovuto rimandare la conferenza Smashing a San Francisco, ho chiesto a Rachel quale fosse il piano per spostare le conferenze e i workshop imminenti nel dominio virtuale.

Rachel An Drew: Molto, molto rapidamente, una volta che ci siamo resi conto che avremmo dovuto posticipare San Francisco, ovviamente, abbiamo seminari, sia io che Vitaly organizziamo seminari su smash e comp, ed erano esauriti a San Francisco, entrambi i nostri laboratori. Ovviamente, abbiamo molte altre persone che vengono e tengono workshop per noi, persone con cui abbiamo lavorato per molto tempo, e hanno scoperto che tutti i loro workshop, e per quelli di noi che fanno workshop, hanno effettivamente un parte fondamentale del nostro reddito.

Rachel An Drew: Parlando in pubblico, non guadagni molti soldi in genere andando e parlando in pubblico. La maggior parte delle persone non viene pagata molto, non se si considera la quantità di tempo necessaria per scrivere discorsi e così via. I seminari tendono ad essere un modo piuttosto carino per le persone che sono brave a insegnare queste cose per guadagnare un po' di soldi. Quindi rappresentano il reddito delle persone. Quindi non solo avevo bisogno di me e Vitaly aveva perso i nostri seminari all'inizio di quest'anno. Ci siamo anche resi conto che anche molti dei nostri altoparlanti Smashing facevano affidamento su quei workshop.

Rachel An Drew: Quindi abbiamo pensato: "Beh, perché non portarli online?" Molto, molto rapidamente, davvero pochi giorni dopo che ciò è accaduto, abbiamo deciso che io e Vitaly saremmo stati i primi a mettere la testa a posto sul potere, ma dato che siamo noi, e potremmo in qualche modo capire come farlo. Abbiamo anche workshop molto diversi. Vitaly è molto più collaborativo. Ha attività e cose di gruppo. Insegno stile di classe. Quindi tra noi abbiamo pensato: "Beh, stiamo coprendo tutte le basi". Quindi abbiamo pensato: "Facciamolo e basta. Vediamo se funziona". Quindi li pubblicizziamo. Abbiamo in qualche modo capito quanto tempo ci voleva, e poi ci siamo seduti e abbiamo detto: "Beh, che aspetto ha davvero un seminario online? Cos'è questo?"

Drew: Penso da un punto di vista tecnico come sviluppatori web che pensano immediatamente, come diavolo faremo a fornire qualcosa del genere, voglio dire, ci devono essere molte piattaforme diverse che hai guardato. Quali sono state le diverse cose che hai guardato e cosa alla fine è arrivato Smashing?

Rachel An Drew: Quindi abbiamo dato un'occhiata a ogni genere di cose, e siamo ancora in procinto di farlo. Al momento stiamo usando Zoom. Il motivo per cui utilizziamo Zoom è l'accessibilità. Era la più accessibile delle piattaforme. Ovviamente, non vogliamo escludere le persone a causa della piattaforma che abbiamo scelto. Penso che le altre piattaforme stiano migliorando e le persone stiano... Penso che molte piattaforme abbiano avuto persone che si sono avvicinate a loro e hanno detto: "Sì, sei fantastico. Ma abbiamo bisogno che tu sia accessibile”. Quindi lo zoom è il più facile da usare per le persone al momento". Ecco perché abbiamo finito per usarli. Non so se lo faremo per sempre. Ma è quello che stiamo usando al momento, e ha funzionato abbastanza bene come un modo per fare queste cose.

Drew: Quando la fatica di Zoom è iniziata e il mondo ha iniziato ad adattarsi a quella che è stata rapidamente chiamata la nuova normalità, ho parlato con Phil Smith di come la tecnologia può aiutarci a rispondere a situazioni come il COVID-19. Realizzazione dell'app React Native, CardMedic in soli 10 giorni. Ho chiesto a Phil come riesce a bilanciare la scelta della migliore tecnologia per il lavoro rispetto alle tecnologie con cui ha familiarità e con cui può lavorare rapidamente.

Phil Smith: Questa è una buona domanda. Penso che non appena il progetto mi è stato menzionato, ho pensato di sapere esattamente come costruirò tutto questo. Se non avessi figli e mi fossi seduto in una stanza buia, penso che avrei probabilmente potuto cambiare tutto in circa cinque giorni se avessi lavorato su di esso solido, solido, solido perché i requisiti erano molto in in linea con la mia esperienza di creazione di app. Ho creato un tipo simile di cose, in cui chiama un'API, memorizza i risultati nello stato e li presenta. Ora sono in una posizione in cui ci sono alcune parti in cui dico: "Ok, devo tornare indietro e riformularlo".

Phil Smith: Ho parlato della digitazione di tin, ma in realtà i tipi possono essere piuttosto sciolti nell'app e questo deve essere rafforzato. Sul back-end, non ci sono molti test e ora stiamo iniziando a lanciare il back-end perché molte persone si sono fatte avanti e hanno detto: “In realtà, questa è una grande risorsa. Vorrei offrire i miei servizi volontariamente per tradurre questo nella mia lingua madre. Le estremità posteriori sono utilizzate da più persone, quindi sto solo pensando: "Aspetta, ho bisogno di qualche altro test qui per assicurarmi che nulla possa rompersi perché ci sono persone che lo usano in produzione ora". Penso di aver risposto alla tua domanda. In sostanza, non c'era alcun processo decisionale. Dovevo solo portarlo là fuori il più rapidamente possibile.

Drew: Poiché i luoghi di lavoro sono chiusi e molti di noi si sono adattati al lavoro da casa, ho parlato con Ben Frain dell'ottimizzazione dello spazio di lavoro domestico in modo che sia un luogo confortevole e produttivo non comporterà problemi di salute fisica a lungo termine. Con budget limitati disponibili per l'installazione a casa, ho chiesto a Ben se una buona sedia fosse il punto di partenza migliore.

Ben Frain: Questo sarebbe il mio consiglio. Sì. Voglio dire, non posso dichiarare di essere un'autorità su queste cose, ma sembra che sia probabilmente la cosa più importante che potresti fare per metterti a tuo agio durante la giornata. Puoi iniziare con qualcosa di abbastanza costoso. Ho fatto lo stesso errore e ho finito per ottenere una sedia da ufficio da 45 libbre da Amazon, e non mi rendevo conto che non aveva un'inclinazione in avanti, qualunque sia la parola giusta per quella cosa, sull'asse. Quindi quello che ho scoperto è che stava scavando nella parte inferiore delle mie cosce, una specie di dietro le mie ginocchia, e stavo pensando: "Perché le mie gambe stanno morendo dopo 45 minuti di seduta in quella cosa?"

Ben Frain: Penso in particolare che se lavori per un'azienda che fornisce sedie da ufficio decenti, le dai per scontate, e solo quando guardi quella particolare marca e marchio che dici: "Oh mio Dio, questo è una sedia da 700 dollari”. Quando ti rendi conto di quella critica, le persone ci hanno pensato e hanno fatto molto per te, e poi ovviamente vieni nel tuo ambiente domestico e pensi: "Perché non spendere X cento dollari per una sedia?" Ma forse ne vale la pena. Soprattutto se sei qui per il lungo raggio.

Drew: E il lungo raggio è quello che abbiamo. Qualcos'altro che è in giro per il lungo raggio è Drupal. A giugno ho parlato con Angie Byron dei cambiamenti in Drupal 9. A 20 anni dalla sua prima uscita, Drupal ha fatto molta strada. Ho chiesto ad Angie come fosse il processo di aggiornamento di un sito Drupal esistente quando si è passati a Drupal 9 e se fosse probabile che fosse un grosso onere per chi ha siti di lunga data.

Angie Byron: Penso che ci siano fondamentalmente tre scenari. Quindi uno è se stavi eseguendo Drupal 8 e ogni volta che usciva una nuova versione minore di Drupal 8, l'hai aggiornato immediatamente a una e hai iniziato a utilizzare le nuove cose. Il tuo percorso sarà praticamente nulla. Hai già fatto tutto il lavoro e stai bene. Se ti sei trasferito a Drupal 8 qualche tempo fa e non sei stato al passo con i cambiamenti del BC, c'è un po' di lavoro per te.

Angie Byron: In ogni caso, è sicuramente l'aggiornamento più semplice in oltre un decennio del nostro software e abbiamo un sacco di strumenti diversi per aiutarti. C'è una dashboard che mostra tutti i moduli che hanno contribuito e qual è la loro situazione in Drupal 9. Ci sono strumenti automatizzati per esaminare e controllare il codice e contrassegnare tutte le funzioni obsolete che hai, e ci sono strumenti per andare automaticamente e trovare "Oh, questa è l'ultima versione del tuo modulo ed è pronto per Drupal 9? Dovresti scaricarlo", quel genere di cose.

Angie Byron: Quindi da Drupal 8 a 9, direi che quella parte è abbastanza ben coperta. Se provieni da una versione precedente di Drupal, diciamo Drupal 7 o inferiore a Drupal 9, inizia a sembrare un po' più complicato. Tra le modifiche che abbiamo apportato in Drupal 8, dove, ad esempio, siamo passati interamente a PHP orientato agli oggetti e abbiamo iniziato a utilizzare modelli di progettazione che sono stati trovati in altri progetti software, che è una cosa davvero intelligente da fare dal punto di vista architettonico, ma lo fa significa che se avevi un sacco di codice personalizzato nella tua vecchia vita, in Drupal 9 dovrai trovare delle alternative per quello.

Angie Byron: Quindi Acquia è un prodotto e sviluppo chiamato Acquia Migration Accelerator che mira a risolvere quel problema, in cui stiamo creando una bella applicazione definita da React, che legge i tuoi vecchi dati Drupal 7, crea dati Drupal 8 equivalenti per te insieme a tutti i moduli di cui avrai bisogno che mappano i tuoi vecchi moduli Drupal 7, ove possibile, per provare ad accelerare un po' quel processo perché vogliamo assicurarci che tutti coloro che sono su versioni precedenti possano ancora passare al nuovo ordine mondiale, dove tutti sono sulla stessa versione e stiamo lavorando tutti insieme.

Angie Byron: Inoltre, abbiamo anche esteso Drupal 7... La comunità open source di Drupal, la loro fine vita in Drupal 7 a partire da novembre del prossimo anno. Attualmente, comunque, dobbiamo discutere se il COVID abbia un impatto su questo o meno. Ma ci sono un certo numero di aziende diverse e Acquia è una di queste che offre supporto esteso per Drupal 7 oltre, almeno fino al 2024. In questo modo le persone che hanno un aggiornamento facile hanno un anno e mezzo per farlo, le persone hanno un aggiornamento meno facile, hanno potenzialmente tre anni e mezzo per farlo o più se necessario, e stiamo cercando davvero di rendere possibile a tutti di spostarsi e quindi creare strumenti come Acquia Migrate Accelerator per accelerare il processo.

Drew: Learning React è stato oggetto di una conversazione con Mina Markham. Mina ed io eravamo stati entrambi nella posizione di imparare React per la prima volta. Riflettendo sul peso che i framework come React hanno messo sul browser, ho chiesto a Mina se mettere così tanto controllo nelle mani del client fosse un errore.

Mina Markham: Voglio dire di sì con l'avvertenza che, ancora una volta, la mia esperienza è molto contenuta in siti Web per lo più statici. Non faccio molto sviluppo del prodotto. Quindi forse in quel regno, questo ha più senso. Ma dal mio punto di vista, mi sembra che usiamo un sacco di volte un'accetta quando abbiamo solo bisogno di un coltello da burro. Non so perché dobbiamo mettere tutto questo nel browser, mettere così tanto lavoro e così tanta pressione sul cliente quando possiamo fare le cose molto... Sento che potremmo farlo molto più semplice. Una delle cose che mi ha sempre reso un po' titubante nell'usare React, o dico titubante, ma quello che intendo quando mi ha fatto arrabbiare visceralmente e mi sono opposto attivamente era quando andavo su un sito Web, e letteralmente niente rendeva perché c'è stato un errore o qualcosa del genere, l'intera pagina è interrotta perché una funzione si è interrotta.

Mina Markham: Mi ha infastidito il fatto che molte volte fosse un approccio tutto o niente. Uno dei discorsi che ho tenuto all'AEA in passato e in altri luoghi in passato riguardava come includere il miglioramento progressivo e non solo il tuo sviluppo, ma anche una più ampia direzione artistica e design dei siti. Vorrei sottolineare specificamente esempi di siti Web che non hanno apportato miglioramenti progressivi o alcun tipo di degradazione aggraziata. O hai JavaScript in esecuzione nel browser o non ottieni assolutamente nulla. Sarebbe solo un semplice sito che rappresentasse informazioni sulla storia del web design, che era uno dei siti di cui si parlava, la storia del web design dal 1990 ad oggi. Era un bellissimo sito web con molte linee temporali, animazioni di cose. Ma avrebbe anche potuto essere reso staticamente con un semplice elenco. Ci sono stati dei passaggi tra il non mostrare nulla e il mostrare quell'esperienza meravigliosamente migliorata che penso sia andata persa a causa del modo in cui ci stiamo avvicinando allo sviluppo web moderno ora.

Drew: Ho parlato con Andy Bell di CUBE CSS, una metodologia di styling alla maniera di BEM, SMACSS e OOCSS. Molti approcci CSS cercano di lavorare contro le proprietà naturali dei CSS come la cascata. CUBE abbraccia molto questo comportamento. Ecco Andy.

Andy Bell: Una buona sorta di analogia perché SCSS, come Sass, è un'estensione del linguaggio CSS naturale, vero? Hai ancora praticamente ragione nei CSS. Quindi CUBE CSS è così. Quindi è un'estensione di CSS. Quindi dovremmo ancora scrivere CSS, come dovrebbe essere CSS... beh, dovrebbe essere scritto. Siamo onesti, è così che dovrebbe essere scritto. Il nome lo svela, Cascading Style Sheets. Quindi lo sta abbracciando di nuovo perché quello che ho scoperto è che sono arrivato fino al livello di micro-ottimizzazione. Sono stato lungo il percorso in cui ho visto molte persone andare di recente in cui ... L'ho menzionato anche nell'articolo, dove posso vedere ... Ci sono alcune prove di recente. Ho notato che persone hanno creato componenti distanziatori e cose del genere, e capisco il problema. Sono stato in quella situazione.

Andy Bell: Il modo in cui l'ho risolto è stato, invece di approfondire e cercare di micro-ottimizzare, in realtà ho iniziato a pensare alle cose a livello compositivo, perché non importa quanto siano piccoli i tuoi componenti. Ad un certo punto diventeranno pagine. Saranno visualizzazioni. Non puoi evitarlo. È così che sarà. Quindi, invece di provare a dire: "Esatto, ho bisogno di questi piccoli aiutanti per fare questo layout", dici: "Esatto, ho una visualizzazione della pagina dei contatti o una visualizzazione della pagina del prodotto, e questa è una composizione scheletrica del layout. Quindi, al suo interno, posso inserire tutti i componenti che voglio.

Andy Bell: Ora abbiamo cose come Grid e Flexbox che lo rendono molto più realizzabile e puoi essenzialmente mettere tutto ciò che vuoi all'interno del layout scheletrico. Non importa. Quindi i componenti dovrebbero, a quel punto, comportarsi come vuoi che si comportino, con o senza query contenitore.

Drew: Gatsby è stato l'argomento della mia chiacchierata con Marcy Sutton. Sebbene la maggior parte dei generatori di siti statici siano indipendenti dal codice front-end, Gatsby utilizza React e quindi il codice Gatsby viene eseguito come parte della tua esperienza web finale. Ho chiesto a Marcy quale fosse quel codice e quali funzionalità fornisse.

Marcy Sutton: Sì. Direi che il pezzo più importante è il routing lato client. Quindi Gatsby in questo momento sta usando il ricostruttore sotto il cofano. È solo una specie di propria implementazione. Ma questo è il pezzo che quando carichi il tuo sito statico per la prima volta, ci sono file HTML lì. Quindi, se l'utente disattiva JavaScript per qualche motivo, il tuo sito dovrebbe essere ancora lì, avere ancora dei contenuti. Ma se JavaScript è abilitato, è allora che si verifica questo passaggio di idratazione, in cui quando utilizzi i collegamenti nel tuo sito Gatsby, preleverà le risorse da quella pagina. Quindi si caricherà più velocemente. Quindi è tutto abilitato con questo livello JavaScript che ti offre Gatsby.

Marcy Sutton: Quindi, oltre a questo, dipende davvero da cosa stai usando nel tuo sito, cosa finirà in quel bundle JavaScript. Ma per le cose che utilizzano molta interattività, come le interfacce accessibili, è un buon posto dove stare. Per me, mi piace davvero avere JavaScript a mia disposizione in ogni momento e avere il mio markup in una buona posizione. So che è una questione di preferenza, se vuoi che il tuo HTML, JavaScript e CSS, siano tutti ben accoppiati, e c'è spazio per variazioni all'interno della costruzione di Gatsby. Non devi sempre usare qualcosa come CSS e JS. Ma si tratta davvero di mettere a tua disposizione la potenza di quel livello JavaScript dinamico mentre scrivi il tuo sito web. Non è come questo componente aggiuntivo in un file separato.

Drew: Quando penso a come funziona di solito un generatore di siti statici, penso al contenuto forse in file markdown e il generatore scorre su quel contenuto e lo unisce ai modelli e crea decine, centinaia, migliaia di file HTML, che sono i pagine del tuo sito web. Quando penso a un sito o a un'app React, penso più all'esperienza a pagina singola, in cui le interfacce vengono create al volo da React. Quindi stai dicendo che Gatsby fa entrambe le cose? Sta creando tutte le pagine e anche migliorandole con JavaScript?

Marcy Sutton: Lo è, sì. Gatsby utilizzerà Node.js in fase di compilazione, esaminerà i componenti React e li compilerà in file HTML, che onestamente, la prima volta che ho guardato Gatsby, non avrei disattivato JavaScript ed era tipo: "Va bene, ci sono altre pagine qui? Cos'è questo?" Ero così felice che Gatsby funzionasse in quel modo per impostazione predefinita. Creerà file costruiti dai tuoi componenti React, il che è fantastico.

Marcy Sutton: Ho esplorato approcci di miglioramento più progressivi poiché è in JavaScript, ad esempio, cosa succede se si desidera generare qualcosa di progressivamente migliorato per gli utenti, dove se hanno JavaScript disattivato, non si desidera tutto questo codice rotto che presuppone JavaScript è lì. Quindi ci sono alcune stranezze con esso. Ma puoi aggirare questo genere di cose, almeno per i flussi di utenti principali in cui desideri che qualcuno sia ancora in grado di acquistare qualcosa. Potrebbe essere necessario aggiungere del supporto e per quei casi d'uso. Ma sono stato piacevolmente sorpreso dal modo in cui Gatsby lo distribuisce per impostazione predefinita.

Marcy Sutton: Quindi è una scelta che hanno fatto costruire siti in questo modo, e valutiamo sempre, è ancora il modo migliore? Cosa dobbiamo fare per dare ai nostri utenti ciò che chiedono? Quindi stiamo facendo alcune esplorazioni internamente, in corso solo per assicurarci che Gatsby stia facendo il miglior lavoro possibile nella creazione di un sito Web, quindi mantenendo piccole le dimensioni dei pacchetti e assicurandoci che per fare compromessi per quello che diciamo è codice performante con pre -fetching, abbiamo i dati per eseguirne il backup? Questo è il tipo di cosa che mi interessa molto, in quanto sostenitore degli sviluppatori, è assicurarsi che ciò che stiamo impacchettando e raggruppando sui siti Web sia effettivamente necessario e diventi davvero il miglior sito di Gatsby che può realizzare.

Drew: Parlando con Chris Ferdinandi a luglio, ho chiesto se le best practices moderne fossero dannose per il web. Chris backs a movement known as the Lean Web, and I asked him what that entailed. Here's Chris.

Chris Ferdinandi: When I look at the way we build for the web today, it feels a little bit like a bloated over-engineered mess. Sono arrivato a credere che molte di quelle che oggi consideriamo come le migliori pratiche potrebbero effettivamente peggiorare il web. The Lean Web is an approach to web development that is focused on simplicity, on performance, and the developer experience over… I'm sorry, not the developer experience, the user experience rather, over the developer experience and the ease of building things from a team perspective, which is what I think where we put a lot of focus today.

Chris Ferdinandi: As we'll probably get into in our conversation, I've actually come to find that a lot of these things we think of as improving the developer experience do so for a subset of developers but not necessarily everybody who's working on the thing you're building. So there's a whole bunch of kind of issues with that too that we can kind of dig into. 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: In August, Chris Coyier joined us to talk about all things serverless. I asked him what sort of the tasks they were putting serverless to over at CodePen?

Chris Coyier: Well, there's a whole bunch of things. One of them is, I think, hopefully fairly obvious is, I need… The point of CodePen is that you write each HTML, CSS, and JavaScript in the browser, and it renders it in front of you, right? Ma puoi anche scegliere le lingue del preprocessore. Diciamo che ti piace Sass. Si attiva Sass nel CSS e si scrive Sass. Bene, qualcosa deve elaborare il Sass. Al giorno d'oggi, Sass è scritto in Dart o qualcosa del genere. Theoretically, you could do that in the client. Ma queste librerie che eseguono la pre-elaborazione sono piuttosto grandi. Non credo di volerti spedire l'intera libreria Sass, solo per eseguire quella cosa. I don't want to. That's not the right architecture for this necessarily. Maybe it is down the road. I mean, we could talk about offline crap, yada, yada, web workers.

Chris Coyier: There's a million architectural things we could do. Ma ecco come funziona ora, c'è una lambda. Elabora il Sass. Ha un piccolo, minuscolo, minuscolo, piccolo lavoro. You send it this blob of Sass, and it sends you stuff back, which is the processed CSS, maybe a site map, whatever. It has one tiny little job, and we probably pay for that lambda like four cents or something. Because lambdas are just incredibly cheap, and you can hammer it too. Non devi preoccuparti della scala. You just hit that thing as much as you want, and your bill will be astonishingly cheap.

Chris Coyier: There is moments where serverless starts to cross that line of being too expensive. I don't know what that is. I'm not that master of stuff like that. But generally, any serverless stuff we do, we basically all nearly count as free, because it's that cheap. Ma ce n'è uno per Sass. Ce n'è uno per Meno. Ce n'è uno per Babbel. Ce n'è uno per TypeScript. Ce n'è uno per... Tutti quelli sono singoli lambda che gestiamo. Here's some code, give it to the lambda. It comes back, and we do whatever we're going to do with it. Ma lo usiamo per molto di più, anche di recente.

Chris Coyier: Here's an example. Ogni singola penna su CodePen ha uno screenshot. È fantastico, vero? So the people make a thing, and then we need a PNG or a JPEG, or something of it, so that we can… that way when you tweet it, you get the little preview of it. Se lo condividi in Slack, ne ottieni una piccola anteprima. We use it on the website itself to render… Instead of an iframe, if we could detect that the Pen isn't animated, because an iframe's image is much lighter, so why not use the image? Comunque non è animato. Solo guadagni di prestazioni del genere.

Chris Coyier: So each of those screenshots has a URL to it, obviously. We've architected it so that that URL is actually a serverless function. È un lavoratore. So if that URL gets hit, we can really quickly check if we've already taken that screenshot or not. That's actually enabled by CloudFlare Workers, because CloudFlare Workers are not just a serverless function, but they have a data store too. They have this thing called key-value store. So the ID of that, we can just check really quick, and it'll be, “True or false, do you have it or not?”

Chris Coyier: If it's got it, it serves it, and it serves it over CloudFlare, which is super fast to begin with and then gives you all this ability too because it's an image CDN, you can say, “Well, serve it in the optimal format. Servitelo come queste dimensioni. Non devo fare l'immagine in quelle dimensioni. You just put the dimensions in the URL, and it comes back as that size, magically.

Drew: I talked to Next.js co-creator, Guillermo Rauch about the features on offer in Next.js and asked about its automated code splitting functionality. As the size of our JavaScript bundles can have quite an impact on performance, I was interested to know if Next had ways to tackle that. Here's Guillermo.

Guillermo Rauch: Yeah. Your observation is 100% right. So one of the biggest things with the web and one of the biggest weights on the web is JavaScript. Just like different materials have different densities and weights, irrespective of the actual physical volume, JavaScript tends to be a very dense, heavy element. Even small amounts of JavaScript compared to, for example, images that can be processed asynchronously and off the main thread, JavaScript tends to be particularly bothersome.

Guillermo Rauch: So Next.js has invested a tremendous amount of effort into automatically optimizing your bundles. So the first one that was my first intuition when I first sort of came up with the idea for Next.js was, okay, you're going to define, for example, 10 routes. In the Next.js world you create a pages directory, and you drop your files in there, index.js, about.js, settings.js, dashboard.js, terms-of-service.js, signup.js, login.js. Questi diventano punti di accesso alla tua applicazione che puoi condividere attraverso tutti i tipi di media.

Guillermo Rauch: When you enter those, we want to give you JS that is relevant for that page, first and foremost, and then perhaps a common bundle so that subsequent navigations within the system are very snappy. Next.js inoltre, che è molto, molto carino, pre-carica automaticamente il resto delle pagine collegate a quel punto di ingresso, in modo tale da sembrare un'applicazione a pagina singola. So a lot of people say like, “Why not just use Create React app if I know that I have maybe a couple routes?” I always tell them, “Well, look. You can define those as pages, and because Next.js will automatically pre-fetch ones that are connected, you end up getting your single-page application, but it's better optimized with regards to that initial paint, that initial entry point.”

Drew: In September, I had the pleasure of talking to Cassie Evans about SVG animation. We talked about the approachability of SVG for developers who are already familiar with HTML. Here's Cassie.

Cassie Evans: I think that that's what I love the most about SVG is I'm really into creative coding and also teaching people, and I found that teaching people who are more of a creative leaning, they sometimes get a little thrown off when you immediately jump in with JavaScript or Python or something like that for creative coding. But without fail, I've managed to get anyone that I taught on board with SVG because there some really approachable entry points because it does look like HTML.

Cassie Evans: So you can give someone with an understanding of HTML and how to build websites SVG, and it looks the same, but it's the graphics instead of documents, and then you can animate that with CSS to start off with, which is also a little bit more comfortable, and then you can kind of progress to animating it with JavaScript. So it's a really good learning curve.

Drew: Of course, it can be dynamic. It's not just a case of creating motion. You can actually make the properties of it dynamic. So one of the interesting things I've seen SVG used for, and it's a grand term, but data visualization, dataviz, and drawing graphs and charts and of course things like dashboards that we seem to have everywhere these days. SVG is sort of perfect for that, isn't it?

Cassie Evans: Yes, definitely. SVG is great for dataviz. All the way from kind of small dataviz up to D3 which is very well known dataviz library that uses SVG under the hood. But you could also just, if you've got a little bit of data that you wanted to show on a web page, you could create a chart in a graphics editing program, and then you could just use JavaScript to change those values and kind of change how your graph looks. So you don't have to go all in with a massive database library. You can kind of just start off small.

Drew: The Jamstack framework, RedwoodJS was the topic of conversation with Anthony Campolo. I asked Anthony what it meant to be a full-stack Jamstack framework in practical terms.

Anthony Campolo: Yeah, it's pushing the boundaries of what a Jamstack application can be. So by calling it full-stack Jamstack, it's about, how do we go beyond just the front end to having the same sort of deployment paradigm of just get pushed, getting your whole code deployed? How do we get that but also with our back end and have it all connected?

Drew: Vue.js version three was released in October, and I caught up with Natalia Tepluhina from the Vue core team. Discussing the new version, I was curious if the major version bump was just a result of a few backward incompatible modifications or if this was a very clear revisiting of Vue to make deeper changes to the framework.

Natalia Tepluhina: No. I think it was an idea to create a new version due to a few very important things. Quindi, prima di tutto, c'era una motivazione per cambiare la reattività. Previous one was built upon Object.defineProperty, and it had a few caveats. They're all documented, but still, even if you document something that people shouldn't do, they will do it anyway, and you would need to point them to the documentation. Nobody reads documentation, by the way. For some reason, it just happens. Until you point people out, it doesn't exist in docs, it does. Ma va bene. Ti insegneremo comunque.

Natalia Tepluhina: So reactivity was one of the things. Performance was the next. Vue 2 still had and has not the worst performance, but we had a few ideas about how to make Vue faster, and also, there was one pain point for a particular part of our, let's say audience, people that use Vue. Era dattiloscritto. Vue 2 internally was written in Flow, which is still strongly typed one, but typing with TypeScript were a real nightmare especially if you were working with our state management Vuex.

Natalia Tepluhina: Quindi questa è stata di nuovo una parte importante. L'ultimo è stato che ci mancava la funzionalità della logica astratta, in termini di non componenti, ma parti logiche compossibili, come funzioni di supporto e così via, ma dovrebbero essere in grado di includere anche l'attività Vue. Un bell'esempio qui potrebbe essere React Hooks, giusto? Ti consentono di astrarre le parti della funzionalità e questo era chiaramente mancante in Vue. So che in questo momento suona come "Hai rubato la funzione da React". Non in effetti. Credo che l'impollinazione incrociata delle idee sia una parte importante e interessante nel nostro ecosistema e aiuta anche gli sviluppatori a passare da un preferito all'altro, giusto? Quindi stavamo lavorando su queste funzionalità principali per creare Vue 3 come versione principale.

Drew: In seguito ci siamo tuffati in TypeScript con Stefan Baumgartner per scoprire come può aiutarci a scrivere codice migliore con meno bug. Osservando la tendenza delle organizzazioni a spostare completamente la propria base di codice su JavaScript, ho chiesto a Stefan se TypeScript fosse qualcosa da cui i team più grandi trarrebbero beneficio più degli individui.

Stefan Baumgartner: Quindi attualmente sono nella stessa transizione. Quindi abbiamo molti sviluppatori Java e C++ che scriveranno molto JavaScript in futuro. TypeScript può essere una sorta di guida per quelle aree spaventose del nuovo linguaggio di programmazione. JavaScript ha molte stranezze, molta storia e molti pregiudizi se provieni da un linguaggio di programmazione diverso. Quindi TypeScript può essere una guida perché ci sono alcuni concetti che conosci nel sistema dei tipi.

Stefan Baumgartner: Ma anche, penso, specialmente quando hai molte persone che lavorano nella stessa base di codice o molte persone che hanno bisogno di lavorare tra loro, questo può essere un ulteriore livello di guida nel tuo progetto, in cui non lo fai Non ho brutte sorprese alla fine. Quindi, ovviamente, la tecnologia non risolve alcun problema di comunicazione. Questo non è ciò a cui è destinato TypeScript. Ma può abbassare, o può fare molto più spazio per la giusta discussione, quindi se non devi parlare di cosa ti aspetti da me nel tuo codice, ma piuttosto, cosa dovrebbe fare il tuo codice o cosa dovrebbe fare il tuo biblioteca fare?

Stefan Baumgartner: Dico sempre che se scrivi codice per altre persone o se scrivi codice con molte persone o se scrivi codice solo per te stesso, devi rivisitare il giorno successivo, considera TypeScript perché potrebbe aiutarti nel lunga corsa. Questo non è solo un investimento per il prossimo progetto della prossima settimana, ma più per uno che dice, va bene, soprattutto se hai progetti di lunga durata per un mese, due o anni, offrilo sicuramente. Non saprai mai a cosa stavi pensando quando hai scritto il piccolo pezzo di codice un anno fa, ma i tipi possono darti un'idea di cosa intendevi.

Drew: A novembre, ho parlato con David Darnes del generatore di siti statici, Eleventy. Abbiamo parlato di modelli e di quanti generatori di siti statici sono piuttosto ostinati su quale tipo di modelli dovresti usare. Mi chiedevo se Eleventy avesse lo stesso tipo di forti convinzioni. Ecco Dave.

David Darnes: No, devo dire che è quanto di più imparziale si possa ottenere. È un punto di vista un po' personale, ma ho faticato a vedere qualsiasi struttura o qualsiasi cosa che possa essere libera da opinione perché, per creare qualcosa, devi avere un'opinione su come vuoi fare qualcosa. È una specie di ossimoro. Sono sicuro che le persone potrebbero correggermi su questo. Ma si. Puoi passare a qualsiasi lingua di creazione di modelli con cui ti senti più a tuo agio. Voglio dire, stavamo solo parlando di lingue con cui ti senti a tuo agio. Eleventy fa appello a questo in un certo senso con ciò che i linguaggi di template usano all'interno del tuo HTML, o addirittura il tuo CSS, se vuoi.

David Darnes: Per me, sono andato direttamente dai nunjucks perché i nunjucks sono il linguaggio predefinito per i modelli all'interno di Eleventy. Ciò significa che posso usare l'estensione dot HTML e lasciarlo così com'è. Ora, confonderò ancora di più le persone e dirò: “Puoi nominarlo come vuoi comunque. Puoi divertirti davvero con esso. Ma puoi usare il manubrio. Penso che tu possa semplicemente usare il normale modello JavaScript e scorrere in questo modo. Manubrio abbastanza popolare e anche liquido. Non riesco a pensare a tutti loro dalla parte superiore della mia testa, ma se imposti tutto nella configurazione, puoi semplicemente scegliere come vuoi.

David Darnes: Direi che sono un grande fan dei modelli di linguaggi in generale. Non è passato molto tempo da quando ho scoperto che si poteva usare il ramoscello all'interno di WordPress, e questo mi ha fatto impazzire. Ero tipo: "Oh, grazie al cielo. Non devo gestire un ciclo for all'interno di PHP. Ancora una volta, penso a qualcosa di un po' più comodo e comprensibile, anche più leggibile. Quindi sì. Eleventy ha molte diverse opzioni di creazione di modelli e dovrebbe interessare le persone che si sentono a proprio agio con quelle diverse.

Drew: Ho parlato con Leslie Cohn-Wein di come Netlify utilizzi la propria piattaforma per creare Netlify e di come la loro funzionalità di anteprima di distribuzione diventi un'efficace piattaforma di gestione temporanea per le modifiche front-end.

Leslie Cohn-Wein: Forse la parte che preferisco dell'intero processo è la magia di Deploy Previews, che otteniamo tramite Netlify. Quindi quello che succede è che stai lavorando in GitHub, aumenti le tue PR. Quindi apri il tuo PR in GitHub e questo creerà automaticamente una build della tua anteprima di distribuzione dell'app. Quindi in realtà utilizziamo le anteprime di distribuzione dell'app stessa per testare, per assicurarci che tutto funzioni come dovrebbe. Eseguiamo i nostri test. Questo è ciò che usiamo per verificare manualmente durante la revisione del codice. Quindi abbiamo una sorta di distribuzione continua configurata direttamente da GitHub.

Leslie Cohn-Wein: Quindi una delle altre cose interessanti che abbiamo impostato è che in realtà abbiamo un paio di diversi siti Netlify che stanno prelevando dallo stesso repository in cui risiede la nostra app. Quindi abbiamo entrambi la nostra app. Abbiamo un'istanza di Storybook che ha una sorta di componenti dell'interfaccia utente per l'app. Quindi abbiamo sia la nostra app stessa. Abbiamo i componenti dell'interfaccia utente di Storybook e fondamentalmente abbiamo un sito Netlify che mostra la nostra interfaccia utente di Storybook, e quindi abbiamo anche un terzo sito che esegue un analizzatore di pacchetti webpack. Quindi è una sorta di interfaccia utente visiva che ti offre una visualizzazione della mappa ad albero di tutti i bundle di app, e possiamo in qualche modo misurarne le dimensioni, ed è solo un promemoria per noi di ricontrollare più o meno ogni distribuzione dell'app fuori, possiamo controllare e assicurarci che non stiamo facendo nulla di strano con la nostra dimensione del pacchetto lì.

Leslie Cohn-Wein: Quindi tutti e tre questi siti vengono generati in una richiesta pull dell'app. Quindi otterrai collegamenti all'anteprima, essenzialmente le tue anteprime di distribuzione, sia dell'app Storybook che a quel profilo dell'app che possiamo controllare.

Drew: A dicembre, ho parlato con Chris Murphy del design del prodotto e di cosa significa per il business essere progettato in modo mirato. Abbiamo discusso se un individuo fondatore si concentra sul design, se questo trapela nel business e se un prodotto è naturalmente un'estensione della persona che lo ha creato.

Chris Murphy: Penso che sia davvero un'ottima domanda, Drew, e penso che la risposta sia che dipenda. Penso che dipenda da quella persona e dalle dimensioni dell'azienda. Se dai un'occhiata a Hiut Denim, e io uso molto Hiut nel mio insegnamento, è davvero un ottimo esempio di un'azienda che sta facendo bene una cosa, e questo è il loro tipo di jeans con spalline. Penso che se guardi al precedente di David... David e Clare, perché sono una partnership. Se guardi alla precedente compagnia di David Hieatt e Clare Hieatt, che era Howies, quella compagnia era cresciuta così tanto che c'erano così tante persone coinvolte.

Chris Murphy: Una volta che la scala inizia a insinuarsi, diventa molto difficile tenere d'occhio tutti i piccoli punti di contatto che contano nel percorso del cliente. Penso che sia davvero significativo quando hanno lasciato Howies, perché Howies era stato acquistato da... È complicato. Vai a leggerlo su internet. Ma era Timberland, e Timberland è stata acquistata, e c'è tutta questa storia.

Chris Murphy: Penso che sia davvero interessante che ciò su cui si concentrano ora siano i jeans. Questo è tutto. Raccontano una storia straordinariamente bella sui jeans. Stanno anche confezionando tutto davvero, davvero bene, e i jeans sono come un veicolo per le storie, davvero. Questo è qualcosa che penso, Drew, diventerà più importante man mano che usciamo dall'altra parte del COVID, da cui spero che usciamo dall'altra parte. Tutti quelli che fanno quei jeans ricevono un salario adeguato. Uno dei problemi che ho in questo momento quando guardo al mondo è che non tutti ricevono un salario adeguato, e lo trovo un po' preoccupante, come qualcuno... Guarda, ho 51 anni. Mio figlio ha 25, 24 anni , 25, qualcosa del genere. È terribile. Dovrei sapere tutte queste cose. È un fotografo di matrimoni. È un fotografo di matrimoni da circa un anno e poco. I suoi affari sono completamente decimati perché nessuno si sposa davvero in questo momento perché è solo difficile. Non ha stipendio perché non aveva abbastanza libri di lavoro autonomo per ottenere il sostegno.

Chris Murphy: È caduto attraverso le crepe e ci sono molte altre persone che sono cadute attraverso le crepe. Direi che è un problema di progettazione, che dobbiamo considerarlo come un problema di progettazione. Ma se guardo anche alla questione più ampia del COVID, del governo e di tutte queste cose senza diventare troppo politico, ieri ho letto un articolo sul Guardian sul vicino di Matt Hancock, e chiunque ascolti chi non è dal Regno Unito, Matt Hancock è il Segretario alla Salute. Il suo vicino, che gestiva un'impresa, gli stava scrivendo un messaggio e chiedendogli consigli su "Come faccio a fornire prodotti per questa cosa del COVID?" C'è un sacco di chiacchiere intorno alla chumocracy, come la chiamano i giornali, amici di amici di ministri del governo che sembrano trovare lavoro perché conoscono le persone giuste.

Chris Murphy: Ho la sensazione che andremo dall'altra parte di tutto questo e vedremo questo... Gli individui lo vedono e pensano: "Beh, dove vanno a finire questi soldi e le persone vengono pagate correttamente? Qual è il prezzo di questa maglietta da una sterlina del negozio X?" Non voglio citare nessun marchio. Ma tutto deve essere pagato, e tutto ciò che è stato fatto, le persone devono essere pagate per farlo. Penso che le persone siano sempre più interessate, le persone vengono pagate in modo equo?

Drew: GraphQL è stato l'argomento del nostro ultimo episodio completo dell'anno, e ho fatto una chiacchierata con Eve Porcello e ho chiesto dove si inserisce GraphQL nello stack di sviluppo.

Eve Porcello: Sì. GraphQL si adatta tra il front-end e il back-end. Quindi è come vivere nel mezzo tra i due e offre molti vantaggi agli sviluppatori front-end e agli sviluppatori back-end. Se sei uno sviluppatore front-end, puoi definire tutti i requisiti di dati del tuo front-end. Quindi, se hai un grande elenco di componenti di React, ad esempio, potresti scrivere una query e questo definirà tutti i campi di cui avresti bisogno per popolare i dati per quella pagina.

Eve Porcello: Ora, con il pezzo di backend, è davvero proprio, perché possiamo raccogliere molti dati da molte fonti diverse. Quindi abbiamo i dati nelle API REST e nei database e in tutti questi luoghi diversi, e GraphQL ci fornisce questo bel piccolo livello di orchestrazione per dare davvero un senso al caos di dove si trovano tutti i nostri dati. Quindi è davvero utile per tutti in tutto lo stack.