Smashing Podcast Episodul 21 cu Chris Ferdinandi: Cele mai bune practici moderne sunt rele pentru web?

Astăzi, ne întrebăm dacă cele mai bune practici moderne sunt dăunătoare pentru web? Cadrele moderne ne conduc pe calea greșită? Vorbesc cu expertul Lean Web Chris Ferdinandi pentru a afla.

Afișați note

• Pagina lui Chris cu link-uri și note pentru podcast
• Cartea Lean Web
• Chris Ferdinandi pe web
• Chris pe Twitter
• Podcastul JavaScript Vanilla

Actualizare săptămânală

• „Traducerea designului Wireframes în HTML/CSS accesibil”
  de Harris Schneiderman
• „Crearea de aplicații desktop cu Electron și Vue”
  de Timi Omoyeni
• „Tehnici CSS moderne pentru a îmbunătăți lizibilitatea”
  de Edoardo Cavazza
• „Cum să utilizați componentele stilate în React”
  de Adebiyi Adedotun Lukman
• „Cum să creez un Porsche 911 cu schiță”
  de Nikola Lazarevic

Transcriere

Drew McLellan: Este autorul seriei Vanilla JS Pocket Guide, creatorul programului de formare Vanilla JS Academy și gazda Podcastului Vanilla JS. El a dezvoltat un buletin informativ Sfaturi, acesta este citit de aproape 10.000 de dezvoltatori în fiecare zi a săptămânii. A predat dezvoltatori la organizații precum Chobani și The Boston Globe. Și pluginurile sale JavaScript au fost folosite de organizații precum Apple și Harvard Business School. Mai presus de toate, îi place să ajute oamenii să învețe Vanilla JavaScript. Așa că știm că ar prefera să aleagă Vanilla JavaScript în detrimentul unui cadru, dar știai că a fost odată ales într-un grup de poliție ca fiind persoana cel mai puțin probabil să fi comis crima? Prietenii mei Smashing, vă rog bun venit lui Chris Ferdinandi. Bună, Chris. Ce mai faci?

Chris Ferdinandi: Oh, sunt zdrobitor. Mulțumesc că m-ai primit.

Drew: Am vrut să vă vorbesc astăzi despre acest concept de Lean Web, care este o pasiune pentru tine, nu-i așa?

Chris: Da, foarte mult.

Drew: De ce nu ne faci scena? Când vorbim despre un Web Lean, care este problema pe care încercăm să o rezolvăm?

Chris: Da, grozavă întrebare. Doar ca o avertizare pentru toți ascultătorii, acest episod ar putea face ca un bătrân să țipe la nor. O să încerc să evit asta. Când mă uit la modul în care construim pentru web astăzi, se simte un pic ca o mizerie umflată supra-proiectată. 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.

Chris: Lean Web este o abordare a dezvoltării web care se concentrează pe simplitate, pe performanță și pe experiența dezvoltatorului peste... Îmi pare rău, nu pe experiența dezvoltatorului. Mai degrabă, experiența utilizatorului, peste experiența dezvoltatorului și ușurința de a construi lucruri dintr-o perspectivă de echipă, ceea ce cred eu în care ne-am concentrat mult astăzi și pe care probabil vom intra în conversația noastră.

Chris: De fapt, am ajuns să constat că multe dintre aceste lucruri pe care le considerăm a îmbunătăți experiența dezvoltatorului fac acest lucru pentru un subset de dezvoltatori, dar nu neapărat pentru toți cei care lucrează la lucrul pe care îl construiești. Deci, există și o grămadă de probleme cu asta, în care putem săpă. 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: Pe măsură ce web-ul se maturizează ca platformă de dezvoltare, se pare că există această tendință din ce în ce mai mare către specializare.

Chris: Da.

Drew: Oameni care obișnuiau să acopere Full Stack și apoi ne-am împărțit în front-end și back-end. Și apoi acel front-end s-a împărțit în oameni care fac dezvoltare CSS sau JavaScript. Și apoi din ce în ce mai mult în JavaScript, devine mai specializat. Cineva ar putea să se considere și să se comercializeze ca un dezvoltator React sau un dezvoltator Angular, iar întreaga identitate și perspectivă se bazează pe un anumit cadru în care sunt foarte calificați. Este această dependență de cadre, nucleul muncii noastre pe web, un lucru rău?

Chris: Este nuanțat. Am fost foarte puternic în tabăra da, întotdeauna. Cred că, în linii mari, încă simt că da, obsesia noastră ca industrie cu cadre și instrumente în general, este potențial un pic în detrimentul nostru. Nu cred că cadrele sunt în mod inerent proaste. Cred că sunt utile pentru un subset foarte restrâns de cazuri de utilizare. Și ajungem să le folosim pentru aproape orice, inclusiv pentru multe situații în care nu sunt neapărat cea mai bună alegere pentru tine sau pentru proiect.

Chris: Când mă gândesc la multe dintre problemele pe care le avem astăzi pe web, miezul acestor probleme începe cu adevărat cu dependența noastră excesivă de cadre. Tot ceea ce urmează după aceea este în multe feluri, pentru că aruncăm atât de multe, nu doar cadre, care este JavaScript în general, pe web. Spun asta ca cineva care îi învață profesional pe oameni cum să scrie și să folosească JavaScript. Așa îmi fac banii. Și spun aici că cred că folosim prea mult JavaScript, ceea ce uneori este un lucru puțin ciudat.

Drew: În perioada de dinaintea apariției cadrelor mari, obișnuiam să construim interfețe de utilizator și lucruri cu jQuery sau orice altceva. Și apoi au apărut cadrele și ne-au oferit mai mult acest concept de interfață de utilizare bazată pe stat.

Chris: Da.

Drew: Acum, ăsta este o parte destul de complexă de inginerie pe care trebuie să-l puneți în aplicare. Lucrul cu mai puțin JavaScript exclude utilizarea așa ceva sau trebuie să-l reimplementați singur? Tocmai creezi un boilerplate încărcat?

