Smashing Podcast Episodul 32: Recenzia anului 2020

În acest episod, aruncăm o privire înapoi la 2020. Cu cine am vorbit în episoadele noastre de anul acesta și ce am învățat? Să ascultăm câteva clipuri pentru a afla.

Afișați note

Puteți găsi toate episoadele noastre anterioare, inclusiv o transcriere completă a fiecărui interviu la podcast.smashingmagazine.com.

Ne vedem în 2021, tuturor!

Transcriere

Drew McLellan: În ianuarie, am vorbit cu Amy Hupe despre munca ei privind sistemul de proiectare al guvernului Regatului Unit și, în special, despre modul în care echipa a sporit adoptarea sistemului de către organizația mai largă prin încurajarea contribuțiilor. Iată-o pe Amy.

Amy Hupe: Am început foarte devreme. Așa că, cu mult înainte de a avea un fel de sistem public de design, am început să ne angajăm cu oameni despre care credeam că ar fi contribuitori interesați. Ar trebui să menționez aici că am avut în echipă un designer de servicii genial. Ea s-a alăturat nouă în... Nu voi corecta datele în niciun fel momentan, dar cred că ea a lucrat cu noi în tot anul 2018, iar numele ei este Ignacia. Ea a făcut o treabă fantastică de a merge în jur și de a implica oamenii. Deci, unul dintre lucrurile pe care le-a făcut a fost să meargă și să identifice toate modelele diferite în guvern și toate tipurile diferite de variații ale acelor modele. Așa că ieșiți și să spuneți: „Bine. Există 10 moduri diferite de a cere o adresă în guvern. Să le analizăm pe toate împreună și să decidem care credem că este cea mai potrivită abordare. Cum le putem consolida într-una singură?”

Amy Hupe: A condus un atelier mare pentru a încerca să îi convingă pe oameni să se uite la acestea și să facă acest tip de consolidare ca o echipă. Cred că abordarea ei de a construi un fel de colaborare cu mult înainte să lansăm ceva publicului a ajutat cu adevărat la asta, deoarece însemna că oamenii aveau deja acest tip de conștientizare și mulți oameni deja au contribuit la asta într-un fel sau altul. altul înainte de a-l face public. Așa că am trecut de câțiva pași înainte. Așa că cred că a fost foarte important și doar perseverență, multă perseverență din partea întregii echipe pentru a ajuta oamenii să contribuie.

Amy Hupe: Cred că există ideea că, dacă îi convingi pe oameni să contribuie la un sistem de design, acesta este un concert destul de drăguț, pentru că poți să-i convingi pe oameni să facă toată munca pentru tine și tu stai acolo și tu faceți micile remedieri de cod și toată lumea vă oferă de fapt toate lucrurile bune. Dar, de fapt, așa cum știe oricine care a lucrat la un sistem de proiectare, este incredibil de complex. Este foarte dificil să faci o soluție centralizată care să funcționeze pentru mai multe echipe diferite.

Amy Hupe: Într-adevăr, cu excepția cazului în care ați lucrat la un sistem de design, nu este rezonabil să vă așteptați ca cineva să înțeleagă cu adevărat de ce este nevoie. Deci, există o mulțime de fel de ținere de mână. Este multă muncă implicată în sprijinirea contribuitorilor să contribuie. Cred că am mai spus acest lucru, dar probabil că durează mai mult, cred, pentru a ajuta pe cineva să contribuie la un sistem de proiectare decât ar face-o doar pentru a face lucrul dvs. și echipa centralizată. Dar cred că recunoscând valoarea pe care o aduce și să fii perseverent în eforturile tale de a face oamenii conștienți de contribuție, de a-i ajuta să o facă, de a-i ajuta să se simtă oarecum motivați să o facă, cred că da, acea perseverență a fost într-adevăr atât de esențială pentru succesul nostru în acest domeniu.

Drew: Ni s-au alăturat Stephanie Stimac și Aaron Gustafson de la Microsoft pentru a vorbi despre adoptarea de către Edge a Chromium ca motor de randare. L-am întrebat pe Aaron despre peisajul competitiv dintre browsere și unde mai multe browsere care se unesc pe același motor de randare ar elimina această concurență sănătoasă și, prin urmare, ar fi dăunătoare pentru web-ul deschis.

Aaron Gustafson: Acesta este ceva cu care, cu siguranță, fiind de mult timp o persoană cu standardele web, mă lupt puțin. Înțeleg perfect justificarea de afaceri pentru asta. Din punctul de vedere al Microsoft, a avut mult sens. Din perspectiva dezvoltării front-end, este plăcut să nu fii nevoit să satisfacă o grămadă de motoare diferite. Adică, per ansamblu, aceia dintre noi care lucrăm pe web de mult timp am văzut cu siguranță multă convergență în ceea ce privește randarea. Nu avem atâtea probleme cât am avut, să zicem în Netscape timp de șapte zile, unde am avut exact ca... Știam companii care creau foi de stil unice pentru fiecare browser diferit, ceea ce era pur și simplu insuportabil.

Aaron Gustafson: Dar cred că ceea ce este diferit acum este că, în războaiele inițiale ale browserelor, aveai toate aceste motoare proprietare și toată lumea era într-un fel de joc de perspectivă în ceea ce privește încercarea de a livra noi caracteristici ale platformei și noi funcții JavaScript sau în cazul Microsoft de inginerie inversă JavaScript pentru a crea JScript și a încerca să descopere cum să le potrivească pe toate.

Aaron Gustafson: Dar acum avem capacitatea de a lucra împreună în proiecte open source și încă avem dialog și încă... nu știu. Lupta nu este cuvântul potrivit, ci a avea discuții serioase despre impactul diferitelor abordări și a nu fi de acord unul cu celălalt și a lucra cu adevărat pentru a face specificațiile cu adevărat bune și pentru a avea, de asemenea, abordări concurente ale codului de bază în contextul, să spunem un Chromium. proiect sau WebKit sau ceva de genul acesta sau Missoula în spațiul Firefox.

Aaron Gustafson: Deci da. Pe de o parte, am pierdut un alt motor de randare și am simțit aceeași durere când opera a decis să meargă la Chromium. Dar mă simt oarecum încurajat să fiu în interiorul Microsoft și să văd cât de angajați suntem să participăm efectiv la proiectul Chromium într-un mod semnificativ și nu doar să stăm pe spate și să acceptăm tot ce vine în aval de Chromium, ci de fapt să verificăm ceea ce se întâmplă. platforma și participarea la asta... Da.

Aaron Gustafson: Așa că sunt puțin încurajat de asta și simt că nu suntem doar acolo pentru a lua din acel proiect și doar pentru a accepta tot ceea ce este transmis de toți diferiții oameni care au o miză în acel proiect, ci și pentru a de fapt, să colaborez și acolo.

