Smashing Podcast Episode 45 Z Jeremy Wagner: Co to jest odpowiedzialny JavaScript?

Ten odcinek został uprzejmie wsparty przez naszych drogich przyjaciół z Wix, platformy dla profesjonalistów do tworzenia witryn klientów, zarządzania złożonymi projektami i rozwijania firm online. Dziękuję Ci!

W tym odcinku mówimy o odpowiedzialnym JavaScript. Co to znaczy, że kod jest odpowiedzialny i jak powinniśmy inaczej podchodzić do projektów? Rozmawiałem z ekspertem Jeremym Wagnerem, aby się dowiedzieć.

Pokaż notatki

• Odpowiedzialna strona JavaScript
• Kup książkę od A Book Apart
• Osobista strona Jeremy'ego
• Jeremy na Twitterze

Cotygodniowa aktualizacja

• Prawo Fittsa w erze dotyku napisane przez Stevena Hoobera
• Projektowanie stron internetowych zrobione dobrze: idealnie bez sensu napisane przez Fredericka O'Brien
• Wszystko, co chcesz wiedzieć o tworzeniu głosowych interfejsów użytkownika, napisali Nick Babich i Gleb Kuznetsov
• Implikacje przyłączenia WordPressa do protokołu blokowego napisanego przez Leonarda Losoviza
• Myśli o promocji cenowej autorstwa Knuta Melvara

Transkrypcja

Drew McLellan: Jest pisarzem technicznym, nerdem wydajności sieci, programistą i mówcą, obecnie pracuje w Google. Napisał dla A List Apart, CSS-Tricks and Smashing Magazine i jest autorem nowego tytułu, Responsible JavaScript for A Book Apart. Więc wiemy, że jest wykwalifikowanym technikiem i komunikatorem, ale czy wiesz, że chce okrążyć kulę ziemską na desce do wiosłowania? Moi miażdżący przyjaciele, witajcie Jeremy'ego Wagnera. Cześć Jeremy, jak się masz?

Jeremy Wagner: Rozwalam. Jak się masz?

Drew: Jestem bardzo dobry. Dziękuję Ci. Chciałem dziś z tobą porozmawiać o idei odpowiedzialnego JavaScriptu. Czy jest to jakieś nowe podejście lub technika, czy dosłownie mówisz o odpowiedzialnym korzystaniu z JavaScript?

Jeremy: Dosłownie mówię o odpowiedzialnym korzystaniu z JavaScript. Tak więc w archiwum HTTP zaobserwowaliśmy prawie 58% wzrost średniej ilości kodu JavaScript pobranego przez urządzenia mobilne z około 290 kilobajtów do prawie 500 kilobajtów w ciągu ostatniego roku.

Drew: Wow.

Jeremy: Więc kiedy mówię o odpowiedzialnym korzystaniu z JavaScript, jest to dla użytkownika pierwszy rodzaj podejścia do powiedzenia… krytycznej oceny tego, co tworzymy i jest celem tego, co tworzymy, obsługiwanym przez nowoczesne praktyki tworzenia stron internetowych, więc mówić. I wydaje mi się, że to trochę… może nie przymrużeniem oka, ale nie brałem udziału w nowoczesnym tworzeniu stron internetowych, ale jednym z produktów ubocznych współczesnego tworzenia stron internetowych jest to, że bardzo łatwo jest dodawać zależności do projektów. Wszystko to instalacja MPM, a każda instalacja MPM ma swój koszt, który jest różny. Ale widzimy, że w tych archiwalnych danych HTTP 95. percentyl… oznacza 5% doświadczeń, które są najwolniejsze… lub nie najwolniejsze, ale zawierają najwięcej JavaScriptu, który wzrósł w ciągu ostatniego roku o około 875 kilobajtów do około 1,4 megabajtów.

Drew: Wow.

Jeremy: A więc przesyłana jest ogromna ilość JavaScriptu, która ma wpływ zarówno na wydajność ładowania, jak i na wydajność środowiska wykonawczego.

Drew: Więc wspomniałeś o występie. Wygląda na to, że z mojego punktu widzenia współczesne środowisko internetowe jest jak 10% HTML i CSS oraz 90% JavaScript. I muszą być w tym względzie względy wydajności. Chodzi mi o to, że mówiłeś o ilości danych, które przesyłamy, ale są też inne względy wydajnościowe związane z dużą ilością JavaScriptu.

Jeremy: Tak. Więc mając wolne łącze internetowe i wiesz… gdzie mieszkam w Stanach Zjednoczonych, jeśli wyjedziesz wystarczająco daleko poza duże miasto, będzie to trochę trudne w zależności od tego, dokąd się udasz… po prostu poradzić sobie z tym, jak wolny może być internet rodzaj tych obszarów wiejskich i jest znacząca liczba ludzi mieszkających na obszarach takich jak ten. A zatem aspekt wydajności ładowania jest już wystarczająco trudny, gdy zaczynasz wysyłać megabajty JavaScriptu, ale możesz również mieć do czynienia z kimś, kto nie ma iPhone'a… jak iPhone X lub jak iPhone 13.

