Smashing Podcast Episodul 45 cu Jeremy Wagner: Ce este JavaScript responsabil?

Acest episod a fost susținut cu amabilitate de dragii noștri prieteni de la Wix, platforma pentru profesioniști pentru a construi site-uri pentru clienți, a gestiona proiecte complexe și a dezvolta afaceri online. Mulțumesc!

În acest episod, vorbim despre JavaScript responsabil. Ce înseamnă pentru cod să fie responsabil și cum ar trebui să abordăm proiectele diferit? Am vorbit cu expertul Jeremy Wagner pentru a afla.

Afișați note

• Site JavaScript responsabil
• Cumpărați cartea de la A Book Apart
• Site-ul personal al lui Jeremy
• Jeremy pe Twitter

Actualizare săptămânală

• Legea lui Fitts In The Touch Era scris de Steven Hoober
• Web Design Done Well: Perfectly inutile scris de Frederick O'Brien
• Tot ce vrei să știi despre crearea interfețelor vocale cu utilizatorul scris de Nick Babich și Gleb Kuznetsov
• Implicațiile WordPress Joining The Block Protocol scris de Leonardo Losoviz
• Gânduri despre Markdown scris de Knut Melvar

Transcriere

Drew McLellan: Este un scriitor tehnic, un tocilar de performanță web, dezvoltator și vorbitor, care lucrează în prezent la Google. A scris pentru A List Apart, CSS-Tricks și Smashing Magazine și este autorul unui nou titlu, Responsible JavaScript for A Book Apart. Deci știm că este un tehnician și un comunicator priceput, dar știai că vrea să facă ocolul globului pe o placă de standup paddle? Prietenii mei zdrobitori, vă rog bun venit lui Jeremy Wagner. Salut Jeremy, ce mai faci?

Jeremy Wagner: Sunt zdrobitor. Ce mai faci?

Drew: Sunt foarte bun. Mulțumesc. Am vrut să vă vorbesc astăzi despre această idee de JavaScript responsabil. Este aceasta un fel de abordare sau tehnică nouă sau vorbiți literalmente despre utilizarea responsabilă a JavaScript?

Jeremy: Vorbesc literalmente despre utilizarea responsabilă a JavaScript. Deci, conform arhivei HTTP, am observat o creștere medie de aproape 58% a cantității de JavaScript descărcate de dispozitivele mobile de la aproximativ 290 de kiloocteți la aproape 500 de kiloocteți în ultimul an.

Drew: Uau.

Jeremy: Așadar, când vorbesc despre utilizarea responsabilă a JavaScript, este un prim fel de abordare a utilizatorului care trebuie să spună... de a evalua critic ce construim și este scopul a ceea ce construim servit de practicile moderne de dezvoltare web, deci a vorbi. Și bănuiesc că este un fel de... poate că nu iubesc, dar nu m-am bucurat de dezvoltarea web modernă, dar un produs secundar al dezvoltării web moderne este că este foarte ușor să adăugați dependențe la proiecte. Totul este o instalare MPM departe și fiecare instalare MPM are un cost, costul respectiv variază. Dar ceea ce vedem este că în acele date de arhivă HTTP, percentila 95... adică cele 5% dintre experiențele care sunt cele mai lente... sau nu cele mai lente, dar care oferă cel mai mult JavaScript, care a crescut în ultimul an cu aproximativ 875 kilobytes până la aproximativ 1,4 megaocteți.

Drew: Uau.

Jeremy: Deci, este o cantitate enormă de JavaScript care este transferată și are atât performanța de încărcare, cât și implicațiile de rulare.

Drew: Deci ai menționat performanța acolo. Se pare că experiența web modernă din punctul meu de vedere este ca 10% HTML și CSS și 90% JavaScript. Și trebuie să existe un fel de considerații de performanță în acest sens. Adică, ați vorbit despre cantitatea de date pe care o transferăm, dar există și alte considerații de performanță atunci când aveți o mulțime de JavaScript.

Jeremy: Corect. Deci, având o conexiune lentă la internet și știi... unde locuiesc eu în Statele Unite, dacă mergi suficient de departe în afara unui oraș important, devine cam dificil, în funcție de unde mergi... să faci față cât de lent poate fi internetul. un fel de aceste zone rurale și este semnificativ pentru oamenii care trăiesc în zone ca aceasta. Așadar, aspectul performanței de încărcare este deja destul de provocator atunci când începeți să expediați megaocteți de JavaScript, dar este posibil să aveți de-a face și cu cineva care nu are un iPhone... cum ar fi un iPhone X sau ca un iPhone 13.