Drew: În februarie, am vorbit cu Stephanie Walter despre lucrul cu cadre de UI precum Bootstrap și prieteni și despre echilibrarea acestora cu nevoile personalizate ale unei interfețe utilizabile. Am întrebat-o pe Stephanie dacă este posibil să creez o interfață de utilizare extrem de utilizabilă folosind un cadru disponibil sau dacă va fi întotdeauna un compromis puțin ciudat.

Stephanie Walter: Da. Cred că este. Dar depinde și de nivelul de compromis pe care ești dispus să-l faci, iar acest lucru compromite ambele părți. În acest moment, compromit o mulțime de butoane, de exemplu, pentru că aveți niște butoane cu adevărat specifice într-o interfață de utilizare materială. Nu prea îmi place efectul de ondulare pe buton. Cred că funcționează grozav pe mobil, deoarece pe mobil, aveți nevoie de un fel de feedback mare atunci când utilizatorul face clic sau atinge butonul. Dar apoi ei pun acest tip de efect de ondulare care merge până la buton. Este puțin exagerat, mai ales când sunt multe butoane. Dar totuși vom păstra acest efect de ondulare pentru că ar fi super complex să-l eliminam, deoarece acesta a fost încorporat în cadrul React și să avem un alt efect de hover pe acest buton, ceva mai subtil care nu ar fi acest tip de lucru stufător. Aici. Ar fi super complex. Deci acesta este genul de compromisuri pe care le faci.

Drew: Designul etic a fost subiectul conversației mele cu Trina Felber și Martin Michael Fredrickson. Am întrebat dacă adoptarea unei abordări etice a designului și evitarea tiparelor întunecate este un caz de gândire pe termen lung la sănătatea și creșterea unei afaceri, mai degrabă decât doar obiectivele de vânzări pe termen scurt. Iată-l pe Martin.

Martin Michael Fredrickson: Este perfect adevărat. Cred că trebuie să te uiți la afacerea pe care o faci online de parcă ai avea un magazin pe strada principală într-un oraș de dimensiuni medii, unde trebuie să-ți păstrezi intactă reputația. Dacă nu vă trateți bine clienții, atunci dacă nu vă tratați bine clienții, pe termen lung, veți rămâne fără afaceri pentru că oamenii vor merge la alt magazin sau vor cumpăra online. Deci, orice ai face online, chiar trebuie să te gândești că există un efect pe termen lung și, de asemenea, există un cost ascuns în a face lucruri care sunt complexe sau care manipulează. Dacă dezordinezi, așa cum spune Trina, va exista o economie pe termen lung, iar asta nu se calculează niciodată atunci când vorbești despre modelul de afaceri. Întotdeauna vorbești despre câți bani poți câștiga. Nu vorbești niciodată despre costul câștigării acestei sume de bani.

Drew: În martie, am vorbit cu Eduardo Boucas despre un instrument cu sursă deschisă numit Sourcebit, care adună conținut din surse disparate și îl pune la dispoziție pentru generatorul tău static de site. L-am întrebat pe Eduardo dacă acest lucru ar putea îmbunătăți experiența utilizatorului de autorizare pentru un SSG, permițând integrarea cu instrumente precum CMS-urile fără cap.

Eduardo Boucas: Exact. Da. Modul în care ar putea... Văd într-un fel două moduri diferite de a folosi instrumentul care pot ajuta dezvoltatorii. Una este să faceți Sourcebit parte din rutina dvs. de implementare. Deci, dacă utilizați o platformă de găzduire, cum ar fi Netlify, de exemplu, și configurați comenzile dvs. de implementare să fie, nu știu, Hugo build, este, comanda build pentru Hugo sau ceva de genul, genul de comandă care generează fișierele statice pentru Hugo. Ai avea și o altă comandă ca parte a acelei rutine. Ar fi ceva de genul Sourcebit fetch. Deci, la momentul construirii, Sourcebit va extrage toate celelalte date, va genera toate fișierele de care are nevoie Hugo, iar apoi întreaga implementare va folosi deja acele fișiere și va implementa tot conținutul care vine de la CMS.

Eduardo Boucas: Deci acesta este un fel de caz posibil de utilizare pentru Sourcebit. Celălalt este să utilizați Sourcebit ca dezvoltare locală în fluxul de lucru de dezvoltare locală. Deci, puteți rula Sourcebit cu ceva pe care noi îl numim modul ceas. Deci Sourcebit continuă să caute modificări în sursa de date de la distanță, deci, în acest caz, CMS-ul fără cap. Deci, ori de câte ori publicați un articol sau modificați o intrare în CMS, Sourcebit va recunoaște acest lucru și va regenera toate fișierele pentru dvs. la nivel local.

Eduardo Boucas: Deci, ceea ce înseamnă pentru dezvoltatorul care lucrează la nivel local este că puteți avea fereastra CMS lângă site-ul dvs. Hugo rulând local și apoi puteți vedea schimbările care au loc în timp real. Schimbați ceva pe CMS și apoi puteți vedea că schimbarea se reflectă pe site-ul local, ceea ce mi se pare super util. Deci acestea sunt cele două moduri în care ați putea folosi Sourcebit.

Drew: Optimizarea conversiilor a fost subiectul zilei. Când am vorbit cu veteranul podcaster și consultant, Paul Boag. Am vorbit despre câteva dintre tehnicile pe care site-urile le folosesc pentru a converti vizitatorii în clienți. Dar am vrut să-l întreb pe Paul cum măsori impactul schimbărilor pe care le faci. a explicat Paul.

Paul Boag: Da. Absolut. Cred că, din nou, acesta este un lucru în care multe organizații sunt destul de sărace este să fie clar despre cum vor măsura succesul. Acum, da, rata de conversie este o singură valoare. Ar trebui neapărat să urmărești. Dar chiar și cu conversie, trebuie să fii puțin mai sofisticat decât câți oameni cumpără. De asemenea, trebuie să acordați atenție valorii medii a comenzii. Trebuie să acordați o atenție deosebită valorii pe viață, nu? Deci, cât valorează un client pe parcursul întregii sale vieți, pentru că s-ar putea să descoperiți că obțineți un număr destul de mare de clienți, dacă utilizați modele întunecate și lucruri de genul ăsta. Dar într-adevăr, conversia ar trebui să fie doar una dintre valorile pe care le măsurați.