Chris: Multe depind de ceea ce faci. Dacă aveți o interfață care nu se schimbă, puteți construi o interfață de utilizare bazată pe stare cu... Nu știu, poate o duzină de linii de cod. Dacă aveți o interfață care nu se schimbă, probabil că aș spune sincer că interfața de utilizare bazată pe stat. Nu este neapărat abordarea corectă. Probabil că mai sunt și alte lucruri pe care le poți face în schimb. Gândiți-vă la generatoarele de site-uri statice, unele markupuri pre-rendate, chiar și un site bazat pe WordPress sau PHP de școală veche.

Chris: Dar acest lucru începe să devină interesant este atunci când intri în interfețe mai dinamice și interactive. Nu doar aplicații. Știu că oamenilor le place să tragă această linie între site-uri web și aplicații și cred că există o amestecare ciudată între ele două și linia nu este întotdeauna la fel de clară. Când începeți să intrați în mai multe, utilizatorul face lucruri, ceva se schimbă. Interfața de utilizare bazată pe stat devine puțin mai importantă. Dar tot nu aveți nevoie de tone de cod pentru a face acest lucru.

Chris: Mă uit la ceva de genul React sau Vue, care sunt piese de inginerie absolut uimitoare. Nu vreau să iau de la oamenii care lucrează la acestea. Am ajuns ca un exercițiu de învățare, construindu-mi propriul mini-cadru doar pentru a înțelege mai bine cum funcționează aceste lucruri sub capotă. Este foarte greu să țin cont de toate piesele în mișcare diferite. Așa că am un respect extraordinar pentru oamenii care construiesc și lucrează la aceste instrumente. Dar React și Vue sunt ambele aproximativ 30 de kiloocteți după minimizare și gzipping. Deci, odată ce le despachetezi, sunt substanțial mai mari decât atât.

Chris: Nu toate, dar o bună parte din această greutate este dedicată acestui lucru numit DOM virtual. Există alternative care utilizează API-uri sau abordări similare. Pentru React, aveți Preact, care este de 2,5 kiloocteți sau aproximativ 3 kiloocteți în loc de 30. Este o zecime din dimensiune. Pentru Vue, aveți în schimb Alpine JS, care este de aproximativ 7 kiloocteți. Totuși, substanțial mai mic. Marea diferență dintre aceștia și omologii lor mai mari este că au renunțat la DOM-ul virtual. Ei pot renunța la o metodă sau două. Dar, în general, este aceeași abordare și același tip de API în modul de lucru cu codul și sunt substanțial mai mici.

Chris: Cred că multe dintre instrumentele pe care le folosim sunt potențial depășite pentru lucrurile pe care încercăm să le facem. Dacă aveți nevoie de o interfață de utilizare bazată pe stare și aveți nevoie de date reactive și de aceste interfețe dinamice, este grozav. Cred că unul dintre lucrurile importante despre care încerc și le vorbesc astăzi nu este... să nu folosesc niciodată instrumente. Pentru mine, Vanilla JS nu înseamnă că scrii de mână fiecare linie de cod și fiecare proiect pe care îl faci. Asta e nebunie. Nu am putut face asta, nu fac asta. Dar este să fim mai selectivi cu privire la instrumentele pe care le folosim. Mereu mergem pe instrumentul multiplu, cuțitul elvețian care are toate aceste lucruri în el. Și uneori, tot ce aveți nevoie este o pereche de foarfece. Nu aveți nevoie de toate celelalte lucruri, dar le avem oricum.

Chris: Ceea ce este o cale foarte lungă până la... Îmi pare rău că îți răspund la întrebare. Ceea ce uneori este mai mult cod decât ai putea sau ai vrea să scrii singur, dar nu este atât de mult cod pe cât cred că credem că necesită. Când spun că nu ai nevoie de un cadru, primesc o mulțime de respingeri în jurul acestei idei că „Ei bine, dacă nu folosești un cadru, practic îl scrii pe al tău.” Apoi asta vine cu propriile sale probleme. Cred că există un loc între utilizarea React sau Vue și scrierea propriului cadru și poate alege ceva care este puțin mai mic. Există uneori motive pentru care scrierea propriului framework ar putea fi de fapt apelul potrivit, în funcție de ceea ce încercați să faceți. Totul este foarte fluid și subiectiv.

Drew: Este destul de interesant că, ca exercițiu de învățare, ți-ai implementat propriul cadru bazat pe stat. Îmi amintesc în trecut, obișnuiam să mă gândesc că de fiecare dată când ajungeam la o bibliotecă sau ceva de genul acesta, îmi plăcea să cred că o pot implementa și eu.

Chris: Sigur, sigur.

Drew: Dar să ajung la bibliotecă m-a scutit de bătaia de cap de a face asta. Știam că dacă ar trebui să scriu singur acest cod, știam ce abordare aș lua pentru a o face. Și asta a fost adevărat până la utilizarea unor lucruri precum jQuery și altele. În zilele noastre, cred că dacă ar trebui să scriu propria mea versiune de Vue sau React, aproape că habar nu am ce se întâmplă acum în acea bibliotecă, în tot acel cod.

Drew: Pentru cei dintre noi care nu sunt familiarizați, când spuneți ceva de genul Preact elimină DOM-ul virtual și face totul mult mai mic, ce ne oferă acel DOM virtual?

Chris: Pentru a răspunde la această întrebare, vreau să fac doar un mic pas înapoi. Unul dintre cele mai frumoase lucruri pe care ți le oferă cadrele și alte biblioteci bazate pe stat este diferența de DOM. Dacă chiar nu actualizați atât de mult interfața de utilizare, vă puteți descurca spunând: „Iată un șir cu cum ar trebui să arate markupul. În HTML, voi pune tot acest marcaj în acest element.” Când trebuie să schimbi ceva, o faci din nou. Este puțin costisitor pentru browsere, deoarece declanșează o revopsire.