Jeremy: S-ar putea să fie doar pe un telefon funcțional sau doar ca un telefon Android cu buget redus, încercând doar să navigheze prin viață. Adică, gândește-te la lucruri precum online banking, asistență pentru șomaj sau alte asistențe guvernamentale, portaluri de genul ăsta pentru aplicații. Învățare online, există doar o mulțime de locuri în care JavaScript excesiv poate avea într-adevăr un efect dăunător pentru oamenii care ar putea să nu fie suficient de norocoși să locuiască în zone metropolitane mari sau chiar în zone metropolitane care nu sunt bine deservite de internet în bandă largă și pentru cei cu dispozitive mai lente. . Cred că, ca dezvoltatori, avem această tendință să ne uităm la... cumpărăm MacBook-uri sau aceste dispozitive de ultimă generație și uneori nu prea vedem unde pot apărea aceste probleme atunci când folosim JavaScript în exces.

Drew: Și, așa cum ați menționat aici, uneori indivizii care au cel mai mult de pierdut prin faptul că nu pot accesa un serviciu sunt penalizați de astfel de lucruri. Acei oameni fără conexiuni rapide de date sau fără dispozitive foarte capabile accesează uneori servicii care înseamnă totul pentru... înseamnă tot ceea ce pot obține pentru ei. Deci, devine aproape o problemă a drepturilor omului în anumite privințe.

Jeremy: Da. Adică, avem tendința de a vedea performanța web încadrată în termeni de valoare a afacerii. Am fost consultant de performanță pentru unele e-com și ca o mare companie alimentară, o mare e-com... ca un magazin, ca o priză de electronice și este foarte tentant să fac asta, nu? Pentru că atunci când lucrezi pentru o afacere, vreau să spun, evident că vrei ca finanțele să fie sănătoase, iar performanța web cred că joacă un rol în acest sens. Cred că există o serie de studii de caz care demonstrează acest lucru. Cu toate acestea, există acel aspect uman și chiar și pentru afaceri, cum ar fi magazinele alimentare și așa ceva. Da, sunt bazate pe venituri. Ei vor să aibă finanțe sănătoase și, prin urmare, performanța web face parte din asta, dar servesc și unei nevoi critice, nu? Parcă trebuie să mănânci, nu?

Jeremy: Și, ca și cum unii oameni s-ar putea să fie leși acasă dintr-un motiv sau altul. S-ar putea să nu se poată urca cu ușurință într-o mașină. S-ar putea să nu aibă mașină. Deci se bazează pe aceste servicii pentru a obține întreținere, dar mai mult decât atât, asistență dacă au nevoie de ea și mai ales le place intervenția în criză și genul ăsta de lucruri. Nu cred că este îngrozitor de exagerat să spun că un partener care a fost abuzat și dat afară din casă s-ar putea întoarce la smartphone-ul său și ar putea să lovească Google pentru a încerca să găsească un portal pentru intervenție și asistență în situații de criză. Și JavaScript poate împiedica aceste tipuri de obiective și să servească acele nevoi umane. Când avem tendința de a ne sprijini pe el doar puțin prea mult.

Drew: Vreau să spun, am văzut un fel de imagine în ultimele 18 luni sau cam asa ceva, cu COVID și oamenii care au intrat în izolare și, după cum spuneți, au nevoie să comande alimente pentru a fi livrate. Web-ul devine un colac de salvare pentru ei în acel moment. Se simt sub vreme, nu pot să-și părăsească cazarea pentru că se izolează și trebuie să-și facă rost de mâncare și trebuie să-și facă rost de provizii esențiale. Deci da, cred că este o parte din ce în ce mai importantă din viața de zi cu zi pentru noi toți.

Jeremy: Exact. Și revenind la genul de poveste despre dispozitiv, Tim Kadlec a scris o piesă uimitoare cu câțiva ani în urmă, cred că a fost doi ani, poate trei ani în urmă, dar se numea Prioritizing the Long Tail of Performance. Și când te uiți la asta... așa că în limbajul performanței web, vorbim cam despre datele de laborator versus datele de pe teren. Și datele de laborator sunt ca atunci când rulați Lighthouse sau aruncați un site web la un test de pagină web pentru a vedea cum merge. Toate acestea sunt instrumente cu adevărat utile, dar când te uiți la acele date de câmp, începi cu adevărat să obții o imagine mai mare și o imagine mai mare a cine este cu adevărat publicul tău. Și în acest articol, Tim Kadlec vorbește despre ce înseamnă să prioritizezi coada lungă a performanței. Adică toate aceste dispozitive care... poate nu sunt la fel de robuste și la fel de puternice precum dispozitivele pe care le avem noi, în calitate de dezvoltatori.