Paul Boag: Există, de asemenea, lucruri precum că trebuie să acordați atenție angajamentului, cât de implicați sunt oamenii cu conținutul dvs., pentru că asta face o mare diferență dacă în cele din urmă vor face conversie. Deci te uiți la lucruri precum: cât costă videoclipurile tale, le vizionează, cât timp petrec pe site-ul tău și la ce se uită în timp ce o fac? Se implică pe rețelele sociale și pe astfel de lucruri? Apoi, aspectul final este, evident, utilizarea. Trebuie să măsurați cât de repede poate cineva finaliza o anumită sarcină pe site-ul său web și cât de ușor găsește că sistemul de utilizat și diverse alte criterii diferite.

Paul Boag: Există o mulțime de mecanisme pe care le puteți folosi pentru a măsura acele lucruri diferite. Există câteva instrumente grozave și, de asemenea, câteva valori bune pe care le puteți adopta. Deci, de exemplu, în ceea ce privește gradul de utilizare, există ceva numit scala de utilizare a sistemului, care poate fi o măsură foarte utilă de măsurat. Dar, în egală măsură, există instrumente precum maze.design este unul pe care îl folosesc adesea, care va măsura cât de mult îi ia cuiva să facă o achiziție, de exemplu, să treacă prin casă. Deci da. Având acest tip de gamă largă de valori, nu vă concentrați doar asupra câte vânzări am realizat în acest trimestru? Trebuie să te uiți la imaginea de ansamblu.

Drew: În aprilie, am discutat cu Laura Kalbag de la Better Blocker despre confidențialitatea online. Am vorbit despre granițele din ce în ce mai subțiri dintre ceea ce este considerat public și ceea ce este privat și despre cum lucrurile pe care le considerăm private ar putea să nu fie văzute astfel de companiile cărora le încredințăm datele noastre. Aici e Laura.

Laura Kalbag: Am un exemplu clasic în acest sens, care mi s-a întâmplat acum câțiva ani. Așa că eram pe Facebook și mama tocmai murise și primeam reclame pentru directorii de pompe funebre. Mi s-a părut cu adevărat ciudat, deoarece niciunul din familia mea nu spusese nimic pe o platformă de socializare în acel moment. Niciunul din familia mea nu a spus nimic pe Facebook pentru că am convenit că nimeni nu vrea să afle așa ceva despre un prieten sau membru al familiei prin Facebook. Deci nu am spus despre asta.

Laura Kalbag: Așa că i-am întrebat pe frații mei: „Oh, a spus ceva pe Facebook care ar putea provoca acest lucru ciudat.” Pentru că de obicei primesc reclame pentru machiaj și rochii și teste de sarcină și toate acele lucruri distractive pe care le place să vorbească. Sunt femei de o anumită vârstă. În schimb, sora mea s-a întors la mine. Ea a spus: „Ei bine, da. Prietenul meu locuiește în Australia.” Așa că i-am trimis un mesaj pe Facebook Messenger și i-am spus că mama noastră a murit. Desigur, Facebook știa că suntem surori. Are acea conexiune de relație pe care o poți alege să o adaugi acolo. Adică, probabil că s-ar putea ghici că eram surori oricum, după locațiile în care am fost împreună, faptul că împărtășim un nume de familie și am hotărât: „Oh, ăsta e un anunț potrivit pentru a-i pune în picioare.”

Drew: Este îngrijorător, nu-i așa, să credem că tehnologia ia aceste decizii pentru noi, care de fapt afectează oamenii potențial, în acest exemplu, un moment destul de sensibil sau vulnerabil?

Laura Kalbag: Da. Noi spunem că este înfiorător. De multe ori oamenii spun: „Oh, este aproape ca și cum microfonul de pe telefonul meu sau de pe laptopul meu m-ar asculta pentru că pur și simplu aveam această conversație despre acest anumit produs și dintr-o dată apare în feedul meu peste tot.” Cred că ceea ce este de fapt înfricoșător este faptul că majoritatea nu au acces la microfonul tău. Dar este faptul că celelalte comportamente ale tale, căutarea ta, faptul că știe cu cine vorbești din cauza apropierii tale unul de celălalt și a locației tale pe dispozitivele tale. Poate conecta toate acele lucruri pe care s-ar putea să nu le conectăm împreună doar pentru a spune: „Oh, poate că vor fi interesați de acest produs pentru că probabil se gândeau, vorbeau deja despre el.”

Drew: Pe măsură ce pandemia de coronavirus a lovit și multe națiuni au intrat într-o formă de izolare, am vorbit cu Rachel Andrew despre modul în care Smashing își adapta conferința personală programată să aibă loc în schimb online. Trebuia să amân conferința Smashing, San Francisco, am întrebat-o pe Rachel care este planul pentru mutarea viitoarelor conferințe și ateliere în domeniul virtual.

Rachel An Drew: Foarte, foarte repede, odată ce ne-am dat seama că va trebui să amânăm San Francisco, evident, avem ateliere, atât eu cât și Vitaly conducem ateliere la smash și comp, și s-au epuizat în San Francisco, ambele atelierele noastre. Evident, avem o mulțime de alți oameni care vin și conduc ateliere pentru noi, oameni cu care am lucrat de mult timp și au descoperit că toate atelierele lor, iar pentru cei dintre noi facem ateliere, au de fapt un parte cheie a veniturilor noastre.

Rachel An Drew: Vorbind în public, nu câștigi mulți bani de obicei mergând și vorbind în public. Majoritatea oamenilor nu sunt plătiți foarte mult, nu dacă iei în considerare timpul necesar pentru a scrie discuții și așa mai departe. Atelierele tind să fie o modalitate destul de drăguță pentru oamenii care sunt buni la predarea acestor lucruri de a câștiga niște bani. Deci ele reprezintă veniturile oamenilor. Deci nu aveam nevoie doar de mine și Vitaly ne pierduseră atelierele la începutul acestui an. De asemenea, am realizat că multe dintre difuzoarele noastre Smashing se bazau și pe acele ateliere.

Rachel An Drew: Așa că ne-am gândit: „Ei bine, de ce nu le ducem pur și simplu online?” Foarte, foarte repede, într-adevăr în câteva zile după ce s-a întâmplat asta, am decis că eu și Vitaly vom fi oarecum primii care ne vor pune capul peste putere, dar având în vedere că suntem noi și am putea să ne dăm seama cum să o facem. Avem și ateliere foarte diferite. Vitaly este mult mai mult colaborativ. Are activități și chestii de grup. Predau stilul clasei. Așa că între noi ne-am gândit: „Ei bine, acoperim într-un fel toate bazele”. Așa că ne-am gândit: „Hai să o facem. Să vedem dacă funcționează.” Așa că le facem reclamă. Ne-am dat seama cât de mult a durat fiecare, apoi ne-am așezat și am spus: „Ei bine, cum arată cu adevărat un atelier online? Ce este asta?"