Jeremy: Mogą być po prostu na telefonie z internetem lub czymś w rodzaju niedrogiego telefonu z Androidem, po prostu próbując nawigować przez życie. To znaczy, pomyśl o takich rzeczach jak bankowość internetowa, pomoc dla bezrobotnych lub inna pomoc rządowa, takie portale z aplikacjami. Nauka online, jest tylko wiele miejsc, w których nadmierny JavaScript może naprawdę mieć szkodliwy wpływ na ludzi, którzy mogą nie mieć szczęścia, aby mieszkać w dużych obszarach miejskich lub nawet w obszarach miejskich, które nie są dobrze obsługiwane przez szerokopasmowy Internet i te na wolniejszych urządzeniach . Myślę, że jako programiści mamy tendencję do patrzenia na… kupujemy MacBooki lub te wysokiej klasy urządzenia i czasami tak naprawdę nie widzimy, gdzie te problemy mogą się pojawić, gdy nadużywamy JavaScript.

Drew: I tak jak tam wspomniałeś, czasami to osoby, które mają najwięcej do stracenia, nie mogąc uzyskać dostępu do usługi, są karane przez tego rodzaju rzeczy. Ci ludzie bez szybkich połączeń danych lub bez bardzo wydajnych urządzeń czasami uzyskują dostęp do usług, które oznaczają wszystko dla… oznacza dla nich wszystko, do czego mogą uzyskać dostęp. Tak więc pod pewnymi względami staje się to niemal kwestią praw człowieka.

Jeremy: Tak. Chodzi mi o to, że mamy tendencję do postrzegania wydajności sieci pod kątem wartości biznesowej. Byłem konsultantem ds. wydajności w pewnym e-com i jak duża firma spożywcza, duża e-com… jak sklep, jak sklep z elektroniką i to bardzo kuszące, prawda? Ponieważ kiedy pracujesz dla firmy, to znaczy, oczywiście chcesz, aby finanse były zdrowe, a wydajność sieci odgrywa w tym rolę, jak sądzę. Myślę, że istnieje wiele studiów przypadku, które to potwierdzają. Jest jednak aspekt ludzki, a nawet dla firm, takich jak sklepy spożywcze i tego typu rzeczy. Tak, są napędzane przychodami. Chcą mieć zdrowe finanse, więc wydajność sieci jest tego częścią, ale służą również krytycznej potrzebie, prawda? Jakbyś musiał jeść, prawda?

Jeremy: I jak niektórzy ludzie mogą być w domu z tego czy innego powodu. Mogą nie być w stanie łatwo wsiąść do samochodu. Mogą nie mieć samochodu. Polegają więc na tych usługach, aby uzyskać zaopatrzenie, ale co więcej, pomoc, jeśli jej potrzebują, a szczególnie lubią interwencje kryzysowe i tego typu rzeczy. Nie sądzę, aby stwierdzenie, że partner, który był maltretowany i wyrzucony z domu, może sięgnąć po smartfona i uderzyć w Google znaleźć portal interwencji kryzysowej i pomocy, nie jest zbyt przesadne. A JavaScript może przeszkadzać w realizacji tego typu celów i służyć tym ludzkim potrzebom. Kiedy mamy tendencję do opierania się na nim trochę za bardzo.

Drew: Chodzi mi o to, że widzieliśmy tego rodzaju przebłysk w ciągu ostatnich 18 miesięcy, kiedy COVID i ludzie popadli w izolację i, jak mówisz, musieli zamawiać artykuły spożywcze, które mają być dostarczone. W tym momencie sieć staje się dla nich kołem ratunkowym. Czują się kiepsko, nie mogą opuścić mieszkania, ponieważ są odizolowani i muszą zdobyć jedzenie i niezbędne zapasy. Więc tak, myślę, że jest to coraz ważniejsza część codziennego życia dla nas wszystkich.

Jeremy: Dokładnie. Wracając do historii urządzeń, Tim Kadlec napisał kilka lat temu niesamowity artykuł. Myślę, że to było dwa lata, może trzy lata temu, ale nazywał się Priorytetyzacja długiego ogona wydajności. A kiedy na to spojrzysz… więc w żargonie wydajności sieci mówimy o danych laboratoryjnych w porównaniu z danymi terenowymi. A dane laboratoryjne są jak wtedy, gdy prowadzisz latarnię morską lub wrzucasz witrynę na test strony internetowej, aby zobaczyć, jak sobie radzi. To wszystko są naprawdę przydatne narzędzia, ale kiedy spojrzysz na te dane terenowe, naprawdę zaczynasz mieć większy obraz i większy obraz tego, kim naprawdę są Twoi odbiorcy. W tym artykule Tim Kadlec mówi o tym, co to znaczy priorytetyzować długi ogon wydajności. To znaczy wszystkie te urządzenia, które… być może nie są tak mocne i tak potężne, jak urządzenia, które my jako programiści możemy mieć.