Jeremy: Și ideea din spatele acelui articol este că, dacă ne putem concentra pe acea 90-a sau 95-a percentilă pe care suntem... și să îmbunătățim acea experiență pentru acești oameni, vom construi un web mai rapid pentru toată lumea, inclusiv pentru cei de pe dispozitive rapide. Și atacați un punct de date despre asta în SUA și acesta este doar de la statcounter.com. Ceva de genul 28 de puncte... aproximativ 28% dintre oameni sunt pe un dispozitiv iOS pe care acest instrument îl capturează. Și aproximativ 21% dintre ei sunt Android. Și Android tinde să reprezinte o bună parte din acea coadă lungă de dispozitive, deoarece Android nu este monolitic. Mai mulți producători de dispozitive produc telefoane Android, dar pentru a contrasta asta cu lumea, pentru că lumea este mai mult decât Statele Unite, aproximativ 16% dintre oameni folosesc iOS și aproximativ 41% dintre cei care sunt pe Android. Deci, chiar plătește să prioritizezi acele experiențe mai lente sau potențial mai lente.

Drew: Am citit în cartea ta despre accelerarea termică a dispozitivului, ceea ce nu este ceva la care m-am gândit vreodată înainte. Care sunt preocupările acolo?

Jeremy: Preocupările acolo, și nu sunt ca un expert în microprocesoare în niciun fel. Sunt doar dezvoltatorul web care probabil scrie puțin prea mult, dar... deci ideea din spatele throttlingului termic și asta există în toate sistemele, nu doar ca telefoanele și tabletele, este că un microprocesor va... atunci când preia sarcini excesive de lucru sau într-adevăr doar sarcini de lucru în general, produsul rezidual al acelei lucrări este căldura. Și astfel dispozitivele au modalități de a atenua acest lucru. Așa cum laptopul tău are atât un dispozitiv de răcire pasiv, cât și unul activ.

Jeremy: Așa că un dispozitiv de răcire pasiv este ca un radiator sau un fel de distribuitor de căldură. Și partea activă a acesteia este ca un ventilator pentru a dispersa mai eficient căldura. Unele, cum ar fi build-urile personalizate de PC-uri, ar putea folosi precum răcirea lichidă, care este un fel de exemplu relativ extrem, dar un telefon mobil nu are asta, pentru că unde o să potriviți cu adevărat un ventilator în toate acestea, dacă portabilitatea este un fel de dvs. lucru, nu?

Jeremy: Deci, pentru ca aceste dispozitive să facă față acestor sarcini grele de lucru, ele pot reduce artificial viteza procesorului, cum ar fi reducerea frecvenței de ceas până când acel dispozitiv intră într-o stare în care rata de ceas poate fi crescută. Și asta are implicații pentru că dacă mesteci prin tone și tone și tone și tone de JavaScript, ai ca aceste bucăți mari care vin pe fir, ei bine, asta demarează procesarea, nu? Deci este multă procesare prin evaluare și analiză în compilare și apoi execuție. Și dacă faci asta cu un megaoctet sau doi de JavaScript și ai o mulțime de alte procese care se desfășoară în fundal, cum ar fi diferite file, acel tip de lucru care, care îți poate pune starea... asta crește probabilitatea ca dispozitivul poate intra într-o stare de accelerare termică, ceea ce înseamnă că va fi mai puțin capabil să-și asume acel lucru suplimentar.

Drew: Deci este un fel de buclă de feedback negativ. nu-i asa? Îi dai dispozitivului multă muncă de făcut. Devine foarte fierbinte și apoi este mai puțin capabil să execute efectiv acea lucrare, deoarece trebuie să accelereze înapoi.

Jeremy: Corect. Și din nou, nu sunt un expert în microprocesoare. Sunt sigur că dacă, dacă, dacă un inginer care a fost cu adevărat familiarizat cu acest lucru, ar putea probabil să mă corecteze cu privire la unele dintre detalii, dar ideea generală este că da, pe măsură ce presiunea din mediu crește, dispozitivul este mai puțin capabil să face față acestor sarcini grele până când presiunea scade.

Drew: deci scriem JavaScript pentru întregul spectru de dispozitive de la cel mai recent Apple M1 Max este noul procesor, nu-i așa? Laptop-uri până la dispozitive care abia au suficientă memorie RAM de lucru pentru a reda o pagină web. Dar web-ul nu a început așa, ascultătorii mai tineri ar putea fi interesați să știe că obișnuiam să construim experiențe web interactive fără JavaScript. Cadrul nostru mare și greu va fi distrugerea noastră.

Jeremy: Aș spune că cadrele au un timp și un loc, iar cei care citesc un fel de fragmente din această carte s-ar putea să-și facă ideea că sunt anti-cadru. Și cu siguranță critic mai multe cadre, dar ele servesc un scop și este posibil să le utilizez într-un mod care păstrează o experiență bună de utilizator sau poate duce la o experiență bună pentru utilizator. Dar ceea ce nu cred că facem suficient este să evaluăm în mod critic aceste cadre în ceea ce privește modul în care dăunează... performanței timpului de rulare, nu? Deci tipul de lucruri despre care vorbesc, în cazul în care, dacă dai clic pe un buton, și dispozitivul durează o secundă, poate două pentru a răspunde la acea intrare, pentru că se întâmplă atât de multe în fundal. Aveți chestii JavaScript terță parte, cum ar fi colectarea de analize și apoi aveți ca și alte lucruri care rulează pe fire.