Drew: Cred că dintr-o perspectivă tehnică, ca dezvoltatori web, care se gândesc imediat, cum naiba vom livra așa ceva, vreau să spun, trebuie să existe o mulțime de platforme diferite la care te-ai uitat. Care au fost diferitele lucruri la care te-ai uitat și cu ce a venit în cele din urmă Smashing?

Rachel An Drew: Așa că ne-am uitat la tot felul de lucruri și suntem încă în proces de a face asta. Momentan folosim Zoom. Motivul pentru care folosim Zoom este accesibilitatea. Era cea mai accesibilă dintre platforme. Evident, nu vrem să tăiem oamenii din cauza platformei pe care am ales-o. Cred că celelalte platforme sunt din ce în ce mai bune și oamenii sunt... Cred că multe platforme au avut oameni care au venit la ele și le-au spus: „Da, arăți grozav. Dar avem nevoie să fii accesibil.” Prin urmare, zoom-ul este cel mai ușor de utilizat pentru oameni în acest moment.” Deci, de aceea am ajuns să le folosim. Nu știu dacă vom face pentru totdeauna. Dar asta este ceea ce folosim în acest moment și a funcționat destul de bine ca o modalitate de a face aceste lucruri.

Drew: Pe măsură ce oboseala Zoom a apărut și lumea a început să se adapteze la ceea ce s-a numit rapid noua normalitate, am vorbit cu Phil Smith despre modul în care tehnologia ne poate ajuta să răspundem la situații precum COVID-19. Construirea aplicației React Native, CardMedic în doar 10 zile. L-am întrebat pe Phil cum procedează pentru a echilibra alegerea celei mai bune tehnologii pentru job față de tehnologiile cu care este familiarizat și în care poate lucra rapid.

Phil Smith: Aceasta este o întrebare bună. Cred că de îndată ce mi-a fost menționat proiectul, m-am gândit că știu exact cum voi construi toate acestea. Dacă nu aș fi avut copii și aș fi stat într-o cameră întunecată, cred că probabil că aș fi putut întoarce totul în aproximativ cinci zile dacă aș fi lucrat la el solid, solid, solid, deoarece cerințele erau foarte mult în în concordanță cu experiența mea de a construi aplicații. Am construit lucruri similare, în care apelează la un API, stochează rezultatele în stare și le prezintă. Acum sunt într-o poziție în care există câteva fragmente în care îmi spun: „Bine, trebuie să mă întorc și să refactorez asta”.

Phil Smith: Am vorbit despre tastarea tipului, dar, de fapt, tipurile pot fi destul de libere în aplicație, iar acest lucru trebuie să fie înăsprit. În partea din spate, nu sunt multe teste și acum începem să lansăm partea din spate pentru că mulți oameni au venit și au spus: „De fapt, aceasta este o resursă grozavă. Aș dori să-mi ofer serviciile pentru a traduce acest lucru în limba mea maternă.” Capetele din spate sunt folosite de mai mulți oameni, așa că mă gândesc doar: „Așteaptă, mai am nevoie de câteva teste aici pentru a mă asigura că nimic nu se poate rupe, deoarece există oameni care folosesc asta în producție acum”. Cred că ți-am răspuns la întrebare. În esență, nu s-a luat o decizie. Trebuia doar să-l scot acolo cât mai repede posibil.

Drew: Pe măsură ce locurile de muncă s-au închis și mulți dintre noi ne-am adaptat să lucreze acasă, am vorbit cu Ben Frain despre optimizarea spațiului de lucru de acasă pentru a fi un loc confortabil și productiv nu va duce la probleme de sănătate fizică pe termen lung. Cu bugete limitate disponibile pentru a se instala acasă, l-am întrebat pe Ben dacă un scaun bun este cel mai bun loc pentru a începe.

Ben Frain: Acesta ar fi sfatul meu. Da. Adică, nu pot pretinde că sunt o autoritate în aceste lucruri, dar se pare că este probabil cel mai important lucru pe care l-ai putea face pentru a te simți confortabil pe parcursul zilei. Puteți începe cu ceva destul de scump. Am făcut aceeași greșeală și am ajuns să iau un scaun de birou de 45 de lire de la Amazon și nu mi-am dat seama că nu are o înclinare înainte, oricare ar fi cuvântul potrivit pentru acel lucru, pe axă. Deci, ceea ce am descoperit este că îmi înfige partea de dedesubt a coapselor, cam în spatele genunchilor, și mă gândeam: „De ce îmi mor picioarele după 45 de minute de stat în chestia aia?”

Ben Frain: Cred că, în special, dacă lucrezi pentru o companie care oferă scaune de birou decente, le iei de la sine înțeles și abia după ce te uiți la acea marcă și marca anume vei spune: „O, Doamne, asta este un scaun de 700 de dolari.” Când îți dai seama de acel crikey, oamenii s-au gândit la asta și au făcut multe pentru tine, apoi, evident, ajungi în mediul tău acasă și te gândești: „De ce să nu cheltuiești X sute de dolari pe un scaun?” Dar poate că merită. Mai ales dacă ești aici pe termen lung.

Drew: Și distanța lungă este ceea ce avem. Altceva care există pe termen lung este Drupal. În iunie, am vorbit cu Angie Byron despre schimbările din Drupal 9. La 20 de ani de la prima lansare, Drupal a parcurs un drum lung. Am întrebat-o pe Angie cum a fost procesul de actualizare a unui site Drupal existent atunci când m-am mutat la Drupal 9 și dacă este probabil să fie o povară mare pentru cei cu site-uri de lungă durată.

Angie Byron: Cred că sunt practic trei scenarii. Așadar, una este că dacă rulați Drupal 8 și de fiecare dată când a apărut o nouă versiune minoră a Drupal 8, ați actualizat-o imediat și ați început să folosiți noile lucruri. Drumul tău va fi practic nimic. Ai făcut deja toată treaba și ești bine. Dacă te-ai mutat la Drupal 8 cu ceva timp în urmă și nu ai ținut pasul cu schimbările BC, mai este puțin de lucru pentru tine.

Angie Byron: Oricum, este cu siguranță cea mai ușoară actualizare din peste un deceniu a software-ului nostru și avem o mulțime de instrumente diferite pentru a vă ajuta cu aceasta. Există un tablou de bord care arată toate modulele contribuite și care este situația lor Drupal 9. Există instrumente automate pentru a parcurge și a verifica codul și a semnala orice funcții învechite pe care le aveți și există instrumente pentru a accesa automat și a găsi: „Oh, aceasta este cea mai recentă versiune a modulului dvs. și este gata Drupal 9? Ar trebui să-l descarci”, genul ăsta de chestii.