Jeremy: Ideą tego artykułu jest to, że jeśli możemy skoncentrować się na 90-tym lub 95-tym percentylu, jesteśmy... i poprawić to doświadczenie dla tych ludzi, budujemy szybszą sieć dla wszystkich, także tych na szybkich urządzeniach. I zaatakuj punkt danych na ten temat w USA, a to jest właśnie z takiego jak statcounter.com. Coś w rodzaju 28 punktów… około 28% osób korzysta z urządzenia z systemem iOS, które przechwytuje to narzędzie. A około 21% z nich to Android. A Android ma tendencję do reprezentowania sporej części tego długiego ogona urządzeń, ponieważ Android nie jest monolityczny. Wielu producentów urządzeń produkuje telefony z Androidem, ale dla porównania tego ze światem, ponieważ świat to coś więcej niż tylko Stany Zjednoczone, to około 16% ludzi korzystających z iOS i około 41% ludzi korzystających z Androida. Więc naprawdę opłaca się traktować priorytetowo te wolniejsze lub potencjalnie wolniejsze doświadczenia.

Drew: Czytałem w twojej książce o dławieniu termicznym urządzeń, co nigdy wcześniej nie było czymś, nad czym się zastanawiałem. Jakie są tam obawy?

Jeremy: Obawiam się tutaj, a ja nie jestem ekspertem od mikroprocesorów. Jestem po prostu web developerem, który prawdopodobnie pisze trochę za dużo, ale… więc idea dławienia termicznego, która istnieje we wszystkich systemach, nie tylko jak telefony i tablety, polega na tym, że mikroprocesor… gdy przejmie nadmierne obciążenie lub tak naprawdę tylko ogólnie obciążenie pracą, produktem odpadowym tej pracy jest ciepło. I tak urządzenia mają sposoby na złagodzenie tego. Jak twój laptop ma zarówno pasywne, jak i aktywne urządzenie chłodzące.

Jeremy: Więc pasywne urządzenie chłodzące jest jak radiator lub jakiś rozpraszacz ciepła. A jego aktywna część działa jak wentylator, który skuteczniej rozprasza ciepło. Niektóre, takie jak niestandardowe konstrukcje komputerów, mogą wykorzystywać chłodzenie cieczą, co jest rodzajem bardziej ekstremalnego przykładu, ale telefon komórkowy tego nie ma, ponieważ gdzie naprawdę zmieścisz wentylator w tym wszystkim, jeśli przenośność jest dla ciebie rzecz, prawda?

Jeremy: Aby więc te urządzenia poradziły sobie z tak dużym obciążeniem, mogą sztucznie zmniejszać szybkość procesora, na przykład zmniejszać częstotliwość taktowania, aż urządzenie wejdzie w stan, w którym można podnieść tę częstotliwość. A to ma implikacje, ponieważ jeśli przeżuwasz tony, tony, tony i tony JavaScript, masz takie duże kawałki spływające w dół drutu, cóż, to rozpoczyna przetwarzanie, prawda? Jest to więc dużo przetwarzania poprzez ocenę i parsowanie w kompilacji, a następnie wykonanie. A jeśli robisz to z megabajtem lub dwoma JavaScriptem, a w tle zachodzi wiele innych procesów, takich jak różne zakładki, tego typu rzeczy, które mogą wprowadzić twój stan… to zwiększa prawdopodobieństwo, że urządzenie może wejść w stan dławienia termicznego, co oznacza, że ​​będzie mniej zdolne do podjęcia tej dodatkowej pracy.

Drew: Więc jest to rodzaj negatywnej pętli sprzężenia zwrotnego. Prawda? Dajesz urządzeniu dużo pracy. Robi się bardzo gorąco, a następnie jest mniej zdolny do wykonania tej pracy, ponieważ musi zwolnić.

Jeremy: Tak. I znowu nie jestem ekspertem od mikroprocesorów. Jestem pewien, że gdyby inżynier, który był naprawdę dobrze zaznajomiony z tym tematem, prawdopodobnie poprawiłby mnie w niektórych szczegółach, ale ogólna idea jest taka, że ​​tak, w miarę wzrostu ciśnienia otoczenia urządzenie jest mniej zdolne do radzić sobie z tymi dużymi obciążeniami, dopóki ciśnienie nie spadnie.

Drew: więc piszemy JavaScript dla całego spektrum urządzeń z najnowszego Apple M1 Max to nowy procesor, prawda? Laptopy aż do urządzeń, które ledwo mają wystarczającą ilość działającej pamięci RAM, aby renderować stronę internetową. Ale sieć nie zaczęła się w ten sposób, młodsi słuchacze mogą być zainteresowani tym, że kiedyś tworzyliśmy interaktywne środowiska internetowe bez żadnego JavaScriptu. Nasza wielka, ciężka struktura będzie naszą zgubą.

Jeremy: Powiedziałbym, że frameworki mają czas i miejsce, a ci, którzy czytają fragmenty tej książki, mogą pomyśleć, że jestem anty-frameworkiem. I zdecydowanie krytycznie odnoszę się do kilku frameworków, ale służą one celowi i można z nich korzystać w sposób, który zapewnia dobre wrażenia użytkownika lub może skutkować dobrym doświadczeniem użytkownika. Ale myślę, że nie robimy wystarczająco dużo, by krytycznie oceniać te frameworki pod kątem tego, jak szkodzą… wydajności w czasie wykonywania, prawda? A więc rodzaj rzeczy, o których mówię, gdzie jeśli klikniesz przycisk, a urządzenie zajmie sekundę, może dwie, aby odpowiedzieć na to wejście, ponieważ tak wiele dzieje się w tle. Masz inne rzeczy związane z JavaScriptem, takie jak zbieranie danych analitycznych, a także inne rzeczy działające w wątkach.