Jeremy: Și dacă nu evaluezi critic performanța de rulare a unui cadru, s-ar putea să lași câteva oportunități pe masă pentru a-ți servi mai bine utilizatorii. Deci, un exemplu bun, îmi place întotdeauna să folosesc este reacționează versus pre-acționează. Am cam bătut toba asta de ceva vreme. Am scris un articol pentru CSS-Tricks cu ceva timp în urmă, care a descris o interacțiune de bază a clicului, cum ar fi un meniu de navigare mobil. Și sună banal, dar ceea ce descoperiți este că, pe toate dispozitivele, reactia oferă o performanță mai bună la timp de rulare, dar are practic același API. Există diferențe, există câteva diferențe și chestii care pot fi tapetate cu pre-act compat, dar atât de simplu... și nu ar trebui să spun o alegere simplă, ci acea alegere, acea alegere fundamentală poate fi diferența dintre o experiență care funcționează foarte bine pentru toți utilizatorii sau cel puțin pentru majoritatea utilizatorilor, sau o experiență care funcționează bine doar pentru unii. Sper că a avut ceva sens.]

Drew: Adică, cu toate cadrele și instrumentele de construcție, par să se îmbunătățească tot timpul în a face lucruri precum scuturarea copacilor și optimizarea pachetelor pe care le expediază și modul în care sunt apoi livrate în browser. Când utilizați cadre mari, credeți că există un punct de basculanță în care scrieți o aplicație atât de mare, atât de mult cod propriu, încât cadrul vă permite să livrați mai puțin cod din cauza abstracției sale?

Jeremy: Este o întrebare dificil de răspuns. Un aspect al acestuia este că cadrul în sine reprezintă o cantitate de cod pe care nu o puteți optimiza niciodată. Deci, având ca un cadru subțire, ca pre-act sau orice număr de asemenea... Sau ca vraja, de exemplu, asta ajută foarte mult. Dar problema pe care am văzut-o și cred că datele din arhiva HTTP susțin acest punct este că de fiecare dată când avem aceste progrese în microprocesoare și rețele care devin mai rapide este că avem tendința de a consuma acel câștig, nu?

Jeremy: Avem tendința de a fi doar pe această bandă de alergare unde nu avansăm niciodată cu adevărat. Și nu știu, de parcă nu sunt clarvăzător despre istoria... sau îmi pare rău, cum arată viitorul cadrelor. Sunt sigur că există câteva câștiguri de eficiență care pot fi adunate. Dar ceea ce vedem în domeniu în ceea ce privește cât de mult JavaScript este brut... este folosită doar cantitatea brută de JavaScript. Nu-mi spune că aceasta este o problemă din care ne putem automatiza cumva ieșirea. Cred că trebuie să... trebuie să fim ființe umane și să intervenim și să luăm decizii care sunt în interesul utilizatorilor. Altfel, nu ne văd coborând din această bandă de alergare, poate nu în cariera mea, dar nu știu.

Drew: În carte vorbiți despre site-uri web și aplicații web și despre modul în care înțelegerea diferenței și cu care lucrați vă ajută să vă alegeți strategia pentru modul în care dezvoltați și optimizați. Povestește-ne puțin despre asta.

Jeremy: Aceasta este o întrebare foarte bună. Și scriu despre asta în articolul cu titlul eponim pe care l-am scris pentru A List Apart, numit Responsible JavaScript Part One, care este un fel de preludiul acestei cărți. Este că încărcăm foarte mult în această terminologie. Ca și scriitor tehnic, văd că cei doi se obișnuiesc într-un fel interschimbabil. Ceea ce văd este cu site-urile web, implicația este că este un fel de experiență cu mai multe vârste, nu? Este o colecție de documente. Acum, un document... acele documente ar putea avea funcționalități încorporate ca aceste insule mici, așa cum a fost termenul în ultima vreme, aceste insule mici de funcționalități care permit oamenilor să facă lucrurile.