Angie Byron: Deci de la Drupal 8 la 9, aș spune că acea parte este destul de bine acoperită. Dacă veniți de la o versiune anterioară a Drupal, să spunem Drupal 7 sau mai jos până la Drupal 9, asta începe să pară puțin mai complicat. Printre modificările pe care le-am făcut în Drupal 8, unde, de exemplu, ne-am mutat în întregime la PHP orientat pe obiecte și am început să utilizăm modele de design care s-au găsit în alte proiecte software, ceea ce este un lucru foarte inteligent de făcut din punct de vedere arhitectural, dar nu înseamnă că, dacă ai avut o mulțime de cod personalizat în vechea ta viață, asta în Drupal 9, va trebui să găsești alternative pentru asta.

Angie Byron: Deci, Acquia este un produs și o dezvoltare numită Acquia Migration Accelerator, care urmărește să rezolve această problemă, în care creăm o aplicație drăguță, definită de React, care citește în vechile tale date Drupal 7, creează date Drupal 8 echivalente pentru tine. împreună cu toate modulele de care veți avea nevoie de acea hartă către vechile dvs. module Drupal 7, acolo unde este posibil, pentru a încerca să grăbiți destul de mult acest proces, deoarece vrem să ne asigurăm că toți cei care au versiuni mai vechi pot încă trece la Noua ordine mondială, în care toată lumea este pe aceeași versiune și lucrăm cu toții împreună.

Angie Byron: Apoi, în plus, am extins și Drupal 7... Comunitatea open source a Drupal, sfârșitul vieții lor în Drupal 7 din noiembrie anul viitor. În prezent, oricum, trebuie să discutăm dacă COVID-ul are impact sau nu. Dar există o serie de companii diferite, iar Acquia este una dintre ele care oferă suport extins pentru Drupal 7 dincolo de asta, cel puțin până în 2024. Astfel încât oamenii care au o actualizare ușoară să aibă un an și jumătate pentru a o face, oamenii să aibă o actualizare mai puțin ușoară, să aibă potențial trei ani și jumătate pentru a o face sau mai mult dacă este nevoie, și ne străduim cu adevărat să facem posibil ca toată lumea să se mute și apoi să construim instrumente precum Acquia Migrate Accelerator pentru a ajuta la accelerarea procesului.

Drew: Learning React a fost subiectul unei conversații cu Mina Markham. Mina și cu mine am fost amândoi în situația de a învăța React pentru prima dată. Reflectând la cât de multă sarcină au cadrele precum React pe browser, am întrebat-o pe Mina dacă a pune atât de mult control în mâinile clientului a fost o greșeală.

Mina Markham: Vreau să spun da, cu avertismentul că, din nou, experiența mea este foarte mult limitată la site-urile web în mare parte statice. Nu fac foarte multă dezvoltare de produse. Așa că poate în acel tărâm, acest lucru are mai mult sens. Dar din perspectiva mea, simt că de multe ori folosim o secure când avem nevoie doar de un cuțit pentru unt. Nu știu de ce trebuie să punem toate astea în browser, să punem atât de multă muncă și atât de multă presiune asupra clientului când putem face lucruri mult... Simt că am putea face asta mult mai simplu. Unul dintre lucrurile care m-au făcut întotdeauna puțin ezit să folosesc React, sau spun ezit, dar ceea ce vreau să spun când m-a enervat visceral și m-am opus activ a fost când mergeam pe un site web și, literalmente, nimic nu s-a redat pentru că a existat o eroare sau ceva de genul că întreaga pagină este defectă pentru că s-a defectat o funcție.

Mina Markham: M-a cam enervat faptul că, de multe ori, a fost o abordare totul sau nimic. Una dintre discuțiile pe care le-am susținut la AEA în trecut și în alte locuri în trecut a fost un fel de a vorbi despre cum să includeți îmbunătățirea progresivă și nu doar dezvoltarea dvs., ci și o direcție de artă mai mare și design de site-uri. Aș indica în mod specific exemple de site-uri web care nu au făcut îmbunătățiri progresive sau orice fel de degradare grațioasă. Era fie că aveți JavaScript rulat în browser, fie nu obțineți absolut nimic. Ar fi doar un simplu site care să reprezinte informații despre istoria web design-ului, care a fost unul dintre site-urile despre care s-a vorbit de fapt, istoria web design-ului din 1990 până în prezent. A fost un site frumos cu o mulțime de cronologie, animație de lucruri. Dar ar fi putut fi redat static doar cu o listă. Au fost pași între a nu arăta nimic și a arăta acea experiență frumos îmbunătățită, care cred că s-a pierdut din cauza modului în care ne-am abordat acum dezvoltarea web modernă.

Drew: Am vorbit cu Andy Bell despre CUBE CSS, o metodologie de stilare în maniera BEM, SMACSS și OOCSS. Multe abordări CSS încearcă să funcționeze împotriva proprietăților naturale ale CSS, cum ar fi cascada. CUBE îmbrățișează foarte mult acest comportament. Iată-l pe Andy.

Andy Bell: Un bun fel de analogie pentru acesta este SCSS, ca și Sass, este o extensie a limbajului natural CSS, nu-i așa? Mai ai dreptate în CSS. Deci CUBE CSS este așa. Deci este o extensie a CSS. Deci ar trebui să scriem în continuare CSS, așa cum ar trebui CSS... ei bine, ar trebui să fie scris. Să fim sinceri, așa ar trebui să fie scris. Numele îl dezvăluie, Cascading Style Sheets. Așa că acceptă asta din nou, pentru că ceea ce am descoperit este că am coborât până la nivelul de micro-optimizare. Am mers pe calea în care văd o mulțime de oameni coborând recent, unde... Am menționat asta și în articol, unde pot vedea... Există câteva dovezi în acest sens recent. Am observat că oamenii au creat componente de distanțiere și chestii de genul acesta și înțeleg această problemă. Am fost in acea situatie.

Andy Bell: Modul în care am remediat a fost, în loc să măresc și să încerc să micro-optimizez, am început să mă gândesc la lucruri la nivel compozițional, deoarece nu contează cât de mici sunt componentele tale. La un moment dat vor fi pagini. Vor fi vederi. Nu poți evita asta. Așa va fi. Deci, în loc să încercați să spuneți: „Bine, am nevoie de acești ajutoare minuscule pentru a face acest aspect”, spuneți: „Bine, am o vizualizare a paginii de contact sau o vizualizare a paginii de produs și aceasta este o compoziție de aspect schelet. Apoi, în interiorul acesteia, pot introduce orice componente vreau acolo.”

Andy Bell: Avem lucruri precum Grid și Flexbox acum care fac acest lucru mult mai realizabil și, în esență, puteți pune orice doriți în interiorul aspectului scheletului. Nu contează. Apoi, componentele ar trebui, în acel moment, să se comporte așa cum doriți să se comporte, cu sau fără interogări container.