Chris: Dar cred că, potențial mai important decât atât, una dintre problemele în a face asta este că aveți orice fel de element interactiv acolo, un câmp de formular, o legătură pe care cineva s-a concentrat. Acea focalizare este pierdută pentru că elementul... chiar dacă aveți un lucru nou care arată similar, nu este același element literal. Deci, dacă se pierde concentrarea, se poate crea confuzie pentru persoanele care folosesc cititoare de ecran. Există doar o grămadă de probleme cu asta.

Chris: Orice lucru cu UI bazat pe stat, care merită greutatea lui, va implementa unele dintre diferențele DOM, unde ei spun: „Iată cum ar trebui să arate interfața de utilizare. Iată cum arată acum în DOM. Ce este diferit?" Și va merge și va schimba acele lucruri. În mod eficient, face lucrurile pe care le-ați face doar dacă actualizați manual interfața de utilizare, dar o face pentru dvs. sub capotă. Așa că poți spune doar: „Iată cum vreau să arate”. Și apoi biblioteca sau cadrul își dă seama.

Chris: Lucrurile mai mici precum Preact sau Alpine, de fapt fac asta direct. Ei convertesc șirul pe care le oferiți despre cum ar trebui să arate interfața de utilizare în elemente HTML. Și apoi compară fiecare element cu piesa corespunzătoare din DOM-ul literal. Pe măsură ce ajungeți cu interfețe care devin din ce în ce mai mari și mai mari, asta poate avea o implicație de performanță, deoarece interogarea DOM-ului din nou și din nou devine costisitoare. Dacă doriți să înțelegeți tipul de interfață în care aceasta devine o problemă, faceți clic dreapta și inspectați elementul pe butonul „Favorit” de pe Twitter sau pe butonul „Like” de pe Facebook. Și aruncați o privire la imbricarea div-urilor care vă duce la acel element. Este foarte, foarte adânc. Este ca o duzină de div-uri, imbricate unul în celălalt doar pentru acel singur tweet.

Chris: Când începi să cobori atât de multe straturi, începe să afecteze cu adevărat performanța. Ceea ce face DOM-ul virtual este, în loc să verifice DOM-ul real de fiecare dată, creează o hartă bazată pe obiecte a modului în care arată interfața de utilizare în JavaScript. Și apoi face același lucru pentru UI cu care doriți să o înlocuiți pe cea existentă și le compară pe cele două. Asta înseamnă mult mai multă performanță în teorie decât să faci asta în DOM real. Odată ce primește o listă cu lucrurile pe care trebuie să le schimbe, pur și simplu rulează și face acele modificări. Dar trebuie să atace DOM-ul doar o dată. Nu se verifică fiecare element, de fiecare dată. Dacă aveți interfețe precum Twitter sau Facebook sau QuickBooks sau ceva de genul, DOM virtual are probabil foarte mult sens.

Chris: Provocarea cu acesta este... diferența dintre Preact și React este de 27 de kiloocteți înainte de a despacheta totul în unda de cod reală. Timpul de descărcare brută și de despachetare și compilare poate adăuga destul de multă latență la încărcarea inițială a unei interfețe de utilizare. Acest lucru devine și mai pronunțat dacă utilizatorii dvs. nu sunt pe cele mai recente dispozitive de la Apple. Chiar și un dispozitiv Android de acum câțiva ani sau un telefon cu caracteristici, sau dacă aveți oameni în țări în curs de dezvoltare, este doar... timpul pentru a începe este mai lent. Și pe lângă asta, timpul interactiv real este mai lent din cauza abstracției suplimentare.

Chris: Deci nu este vorba doar de încărcarea ei și sunt comparabile ca viteză. Fiecare microinteracțiune pe care o face cineva și schimbările care trebuie să se întâmple pot fi, de asemenea, puțin mai lente, doar din cauza întregului cod suplimentar de acolo. Dacă aveți o interfață de utilizare cu adevărat, foarte complexă, cu o mulțime de elemente imbricate și o mulțime de date, atunci câștigurile de performanță ale DOM-ului virtual depășesc greutatea suplimentară a codului. Dar orice interfață de utilizare tipică pentru o aplicație tipică pentru care văd dezvoltatorii care folosesc React sau Vue, beneficiul pe care îl obțineți de la DOM-ul virtual pur și simplu nu există și le-ar fi mai bine. Chiar dacă doriți să păstrați aceeași comoditate cu React, utilizați Preact. Este o fracțiune din dimensiune, va funcționa exact în același mod și va fi mai performant. Acesta este genul de lucruri pentru care tind să argumentez.

Chris: Trebuie să fim mai buni în alegerea instrumentului potrivit pentru job. Dacă mergeți cu o astfel de abordare, dacă ajungeți într-un punct în care un DOM virtual are de fapt sens, este mult mai ușor să portați Preact în React decât dacă îl utilizați pe al dvs. Asta e situația. Dacă sunteți cu adevărat îngrijorat de asta, veți avea și niște protecție pentru viitor.

Drew: Unii ar putea spune că ar putea argumenta că aceste cadre, lucruri precum Vue, React sunt atât de optimizate pentru performanță încât obțineți atât de multe beneficii acolo încât cu siguranță doar le asociați cu un manager de pachete într-un bundler pentru a vă asigura că" trimiteți doar codul pe care doriți. Sigur, ești deja mult înainte doar făcând asta?

Chris: Da. nu sunt de acord. Nu am prea multe de detaliat despre asta, în afară de... Cred că poate, dar nu chiar. Chiar și cu un bundler, mai aveți nevoie de acel nucleu React. Chiar și cu gruparea, va fi mai mare decât folosirea a ceva de genul Preact.