Jeremy: A jeśli nie ocenisz krytycznie wydajności środowiska wykonawczego frameworka, możesz zostawić pewne możliwości, aby lepiej służyć swoim użytkownikom. Dobrym przykładem, którego zawsze lubię używać, jest reakcja kontra pre-act. Od jakiegoś czasu uderzam w ten bęben. Jakiś czas temu napisałem artykuł dla CSS-Tricks, w którym profilowano podstawową interakcję kliknięcia, taką jak mobilne menu nawigacyjne. Brzmi to trywialnie, ale okazuje się, że na wszystkich urządzeniach reakcja zapewnia lepszą wydajność w czasie wykonywania, ale ma w zasadzie ten sam interfejs API. Są różnice, jest kilka drobnych różnic i rzeczy, które można zamaskować przed aktem, ale to proste… i nie powinienem mówić o prostym wyborze, ale ten wybór, ten podstawowy wybór może być różnicą między doświadczeniem to działa naprawdę dobrze dla wszystkich użytkowników lub przynajmniej większości użytkowników, lub doświadczenie, które działa dobrze tylko dla niektórych. Mam nadzieję, że to miało jakiś sens.]

Drew: Mam na myśli, że przy wszystkich frameworkach i narzędziach do budowania, wydają się być coraz lepsze w robieniu takich rzeczy, jak potrząsanie drzewami i optymalizacja pakietów, które wysyłają, oraz sposób ich dostarczania do przeglądarki. Czy podczas korzystania z dużych frameworków jest punkt krytyczny, kiedy myślisz, że piszesz tak dużą aplikację, tyle własnego kodu, że framework umożliwia wysyłanie mniej kodu z powodu całej swojej abstrakcji?

Jeremy: To trochę trudne pytanie. Jednym z aspektów jest to, że sam framework reprezentuje ilość kodu, której nigdy nie można zoptymalizować. Tak więc posiadanie cienkich ram, takich jak pre-act lub jakakolwiek liczba podobnych… Lub na przykład zaklęcie, które bardzo pomaga. Ale problem, który widziałem i myślę, że dane z archiwum HTTP wspierają ten punkt, polega na tym, że wydaje się, że za każdym razem, gdy mamy postęp w mikroprocesorach i sieciach, które stają się coraz szybsze, mamy tendencję do konsumowania tego zysku, prawda?

Jeremy: Mamy tendencję do przebywania na tej bieżni, gdzie nigdy tak naprawdę nie robimy postępów. I nie wiem, jakbym nie był jasnowidzem, jaka jest historia… albo przepraszam, jak wygląda przyszłość frameworków. Jestem pewien, że można uzyskać pewien wzrost wydajności. Ale to, co widzimy w tej dziedzinie, jeśli chodzi o to, jak bardzo surowy JavaScript jest… używana jest tylko surowa ilość JavaScript. Nie mówi mi, że jest to problem, z którego możemy zautomatyzować nasze wyjście. Myślę, że musimy… musimy być ludźmi, interweniować i podejmować decyzje, które są w najlepszym interesie użytkowników. W przeciwnym razie nie widzę, żebyśmy schodzili z tej bieżni, może nie w mojej karierze, ale nie wiem.

Drew: W książce mówisz o witrynach i aplikacjach internetowych oraz o tym, jak zrozumienie różnicy i z którą z nich pracujesz, pomaga wybrać strategię rozwoju i optymalizacji. Opowiedz nam trochę o tym.

Jeremy: To naprawdę dobre pytanie. I piszę o tym w artykule o tym samym tytule, który napisałem dla A List Apart zatytułowanym Responsible JavaScript Part One, który jest swego rodzaju wstępem do tej książki. Czy to, że ładujemy dużo do tej terminologii. Jako pisarz techniczny, widzę, że te dwa rodzaje są używane zamiennie. To, co widzę, dotyczy witryn internetowych, co sugeruje, że jest to rodzaj doświadczenia dla wielu grup wiekowych, prawda? To zbiór dokumentów. Teraz dokument… te dokumenty mogą mieć wbudowane funkcje, takie jak te małe wysepki, jak ostatnio nazywano, te małe wysepki funkcji, które umożliwiają ludziom wykonywanie zadań.

Jeremy: Ale są też aplikacje internetowe i aplikacje internetowe, które kojarzą się z natywną funkcjonalnością aplikacji. Mówimy więc o aplikacjach jednostronicowych, mówimy o dużych ilościach JavaScriptu, które napędzają złożoną interaktywność. A są chwile, kiedy model aplikacji internetowej ma sens. Jak na przykład Spotify jest tego dobrym przykładem. To działa lepiej jako aplikacja internetowa. Naprawdę nie chciałbyś tego używać ani projektować jako aplikacji wielostronicowej. Podobnie jak w przypadku tradycyjnej witryny internetowej, ale myślę, że nie jest to trwałe ustawienie domyślne, ponieważ gdy domyślnym ustawieniem dla każdego projektu jest powiedzenie: „Cóż, wszystko, czego potrzebujemy, aby dostarczyć aplikację jednostronicową, taką jak router po stronie klienta i ciężki framework i odciążyć wszystkie tego przetwarzania renderowania z serwera na klienta.” Myślę, że to jest moment, w którym dochodzisz do punktu, w którym wykluczasz użytkowników, choć nieumyślnie, ale mimo to ich wykluczasz.