Drew: Gatsby a fost subiectul discuției mele cu Marcy Sutton. În timp ce majoritatea generatoarelor de site-uri statice sunt agnostice de cod front-end, Gatsby folosește React și, prin urmare, ajungeți să rulați codul Gatsby ca parte a experienței dumneavoastră web finale. Am întrebat-o pe Marcy ce este acel cod și ce funcționalitate oferă.

Marcy Sutton: Da. Aș spune că cea mai mare parte din asta este rutarea pe partea clientului. Așa că Gatsby acum folosește reșapătoare sub capotă. Este doar o implementare proprie. Dar aceasta este piesa că atunci când încărcați site-ul static pentru prima dată, există fișiere HTML acolo. Deci, dacă utilizatorul dezactivează JavaScript dintr-un anumit motiv, site-ul dvs. ar trebui să fie în continuare acolo, să aibă în continuare conținut. Dar dacă JavaScript este activat, atunci are loc acest pas de hidratare, unde atunci când utilizați link-uri în site-ul dvs. Gatsby, va merge pre-preluare resurse de pe pagina respectivă. Deci se va încărca mai repede. Deci, totul este activat cu acest strat JavaScript pe care ți-l oferă Gatsby.

Marcy Sutton: Deci, dincolo de asta, depinde într-adevăr ce folosești pe site-ul tău, ce va ajunge în acel pachet JavaScript. Dar pentru lucrurile care folosesc multă interactivitate, cum ar fi interfețele accesibile, acesta este un loc bun pentru a fi. Pentru mine, îmi place foarte mult să am JavaScript disponibil în orice moment și ca marcajul să fie într-un loc bun. Știu că este o chestiune de preferință, dacă doriți ca HTML și JavaScript și CSS să fie bine cuplate și că există loc pentru variații în construcția Gatsby. Nu trebuie să utilizați întotdeauna ceva de genul CSS și JS. Dar este cu adevărat să obțineți puterea acelui strat JavaScript dinamic disponibil pentru dvs. în timp ce vă scrieți site-ul. Nu este ca acest add-on într-un fișier separat.

Drew: Când mă gândesc la modul în care funcționează de obicei un generator de site-uri static, mă gândesc la conținutul din fișiere de reducere, iar generatorul rulează acel conținut și îl îmbină cu șabloane și creează zeci, sute, mii de fișiere HTML, care sunt paginile site-ului dvs. Când mă gândesc la un site sau o aplicație React, mă gândesc mai mult la experiența pe o singură pagină, în care interfețele sunt create de React din mers. Deci vrei să spui că Gatsby face ambele astea? Creează toate paginile și, de asemenea, le îmbunătățește cu JavaScript?

Marcy Sutton: Este, da. Gatsby va folosi Node.js în momentul construirii, va trece peste componentele dvs. React și le va compila în fișiere HTML, ceea ce sincer, prima dată când m-am uitat la Gatsby, nu am dezactivat JavaScript și am spus: „Bine, mai sunt alte pagini aici? Ce este asta?" Am fost atât de fericit că Gatsby funcționează astfel implicit. Va crea fișiere construite din componentele dvs. React, ceea ce este minunat.

Marcy Sutton: Am explorat abordări mai progresive de îmbunătățire, deoarece este în JavaScript, cum ar fi, dacă doriți să afișați ceva îmbunătățit progresiv pentru utilizatori, unde dacă au JavaScript dezactivat, nu doriți tot acest cod rupt care presupune JavaScript. Este acolo. Așa că există niște ciudatenii cu el. Dar poți rezolva astfel de lucruri, cel puțin pentru fluxurile tale de utilizatori de bază în care vrei ca cineva să poată cumpăra în continuare ceva. S-ar putea să fie nevoie să adăugați asistență și pentru acele cazuri de utilizare. Dar am fost plăcut surprins de felul în care Gatsby o lansează implicit.

Marcy Sutton: Deci este o alegere pe care au făcut-o să construiască site-uri în acest fel, și evaluăm mereu, este încă cea mai bună modalitate? Ce trebuie să facem pentru a oferi utilizatorilor noștri ceea ce cer? Așa că facem câteva explorări la nivel intern, în desfășurare doar pentru a ne asigura că Gatsby face cea mai bună treabă posibilă la construirea unui site web, astfel încât să păstrăm dimensiunile pachetelor mici și să ne asigurăm că pentru a face compromisuri pentru ceea ce spunem noi este un cod performant cu pre -preluare, avem datele pentru a face o copie de rezervă? Acesta este genul de lucru care mă interesează foarte mult, în calitate de susținător al dezvoltatorilor, este să mă asigur că ceea ce ambalăm și grupăm pe site-uri web este de fapt necesar și va face cu adevărat cel mai bun site Gatsby pe care îl poate face.

Drew: Vorbind cu Chris Ferdinandi în iulie, am întrebat dacă cele mai bune practici moderne sunt dăunătoare pentru 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. Am ajuns să cred că multe dintre ceea ce considerăm că sunt cele mai bune practici astăzi ar putea înrăutăți de fapt web-ul. 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. Dar, într-adevăr, Lean Web se concentrează pe simplitate și performanță pentru utilizator și să prioritizeze sau să pună accent pe oamenii care folosesc lucrurile pe care le facem, mai degrabă decât pe noi, pe oamenii care le facem.

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? Dar puteți alege și limbi de pre-procesor. Să spunem că îți place Sass. Activați Sass în CSS și scrieți Sass. Ei bine, ceva trebuie să proceseze Sass. În zilele noastre, Sass este scris în Dart sau așa ceva. Theoretically, you could do that in the client. Dar aceste biblioteci care fac preprocesare sunt destul de mari. Nu cred că vreau să-ți trimit întreaga bibliotecă Sass, doar pentru a rula chestia aia. 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. Dar iată cum funcționează acum, dacă există o lambda. Procesează Sass. Are o slujbă micuță, micuță, micuță. 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. Nu trebuie să vă faceți griji cu privire la scară. 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. Dar există unul pentru Sass. Există unul pentru Less. Există unul pentru Babbel. Există unul pentru TypeScript. Există unul pentru... Toate acestea sunt lambda individuale pe care le conducem. Here's some code, give it to the lambda. It comes back, and we do whatever we're going to do with it. Dar îl folosim pentru mult mai mult decât atât, chiar și recent.