Chris: Drew, apreciez foarte mult că ai condus întrebarea despre asta. Pentru că unul dintre celelalte lucruri despre care vorbesc în cartea mea, The Lean Web, și discursul meu cu același nume, este modul în care aceste instrumente... Ai menționat gruparea, de exemplu. Unul dintre lucrurile pe care le facem pentru a ocoli impactul de performanță pe care îl luăm din folosirea acestui JavaScript este că punem și mai mult JavaScript în front-end pentru a ține seama de asta. Una dintre modalitățile prin care facem asta este managerii de pachete și pachetele de module.

Chris: După cum ați făcut aluzie... pentru cei dintre voi care nu știu, acestea sunt instrumente care vor... vor compila toate micile voastre biți JavaScript într-un singur fișier mare. Cele mai noi și cu atât mai multe... Nu vreau să le numesc grijulii. Dar cele mai noi vor folosi o funcție numită tree shaking, unde scapă de orice cod care nu este de fapt necesar. Dacă acel cod are unele dependențe care nu sunt folosite pentru lucrul pe care l-ați făcut de fapt, ei vor renunța la unele dintre acele lucruri pentru a vă face pachetele cât mai mici posibil. De fapt, nu este o idee groaznică, dar are ca rezultat acest lucru pe care îl numesc de obicei sănătatea dependenței, în care aveți această casă de cărți cu adevărat delicată a dependențelor pe deasupra dependențelor pe deasupra dependențelor.

Chris: Configurarea procesului necesită timp. Și oricine a rulat vreodată o instalare NPM și apoi a descoperit că o grămadă de dependențe erau depășite și a trebuit să petreacă o oră încercând să-și dea seama care dintre ele trebuie remediate și oh, este de fapt o dependență într-o dependență și nu Nu ai capacitatea de a te remedia singur. Este o chestie întreagă. Poate că funcționează pentru tine, dar aș prefera să-mi petrec timpul fără să-mi încurc încercând să-mi adun dependențele.

Chris: Am început să colectez tweet-uri de la oameni în care se plâng de timpul pierdut în fluxul lor de lucru. Unul dintre preferatii mei, Brad Frost în urmă cu câțiva ani, vorbea despre realizarea deprimantă a faptului că lucrul prin care te-ai încercat în JS modern ți-ar fi putut lua 10 minute în jQuery. Nu sunt cu adevărat un fan jQuery, dar simt această durere când vine vorba de lucrul cu cadre.

Chris: Cealaltă problemă cu multe dintre aceste instrumente este că încep să devină gardieni. Nu știu cât de mult vrei să te scufunzi sau nu în asta, Drew. Dar una dintre marile mele respingeri împotriva JS, toate lucrurile dintr-un flux de lucru. Mai ales când începi să spui: „Ei bine, dacă folosim deja JS pentru HTML, de ce să nu îl folosim și pentru CSS?” Începi să excluzi o mulțime de oameni cu adevărat talentați din procesul de dezvoltare. Este doar o pierdere foarte mare pentru proiect pentru comunitate în ansamblu.

Drew: Ei bine, cu siguranță sunt... Am început să iau React la începutul lui 2020, adăugând asta la setul meu de abilități. O fac acum de aproape șapte luni. Trebuie să spun că o parte în care sunt cel mai puțin încrezător este configurarea instrumentelor pentru începerea unui proiect.

Drew: Se pare că este foarte mult de lucru pentru a aduce ceva pentru Hello World, și sunt chiar mai multe pe care trebuie să le știi pentru ca acesta să fie gata de producție. Acest lucru trebuie să facă mai dificil să începeți dezvoltarea, dacă acest lucru este prezentat ca ceea ce ar trebui să faceți în 2020 pentru a învăța să fiți un dezvoltator web. Cineva care vine nou la el va avea o problemă reală. Va fi o adevărată barieră la intrare, nu-i așa?

Chris: Absolut. Cealaltă parte aici este că dezvoltatorii JavaScript nu sunt întotdeauna singurii oameni care lucrează la o bază de cod sau contribuie într-un mod semnificativ la acea bază de cod. Cu cât cunoașterea JavaScript este o cerință pentru a lucra cu o bază de cod, cu atât este mai puțin probabil ca acești oameni să poată participa efectiv la proiect.

Chris: Un exemplu despre care îmi place să vorbesc este WordPress, care a fost recent... Nu ar trebui să spun recent în acest moment. Au trecut câțiva ani acum. Dar și-au mutat din ce în ce mai mult stack-ul de back-end către JavaScript, departe de PHP, ceea ce nu este în mod inerent un lucru rău. Noul lor editor, Gutenburg, este construit pe React.

Chris: În 2018, consultantul principal de accesibilitate al WordPress, Rian Rietveld, al cărui nume aproape sigur l-am măcelărit... a demisionat foarte public de la poziționarea ei și a documentat motivul într-un articol cu ​​adevărat detaliat. Miezul problemei a fost că ea și echipa ei au fost însărcinate să auditeze acest editor pentru a se asigura că va fi accesibil. WordPress cuprinde acum 30% din web. Scopul lor este de a democratiza publicarea, astfel încât accesibilitatea este o parte foarte importantă a acesteia. Ar trebui să fie o parte importantă a oricărui proiect web. Dar pentru ei în special, este extrem de important. Întreaga sarcină a echipei ei este să se asigure... întreaga sarcină a echipei ei a fost să se asigure că acest editor va fi accesibil. Dar pentru că nici ea, nici nimeni din echipa ei nu avea experiență React și pentru că nu au putut găsi voluntari în comunitatea de accesibilitate cu acea experiență, i-a fost foarte dificil pentru ea și pentru echipa ei să-și facă munca.

Chris: Din punct de vedere istoric, ei puteau identifica erorile și apoi intra și le remediază. Dar odată cu noul flux de lucru bazat pe React, aceștia s-au redus la identificarea erorilor și apoi la depunerea biletelor. Ei au fost adăugați într-un backlog împreună cu toate celelalte solicitări de dezvoltare a caracteristicilor la care dezvoltau JavaScript. O mulțime de lucruri care ar fi putut fi rezolvate cu ușurință nu au ajuns în prima versiune.