Drew: Czy sądzisz, że istnieje duża przepaść między ludźmi, którzy przyjmują podejście, że zamierzamy opublikować witrynę internetową i może ona mieć dowolną interaktywną funkcjonalność, a tymi, którzy mówią: „Jesteśmy firmą programistyczną, jesteśmy Tworzenie produktu, oprogramowania i naszej platformy, którą zamierzamy dostarczać, to sieć, a nie natywne aplikacje dla wielu platform”. Czy jest prawdopodobne, że podchodzą do problemu na zupełnie inne sposoby? Czy rozważania różnią się w zależności od twoich poglądów w tym momencie?

Jeremy: To trudne pytanie. Więc-

Drew: Trudno mi było powiedzieć.

Jeremy: Powiedziałbym, że firma, która… tak dobry przykład byłaby jak wiadomość, prawda? Dobrze im służy model strony internetowej, ponieważ jest to dosłownie zbiór dokumentów, artykułów. A ludzie, którzy rozwijają te doświadczenia, prawdopodobnie będą mieli inny zestaw umiejętności niż np. firma taka jak Spotify lub firma, która ma dużą aplikację internetową, taką jak Envision lub tego typu rzeczy. I tak, myślę, że podejdą do tego z różnych punktów widzenia. Spojrzałem na to tak, że istnieje segment… a przynajmniej tak postrzegam społeczność twórców stron internetowych jako całość, jest to segment ludzi, twórców stron internetowych, którzy wywodzili się z nietradycyjnego tworzenia oprogramowania tła, prawda? A ja jestem jedną z tych osób, majstrowałam przy sieci, kiedy byłam trochę jak dziecko, prawda?

Jeremy: Jak w gimnazjum i robienie głupich stron dla fanów, takich jak gry wideo w tamtych czasach, które naprawdę lubiłem. I nigdy nie miałem takiego wykształcenia informatycznego. Są pewne koncepcje informatyki, które przyswoiłem sobie po drodze. Jest też grupa programistów, szczególnie myślę, że pojawili się w ciągu ostatnich pięciu do dziesięciu lat, którzy podchodzą do tego w sposób bardziej zorientowany na informatykę. I myślę, że to… te różnice i doświadczenia doprowadzą każdą z tych grup do wyciągnięcia własnych wniosków na temat tego, jak najlepiej rozwijać się w sieci. Ale myślę, że jedynym sposobem, w jaki możesz naprawdę… Abyś mógł rozwijać się w sposób zrównoważony dla sieci, jest krytyczna ocena tego, co tworzysz, i próba dostosowania się do podejścia, które najlepiej służy użytkownikom tych produktów. I to jest rodzaj miejsca, w którym model strony internetowej i aplikacji internetowej siedzi w mojej głowie, kiedy oceniam te rzeczy.

Drew: Tak. To interesujące. Mam na myśli to, że w książce cytujesz niektóre z moich prac. Dziękuję bardzo. A mój wybór nudnych technologii na zauważonym w zasadzie PHP Apache i odrobinie ręcznie skręconego JavaScriptu może domyślnie stworzyć bardzo zgryźliwe wrażenia użytkownika, bez konieczności wykonywania jakiejkolwiek szczególnej optymalizacji. Myślę, że zapewnia to wspaniałe wrażenia użytkownika dla odwiedzających witrynę i przeglądających treści na stronie.

Drew: Ale tak naprawdę, wydaje mi się, że środowisko do tworzenia treści jest czymś w rodzaju odwrotnej strony, kiedy jesteś zalogowany i publikujesz materiały na stronie. Myślę, że trochę cierpi z powodu tego, że jest budowany z podejściem do strony internetowej, a nie z podejściem opartym na bardziej rozbudowanej aplikacji internetowej JavaScript, tak bardzo, że myślę… a może musi to być jedno i drugie. Muszę kontynuować publikowanie frontendu w ładnym, statycznym HTML i CSS oraz maleńkich fragmentach JavaScript. Ale backend, w którym chcę zapewnić doświadczenie związane z tworzeniem treści, może lepszy byłby wybór innej technologii. To dość interesujące, bo nie zawsze musi to być jedno czy drugie, prawda? To nie jest wybór binarny. Można powiedzieć, że to bardziej spektrum?