Chris Coyier: Here's an example. Fiecare stilou pe CodePen are o captură de ecran. E cam misto, nu? 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. Dacă îl distribuiți în Slack, obțineți o mică previzualizare a acestuia. 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? Oricum nu este animat. Doar câștiguri de performanță așa.

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. Este un muncitor. 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. Serviți-l ca aceste dimensiuni.” Nu trebuie să fac imaginea în acele dimensiuni. 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. Acestea devin puncte de intrare în aplicația dvs. pe care le puteți partaja prin toate tipurile de 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. De asemenea, Next.js, care este foarte, foarte frumos, preia automat restul paginilor care sunt conectate la acel punct de intrare, astfel încât să pară o aplicație cu o singură pagină. 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. Deci, în primul rând, a existat o motivație de a schimba reactivitatea. 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. Dar bine. Te vom învăța oricum.

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 TypeScript. 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: Deci aceasta a fost din nou o parte uriașă. Ultimul a fost că ne-a cam ratat funcționalitatea logicii abstracte, în ceea ce privește nu componentele, ci părțile logice posibile, cum ar fi ajutoarele de funcții și așa mai departe, dar ar trebui să poată include și activitatea Vue. Un exemplu frumos aici ar putea fi React Hooks, nu? Ele vă permit să abstractizați părțile funcționalității, iar acest lucru lipsea în mod clar în Vue. Știu că acum sună de genul „Ai furat funcția de la React”. Nu de fapt. Cred că polenizarea încrucișată a ideilor este o parte importantă și frumoasă în ecosistemul nostru și, de asemenea, îi ajută pe dezvoltatori să comute între favorite, nu? Așa că lucram la aceste caracteristici principale pentru a crea Vue 3 ca versiune majoră.

Drew: După aceea, ne-am scufundat în TypeScript cu Stefan Baumgartner pentru a afla cum ne poate ajuta să scriem un cod mai bun, cu mai puține erori. Observând tendința organizațiilor de a-și muta baza codului în întregime la JavaScript, l-am întrebat pe Stefan dacă TypeScript este ceva de care echipele mai mari ar beneficia mai mult decât indivizii.

Stefan Baumgartner: Deci, momentan sunt în aceeași tranziție. Deci avem o mulțime de dezvoltatori Java și C++ care vor scrie o mulțime de JavaScript în viitor. TypeScript poate fi un fel de ghid pentru acele zone înfricoșătoare ale noului limbaj de programare. JavaScript are o mulțime de ciudatenii, multă istorie și o mulțime de prejudecăți dacă provin dintr-un alt limbaj de programare. Deci TypeScript poate fi un ghid, deoarece există câteva concepte pe care le cunoașteți în sistemul de tipări.

Stefan Baumgartner: Dar, de asemenea, cred că, mai ales când aveți mulți oameni care lucrează în aceeași bază de cod sau mulți oameni care trebuie să lucreze unul cu celălalt, acesta poate fi un nivel suplimentar de îndrumare în proiectul dvs., în cazul în care nu nu am nicio surpriză proastă până la urmă. Deci, desigur, tehnologia nu rezolvă nicio problemă de comunicare. Nu este destinat pentru aceasta TypeScript. Dar poate scădea sau poate face mult mai mult loc pentru discuția corectă, atunci dacă nu trebuie să vorbiți despre ce așteptați de la mine în codul dvs., ci mai degrabă ce ar trebui să facă codul dvs. sau ce ar trebui să vă biblioteca face?

Stefan Baumgartner: Întotdeauna spun că, dacă scrii vreodată cod pentru alți oameni sau dacă scrii cod cu mulți oameni sau dacă scrii doar cod pentru tine, trebuie să revii a doua zi, ia în considerare TypeScript pentru că s-ar putea să te ajute în Pe termen lung. Aceasta nu este doar o investiție pentru următorul proiect de săptămâna viitoare, ci mai mult pentru unul care spune, bine, mai ales dacă aveți proiecte de lungă durată pentru luni, doi sau ani, cu siguranță oferă asta. Nu o să știi niciodată la ce te-ai gândit când ai scris micuța bucată de cod în urmă cu un an, dar tipurile îți pot da un indiciu despre ce ai vrut să spui.

Drew: În noiembrie, am vorbit cu David Darnes despre generatorul de site-uri static, Eleventy. Am vorbit despre șabloane și despre câți generatori de site-uri statice sunt destul de obișnuiți cu privire la tipul de șabloane pe care ar trebui să-l utilizați. M-am întrebat dacă Eleventy avea același fel de convingeri puternice. Iată-l pe Dave.

David Darnes: Nu, trebuie să spun că este cât se poate de nepăsător. Puțin o viziune personală, dar m-am chinuit să văd orice cadru sau orice care poate fi lipsit de păreri pentru că, pentru a crea ceva, trebuie să ai o părere despre cum vrei să faci ceva. E un fel de oximoron. Sunt sigur că oamenii m-ar putea corecta în privința asta. Dar da. Puteți trece la orice limbaj de șablon cu care vă simțiți cel mai confortabil. Adică, vorbeam doar despre limbi cu care te simți confortabil. Eleventy face apel la asta, într-un fel de sens, cu limbajele de șabloane folosite în HTML-ul dvs. sau chiar la naiba CSS-ul dvs., dacă doriți.

David Darnes: Pentru mine, tocmai m-am dus direct la nunjucks, deoarece nunjucks este limbajul implicit al șablonului din Eleventy. Asta înseamnă că pot folosi extensia dot HTML și să o las așa cum este. Acum, voi face și mai multă confuzie pe oameni și voi spune: „Oricum poți numi asta cum vrei. Te poți distra cu adevărat cu ea.” Dar poți folosi ghidon. Cred că puteți folosi șabloane JavaScript obișnuite și puteți repeta prin ele așa. Ghidonul destul de popular și lichid, de asemenea. Nu mă pot gândi la toate din capul meu, dar dacă le configurați pe toate în configurație, puteți alege cum doriți.

David Darnes: Aș spune că sunt un mare fan al modelării limbilor în general. Nu a fost cu mult timp în urmă când am aflat că poți folosi twig în interiorul WordPress și asta m-a uimit. Am spus: „O, slavă Domnului. Nu trebuie să mă ocup de o buclă for în interiorul PHP.” Din nou, cred că ceva mai confortabil și mai ușor de înțeles, și mai ușor de citit. Deci da. Eleventy are o mulțime de opțiuni diferite de șabloane și ar trebui să atragă oamenii care se simt confortabil cu acelea diferite.

Drew: Am vorbit cu Leslie Cohn-Wein despre modul în care Netlify își folosește propria platformă pentru a construi Netlify și despre modul în care funcționalitatea Deploy Preview devine o platformă eficientă de pregătire pentru schimbările front-end.

Leslie Cohn-Wein: Poate că partea mea preferată din întregul proces este magia Deploy Previews, pe care o obținem prin Netlify. Deci, ceea ce se întâmplă este că lucrați în GitHub, vă creșteți PR. Așa că vă deschideți PR în GitHub, iar aceasta va crea automat o versiune a Previzualizării dvs. de implementare a aplicației. Așa că folosim de fapt Deploy Previews ale aplicației în sine pentru a testa, pentru a ne asigura că totul funcționează așa cum ar trebui. Ne rulăm testele. Acesta este ceea ce folosim pentru a verifica manual în timpul revizuirii codului. Deci avem un fel de toate acele implementări continue configurate chiar din GitHub.