Chris: În mai 2019, la aproximativ un an după ce Rian și-a dat demisia, a fost efectuat un audit detaliat al accesibilității pe Gutenburg. Raportul complet avea 329 de pagini. Numai rezumatul executiv avea 34 de pagini. A documentat 91 de erori legate de accesibilitate destul de detaliat. Multe dintre acestea au fost cu adevărat... Nu vreau să le numesc fructe simple, dar multe dintre ele erau lucruri de bază pe care echipa lui Rian le-ar fi putut rezolva și i-ar fi eliberat pe dezvoltatori să se concentreze pe dezvoltarea caracteristicilor. Asta e ceea ce se pare că au ajuns să facă, a petrecut mult timp dezvoltării caracteristicilor și a împinge aceste lucruri până mai târziu. Dar acea echipă este foarte importantă pentru proiect și ei au fost blocați brusc din proces din cauza unei alegeri tehnice.

Chris: Alex Russell este un dezvoltator al echipei Chrome. El a scris acest articol în urmă cu câțiva ani, intitulat The Developer Bait and Switch, unde a vorbit despre argumentul omul de paie al cadrelor. Această idee că aceste instrumente vă permit să vă mișcați mai repede și, din această cauză, puteți repeta mai rapid și oferi experiențe mai bune. Este ideea că o experiență de dezvoltator mai bună înseamnă o experiență de utilizator mai bună. Cred că acesta este un exemplu foarte clar al modului în care acest argument nu se desfășoară întotdeauna așa cum cred oamenii că se desfășoară. Este o experiență mai bună poate pentru unii oameni, nu pentru toată lumea.

Chris: Dezvoltatorii CSS, oamenii care lucrează la sisteme de proiectare, capacitatea lor de a crea instrumente pe care alții le pot folosi este uneori limitată de aceste alegeri de instrumente. Din experiența mea, am fost mai bun la CSS. S-a schimbat foarte mult în ultimii ani și nu sunt nici pe departe la fel de bun ca înainte. Din experiența mea, oamenii care sunt cu adevărat dezvoltatori CSS avansați... și vreau să spun asta în cel mai adevărat sens. Oamenii care lucrează pe CSS sunt dezvoltatori web corespunzători care lucrează pe un limbaj de programare. Este ceva foarte special, sau poate fi un lucru foarte specializat. Oamenii care sunt excepțional de buni la asta, din experiența mea, nu sunt întotdeauna foarte buni la JavaScript, deoarece ajungi să te scufunzi cu adevărat într-un singur lucru și aluneci puțin pe alte lucruri. Capacitatea lor de a lucra cu aceste tehnologii este, de asemenea, împiedicată, ceea ce este rău pentru că nu era cazul.

Chris: Când stiva a fost mai simplă, a fost mai ușor pentru oameni din mai multe discipline să participe la procesul de dezvoltare. Cred că asta e în detrimentul atât a lucrurilor pe care le construim, cât și a comunității în general, când nu mai este cazul.

Drew: Am găsit recent, într-un proiect, căutând modalități de a rezolva unele dintre problemele CSS, probleme de flux de lucru, lucrăm mai multe la proiect și dimensiunea pachetului crește și vechiul CSS nu este niciodată eliminat. A fost un proiect React, așa că ne-am uitat la unele dintre aceste abordări CSS în JavaScript pentru a vedea ce ar fi cel mai bine să folosim pentru a rezolva problemele pe care le-am avut. Ceea ce a devenit evident foarte repede este că nu există o singură soluție pentru a face acest lucru. Există zeci de moduri diferite în care poți face asta.

Drew: CSS în JS este o abordare generală, dar ați putea trece de la un proiect la altul și este complet influențat într-un mod complet diferit. Chiar dacă sunteți o persoană CSS și învățați o anumită abordare a unui proiect, este posibil ca acele abilități să nu fie oricum transferabile. Este foarte greu de văzut cum ar trebui cineva să investească prea mult timp în învățarea asta dacă nu se simte foarte confortabil cu JavaScript.

Chris: Da. Celălalt lucru interesant pe care cred că tocmai l-ați scos puțin este că, când vorbesc despre asta, una dintre cele mai mari piese de respingere pe care o primesc este că cadrele impun convențiile. Mergi cu Vanilla JavaScript, ai acest câmp verde-albastru cer, poți face orice vrei un fel de proiect. Cu React, există un mod React de a face lucrurile.

Chris: Dar unul dintre lucrurile pe care le-am găsit este că există abordări Reacty, dar nu există o modalitate strictă corectă de a face lucrurile cu React. Este unul dintre lucrurile pe care oamenii le iubesc la el. Este puțin mai flexibil, puteți face lucrurile în câteva moduri diferite dacă doriți. La fel și cu Vue. Puteți folosi acel lucru bazat pe HTML în cazul în care aveți proprietățile dvs. chiar în HTML și Vue le înlocuiește, dar puteți utiliza, de asemenea, un tip de sintaxă mai asemănătoare cu JSX, dacă preferați.

Chris: Am auzit că mai mulți oameni se plâng de când învață React, una dintre marile probleme este că Google cum să faci X în React și primești o duzină de articole care îți spun o duzină de moduri diferite în care ai putea face acest lucru. Asta nu înseamnă că nu pun niște balustrade pe un proiect. Nu cred că este atât de clar ca: „Am ales un cadru. Acum, acesta este modul în care construiesc cu el.” Sincer să fiu, nu știu că nici asta e ceva neapărat pe care mi-aș dori. Nu cred că ți-ai dori acelea strâns închise... poate unii oameni o fac. Dar dacă apreciezi asta ca pe un beneficiu, nu cred că este atât de pronunțat pe cât o spun oamenii uneori.