Jeremy: Dar apoi există ca aplicațiile web și aplicațiile web au cam această conotație de funcționalitate de aplicație nativă. Deci vorbim de aplicații cu o singură pagină, vorbim de cantități mari de JavaScript pentru a genera interactivitate complexă. Și există momente în care modelul aplicației web are sens. De exemplu, Spotify este un bun exemplu în acest sens. Funcționează mai bine ca aplicație web. Nu ați dori cu adevărat să încercați să utilizați asta sau să o proiectați ca o aplicație cu mai multe pagini. Ca un site web tradițional, dar cred că nu este un standard sustenabil, deoarece atunci când implicit pentru fiecare proiect este să spuneți: „Ei bine, tot ce avem nevoie pentru a livra o aplicație pe o singură pagină, cum ar fi un router pe partea clientului și un cadru greu și să descarcăm toate a acestei procesări de redare de la server la client.” Cred că de aici începi să ajungi la un punct în care excluzi utilizatorii, deși neintenționat, dar totuși îi excluzi.

Drew: Există o prăpastie mare, crezi că între oamenii care adoptă abordarea că vom publica un site web și poate avea orice funcționalitate interactivă și cei care spun: „Suntem o companie de software, suntem realizarea unui produs, a unui produs software și a platformei noastre prin care o vom livra este web, mai degrabă decât aplicații native pentru mai multe platforme.” Este posibil ca aceștia să abordeze problema în moduri complet diferite? Sunt considerațiile diferite în funcție de viziunea dvs. în acel moment?

Jeremy: Asta e o întrebare grea. Asa de-

Drew: Mi-a fost greu să spun.

Jeremy: Aș spune că o companie care... deci un exemplu bun ar fi ca o știre, nu? Sunt bine serviți de tipul de model de site, deoarece este literalmente o colecție de documente, articole. Iar oamenii care dezvoltă acele experiențe probabil vor avea un set de abilități diferit de a spune o companie precum Spotify sau o companie care are o aplicație web mare precum Envision sau genul ăsta. Și da, cred că vor veni la asta din unghiuri diferite. Felul în care l-am privit este că există un segment... sau cel puțin așa am perceput eu comunitatea de dezvoltare web în general este că există un segment de oameni, de dezvoltatori web care provin din dezvoltarea de software netradițională. fundaluri, nu? Și eu sunt unul dintre acești oameni, m-am chinuit cu web-ul când eram un fel de copil, nu?

Jeremy: Ca la gimnaziu și făceam pagini de fani stupide pentru toți, cum ar fi jocurile video de la acea vreme care îmi plăceau foarte mult. Și nu am avut niciodată acest tip de educație în domeniul informaticii. Există concepte de informatică pe care le-am preluat pe parcurs. Apoi, există și un segment de dezvoltatori, mai ales cred că au apărut în ultimii cinci până la 10 ani care abordează acest lucru într-un mod mai orientat spre informatică. Și cred că asta va... acele diferențe și experiențe vor conduce fiecare dintre acele grupuri să tragă propriile concluzii despre cum să se dezvolte cel mai bine pentru web. Dar cred că singurul mod în care poți într-adevăr... Că te poți dezvolta în mod durabil pentru web este să evaluezi critic ceea ce construiești și să încerci să te aliniezi în jurul unei abordări care să servească cel mai bine utilizatorilor acelor produse. Și cam așa mi se găsesc în cap site-ul web și modelele de aplicații web când evaluez aceste lucruri.

Drew: Da. Este interesant. Adică, în carte, citezi de fapt o parte din munca mea. Mulțumesc foarte mult. Și alegerea mea de tehnologii plictisitoare pe PHP Apache și o stropire de JavaScript rulat manual pot crea o experiență de utilizator foarte rapidă în mod implicit, fără a fi nevoie să facem nicio optimizare anume. Cred că asta oferă o experiență excelentă de utilizator pentru vizitatorii care vin și vizionează conținutul de pe site.

Drew: Dar, de fapt, mă simt într-un fel ca acel mediu pentru crearea de conținut, un fel de rever, odată ce te-ai autentificat și publicați lucrurile pe site. Cred că suferă puțin din cauza faptului că a fost construit cu o abordare a site-ului web, mai degrabă decât o abordare mai degrabă a aplicației web cu JavaScript, atât de mult încât mă gândesc... sau poate că trebuie să fie ambele. Trebuie să continui publicarea front-end-ului în HTML și CSS static și mici bucăți de JavaScript. Dar backend-ul în care vreau să ofer o experiență de creație de conținut poate că ar fi mai bună o alegere tehnologică diferită. Este destul de interesant pentru că nu trebuie să fie întotdeauna una sau alta, nu-i așa? Nu este o alegere binară. Este mai mult un spectru, ați spune?

Jeremy: Da, absolut. Și cred că începem să vedem mai multe discuții în comunitate despre dezvoltarea web ca un astfel de spectru. Pentru a fi direct pentru oamenii care ar putea fi interesați de cartea mea, cu siguranță vine din partea site-ului web a spectrului. Și din nou, pentru că simt că asta este întotdeauna ca un standard bun. Dacă nu știți cum doriți să construiți ceva, probabil cel mai bine este să încercați să îl construiți într-un mod care să minimizeze utilizarea JavaScript și să minimizeze împingerea mai multă muncă asupra clientului. Acestea fiind spuse, cred că observația este o experiență excelentă. Cred că aceste tehnologii bine uzate și într-adevăr „plictisitoare” funcționează foarte bine pentru sarcina în cauză. Și face acest lucru într-un mod care este ca un fel de deschis și de activare pentru dezvoltator, nu?