Leslie Cohn-Wein: Apoi, unul dintre celelalte lucruri interesante pe care le-am configurat este că avem de fapt câteva site-uri Netlify diferite care extrag din același depozit în care se află aplicația noastră. Deci avem ambele aplicații noastre. Avem o instanță de Storybook care are un fel de componente ale noastre UI pentru aplicație. Deci avem atât aplicația noastră în sine. Avem componentele Storybook UI și, practic, avem un site Netlify care arată Storybook UI, iar apoi avem și un al treilea site care rulează un analizor de pachete webpack. Deci, este un fel de interfață de utilizare vizuală care vă oferă o vizualizare a hărții arborescente a tuturor pachetelor de aplicații și le putem măsura dimensiunea și este doar un memento pentru noi să verificăm de două ori pe măsură ce se desfășoară fiecare implementare a aplicației. afară, putem verifica și să ne asigurăm că nu facem nimic ciudat cu dimensiunea pachetului nostru acolo.

Leslie Cohn-Wein: Deci toate cele trei site-uri sunt generate într-o singură cerere de extragere a aplicației. Așadar, veți primi linkuri către previzualizarea, în esență, Previzualizările dvs. de implementare, atât ale aplicației Storybook, cât și către profilul respectiv al aplicației, pentru ca noi să le verificăm.

Drew: În decembrie, am vorbit cu Chris Murphy despre designul de produs și despre ce înseamnă pentru business să fie concentrat pe proiectare. Am discutat dacă un fondator individual se concentrează asupra designului, face această scurgere în afacere și dacă un produs este în mod natural o extensie a persoanei care l-a creat.

Chris Murphy: Cred că aceasta este o întrebare foarte bună, Drew, și cred că răspunsul la aceasta este că depinde. Cred că depinde de acea persoană și depinde de dimensiunea companiei. Dacă aruncați o privire la Hiut Denim, iar eu folosesc Hiut mult în predarea mea, este un exemplu foarte bun de companie care face un lucru bine, și acesta este genul lor de blugi strapline. Cred că dacă te uiți la precedentul lui David... David și Clare, pentru că sunt un parteneriat. Dacă te uiți la compania anterioară a lui David Hieatt și Clare Hieatt, care era Howies, acea companie a crescut atât de mare, încât erau atât de mulți oameni implicați.

Chris Murphy: Odată ce scara începe să se strecoare, începe să devină foarte dificil să urmăriți toate punctele de contact care contează în călătoria clientului. Cred că este foarte grăitor când au plecat de la Howies, pentru că Howies fusese cumpărat de... E complicat. Citește-l pe internet. Dar a fost Timberland, și Timberland a fost cumpărat și există toată povestea asta.

Chris Murphy: Cred că este foarte interesant că ceea ce se concentrează acum sunt blugii. Asta e. Ei spun o poveste uimitor de bună în jurul blugilor. De asemenea, ambalează totul foarte, foarte bine, iar blugii sunt ca un vehicul pentru povești, într-adevăr. Acesta este ceva ce cred, Drew, va deveni mai important pe măsură ce ieșim la celălalt capăt al COVID, din care sper să ieșim la celălalt capăt. Toți cei care fac blugii aceia primesc un salariu corespunzător. Una dintre problemele pe care le am în momentul în care mă uit la lume este că nu toată lumea primește un salariu adecvat și mi se pare puțin îngrijorător, ca cineva... Uite, am 51 de ani. Fiul meu are 25, 24 de ani. , 25 de ani, așa ceva. Este ingrozitor. Ar trebui să știu toate chestiile astea. Este fotograf de nuntă. Este fotograf de nuntă de un an și puțin. Afacerea lui este complet decimată pentru că nimeni nu se căsătorește cu adevărat pe moment pentru că este doar dificil. Nu are salariu pentru că nu avea suficiente cărți de liber profesionist pentru a obține sprijinul.

Chris Murphy: A căzut printre crăpături și sunt mulți alți oameni care au căzut printre crăpături. Aș spune că este o problemă de design, că trebuie să privim asta ca pe o problemă de design. Dar dacă mă uit și la acea problemă mai largă a COVID și a guvernului și la toate aceste lucruri fără să devin prea politică, am citit ieri un articol din The Guardian despre vecinul lui Matt Hancock și despre oricine ascultă și care nu este din Marea Britanie, Matt Hancock este secretarul de sănătate. Vecinul său, care conducea o afacere, îi trimitea mesaje și îi cerea sfaturi despre „Cum aprovizionez produse pentru acest lucru cu COVID?” Există o mulțime de zgomote în jurul chumocrației, așa o numesc ziarele, prieteni ai prietenilor miniștrilor guvernamentali care par să obțină locuri de muncă pentru că cunosc oamenii potriviți.

Chris Murphy: Am acest sentiment că vom ajunge la celălalt capăt al acestui lucru și vom vedea asta... Indivizii văd asta și se gândesc: „Ei bine, unde se duc acești bani și oamenii sunt plătiți corespunzător? Care este prețul acestui tricou de o liră de la magazinul X?” Nu vreau să menționez nicio marcă. Dar totul trebuie plătit și tot ceea ce este făcut, oamenii trebuie plătiți pentru a reuși. Cred că oamenii sunt din ce în ce mai interesați de, oamenii sunt plătiți corect?

Drew: GraphQL a fost subiectul finalului nostru episod complet al anului și am discutat cu Eve Porcello și am întrebat unde se încadrează GraphQL în stiva de dezvoltare.

Eve Porcello: Da. GraphQL se potrivește între partea din față și cea din spate. Deci, este un fel de viață la mijloc între cele două și oferă o mulțime de beneficii dezvoltatorilor front-end și dezvoltatorilor backend. Dacă sunteți un dezvoltator front-end, puteți defini toate cerințele de date pentru front-end. Deci, dacă aveți o listă mare de componente React, de exemplu, puteți scrie o interogare, iar aceasta va defini toate câmpurile de care aveți nevoie pentru a completa datele pentru pagina respectivă.

Eve Porcello: Acum, cu piesa de backend, este cu adevărat proprie, pentru că putem colecta o mulțime de date din multe surse diferite. Deci avem date în API-uri și baze de date REST și în toate aceste locuri diferite, iar GraphQL ne oferă acest mic strat de orchestrare frumos pentru a înțelege cu adevărat haosul în care se află toate datele noastre. Deci este foarte util pentru toată lumea din toată stiva.