Chris: Ai intrat într-o chestie interesantă, deși chiar acolo, în care ai menționat CSS-ul care nu mai este necesar. Cred că acesta este unul dintre lucrurile legitim interesante pe care le poate obține ceva de genul CSS și JS... sau legarea CSS-ului de componente JavaScript într-un fel, este că dacă acea componentă dispare, CSS-ul, de asemenea, în teorie, dispare cu ea. Multe din asta mi se pare ca aruncarea ingineriei la problemele oamenilor. În mod invariabil, ești încă dependent de oameni undeva de-a lungul liniei. Asta nu înseamnă să nu folosiți niciodată aceste abordări, dar cu siguranță nu sunt singura modalitate de a rezolva această problemă.

Chris: Există instrumente pe care le puteți folosi pentru a vă audita HTML și pentru a scoate stilurile care nu sunt folosite chiar și fără a utiliza CSS și JavaScript. Poți scrie CSS „modul de modă veche” și totuși să faci liniște stilurilor nefolosite. Există abordări de creație pentru CSS care vă oferă un CSS într-o ieșire asemănătoare JS și vă păstrează foaia de stil mică, fără a scoate aceste nume de clasă idioate, care nu sunt citite, pe care le obțineți uneori cu CSS și JS. Ca X2354ABC, sau doar aceste cuvinte prostii care se scuipă.

Chris: Aici încep să intru cu adevărat în bătrânul care țipă la un fel de chestie de nor. Chiar îmi arăt vârsta de dezvoltator aici. Dar da, nu este neapărat că aceste lucruri sunt rele și sunt create pentru a rezolva probleme legitime. Uneori simt că există un pic de... dacă este suficient de bun pentru Facebook, este destul de bun pentru noi, ceva ce se întâmplă cu acestea. Ei bine, Facebook folosește acest instrument. Dacă suntem un adevărat program de inginerie... echipă, departament, organizație, ar trebui și noi. Nu cred că este neapărat modul corect de a gândi. Pentru că Facebook se ocupă de probleme pe care tu nu le faci și invers. Dimensiunea și amploarea a ceea ce lucrează sunt doar diferite și este în regulă.

Drew: Exact. Văd că unele dintre aceste lucruri, cum ar fi CSS și JavaScript, sunt aproape ca un polyfill. Avem probleme legitime, avem nevoie de o modalitate de a le rezolva. Tehnologia nu ne oferă încă o modalitate de a o rezolva. Poate că în timp ce așteptăm ca platforma web să evolueze și să rezolvăm această problemă, acest lucru pe care îl facem chiar acum cu JavaScript ne va ajuta și vom fi bine. Știm că e rău. Știm că nu este o soluție grozavă, dar ne ajută acum. Și sperăm că într-un timp îl putem scoate și folosi soluția nativă.

Chris: E foarte amuzant că aduci în discuție asta. Pentru că, literalmente, aseară, mă uitam la o discuție a lui Jeremy Keith de anul trecut despre aplicațiile web progresive. Dar vorbea despre cum, cu câteva decenii în urmă, încerca să convingă oamenii să folosească JavaScript. Ceea ce pare ridicol la acea vreme, dar JavaScript era acest lucru nou. Le-a arătat oamenilor cum poți face lucruri interesante, cum ar fi să schimbi culoarea unui link pe hover cu acest nou... Pare absurd că ai avea nevoie de JavaScript pentru asta acum, pentru că asta face CSS pentru tine. Dar lucruri precum atributul focus sau proprietatea pur și simplu nu existau la momentul respectiv.

Chris: Unul dintre lucrurile pe care le-a spus în discuție și care cred că a rezonat cu adevărat cu mine este că JavaScript, în multe feluri, deschide acele căi pentru vaci. Este acest limbaj foarte flexibil și deschis pe care îl putem folosi pentru a crea sau a integra funcții care nu există încă. Și apoi, în cele din urmă, browserele ajung din urmă și implementează aceste funcții într-un mod mai nativ. Dar este nevoie de timp. Înțeleg perfect ce spui despre asta. Nu este soluția perfectă, dar este ceea ce avem acum.

Chris: Cred că, pentru mine, cea mai mare diferență între umpluturi polivalente și unele dintre aceste soluții este că umpluturile polivalente sunt concepute pentru a fi îndepărtate. Dacă am o caracteristică pe care vreau să o implementez pe care browserul nu o acceptă încă, dar există un fel de specificație pentru aceasta și scriu un polyfill... odată ce browserele ajung din urmă, pot extrage acel polyfill și nu trebuie să fac schimba orice. Dar atunci când mergi pe calea utilizării unora dintre aceste instrumente, scoaterea lor înseamnă rescrierea întregii baze de cod. Este foarte scump și problematic. Asta nu înseamnă să nu le folosim niciodată, dar cred cu tărie că ar trebui să ne gândim la alegerea instrumentelor care pot fi scoase cu ușurință mai târziu. Dacă nu mai avem nevoie de ele sau platforma ajunge din urmă, nu necesită o rescriere uriașă pentru a le scoate.

Chris: Așadar, ajungând la asta, avem o grămadă de stiluri pe care nu le mai folosim, de aceea personal aș prefera o tehnologie de instrumente de construcție care auditează CSS-ul tău în raport cu marcajul randat și scoate lucrurile de care nu ai nevoie. Pentru că pe drum, dacă o platformă ajunge din urmă, puteți scoate acea bucată din instrumentul de construcție fără a fi nevoie să schimbați totul. Este doar să mărească ceea ce aveți deja, în timp ce CSS și JS nu vă oferă același tip de beneficiu. Mă aleg doar pe acesta, dar mă gândesc la multe dintre aceste tehnologii într-un mod mai larg.

Chris: Simt că lucruri precum React sau Vue probabil pavează niște căi de vaca pe care browserele le vor ajunge în cele din urmă și probabil că vor folosi abordări similare, dacă nu aceleași, așa că ar putea fi mai puțină rescriere implicată acolo. O mulțime de lucruri din ecosistem care sunt conectate în jurul ei pot fi mai puțin.