Jeremy: Tak, absolutnie. I myślę, że zaczynamy widzieć więcej dyskusji w społeczności na temat tworzenia stron internetowych jako takiego spektrum. Mówiąc szczerze dla osób, które mogą być zainteresowane moją książką, zdecydowanie pochodzi ona od strony internetowej. I znowu, ponieważ czuję, że to zawsze jest dobre domyślnie. Jeśli nie wiesz, jak chcesz coś zbudować, prawdopodobnie najlepiej spróbuj zbudować to w sposób, który minimalizuje użycie JavaScript i minimalizuje przenoszenie większej ilości pracy na klienta. To powiedziawszy, myślę, że zauważyłem, że jest to doskonałe doświadczenie. Myślę, że te zużyte i naprawdę „nudne” technologie naprawdę dobrze sprawdzają się w danym zadaniu. I robi to w sposób otwarty i umożliwiający programistom, prawda?

Jeremy: Nie musisz mieć tak głębokiej wiedzy jak… o magazynach zarządzania stanem lub strukturach zarządzania stanem, aby naprawdę wykonać tego rodzaju rzeczy. I myślę, że to zauważone dobrze służy temu szczególnemu podejściu. Ale do twojego punktu, myślę, że w każdej witrynie istnieją możliwości, aby zbliżyć się do środka spektrum bez wchodzenia na wszystkie trasy po stronie klienta, takie jak ciężkie frameworki, które zarządzają wszystkim po kliencie i tego typu rzeczy. Myślę, że podejście wyspy zaczyna badać, jak to wygląda. I muszę przyznać, że prawdopodobnie przypadkowo zrobiłem coś w rodzaju wysp. Myślę, że już od dłuższego czasu, po prostu tak naprawdę nie nazwaliśmy tego. Ale myślę, że teraz, gdy uznaliśmy, że może to być punkt środkowy, możemy zacząć widzieć doświadczenia internetowe, które zapewniają dobre wrażenia użytkownika, ale są nadal bardziej interaktywne. Miejmy nadzieję, że nie było to strasznie meandrujące.

Drew: Trochę przypomina to czasy, kiedy osadziliśmy wyspę Flasha lub…

Jeremy: Tak.

Drew: Coś na stronie, na której jest to nasza mała interaktywna sekcja, a reszta w pewnym sensie przepływa.

Jeremy: Tak jak Flash, o mój Boże, trzy iteracje mojego osobistego portfolio z college'u były naprawdę kiepskie dla zaawansowanych podróbek Flasha i podobnych efektów najechania. I to było naprawdę zabawne. I czasami tęsknię za tym, jakby całe bogactwo treści po prostu zniknęło, ponieważ nie używamy już Flasha. I to naprawdę jest do bani, ale w pewnym sensie było to prekursorem tego rodzaju wysp, o których mówimy. Oznacza to, że możesz mieć po prostu statyczną stronę internetową i wszystko inne, ale wtedy miałbyś to naprawdę bogato interaktywne doświadczenie, jakby umieszczone w samym środku.

Drew: Przez długi czas progresywne ulepszanie było uważane za najlepszy sposób tworzenia doświadczeń internetowych. Czy nadal tak jest, myślisz?

Jeremy: Przyznałbym, że prawdopodobnie… nie, raczej przyznałbym, że progresywne ulepszanie wymaga więcej pracy, ponieważ w pewnym sensie dzielisz swoje doświadczenie programistyczne. Starasz się zapewnić minimalną realną funkcjonalność witryny w taki sposób, aby serwer mógł obsłużyć podobne do tych kluczowych interakcji. Ale na dodatek mówisz: „Dobrze, teraz chcę ułatwić tę interakcję, aby była trochę płynniejsza dzięki JavaScript”. Nadal uważam, że jest to realny sposób na osiągnięcie celów z witryną, aplikacją lub produktem.

Jeremy: Ale powiedziałbym, że nigdy nie zalecałbym, aby każda interakcja na stronie była ułatwiana przez ten rodzaj synchronicznej nawigacji. Dobrym przykładem może być strona kasy dla Twojej witryny econ, która zdecydowanie powinna mieć trasę serwera. Powinieneś mieć trasę serwera, aby dodawać rzeczy do koszyka, a następnie powinieneś być w stanie dodać tylko tyle kodu JavaScript, aby uczynić go trochę bardziej przyjemnym, aby rzeczy mogły być trochę szybsze i bardziej asynchroniczne.

Drew: Jeśli chodzi o mierzenie wydajności. Dużo słyszymy o kluczowych wskaźnikach sieciowych, głównie od Google. Czy to naprawdę punkt odniesienia, z którym powinniśmy się mierzyć? A może właśnie to Google chce, abyśmy myśleli? Rozumiem, że to może być trudne pytanie, że zacząłeś pracować w Google.

Jeremy: Tak, tak. Wiesz, więc mówię tutaj za siebie. Myślę, że web Vitals to… początkowe podstawowe dane webowe to dobra próba określenia, które elementy doświadczenia użytkownika są ważne. Myślę, że wskaźniki, takie jak skumulowana zmiana układu i największa zawartość treściowa, zaczynają myśleć o doświadczeniu w sposób, którego tak naprawdę nie zaczęliśmy określać ilościowo. Przed szczególnie skumulowaną zmianą układu, ponieważ jeśli kiedykolwiek był moment, w którym wściekasz się, dotknij, to dlatego, że przycisk lubi poruszać się po stronie lub coś takiego. To znaczy, myślę, że to jest pomocne, aby to zmierzyć. Jest niedoskonały. I myślę, że każdy, kto pracuje nad podstawowymi danymi internetowymi, zgodzi się, że pożądane jest ulepszenie niektórych z tych wskaźników. Istnieją inne wskaźniki, z którymi niekoniecznie się zgadzam. Podobnie jak opóźnienie pierwszego wejścia jest metryką, którą trudno przypiąć.