Jeremy: Nu trebuie să ai cunoștințe aprofundate despre... magazine de management de stat sau cadre de management de stat pentru a reuși cu adevărat astfel de lucruri. Și cred că acest lucru observat este bine servit de această abordare specială. Dar, în opinia dvs., cred că există oportunități în orice site web de a se apropia de mijlocul spectrului fără a intra în toate direcțiile de pe partea clientului, ca niște cadre grele care gestionează totul despre client și genul ăsta de lucruri. Cred că abordarea insulei începe să exploreze cum arată. Și recunosc, probabil că am făcut fără intenție unele lucruri de tip insule. Cred că avem de ceva vreme, pur și simplu nu i-am pus un nume. Dar cred că acum am identificat că poate ca un punct de mijloc, am putea începe să vedem experiențe web care oferă o experiență bună pentru utilizator, dar sunt încă mai interactive. Să sperăm că nu a fost teribil de șerpuitor.

Drew: E un fel de hartă înapoi la vremurile când am încorpora o insulă de Flash sau...

Jeremy: Da.

Drew: Ceva într-o pagină în care aceasta este mica noastră secțiune interactivă, iar restul curge în jur.

Jeremy: Da, la fel ca Flash, oh, Dumnezeule, trei iterații ale portofoliului meu personal din facultate au fost foarte proaste pentru imitații Flash avansate și efecte de tip hover. Și lucrurile alea au fost foarte, foarte distractive. Și mi-e dor uneori, ca și cum ar fi o mulțime de conținut care va dispărea pentru că nu mai folosim Flash. Și asta chiar e nasol, dar într-un fel a fost un fel de precursor al acestui tip de insule despre care vorbim. Adică ai putea avea ca o pagină web statică și tot, dar apoi ai avea această experiență interactivă cu adevărat bogată, ca și cum ar fi plasată chiar în mijlocul ei.

Drew: Multă vreme, îmbunătățirea progresivă a fost considerată o modalitate de cea mai bună practică de a construi experiențe web. Mai este cazul, crezi?

Jeremy: Aș recunoaște că este probabil... nu probabil aș recunoaște că este mai multă muncă să faci îmbunătățiri progresive pentru că, într-un fel, îți cam bifurci experiența de dezvoltare. Încercați să oferiți funcționalitatea minimă viabilă a unui site web într-un mod în care serverul poate gestiona un fel de interacțiuni cheie. Dar, pe lângă asta, spui: „Bine, acum vreau să facilitez această interacțiune pentru a fi puțin mai fluidă cu JavaScript.” Încă cred că este o modalitate viabilă de a-ți îndeplini obiectivele cu site-ul, aplicația sau produsul tău.

Jeremy: Dar ceea ce aș spune este că nu aș recomanda niciodată ca fiecare interacțiune pe un site web să fie facilitată de acest tip de navigare sincronă. Deci, un exemplu bun ar putea fi pagina dvs. de plată pentru site-ul dvs. econ ar trebui să aibă cu siguranță o rută de server. Ar trebui să aveți o rută de server pentru a adăuga lucruri în coș și apoi ar trebui să puteți presăra doar suficient JavaScript pentru a face acest lucru puțin mai încântător, astfel încât lucrurile să poată fi puțin mai rapide și mai asincrone.

Drew: Când vine vorba de măsurarea performanței. Auzim multe despre elementele vitale web de bază, în principal de la Google. Sunt acestea cu adevărat punctul de referință cu care ar trebui să ne măsurăm? Sau doar asta vrea Google să gândim? Acum înțeleg că aceasta ar putea fi o întrebare dificilă pentru care ați început să lucrați la Google.

Jeremy: Da, da. Știi, așa că vorbesc în numele meu aici. Cred că elementele vitale web sunt... elementele vitale web inițiale de bază sunt o încercare bună de a defini ce părți ale experienței utilizatorului sunt importante. Cred că valori precum schimbarea cumulativă a aspectului și cea mai mare vopsea Contentful încep să se gândească la experiență în moduri pe care nu am început să le cuantificăm cu adevărat. Înainte de schimbarea aspectului cumulativ, pentru că, dacă a existat vreodată un moment în care te înfurii, atingeți este pentru că unui buton îi place să se miște pe pagină sau ceva de genul. Adică, cred că ăsta este un lucru util pentru a-l măsura. Este imperfect. Și cred că oricine lucrează la elementele vitale web de bază ar fi de acord că se dorește îmbunătățirea unora dintre aceste valori. Există și alte valori cu care nu sunt neapărat de acord în totalitate. Ca și prima întârziere de intrare este o măsurătoare pe care este oarecum dificil de pus un pin.