Drew: Cred că este corect, nu-i așa, că platforma web se mișcă încet și cu grijă. Crezi că în urmă cu cinci ani, cu toții puneam Carusele JavaScript pe paginile noastre. Erau peste tot. Toată lumea implementa carusele JavaScript. Dacă platforma web ar fi sărit și ar fi implementat o soluție Carousel pentru a satisface această nevoie, nu ar fi stat acolo fără să o folosească nimeni, deoarece oamenii nu mai fac asta cu Carusele. Pentru că a fost doar un moft, o tendință de design. Pentru a contracara acest lucru și pentru a împiedica platforma în sine să devină umflată și să devină o problemă care trebuie rezolvată, trebuie să se miște într-un ritm mult mai constant. The upshot of that is HTML that I wrote in 1999 still works today because of that slow process.

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

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

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

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

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

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

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

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

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

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

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

Chris: Yep.

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

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

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

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

Chris: Yes.

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

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

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

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

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

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

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

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

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

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

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

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

Chris: Unul dintre celelalte lucruri în care nu am intrat atât de mult pe cât mi-aș fi dorit, dar cred că este foarte important, este că platforma a ajuns din urmă într-un mod foarte mare în ultimii câțiva ani. Îmbrățișarea acestui lucru pe cât posibil va avea ca rezultat o experiență web pentru oameni, care este mai rapidă, mai puțin fragilă, care este mai ușor de construit și de întreținut, deoarece necesită mai puține dependențe, cum ar fi folosirea a ceea ce îți oferă browserul. -cutia. Aveam nevoie de jQuery pentru a selecta lucruri precum clasele. Acum browserele au modalități native de a face asta. Oamenilor le place JSX pentru că vă permite să scrieți HTML în JavaScript într-un mod mai perfect. Dar avem și literale șablon în Vanilla JavaScript care vă oferă același nivel de ușurință fără dependență suplimentară. HTML-ul în sine poate înlocui acum o mulțime de lucruri care înainte necesitau JavaScript, ceea ce este absolut uimitor.

Chris: Am vorbit puțin despre... acesta este o chestie CSS, dar trece cu mouse-ul peste link-uri și despre modul în care aceasta necesita JavaScript. Dar folosind lucruri precum detaliile și elementele de rezumat, puteți crea dezvăluiri, cum ar fi extinderea și restrângerea sau elementele acordeon în mod nativ, fără a fi nevoie de scripting. Puteți face intrări de completare automată folosind doar un... Nu ar trebui să spun doar, urăsc acest cuvânt. Dar folosind un element de intrare umil și apoi un element de listă de date care este asociat cu acesta, cu unele opțiuni. Dacă ești curios despre cum funcționează oricare dintre aceste lucruri la vanillajstoolkit.com, am o grămadă de lucruri JavaScript pe care ți le oferă platforma. Dar, de asemenea, am obișnuit să solicite JavaScript și acum nu am lucruri care ar putea fi interesante dacă doriți ca niște mostre de cod să meargă împreună cu asta.

Chris: Pe partea CSS a lucrurilor, cel mai popular plugin Vanilla JS al meu vreodată este această bibliotecă care vă permite să animați derularea în jos până la link-urile ancorate. Este foarte mare. Este cea mai grea bucată de cod pe care am avut de scris vreodată. Și acum este complet înlocuit cu o singură linie de CSS, comportament de defilare lină. E mai performant. E mai ușor să scrii. Este mai ușor să-i modifici comportamentul. Este doar o soluție generală mai bună.

Chris: Unul dintre celelalte lucruri pe care mi-aș dori să le facem mai mult este să ne sprijinim pe aplicații cu mai multe pagini. Mă simt puțin îndreptățit aici, pentru că am văzut recent un articol de la cineva de la Google care de fapt susține și acum această abordare. Am crezut că a fost destul de interesant, având în vedere acest cadru unghiular uriaș și apoi... toate lucrurile, boom, pe care Google le-a început cu câțiva ani în urmă. E mișto să-i văd revenind la asta. Folosind lucruri precum generatoare de site-uri statice și servicii extraordinare precum Netlify și memorarea în cache CDN, puteți crea experiențe web incredibil de rapide pentru persoanele care folosesc fișiere HTML individuale pentru toate vizualizările dvs. Așa că te sprijini pe unele dintre aceste lucruri ieșite din cutie.

Chris: În situațiile în care acest lucru nu este realist pentru dvs., în care aveți nevoie de mai mult JavaScript, aveți nevoie de un fel de bibliotecă, poate aruncând o privire mai întâi la abordările mai mici și mai modulare, în loc să mergeți doar la giganții industriei. În loc de React, ar funcționa Preact? În loc de unghiular... Adică, în loc de Vue, mai degrabă, ar funcționa Alpine JS? Există, de asemenea, acest pre-compilator foarte interesant, numit Svelt, care vă oferă o experiență ca un cadru și apoi compilează tot codul în Vanilla JavaScript. Așadar, obțineți aceste pachete foarte mici, care au exact ceea ce aveți nevoie și nimic altceva. În loc de CSS și JavaScript, ați putea introduce un linter CSS terță parte care să vă compare HTML-ul cu CSS-ul dvs. și să scoată lucrurile care au rămas acolo din întâmplare? Ar funcționa un alt mod de a crea CSS-ul dvs., cum ar fi CSS orientat pe obiecte de Nicole Sullivan? Nu am apucat să vorbim despre asta, dar este un lucru foarte grozav pe care oamenii ar trebui să-l verifice.