Jeremy: Myślę, że to naprawdę przydatne, prawda? Bo dosłownie mówisz, że chcemy zmierzyć opóźnienie i interaktywność podczas pierwszej interakcji użytkownika, ale brakuje trochę kontekstu, prawda? Ponieważ niektóre… wiele rzeczy może na to wpłynąć, ponieważ niekoniecznie wiąże się to z JavaScriptem. Pierwsze opóźnienie wejściowe może reprezentować opóźnienie spowodowane skupieniem się na polu formularza, prawda? Tego typu rzeczy, rzeczy w HTML. Myślę, że te metryki… takie metryki, jak opóźnienie pierwszego wejścia, mogą być… mogą być korzystne, jeśli możesz je kontekstualizować za pomocą takich rzeczy, jak wpisy z długiego interfejsu API, czasy elementów i tego typu rzeczy. Ostatecznie uważam, że przyszłość kluczowych elementów sieciowych pokaże, że będzie pomocna i instrumentalna w mierzeniu tego, co zapewnia dobre wrażenia użytkownika. To moja osobista opinia.

Drew: Myślę, że to jedna z tych rzeczy, które zawsze możesz zmierzyć ze sobą, zmierzyć własne postępy lub to, czy twoje doświadczenie się pogorszyło, jeśli twój wynik się zmieni, nie przejmując się zbytnio światłami, ale przejmując się tym, co wiesz o kontekście Twojej witryny i o tym, jak zmiana wpłynęła na poprawę.

Jeremy: Myślę, że metryki, takie jak skumulowana zmiana układu, są doskonałe, ale one również mogłyby skorzystać na odrobinie ulepszeń. W obecnej postaci skumulowana zmiana układu mierzy głównie zmiany układu, które mają miejsce podczas ładowania. A jak wiemy, kiedy użytkownik odwiedza stronę i ląduje na stronie, zmiany układu mogą wystąpić w dowolnym momencie, prawda? Więc zdecydowanie jest praca, którą można zrobić, aby na pewno poprawić sposób, w jaki obserwujemy tego rodzaju zjawiska.

Drew: Myślę, że stabilność układu jest jedną z rzeczy, które są trochę trudniejsze do osiągnięcia podczas pracy z progresywnym ulepszaniem. Czasami, gdy ładujesz stronę renderowaną przez serwer, a następnie zaczynasz ją ulepszać w kliencie, może wystąpić niebezpieczeństwo stworzenia tego rodzaju zmiany układu, czyż nie?

Jeremy: Absolutnie. I to jest sytuacja, w której uwodnienie komponentów staje się dość trudne, ponieważ wymiary tego komponentu mogą się zmieniać z wielu powodów. Na przykład może istnieć zawartość w komponencie po stronie klienta, który po prostu nie jest renderowany na serwerze z powodu stanu, który nie jest oceniany, dopóki nie zostanie wykonany na kliencie. To niezwykle trudny problem. Nie zamierzam tu siedzieć i udawać, że mam za to srebrną kulę.

Drew: Chciałem porozmawiać trochę o dynamice importu i dzielenia kodu, które są różnymi technikami rozwiązywania problemów z pobieraniem i wykonywaniem ogromnego pakietu JavaScript na początku doświadczenia. Czy istnieje ryzyko nadmiernej optymalizacji przy składaniu wielu małych żądań, szczególnie w przypadku najprostszych mniejszych projektów, czy jest to coś, co absolutnie nie zaszkodzi wdrażając od samego początku, uprzedzając, że będziesz mieć te problemy? A może powinieneś poczekać, aż faktycznie zobaczysz problemy z wydajnością, zanim zaczniesz myśleć o tego rodzaju rzeczach?

Jeremy: Więc polecam koniec tego, co właśnie powiedziałeś, jest dobrym sposobem na wprowadzenie w to. Nie powinniśmy próbować przedwcześnie optymalizować, chyba że oczywiście optymalizacje te można osiągnąć bardzo szybko i łatwo, ale jeśli wczesna optymalizacja wymaga dużo wysiłku, gdy tak naprawdę nie ma zbyt wielu problemów z wydajnością, twierdzę, że dzielenie kodu jest prawdopodobnie czymś, co nie musi mieć miejsca. Prawdopodobnie możesz po prostu załadować tę funkcję z góry.

Jeremy: Ale na przykład mówię o tym w książce. Jeśli masz interakcję o wysokiej wartości, która jest napędzana przez duży fragment JavaScriptu, a dla mnie, duży fragment JavaScript może oznaczać 20 kilobajtów, ponieważ w sieci jest on skompresowany i może to skończyć się 60-kilobajtowym kawałkiem JavaScript. Następnie, jeśli możesz wyciągnąć to z głównego pakietu lub dowolnego z niezliczonych pakietów, Twoja witryna może być wysyłana, pomożesz wydajności startowej.