Jeremy: Cred că este foarte util, nu? Pentru că ceea ce spui literalmente este că vrem să măsurăm întârzierea și interactivitatea primei interacțiuni pe care o face utilizatorul, dar îi lipsește puțin context, nu? Pentru că unele... multe lucruri îl pot afecta, deoarece nu se leagă întotdeauna de JavaScript. Prima întârziere de introducere ar putea reprezenta întârzierea care este suportată de focalizarea câmpului formular, nu? Genul ăsta de lucruri, lucruri în HTML. Cred că acele valori... astfel de valori, cum ar fi întârzierea primei introduceri, pot fi... pot fi benefice dacă le puteți contextualiza cu lucruri precum intrări din API-ul pentru sarcini lungi, sincronizarea elementelor și acele tipuri de lucruri. În cele din urmă, cred că viitorul elementelor vitale web de bază se va dovedi că va fi util și instrumental în măsurarea a ceea ce face o experiență bună pentru utilizator. Asta e parerea mea personala.

Drew: Bănuiesc că este unul dintre acele lucruri pe care le poți măsura întotdeauna față de tine, să-ți măsori propriile îmbunătățiri sau dacă experiența ta s-a înrăutățit dacă scorul tău se schimbă, nu-ți pasă atât de mult de semafoare, ci de ceea ce știi. despre contextul site-ului dvs. și despre modul în care o schimbare a adus o îmbunătățire.

Jeremy: Cred că valorile precum schimbarea cumulată a aspectului sunt excelente, dar și ele ar putea beneficia de puține îmbunătățiri. În prezent, schimbarea cumulată a aspectului măsoară în principal schimbările de aspect care au loc în timpul încărcării. Și după cum știm, atunci când un utilizator vizitează o pagină și ajunge pe o pagină, pot apărea schimbări de aspect în orice moment, nu? Deci, cu siguranță există de lucru, cred că se poate face pentru a îmbunătăți modul în care observăm acest tip de fenomen, cu siguranță.

Drew: Cred că stabilitatea aspectului este unul dintre lucrurile care este de fapt puțin mai dificil de realizat atunci când lucrezi cu îmbunătățirea progresivă. Uneori, când încărcați o pagină redată pe server și apoi începeți să o îmbunătățiți în client, poate exista pericolul de a crea un asemenea tip de schimbare a aspectului, nu-i așa?

Jeremy: Absolut. Și de aici hidratarea componentelor devine cam dificilă, deoarece dimensiunile acelei componente se pot schimba din mai multe motive. Ca și cum ar putea fi conținut prezent în componenta clientului care pur și simplu nu se redă pe server din cauza stării care nu este evaluată până când este executată pe client. Este o problemă extrem de dificilă. Nu am de gând să stau aici și să mă prefac că am un glonț de argint pentru asta.

Drew: Am vrut să vorbesc puțin despre un fel de dinamică a importurilor și împărțirea codului, ambele fiind tehnici diferite pentru problema de descărcare și execuție a unui pachet uriaș de JavaScript la începutul experienței. Există riscul unei optimizări excesive cu o mulțime de solicitări mici, în special pentru cele mai simple proiecte mai mici, sau este ceva care nu sunt absolut dăunătoare în implementarea, de la început, prevenind că veți avea aceste probleme? Sau ar trebui să așteptați până când vedeți probleme de performanță înainte de a vă gândi la astfel de lucruri?

Jeremy: Așa că aș recomanda finalul a ceea ce tocmai ai spus este o modalitate bună de a conduce cu asta. Nu ar trebui să încercăm să optimizăm prematur decât dacă, desigur, acele optimizări pot fi realizate foarte rapid și ușor, dar dacă este nevoie de mult efort pentru a optimiza devreme, când nu există cu adevărat multe probleme de performanță, aș argumenta că divizarea codului este probabil ceva care nu trebuie să se întâmple. Probabil că puteți încărca acea funcționalitate în avans.

Jeremy: Dar, de exemplu, vorbesc despre asta în carte. Dacă aveți o interacțiune de mare valoare care este condusă de o bucată mare de JavaScript, și pentru mine, o bucată mare de JavaScript ar putea însemna 20 de kiloocteți, deoarece peste firul care este comprimat și care ar putea ajunge să fie o bucată de JavaScript de 60 de kilobyți. Apoi, dacă puteți extrage acest lucru din pachetul principal sau din oricare dintre nenumăratele dvs. de pachete, site-ul dvs. ar putea fi expediat, veți ajuta performanța la pornire.