Chris: Și apoi cred că poate a treia și cea mai importantă piesă aici, deși este mai puțin o abordare specifică și mai mult doar un lucru pe care aș vrea să-l țină cont de mai mulți oameni, este că web-ul este pentru toată lumea. Multe dintre instrumentele pe care le folosim astăzi funcționează pentru oameni care au conexiuni bune la internet și dispozitive puternice. Dar nu funcționează pentru persoanele care sunt pe dispozitive mai vechi, au conexiuni la internet neregulate. Nu sunt doar oameni din zonele în curs de dezvoltare. Este vorba și de oameni din Marea Britanie, în anumite părți ale SUA, unde avem conexiuni la internet absolut abisale. Mijlocul țării noastre are internet foarte lent. Știu că există locuri într-o parte a Londrei în care nu pot conecta o nouă bandă largă din motive istorice, așa că ai rămas cu aceste vechi conexiuni la internet care sunt foarte proaste. Există astfel de locuri în toată lumea. Ultima dată când am fost în Italia, același lucru. Acolo internetul era oribil. Nu stiu daca s-a schimbat de atunci.

Chris: Lucrurile pe care le construim astăzi nu funcționează întotdeauna pentru toată lumea și asta e păcat. Pentru că viziunea web, ceea ce îmi place la el, este că este o platformă pentru absolut toată lumea.

Drew: Dacă ascultătorii doresc să afle mai multe despre această abordare, ați intrat în multe detalii în cartea dvs., The Lean Web. Și asta este disponibil online. Este o carte fizică sau o carte digitală?

Chris: Este un pic din ambele. Ei bine, nu. Cu siguranță nu este o carte fizică. Accesați leanweb.dev. Puteți citi totul gratuit online. Puteți, de asemenea, dacă doriți, există versiuni EPUB și PDF disponibile pentru o sumă foarte mică de bani, am uitat cât de mult acum. Nu m-am mai uitat la el de ceva vreme. Totul este gratuit online, dacă vrei. De asemenea, puteți urmări o discuție pe acest subiect în care intru în mai multe detalii dacă doriți.

Chris: Dar am creat și o pagină specială doar pentru ascultătorii Smashing Podcast la gomakethings.com/smashingpodcast, pentru că sunt foarte creativ în a numi lucruri. Aceasta include o grămadă de resurse în plus față de carte, în jurul lucrurilor despre care am vorbit astăzi. Se leagă de multe dintre tehnicile diferite pe care le-am acoperit, alte articole pe care le-am scris, care aprofundează unele dintre aceste subiecte și mă extind puțin asupra gândirii mele. Dacă oamenii vor să învețe mai multe, acesta ar fi probabil cel mai bun loc pentru a începe.

Drew: E grozav. Mulțumesc. Am învățat totul despre Lean Web. Despre ce ai învățat în ultima vreme, Chris?

Chris: Da, câteva lucruri. Am făcut aluzie la asta puțin mai devreme, urmărind videoclipul lui Jeremy pe aplicațiile web progresive. Am amânat să învăț cum să scriu propria mea aplicație web progresivă de câțiva ani, deoarece nu aveam o nevoie specifică de nimic cu care lucram. Am aflat recent de la unul dintre studenții mei, care se află în Africa de Sud, că s-au confruntat cu întreruperi de curent din cauza unor lucruri pe care le-au întâmplat acolo. Drept urmare, ea nu poate lucra la unele dintre proiectele pe care le-am făcut împreună în mod regulat, deoarece nu mai poate accesa portalul de învățare și nu poate urma.

Chris: Pentru mine, acum construirea unei experiențe în care să funcționeze, chiar dacă cineva nu are internet, a devenit o prioritate mai mare decât... Mi-am dat seama că poate a fost înainte, așa că tocmai am început să cercetez asta și sper să o pun la cap. următoarele câteva săptămâni. Vom vedea. Resursele lui Jeremy Keith în acest sens au fost totuși o salvare absolută. Mă bucur că există.

Chris: Știu, Drew, ai menționat că unul dintre motivele pentru care îți place să pui această întrebare este să arăți că oamenii, indiferent cât de experimentați sunt, învață mereu. Doar o mică anecdotă legată. Sunt dezvoltator web de aproximativ opt ani, cred. Încă trebuie să folosesc pe Google proprietatea CSS pentru a face lucrurile italice, literalmente de fiecare dată când o folosesc. Din anumite motive, creierul meu folosește implicit decorarea textului, chiar dacă acesta nu este cel potrivit. Voi încerca câteva combinații de lucruri diferite și întotdeauna am un cuvânt greșit de fiecare dată. De asemenea, uneori scriu italic în loc de italic. Da. Dacă cineva de acolo simte vreodată că, oh, nu voi învăța niciodată chestiile astea... doar să știi că, indiferent cât de experimentat ești, există întotdeauna ceva cu adevărat de bază pe care îl găsești pe Google din nou și din nou.

Drew: Sunt dezvoltator web de 22, 23 de ani și trebuie să caut pe Google diferitele proprietăți pentru Flexbox, de fiecare dată. Deși îl folosesc de 23 de ani. Dar da, unele lucruri pur și simplu... probabil că vor fi mai multe pe măsură ce îmbătrânesc.

Chris: Da. Sincer, am ajuns să construiesc un întreg site web cu lucruri pe care le folosesc pe Google din nou și din nou, doar pentru a avea o referință mai ușoară de copiere și lipire, pentru că era mai ușor decât Google.

Drew: Nu este o idee rea.

Chris: Ăsta e genul de leneș care sunt. Voi construi un întreg site web pentru a mă salva ca trei secunde de Google.

Drew: Dacă dvs., ascultătorul, doriți să aflați mai multe de la Chris, puteți găsi cartea sa pe web la leanweb.dev și buletinul informativ Sfaturi pentru dezvoltatori și multe altele la gomakethings.com. Chris este pe Twitter la Chris Ferdinandi. Și puteți verifica podcast-ul lui la vanillajspodcast.com sau de oriunde vă obțineți de obicei podcasturile. Mulțumim că ni ești alături astăzi, Chris. Ai cuvinte de despărțire?

Chris: Nu. Mulțumesc foarte mult că m-ai primit, Drew. Am avut un timp absolut uluitor. Asta a fost o grămadă de distracție. Apreciez foarte mult oportunitatea de a veni pe chat.