Jeremy: Ale w książce omawiam technikę postrzegania, kiedy… lub przynajmniej próby dostrzeżenia, kiedy użytkownik może dokonać interakcji o wysokiej wartości. Przykład, którego używam, to fragment kodu JavaScript. Jest to używane do sprawdzania poprawności zawartości formularza, ponieważ sprawdzanie poprawności formularza HTML jest świetne, ale nie można go również stylizować i jest całkiem proste. Nie ma mnóstwa elastyczności, jeśli chodzi o takie rzeczy, jak typ to e-mail, prawda? Ocenia to w pewien sposób. Jednak ta walidacja formularza na kliencie jest bardzo pomocna, ponieważ możemy go również wystylizować. Możemy dostosować wygląd tej walidacji, aby był bliższy estetyce marki lub estetyce strony internetowej. W tym przykładzie powiedziałem, że jeśli użytkownik skupia się… nawet skupia się na którymś z pól formularza, jest to punkt, w którym wstępnie ładujemy ten fragment JavaScript.

Jeremy: Miejmy nadzieję, że do czasu, a mam nadzieję, że wypełnienie formularza zajmie trochę czasu, aby sieć miała wystarczająco dużo czasu, aby go usunąć, aby po wywołaniu dynamicznego importu mógł po prostu trafić na gotówkę do pobierz to, co już zostało wstępnie załadowane. Pracuję nad tym trochę tu i tam i jest to trudne we wszystkich sytuacjach. Na przykład nie można tego robić niezawodnie przez cały czas po najechaniu kursorem, ponieważ niektóre urządzenia nie mają dokładnego wskaźnika. Mają… są… to wejścia z kranu, prawda? Tak więc najechanie następuje w innym czasie, niż gdybyś miał na przykład dokładny wskaźnik.

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: Trochę trwającą rzeczą, którą robię, odkąd się pojawiła, jest majstrowanie w CSS Paint API. Bardzo podoba mi się API do malowania. Mam na myśli, to jakby zawsze istniało samo w sobie…. na swój sposób, ponieważ jak płótno kontekst 2D jest czymś. Ponieważ to… dla tych, którzy nie są świadomi, CSS pain API to sposób, w jaki można osadzić kontekst płótna 2D, sparametryzować go i kontrolować za pomocą CSS, co otwiera wiele naprawdę interesujących możliwości, takich jak animowanie rzeczy, które wcześniej nie można było animować i tego typu rzeczy.

Jeremy: A ostatnio robię odświeżenie bloga. To znaczy… Jestem wielkim maniakiem Final Fantasy, takim jak Final Fantasy II, który właśnie odtworzyłem, więc jest ich około 15, a 16 pojawi się kiedyś, ale to trochę w stylu retro. Więc używam API farb CSS do generowania losowego świata przy użyciu różnych kafelków. Więc są jak rzeki i takie rzeczy, które jak przepływają przez nie, kafelki trawy, drzewa i tego typu rzeczy. I parametryzując to tak, jakby użytkownik odwiedzał moją witrynę w trybie ciemnym… to malowanie będzie renderowane tak, jakby była noc. Będzie miał na sobie coś w rodzaju nakładki i tego typu rzeczy.

Jeremy: Ale API do malowania jest niesamowite. Muszę pozdrowić Tima Holmana. On, widziałem go na JSConf Australia i wygłosił wykład na temat sztuki generatywnej. To było naprawdę po prostu, naprawdę mnie zainteresowało. A potem Sam Richard, kiedy na CSSConf dzień wcześniej mówił o API do malowania CSS, kiedy te dwie rzeczy spotkały się dla mnie, to było jak: „Wow, to jest takie fajne”. I tak naprawdę zrobiłem coś, co nazywa się Paintlets! Jest to Paintlets.Herokuapp.com, jeśli odwiedzasz Chrome i musisz, niestety, ponieważ nie jest jeszcze bardzo dobrze obsługiwany. Możesz zobaczyć kilka różnych, losowych dzieł sztuki, generowanych losowo i… tak, po prostu… to właśnie mnie interesowało, przepraszam. Długa opowieść na ten temat.

Drew: Niesamowite. To brzmi świetnie.

Jeremy: Tak. Tak.

Drew: Jeśli Ty, drogi słuchaczu chciałbyś usłyszeć więcej od Jeremy'ego, możesz znaleźć go na Twitterze, gdzie jest @malchata i znaleźć jego prezentacje, filmy i projekty na jego osobistej stronie internetowej, jeremy.codes, Odpowiedzialny JavaScript jest już dostępny od A Zarezerwuj osobno. Więcej informacji na ten temat można znaleźć na stronie odpowiedzialnyjs.dev. Dzięki za przybycie do mnie dzisiaj Jeremy, czy miałeś jakieś pożegnalne słowa?

Jeremy: Po prostu idź do przodu i buduj dla sieci w najlepszy możliwy sposób i staraj się pamiętać o użytkowniku. To taka moja mantra i mam nadzieję, że ta książka trochę to wbije.