Jeremy: Dar în carte, discut despre o tehnică despre perceperea când... sau cel puțin încercarea de a percepe când utilizatorul ar putea face o interacțiune de mare valoare. Deci exemplul pe care îl folosesc este o bucată de JavaScript. Acesta este folosit pentru a valida conținutul unui formular, deoarece validarea formularului HTML este grozavă, dar nici nu este stilabilă și este destul de simplă. Nu există tone de flexibilitate pentru lucruri precum tipul este egal cu e-mailul, nu? Îl evaluează într-un anumit fel. Cu toate acestea, validarea formularului pe client este foarte utilă, deoarece îl putem și stila. Și putem alinia aspectul acelei validări pentru a fi mai aproape de ceea ce este estetica mărcii sau de ce este estetica site-ului web. Și așa, în acest exemplu, ceea ce am făcut a fost, am spus, dacă un utilizator se concentrează... chiar și doar concentrează oricare dintre câmpurile din formular, acesta este punctul în care preîncărcăm acea bucată de JavaScript.

Jeremy: Așa că sperăm că până la momentul respectiv și aș sper că, pentru că durează puțin să completezi un formular, rețeaua are suficient timp pentru a-l trage în jos, astfel încât, atunci când este apelat importul dinamic, să poată ajunge doar la numerar. obțineți ceea ce a fost deja preîncărcat. Este ceva cu care am lucrat puțin ici și colo și este greu de făcut în toate situațiile. De exemplu, nu puteți face acest lucru în mod fiabil tot timpul când hover, deoarece unele dispozitive nu au un indicator fin. Au... sunt... intrări de la robinet, nu? Deci, un hover are loc la un moment diferit decât dacă ai avea un indicator fin, de exemplu.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Jeremy: Un fel de lucru în curs de desfășurare pe care l-am făcut de când a apărut este să încurc cu API-ul de vopsea CSS. Îmi place foarte mult API-ul paint. Adică, a existat întotdeauna în sine... ca în felul său, deoarece contextul 2D ca pânza a fost un lucru. Pentru că asta e... pentru cei care nu știu, API-ul CSS pain este o modalitate prin care poți încorpora un context de pânză 2D și îl poți parametriza și controla cu CSS, ceea ce deschide o mulțime de posibilități cu adevărat interesante, cum ar fi poți anima lucruri care nu puteai să animați anterior și genul ăsta de lucruri.

Jeremy: Și recent am făcut o reîmprospătare a blogului. Adică... Sunt un nemaipomenit tocilar al Final Fantasy, ca Final Fantasy II pe care tocmai l-am rejucat și așadar, sunt 15 dintre ei și 16 vor apărea cândva, dar este un fel de câmp retro. Așa că am folosit API-ul CSS paint pentru a genera o lume aleatorie folosind diferite plăci. Așa că sunt râuri și chestii care trec prin iarbă și copaci și genul ăsta. Și parametrizând asta așa cum ar fi dacă utilizatorul îmi vizitează site-ul în modul întunecat... pictura va fi redată ca și cum ar fi noapte. Va avea doar un fel de suprapunere pe el și genul ăsta de lucruri.

Jeremy: Dar API-ul de pictură este uimitor. Trebuie să-i dau un strigăt lui Tim Holman. El, l-am văzut la JSConf Australia și a ținut o discuție despre opera de artă generativă. Asta a fost cu adevărat, chiar că m-a interesat. Și apoi Sam Richard, în care la CSSConf cu o zi înainte a vorbit despre API-ul de pictură CSS, când acele două lucruri s-au reunit pentru mine, a fost de genul: „Uau, asta e atât de tare”. Și așa am făcut de fapt un lucru numit Paintlets! Este un Paintlets.Herokuapp.com dacă vizitezi și Chrome și trebuie, din păcate, pentru că încă nu este foarte bine susținut. Puteți vedea ca o grămadă de lucrări de artă diferite, aleatorii, generate aleatoriu și... da, doar am... asta am fost, îmi pare rău. Povestea lungă despre asta.

Drew: Uimitor. Suna foarte bine.

Jeremy: Da. Da.

Drew: Dacă tu, dragă ascultător, ai dori să afli mai multe de la Jeremy, îl poți găsi pe Twitter unde este @malchata și îi poți găsi prezentările scrise, videoclipurile și proiectele pe site-ul său personal, jeremy.codes, JavaScript responsabil este disponibil acum de la A Rezervați Apart. Și puteți găsi mai multe informații despre asta la responsablejs.dev. Mulțumesc că mi-ai venit astăzi Jeremy, ai avut cuvinte de despărțire?

Jeremy: Mergi înainte și construiește pentru web cel mai bun mod posibil și încearcă să ții cont de utilizator. Aceasta este un fel de mantra mea și sper că această carte va face să rămână puțin.