Smashing Podcast Episode 21 z Chrisem Ferdinandi: Czy współczesne najlepsze praktyki są złe dla sieci?

Dziś pytamy, czy nowoczesne sprawdzone metody nie szkodzą sieci? Czy nowoczesne frameworki sprowadzają nas na złą drogę? Aby się dowiedzieć, rozmawiam z ekspertem Lean Web, Chrisem Ferdinandi.

Pokaż notatki

• Strona Chrisa z linkami i notatkami do podcastu
• Książka Lean Web
• Chris Ferdinandi w sieci
• Chris na Twitterze
• Waniliowy podcast JavaScript

Cotygodniowa aktualizacja

• „Tłumaczenie modeli szkieletowych projektu na dostępny kod HTML/CSS”
  autor: Harris Schneiderman
• „Tworzenie aplikacji desktopowych za pomocą Electron i Vue”
  przez Timiego Omoyeni
• „Nowoczesne techniki CSS poprawiające czytelność”
  autorstwa Edoardo Cavazzy
• „Jak używać Styled-Components w React”
  autor: Adebiyi Adedotun Lukman
• „Jak stworzyć Porsche 911 za pomocą szkicu”
  autor: Nikola Lazarević

Transkrypcja

Drew McLellan: Jest autorem serii Vanilla JS Pocket Guide, twórcą programu szkoleniowego Akademii Vanilla JS i gospodarzem podcastu Vanilla JS. Opracował biuletyn z poradami, czytany przez prawie 10 000 programistów każdego dnia tygodnia. Uczył programistów w organizacjach takich jak Chobani i The Boston Globe. A jego wtyczki JavaScript były używane przez organizacje takie jak Apple i Harvard Business School. Przede wszystkim uwielbia pomagać ludziom w nauce Vanilla JavaScript. Więc wiemy, że wolałby wybrać Vanilla JavaScript zamiast frameworka, ale czy wiesz, że kiedyś został wybrany w składzie policji jako osoba, która najmniej popełniła przestępstwo? Moi przyjaciele Smashing, witajcie Chrisa Ferdinandi. Cześć Chris. Jak się masz?

Chris Ferdinandi: Och, miażdżę. Dzięki za zaproszenie.

Drew: Chciałem dziś z tobą porozmawiać o koncepcji Lean Web, która jest dla ciebie czymś w rodzaju pasji, nieprawdaż?

Chris: Tak, bardzo.

Drew: Dlaczego nie przygotujesz dla nas sceny? Kiedy mówimy o Lean Web, jaki problem próbujemy rozwiązać?

Chris: Tak, świetne pytanie. Jako zastrzeżenie dla wszystkich słuchaczy, ten odcinek może sprawić, że mały staruszek krzyczy na chmurę. Spróbuję tego uniknąć. Kiedy patrzę na sposób, w jaki dzisiaj budujemy sieć, wydaje mi się to trochę jak nadęty, przesadny bałagan. Doszedłem do przekonania, że ​​wiele z tego, co dzisiaj uważamy za najlepsze praktyki, może w rzeczywistości pogarszać działanie sieci.

Chris: Lean Web to podejście do tworzenia stron internetowych, które koncentruje się na prostocie, wydajności i doświadczeniu programisty od… przepraszam, nie na doświadczeniu programisty. Doświadczenie użytkownika, a nie doświadczenie programisty i łatwość budowania rzeczy z perspektywy zespołu, na czym myślę, że dzisiaj kładziemy duży nacisk i na który prawdopodobnie będziemy rozmawiać podczas naszej rozmowy.

Chris: Właściwie doszedłem do wniosku, że wiele z tych rzeczy, które uważamy za poprawiające wrażenia programistów, działa tak samo w przypadku podzbioru programistów, ale niekoniecznie wszystkich, którzy pracują nad tym, co tworzysz. Więc z tym też jest cała masa problemów, w których możemy się zagłębić. Ale tak naprawdę Lean Web polega na skupieniu się na prostocie i wydajności dla użytkownika oraz na nadaniu priorytetu lub skupieniu się na ludziach, którzy korzystają z rzeczy, które tworzymy, a nie na nas, ludziach, którzy to robią.

Drew: W miarę jak sieć dojrzewa jako platforma programistyczna, wydaje się, że istnieje coraz większe dążenie do specjalizacji.

Chris: Tak.

Drew: Ludzie, którzy kiedyś okładali Full Stack, a potem podzieliliśmy się na front-end i back-end. A potem ten front-end podzielił się na ludzi, którzy zajmują się programowaniem CSS lub JavaScript. A potem coraz bardziej w JavaScript staje się bardziej wyspecjalizowany. Ktoś może uważać się za programistę React lub programistę Angular, a cała jego tożsamość i perspektywa opiera się na konkretnym frameworku, w którym ma wysokie kwalifikacje. Czy ta zależność od frameworków jest podstawą naszej pracy w sieci, zła rzecz?

Chris: To zniuansowane. Kiedyś byłem bardzo mocno w obozie tak, zawsze. Myślę ogólnie, nadal czuję, że tak, nasza obsesja jako branży związanej z frameworkami i ogólnie narzędziami jest potencjalnie trochę na naszą szkodę. Nie sądzę, że frameworki są z natury złe. Myślę, że są przydatne w bardzo wąskim podzbiorze przypadków użycia. I w końcu używamy ich do prawie wszystkiego, w tym w wielu sytuacjach, w których naprawdę niekoniecznie są najlepszym wyborem dla Ciebie lub dla projektu.

Chris: Kiedy myślę o wielu problemach, które mamy dzisiaj w sieci, sedno tych problemów naprawdę zaczyna się od naszego nadmiernego polegania na frameworkach. Wszystko inne, co następuje po tym, jest na wiele sposobów, ponieważ rzucamy w sieci nie tylko frameworki, które ogólnie jest JavaScriptem. Mówię to jako ktoś, kto zawodowo uczy ludzi pisania i używania JavaScriptu. W ten sposób zarabiam pieniądze. I mówię tutaj, że myślę, że używamy zbyt dużo JavaScript, co czasami jest trochę dziwne.

Drew: W czasie, zanim pojawiły się duże frameworki, budowaliśmy interfejsy użytkownika i rzeczy za pomocą jQuery lub cokolwiek innego. A potem pojawiły się frameworki, które dały nam więcej koncepcji interfejsu użytkownika opartego na stanie.

Chris: Tak.

Drew: To dość złożona część inżynierii, którą musisz opanować. Czy praca z mniejszą ilością JavaScript wyklucza użycie czegoś takiego, czy też musisz sam to zaimplementować? Czy po prostu tworzysz załadowany schemat?

Chris: Wiele zależy od tego, co robisz. Jeśli masz niezmienny interfejs, możesz zbudować interfejs oparty na stanach z… nie wiem, może z kilkanaście linijek kodu. Jeśli masz niezmieniający się interfejs, szczerze powiedziałbym, że UI oparty jest na stanie. Niekoniecznie jest to właściwe podejście. Prawdopodobnie możesz zrobić inne rzeczy. Pomyśl o statycznych generatorach witryn, wstępnie renderowanych znacznikach, a nawet o starej stronie opartej na WordPressie lub PHP.

Chris: Ale zaczyna się to robić ciekawie, kiedy wchodzisz w bardziej dynamiczne i interaktywne interfejsy. Nie tylko aplikacje. Wiem, że ludzie uwielbiają rysować tę granicę między stronami internetowymi a aplikacjami i myślę, że między nimi jest dziwna mieszanka i granica nie zawsze jest tak wyraźna. Kiedy zaczynasz wchodzić w coś więcej, użytkownik robi różne rzeczy, coś się zmienia. Interfejs użytkownika oparty na stanie staje się nieco ważniejszy. Ale nadal nie potrzebujesz mnóstwa kodu, aby tak się stało.

Chris: Patrzę na coś takiego jak React lub Vue, które są absolutnie niesamowitymi dziełami inżynierii. Nie chcę odbierać ludziom, którzy nad nimi pracują. Skończyło się to jako ćwiczenie do nauki, budując własną mini-framework, aby lepiej zrozumieć, jak te rzeczy działają pod maską. Naprawdę trudno jest wyjaśnić wszystkie ruchome elementy. Dlatego mam ogromny szacunek dla ludzi, którzy budują i pracują nad tymi narzędziami. Ale React i Vue mają około 30 kilobajtów po minifikacji i gzipowaniu. Więc kiedy je rozpakujesz, są znacznie większe.

Chris: Nie wszystko, ale spora część tej wagi jest poświęcona temu, co nazywa się wirtualny DOM. Istnieją alternatywy, które wykorzystują podobne interfejsy API lub podejścia. W przypadku React masz Preact, który ma 2,5 kilobajta lub około 3 kilobajtów zamiast 30. To jedna dziesiąta rozmiaru. W przypadku Vue masz zamiast tego Alpine JS, który ma około 7 kilobajtów. Mimo to znacznie mniejszy. Duża różnica między nimi a ich starszymi bratami polega na tym, że pozbyli się wirtualnego DOM. Mogą porzucić jedną lub dwie metody. Ale generalnie jest to to samo podejście i ten sam rodzaj API w sposobie pracy z kodem i są one znacznie mniejsze.

Chris: Myślę, że wiele narzędzi, których używamy, jest potencjalnie przeciążonych rzeczami, które próbujemy zrobić. Jeśli potrzebujesz interfejsu użytkownika opartego na stanie i potrzebujesz reaktywnych danych oraz dynamicznych interfejsów, to świetnie. Myślę, że jedną z wielkich rzeczy, o których dzisiaj próbuję i mówię, nie jest… nigdy nie używaj narzędzi. Dla mnie Vanilla JS to nie jest pisanie odręcznie każdej linii kodu i każdego projektu, który robisz. To szaleństwo. Nie mogłem tego zrobić, nie robię tego. Ale jest bardziej selektywny w stosunku do używanych przez nas narzędzi. Zawsze wybieramy multi-narzędzie, szwajcarski scyzoryk, który ma w sobie to wszystko. A czasami tak naprawdę potrzebujesz tylko nożyczek. Nie potrzebujesz wszystkich innych rzeczy, ale i tak je mamy.

Chris: To naprawdę długa droga do… przepraszam, odpowiedzi na twoje pytanie. Co oznacza, że ​​czasami jest to więcej kodu, niż mógłbyś lub chciałbyś napisać sam, ale nie jest to aż tak dużo kodu, jak myślę, że to wymaga. Kiedy mówię, że nie potrzebujesz frameworka, otrzymuję wiele odepchnięć wokół tego pomysłu, że „Cóż, jeśli nie używasz frameworka, w zasadzie piszesz swój własny”. Wtedy to ma swoje własne problemy. Myślę, że jest miejsce pomiędzy używaniem Reacta lub Vue a pisaniem własnego frameworka, i być może jest to wybranie czegoś, co jest trochę mniejsze. Czasami są powody, dla których napisanie własnego frameworka może być właściwym wywołaniem, w zależności od tego, co próbujesz zrobić. Wszystko jest bardzo płynne i subiektywne.

Drew: To całkiem interesujące, że jako ćwiczenie uczenia się zaimplementowałeś własną strukturę opartą na stanie. Pamiętam, że kiedyś myślałem, że za każdym razem, gdy sięgałem po jakąś bibliotekę czy coś, lubiłem myśleć, że sam mógłbym to zaimplementować.

Chris: Jasne, jasne.

Drew: Ale sięgnięcie do biblioteki oszczędziło mi kłopotów z robieniem tego. Wiedziałem, że gdybym musiał sam napisać ten kod, wiedziałem, jakie podejście podejmę, aby to zrobić. I to było prawdą aż do używania takich rzeczy jak jQuery i inne. W dzisiejszych czasach myślę, że gdybym miał napisać własną wersję Vue lub React, prawie nie mam pojęcia, co się teraz dzieje w tej bibliotece, w całym tym kodzie.

Drew: Dla tych z nas, którzy nie są zaznajomieni, kiedy mówisz coś takiego jak Preact, porzuca wirtualny DOM i zmniejsza wszystko, co nam daje ten wirtualny DOM?

Chris: Aby odpowiedzieć na to pytanie, chcę zrobić tylko mały krok wstecz. Jedną z najprzyjemniejszych rzeczy, jakie dają frameworki i inne biblioteki stanowe, jest różnicowanie DOM. Jeśli tak naprawdę nie aktualizujesz interfejsu użytkownika tak bardzo, możesz powiedzieć: „Oto ciąg tego, jak powinien wyglądać znacznik. W HTML po prostu umieszczę wszystkie te znaczniki w tym elemencie”. Kiedy musisz coś zmienić, robisz to ponownie. To trochę za drogie dla przeglądarek, ponieważ powoduje odświeżenie.

Chris: Ale myślę, że potencjalnie ważniejsze niż to, że jednym z problemów z robieniem tego jest to, że masz tam jakikolwiek interaktywny element, pole formularza, łącze, na którym ktoś się skupił. To skupienie zostało utracone, ponieważ element… nawet jeśli masz nową rzecz, która wygląda podobnie, nie jest to ten sam dosłowny element. Utrata uwagi może więc wprowadzać w błąd osoby korzystające z czytników ekranu. Jest z tym po prostu cała masa problemów.

Chris: Każda rzecz UI oparta na stanie, która jest warta swojej wagi, zaimplementuje trochę dla różnicowania DOM, gdzie mówią: „Oto, jak powinien wyglądać interfejs użytkownika. Oto jak to wygląda teraz w DOM. Co za różnica?" I to zmieni i zmieni te rzeczy. Skutecznie robi to, co robisz, po prostu ręcznie aktualizując interfejs użytkownika, ale robi to za Ciebie pod maską. Możesz więc po prostu powiedzieć: „Oto, jak chcę, żeby to wyglądało”. A potem biblioteka lub framework domyśla się tego.

Chris: Mniejsze rzeczy, takie jak Preact czy Alpine, robią to bezpośrednio. Konwertują ciąg, który im dostarczasz, pokazujący, jak powinien wyglądać interfejs użytkownika, na elementy HTML. A potem porównują każdy element z odpowiadającym mu elementem w dosłownym DOM. Gdy skończysz z interfejsami użytkownika, które stają się coraz większe i większe, może to mieć wpływ na wydajność, ponieważ ciągłe odpytywanie DOM staje się kosztowne. Jeśli chcesz poznać typ interfejsu, w którym staje się to problemem, kliknij prawym przyciskiem myszy i sprawdź element na przycisku „Ulubione” na Twitterze lub przycisku „Lubię to” na Facebooku. I spójrz na zagnieżdżanie elementów div, które prowadzą do tego elementu. Jest bardzo, bardzo głęboka. To jak kilkanaście divów, zagnieżdżonych jeden w drugim tylko dla tego pojedynczego tweeta.

Chris: Kiedy zaczynasz schodzić tak wiele warstw w dół, zaczyna to naprawdę wpływać na wydajność. Wirtualny DOM zamiast za każdym razem sprawdzać prawdziwy DOM, tworzy opartą na obiektach mapę tego, jak wygląda interfejs użytkownika w JavaScript. A następnie robi to samo dla interfejsu użytkownika, którym chcesz zastąpić istniejący, i porównuje te dwa. To o wiele więcej w teorii, niż robienie tego w prawdziwym DOM. Gdy otrzyma listę rzeczy, które musi zmienić, po prostu ucieka i wprowadza te zmiany. Ale wystarczy zaatakować DOM tylko raz. Nie sprawdza każdego elementu za każdym razem. Jeśli masz interfejsy, takie jak Twitter, Facebook, QuickBooks lub coś w tym rodzaju, wirtualny DOM prawdopodobnie ma wiele sensu.

Chris: Wyzwaniem jest… różnica między Preact i React wynosi 27 kilobajtów, zanim rozpakujesz całość do rzeczywistej fali kodu. Sam czas pobierania, rozpakowywania i kompilowania może dodać sporo opóźnień do początkowego ładowania interfejsu użytkownika. Staje się to jeszcze bardziej widoczne, jeśli Twoi użytkownicy nie korzystają z najnowszych urządzeń Apple. Nawet urządzenie z Androidem sprzed kilku lat lub telefon z internetem, lub jeśli masz ludzi w krajach rozwijających się, to po prostu naprawdę… czas na rozpoczęcie działalności jest wolniejszy. Co więcej, rzeczywisty czas interakcji jest wolniejszy z powodu dodatkowej abstrakcji.

Chris: Więc nie chodzi tylko o to, że go ładujesz i są one porównywalne pod względem szybkości. Każda mikrointerakcja, którą ktoś wykonuje, i zmiany, które muszą nastąpić, mogą być również nieco wolniejsze tylko z powodu tego całego dodatkowego kodu. Jeśli masz naprawdę, naprawdę złożony interfejs użytkownika z dużą ilością zagnieżdżonych elementów i dużą ilością danych, to wzrost wydajności wirtualnego DOM przewyższa tę dodatkową wagę kodu. Ale każdy typowy interfejs użytkownika dla typowej aplikacji, do której większość programistów używa Reacta lub Vue, korzyści, jakie czerpiesz z wirtualnego DOM, po prostu nie ma i byłoby im lepiej. Nawet jeśli chcesz zachować tę samą wygodę Reacta, użyj Preact. To ułamek rozmiaru, będzie działać dokładnie w ten sam sposób i będzie bardziej wydajny. To jest rodzaj rzeczy, o które zwykle się kłócę.

Chris: Musimy być lepsi w doborze odpowiedniego narzędzia do pracy. Jeśli pójdziesz z takim podejściem, jeśli dojdziesz do punktu, w którym wirtualny DOM ma sens, znacznie łatwiej jest przenieść Preact do Reacta, niż gdybyś wyrzucił własny. Taka jest sytuacja. Jeśli naprawdę się tym martwisz, masz wbudowaną ochronę na przyszłość.

Drew: Niektórzy mogą powiedzieć, że mogą argumentować, że te frameworki, takie jak Vue, React są tak wysoce zoptymalizowane pod kątem wydajności, że czerpiesz z nich tak wiele korzyści, że z pewnością wystarczy połączyć to z menedżerem pakietów w pakiecie, aby się upewnić. ponownie wysyłasz tylko kod, który chcesz. Z pewnością jesteś daleko do przodu, robiąc to?

Chris: Tak. Nie zgadzam się. Tak naprawdę nie mam o wiele więcej do omówienia poza… chyba może, ale nie do końca. Nawet z pakowaczem nadal potrzebujesz rdzenia React. Nawet z pakietem, to wciąż będzie większe niż użycie czegoś takiego jak Preact.

Chris: Drew, naprawdę doceniam to, że kierujesz pytaniem w tej sprawie. Ponieważ jedną z innych rzeczy, o których mówię w mojej książce The Lean Web i mojej wypowiedzi o tej samej nazwie, jest to, jak te narzędzia… Wspomniałeś na przykład o sprzedaży wiązanej. Jedną z rzeczy, które robimy, aby obejść spadek wydajności, który uzyskujemy z używania całego tego JavaScriptu, jest wrzucanie jeszcze większej liczby JavaScript do interfejsu użytkownika, aby to uwzględnić. Jednym ze sposobów, w jaki to robimy, są menedżery pakietów i pakiety modułów.

Chris: Jak wspomniałeś… dla tych z was, którzy nie wiedzą, są to narzędzia, które… skompilują wszystkie twoje małe, indywidualne bity JavaScript w jeden duży plik. Te nowsze i tym bardziej… nie chcę ich nazywać rozważnymi. Ale nowsze będą używać funkcji zwanej potrząsaniem drzewa, w której pozbywają się kodu, który w rzeczywistości nie jest potrzebny. Jeśli ten kod ma jakieś zależności, które nie są używane do rzeczy, które faktycznie zrobiłeś, porzucą niektóre z tych rzeczy, aby twoje pakiety były jak najmniejsze. Właściwie nie jest to straszny pomysł, ale prowadzi do tego, co zwykle nazywam zdrowiem zależności, gdzie masz ten naprawdę delikatny domek z zależnościami na górze zależności i zależności.

Chris: Konfiguracja procesu wymaga czasu. I każdy, kto kiedykolwiek uruchomił instalację NPM, a potem odkrył, że kilka zależności jest nieaktualnych i musiał spędzić godzinę, próbując dowiedzieć się, które z nich wymagają naprawy, i och, to właściwie jest zależność w zależności, a ty nie nie mam możliwości samodzielnego naprawienia tego. To cała sprawa. Może to działa dla ciebie, ale wolałbym spędzać czas nie grzebać w próbach zebrania moich zależności.

Chris: Zacząłem zbierać tweety od ludzi, w których narzekają na marnowanie czasu na ich pracę. Jeden z moich ulubionych, Brad Frost kilka lat temu, mówił o przygnębiającym uświadomieniu sobie, że to, przez co przechodzisz we współczesnym JS, mogło ci zająć 10 minut w jQuery. Nie jestem fanem jQuery, ale odczuwam ten ból, jeśli chodzi o pracę z frameworkami.

Chris: Innym problemem związanym z wieloma tymi narzędziami jest to, że zaczynają być strażnikami. Nie wiem, jak bardzo chcesz się w to zagłębić czy nie, Drew. Ale jeden z moich wielkich sprzeciwów przeciwko JS, wszystkie rzeczy w przepływie pracy. Zwłaszcza, gdy zaczynasz wtedy mówić: „Cóż, jeśli już używamy JS w HTML, dlaczego nie użyć go również w CSS?” Zaczynasz wykluczać wiele naprawdę utalentowanych osób z procesu rozwoju. To po prostu naprawdę duża strata dla projektu dla całej społeczności.

Drew: No cóż, na pewno… Zacząłem zajmować się Reactem na początku 2020 roku, dodając to do mojego zestawu umiejętności. Robię to już prawie siedem miesięcy. Muszę powiedzieć, że jedną z części, co do której jestem najmniej pewny, jest przygotowanie narzędzi do rozpoczęcia projektu.

Drew: Wygląda na to, że jest strasznie dużo pracy, aby coś do Hello World, a jeszcze więcej musisz wiedzieć, aby przygotować to do produkcji. To musi utrudnić rozpoczęcie rozwoju, jeśli jest to przedstawiane jako to, co powinieneś robić w 2020 roku, aby nauczyć się być programistą internetowym. Ktoś, kto wejdzie do tego nowy, będzie miał prawdziwy problem. To będzie prawdziwa bariera wejścia, prawda?

Chris: Absolutnie. Innym elementem jest to, że programiści JavaScript nie zawsze są jedynymi osobami pracującymi nad bazą kodu lub wnoszącymi znaczący wkład w tę bazę kodu. Im bardziej znajomość języka JavaScript staje się wymogiem pracy z bazą kodu, tym mniej prawdopodobne jest, że osoby te będą mogły faktycznie uczestniczyć w projekcie.

Chris: Przykładem, o którym lubię mówić, jest WordPress, który ostatnio… nie powinienem mówić w tym momencie. Minęło już kilka lat. Ale coraz częściej przestawiają swój stos zaplecza na JavaScript, odchodząc od PHP, co nie jest z natury rzeczy złe. Ich nowy redaktor, Gutenburg, opiera się na React.

Chris: W 2018 r. główny konsultant WordPressa ds. ułatwień dostępu, Rian Rietveld, którego nazwisko prawie na pewno wyrżnąłem… bardzo publicznie zrezygnowała ze swojego stanowiska i udokumentowała dlaczego w bardzo szczegółowym artykule. Sedno problemu polegało na tym, że jej i jej zespołowi powierzono zadanie audytu tego edytora, aby upewnić się, że będzie on dostępny. WordPress obejmuje teraz 30% sieci. Ich celem jest demokratyzacja publikacji, więc dostępność jest naprawdę ważną częścią tego. Powinien być ważną częścią każdego projektu internetowego. Ale szczególnie dla nich jest to niezwykle ważne. Cała praca jej zespołu polega na upewnieniu się… Cała praca jej zespołu polega na upewnieniu się, że ten edytor będzie dostępny. Ale ponieważ ani ona, ani nikt z jej zespołu nie miał doświadczenia z React i ponieważ nie mogli znaleźć wolontariuszy w społeczności dostępności z takim doświadczeniem, to naprawdę utrudniło jej i jej zespołowi wykonywanie swojej pracy.

Chris: Historycznie mogli zidentyfikować błędy, a następnie wejść i je naprawić. Ale dzięki nowemu przepływowi pracy opartemu na React, ograniczono się do identyfikowania błędów, a następnie składania zgłoszeń. Zostały dodane do zaległości wraz ze wszystkimi innymi prośbami dotyczącymi rozwoju funkcji, nad którymi pracowali programiści JavaScript. Wiele rzeczy, które można było łatwo naprawić, nie trafiło do pierwszego wydania.

Chris: W maju 2019 roku, około rok po rezygnacji Riana, przeprowadzono szczegółowy audyt dostępności w Gutenburgu. Pełny raport liczył 329 stron. Samo streszczenie liczyło 34 strony. Szczegółowo udokumentował 91 błędów związanych z ułatwieniami dostępu. Wiele z nich było naprawdę… Nie chcę nazywać ich prostymi, nisko wiszącymi owocami, ale wiele z nich to podstawowe rzeczy, które zespół Riana mógł naprawić, a to pozwoliłoby programistom skupić się na rozwoju funkcji. W końcu wydaje się, że właśnie to zrobili, spędzając dużo czasu na opracowywaniu funkcji i odkładaniu tego na później. Ale ten zespół jest bardzo ważny dla projektu i nagle zostali zablokowani z procesu z powodu wyboru technicznego.

Chris: Alex Russell jest programistą w zespole Chrome. Napisał ten artykuł kilka lat temu zatytułowany The Developer Bait and Switch, w którym mówił o argumencie słomianym dotyczącym frameworków. To pomysł, że te narzędzia pozwalają Ci poruszać się szybciej i dzięki temu możesz szybciej iterować i dostarczać lepsze wrażenia. Chodzi o to, że lepsze wrażenia programisty oznaczają lepsze wrażenia użytkownika. Myślę, że jest to bardzo wyraźny przykład tego, jak ten argument nie zawsze przebiega tak, jak ludzie wierzą, że ma. To może być lepsze doświadczenie dla niektórych osób, nie dla wszystkich.

Chris: Deweloperzy CSS, ludzie pracujący nad systemami projektowania, ich zdolność do tworzenia narzędzi, z których mogą korzystać inni, jest czasami również ograniczona przez wybór tych narzędzi. Z mojego doświadczenia byłem lepszy w CSS. Wiele się zmieniło w ciągu ostatnich kilku lat i nie jestem już tak dobry, jak kiedyś. Z mojego doświadczenia wynika, że ​​ludzie, którzy są naprawdę zaawansowanymi programistami CSS… i mam na myśli to w najprawdziwszym tego słowa znaczeniu. Osoby, które pracują nad CSS to prawdziwi programiści stron internetowych pracujący nad językiem programowania. To bardzo wyjątkowa lub bardzo wyspecjalizowana rzecz. Z mojego doświadczenia wynika, że ​​ludzie, którzy są w tym wyjątkowo dobrzy, nie zawsze są również bardzo dobrzy w JavaScript, ponieważ w końcu zagłębiasz się w jedną rzecz i trochę poślizgujesz się na innych. Ich zdolność do pracy z tymi technologiami również zostaje utrudniona, co jest bardzo złe, ponieważ kiedyś tak nie było.

Chris: Kiedy stos był prostszy, osobom z wielu dyscyplin łatwiej było uczestniczyć w procesie tworzenia. Myślę, że dzieje się to ze szkodą zarówno dla rzeczy, które budujemy, jak i całej społeczności, kiedy już tak nie jest.

Drew: Niedawno odkryłem, że w projekcie badającym sposoby radzenia sobie z niektórymi problemami CSS, problemami z przepływem pracy, pracujemy nad projektem wiele razy i zwiększamy rozmiar pakietu, a stary CSS nigdy nie jest usuwany. Był to projekt React, więc przyglądaliśmy się niektórym z tych podejść CSS w JavaScript, aby zobaczyć, co byłoby dla nas najlepsze do rozwiązania problemów, które mieliśmy. Bardzo szybko okazało się, że nie ma na to tylko jednego rozwiązania. Można to zrobić na dziesiątki różnych sposobów.

Drew: CSS w JS to podejście ogólne, ale możesz przechodzić od jednego projektu do drugiego i ma to zupełnie inny wpływ. Nawet jeśli jesteś osobą zajmującą się CSS i uczysz się określonego podejścia w projekcie, te umiejętności i tak mogą nie być przeniesione. Bardzo trudno jest zrozumieć, jak ktoś powinien poświęcać zbyt dużo czasu na naukę tego, jeśli nie jest zbyt obeznany z JavaScriptem.

Chris: Tak. Inną interesującą rzeczą, o której myślę, że właśnie trochę się wyjawiłeś, jest to, że kiedy o tym mówię, jednym z największych odepchnięć, jakie otrzymuję, jest to, że frameworki wymuszają konwencje. Idziesz z Vanilla JavaScript, masz to zielone pole-błękitne niebo, możesz zrobić wszystko, co chcesz, rodzaj projektu. Z Reactem jest sposób na robienie rzeczy w React.

Chris: Ale jedną z rzeczy, które odkryłem, jest to, że istnieją podejścia Reacty, ale nie ma jednego właściwego sposobu robienia rzeczy z Reactem. To jedna z rzeczy, które ludzie w nim kochają. Jest trochę bardziej elastyczny, możesz robić rzeczy na kilka różnych sposobów, jeśli chcesz. To samo z Vue. Możesz użyć tego opartego na HTML, w którym masz swoje właściwości bezpośrednio w HTML, a Vue je zastąpi, ale możesz także użyć bardziej podobnej do JSX składni, jeśli wolisz.

Chris: Słyszałem, że wielu ludzi narzeka, kiedy uczą się Reacta, jednym z największych problemów jest to, że Google robi X w React i dostajesz tuzin artykułów, w których mówi się o tuzinie różnych sposobów, w jakie możesz to zrobić. Nie oznacza to, że nie stawiają barier ochronnych w projekcie. Nie sądzę, że jest to tak jasne, jak: „Wybrałem ramy. Teraz w ten sposób buduję z nim.” Szczerze mówiąc, nie wiem, czy to jest coś, czego bym chciał. Nie sądzę, żebyś chciał tych ciasno zamkniętych… może niektórzy ludzie. Ale jeśli zachwalasz to jako korzyść, nie sądzę, że jest to tak wyraźne, jak ludzie czasami to uważają.

Chris: Wpadłeś w ciekawą rzecz właśnie tam, gdzie wspomniałeś o CSS, który nie jest już potrzebny. Myślę, że jest to jedna z prawnie interesujących rzeczy, którą coś takiego jak CSS i JS… lub powiązanie w jakiś sposób CSS z komponentami JavaScript może sprawić, że jeśli ten komponent odpadnie, CSS również teoretycznie zniknie. Wiele z tego wydaje mi się rzucaniem inżynierii na problemy ludzi. Niezmiennie nadal jesteś zależny od ludzi gdzieś po drodze. Nie oznacza to, że nigdy nie używaj tych podejść, ale z pewnością nie są one jedynym sposobem rozwiązania tego problemu.

Chris: Istnieją narzędzia, których możesz użyć do audytu kodu HTML i wyciągnięcia stylów, które nie są używane, nawet bez użycia CSS i JavaScript. Możesz pisać CSS „w staromodny sposób” i nadal robić linting nieużywanych stylów. Istnieją autorskie podejścia do CSS, które dają CSS w postaci wyjściowej podobnej do JS i utrzymują mały arkusz stylów bez wypluwania tych bełkotliwych, nieczytelnych dla ludzi nazw klas, które czasami otrzymujesz w CSS i JS. Jak X2354ABC lub po prostu te bezsensowne słowa, które są wypluwane.

Chris: W tym momencie zaczynam naprawdę interesować się tym, co staruszek krzyczy na chmurę. Naprawdę pokazuję tutaj swój wiek programisty. Ale tak, niekoniecznie te rzeczy są złe i mają na celu rozwiązywanie uzasadnionych problemów. Czasami wydaje mi się, że jest trochę… jeśli jest wystarczająco dobre dla Facebooka, to jest wystarczająco dobre dla nas, co się z nimi dzieje. Cóż, Facebook używa tego narzędzia. Jeśli jesteśmy prawdziwym programem inżynierskim… zespołem, działem, organizacją, my też powinniśmy. Niekoniecznie uważam, że to właściwy sposób myślenia o tym. Dzieje się tak, ponieważ Facebook zajmuje się problemami, których Ty nie masz i na odwrót. Rozmiar i skala tego, nad czym pracują, jest po prostu inny i to jest w porządku.

Drew: Dokładnie. Widzę, że niektóre z tych rzeczy, takie jak CSS i JavaScript, są prawie jak wypełnienie. Mamy uzasadnione problemy, potrzebujemy sposobu na ich rozwiązanie. Technologia nie daje nam jeszcze sposobu na rozwiązanie tego problemu. Może podczas gdy czekamy, aż platforma internetowa rozwinie się i zajmiemy się rozwiązaniem tego problemu, ta rzecz, którą teraz robimy z JavaScriptem, przeprowadzi nas przez to i wszystko będzie dobrze. Wiemy, że to złe. Wiemy, że to nie jest świetne rozwiązanie, ale w tej chwili nam pomaga. I miejmy nadzieję, że za jakiś czas możemy go wyciągnąć i użyć natywnego rozwiązania.

Chris: To naprawdę zabawne, że o tym wspominasz. Ponieważ dosłownie wczoraj wieczorem oglądałem wykład Jeremy'ego Keitha z zeszłego roku o progresywnych aplikacjach internetowych. Ale mówił o tym, jak kilka dekad temu próbował przekonać ludzi do używania JavaScript. Co wtedy wydaje się śmieszne, ale JavaScript był tą nową rzeczą. Pokazał ludziom, jak można robić fajne rzeczy, takie jak zmiana koloru linku po najechaniu myszą za pomocą tego nowego… Wydaje się absurdalne, że teraz potrzebujesz do tego JavaScript, ponieważ to właśnie robi dla ciebie CSS. Ale takie rzeczy jak atrybut lub właściwość fokusa po prostu nie istniały w tym czasie.

Chris: Jedną z rzeczy, które powiedział w przemówieniu, która moim zdaniem naprawdę przemówiła do mnie, jest to, że JavaScript na wiele sposobów toruje krowie ścieżki. Jest to bardzo elastyczny i otwarty język, którego możemy używać do tworzenia lub dołączania funkcji, które jeszcze nie istnieją. W końcu przeglądarki nadrabiają zaległości i implementują te funkcje w bardziej natywny sposób. Ale to wymaga czasu. Całkowicie rozumiem, co o tym mówisz. Nie jest to idealne rozwiązanie, ale takie mamy teraz.

Chris: Myślę, że największą różnicą między wypełniaczami a niektórymi z tych rozwiązań jest to, że są one zaprojektowane do wyrywania. Jeśli mam funkcję, którą chcę zaimplementować, której przeglądarka jeszcze nie obsługuje, ale jest dla niej jakaś specyfikacja i piszę wypełnienie… jak tylko przeglądarki nadrobią zaległości, mogę je zgrać i nie muszę zmienić wszystko. Ale kiedy pójdziesz dalej ścieżką używania niektórych z tych narzędzi, wyrwanie ich oznacza przepisanie całej bazy kodu. To naprawdę drogie i problematyczne. Nie oznacza to, że nigdy ich nie używaj, ale czuję się naprawdę mocno, że powinniśmy zastanowić się nad wyborem narzędzi, które można później łatwo wyciągnąć. Jeśli już ich nie potrzebujemy lub platforma nadrabia zaległości, wyciągnięcie ich nie wymaga wielkiego przepisywania.

Chris: Dochodząc do tego, mamy całą masę stylów, których już nie używamy, dlatego osobiście preferowałbym technologię narzędzia do budowania, która sprawdza twój CSS pod kątem renderowanych znaczników i wyciąga rzeczy, których nie potrzebujesz. Ponieważ po drodze, jeśli platforma dogoni, możesz wyciągnąć ten element narzędzia do budowania bez konieczności zmiany wszystkiego. To tylko powiększanie tego, co już masz, podczas gdy CSS i JS nie dają ci tego samego rodzaju korzyści. Po prostu się wybieram, ale myślę o wielu z tych technologii szerzej.

Chris: Czuję, że rzeczy takie jak React lub Vue prawdopodobnie torują krowie ścieżki, które przeglądarki w końcu dogonią i prawdopodobnie stosują podobne podejścia, jeśli nie takie same, więc może być mniej przepisywania. Wiele elementów ekosystemu, które są podłączane, może być mniej.

Drew: Myślę, że to prawda, prawda, że ​​platforma internetowa porusza się powoli i ostrożnie. Myślisz, że pięć lat temu wszyscy umieszczaliśmy na naszych stronach karuzele JavaScript. Byli wszędzie. Wszyscy wdrażali karuzele JavaScript. Gdyby platforma internetowa przeskoczyła i zaimplementowała rozwiązanie karuzelowe, aby zaspokoić tę potrzebę, nie siedziałaby tam, gdzie nikt z niej nie korzystał, ponieważ ludzie nie robią już tego z karuzelami. Ponieważ to była tylko moda, trend w projektowaniu. Aby temu przeciwdziałać i powstrzymać rozdęcie się platformy i przekształcenie się w problem wymagający rozwiązania, musi ona poruszać się w znacznie wolniejszym tempie. The upshot of that is HTML that I wrote in 1999 still works today because of that slow process.

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

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

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

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

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

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

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

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

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

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

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

Chris: Yep.

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

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

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

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

Chris: Yes.

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

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

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

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

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

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

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

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

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

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

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

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

Chris: Jedną z innych rzeczy, w które nie zagłębiliśmy się tak bardzo, jak bym chciał, ale myślę, że jest to bardzo ważne, jest to, że platforma bardzo dogoniła w ciągu ostatnich kilku lat. Przyjęcie tego w jak największym stopniu zaowocuje szybszym, mniej wrażliwym doświadczeniem w sieci, które jest łatwiejsze do zbudowania i utrzymania, ponieważ wymaga mniejszej liczby zależności, takich jak korzystanie z tego, co daje przeglądarka. -pudełko. Kiedyś potrzebowaliśmy jQuery do wybierania rzeczy takich jak klasy. Teraz przeglądarki mają na to natywne sposoby. Ludzie lubią JSX, ponieważ pozwala pisać HTML w JavaScript w bardziej płynny sposób. Ale mamy również literały szablonów w Vanilla JavaScript, które zapewniają ten sam poziom łatwości bez dodatkowej zależności. Sam HTML może teraz zastąpić wiele rzeczy, które kiedyś wymagały JavaScript, co jest absolutnie niesamowite.

Chris: Rozmawialiśmy trochę o… to jest kwestia CSS, ale unosi się kursorem nad linkami i jak to wymagało JavaScriptu. Ale używając elementów takich jak szczegóły i elementy podsumowania, możesz tworzyć ujawnienia, takie jak rozwijanie i zwijanie lub elementy akordeonowe natywnie bez konieczności tworzenia skryptów. Możesz wykonać autouzupełnianie danych wejściowych za pomocą… Nie powinienem mówić po prostu, nienawidzę tego słowa. Ale używając skromnego elementu wejściowego, a następnie elementu listy danych, który zostaje z nim powiązany, z pewnymi opcjami. Jeśli jesteś ciekawy, jak działają te rzeczy na vanillajstoolkit.com, mam kilka rzeczy związanych z JavaScriptem, które daje ci platforma. Ale mam też kilka, które wymagały JavaScript, a teraz nie mam rzeczy, które mogą być interesujące, jeśli chcesz, aby niektóre próbki kodu pasowały do ​​tego.

Chris: Jeśli chodzi o CSS, moją najpopularniejszą wtyczką Vanilla JS w historii jest ta biblioteka, która pozwala animować przewijanie w dół, aby zakotwiczyć linki. To jest bardzo duże. To najtrudniejszy fragment kodu, jaki kiedykolwiek musiałem napisać. A teraz jest całkowicie zastąpiony jedną linią CSS, zachowanie przewijania jest płynne. Jest bardziej wydajny. Łatwiej jest pisać. Łatwiej jest zmodyfikować jego zachowanie. To po prostu lepsze ogólne rozwiązanie.

Chris: Jedną z innych rzeczy, o których chciałbym zrobić więcej, jest oparcie się na aplikacjach wielostronicowych. Czuję się tutaj trochę usprawiedliwiony, ponieważ niedawno widziałem artykuł od kogoś z Google, który faktycznie naciska na takie podejście teraz. Pomyślałem, że to całkiem interesujące, biorąc pod uwagę ten ogromny kąt, a potem framework… wszystkie rzeczy, boom, które Google zaczął kilka lat temu. Fajnie widzieć, jak do tego wracają. Używając takich rzeczy, jak statyczne generatory witryn i niesamowite usługi, takie jak Netlify i buforowanie CDN, możesz tworzyć niewiarygodnie szybkie środowiska internetowe dla osób korzystających z indywidualnych plików HTML dla wszystkich różnych widoków. Więc opieram się na niektórych z tych nieszablonowych rzeczy.

Chris: W sytuacjach, w których nie jest to dla ciebie realistyczne, gdy potrzebujesz więcej JavaScriptu, potrzebujesz jakiejś biblioteki, być może najpierw przyjrzyj się mniejszym i bardziej modułowym podejściom, zamiast po prostu iść do gigantów branży. Czy zamiast React zadziała Preact? Zamiast kątowego… mam na myśli, czy zamiast Vue zadziałałby Alpine JS? Istnieje również naprawdę interesujący pre-kompilator, który teraz nazywa się Svelt, który daje ci doświadczenie podobne do frameworka, a następnie kompiluje cały twój kod do Vanilla JavaScript. Otrzymujesz więc te naprawdę małe pakiety, które zawierają tylko to, czego potrzebujesz i nic więcej. Czy zamiast CSS i JavaScript możesz wpiąć się do jakiegoś zewnętrznego lintera CSS, który porówna Twój HTML z Twoim CSS i wyciągnie rzeczy, które zostały tam przypadkowo? Czy zamiast tego zadziałałby inny sposób tworzenia CSS, na przykład CSS zorientowany obiektowo autorstwa Nicole Sullivan? Tak naprawdę nie rozmawialiśmy o tym, ale to naprawdę fajna rzecz, którą ludzie powinni sprawdzić.

Chris: A potem myślę, że może trzeci i najważniejszy element tutaj, chociaż nie jest to konkretne podejście, a bardziej po prostu chciałbym, aby więcej osób pamiętało, że sieć jest dla wszystkich. Wiele narzędzi, z których dzisiaj korzystamy, działa dla osób, które mają dobre połączenia internetowe i wydajne urządzenia. Ale nie działają dla osób, które korzystają ze starszych urządzeń, mają niestabilne połączenia internetowe. To nie tylko ludzie w rozwijających się obszarach. Dotyczy to również osób w Wielkiej Brytanii, w niektórych częściach Stanów Zjednoczonych, gdzie mamy absolutnie fatalne połączenia internetowe. Środek naszego kraju ma bardzo wolny internet. Wiem, że są miejsca w Londynie, w których nie można podłączyć nowego łącza szerokopasmowego z powodów historycznych, więc pozostajesz ze starymi połączeniami internetowymi, które są naprawdę złe. Na całym świecie są takie miejsca. Ostatni raz byłem we Włoszech, to samo. Internet był okropny. Nie wiem, czy to się zmieniło od tamtego czasu.

Chris: Rzeczy, które dzisiaj budujemy, nie zawsze działają dla wszystkich, a to szkoda. Ponieważ wizja sieci, to, co w niej kocham, to to, że jest to platforma dla absolutnie każdego.

Drew: Jeśli słuchacze chcą dowiedzieć się więcej o tym podejściu, szczegółowo opisałeś je w swojej książce The Lean Web. I to jest dostępne online. Czy jest to książka fizyczna czy cyfrowa?

Chris: To trochę jedno i drugie. Więc nie. To na pewno nie jest fizyczna książka. Wchodzisz na leanweb.dev. Całość można przeczytać za darmo online. Możesz też, jeśli chcesz, dostępne są wersje EPUB i PDF za naprawdę małe pieniądze, teraz zapomniałem ile. Dawno temu nie patrzyłem. Całość jest bezpłatna online, jeśli chcesz. Możesz również obejrzeć wykład na ten temat, w którym wchodzę w szczegóły, jeśli chcesz.

Chris: Ale przygotowałem też specjalną stronę tylko dla słuchaczy Smashing Podcast na gomakethings.com/smashingpodcast, ponieważ jestem bardzo kreatywny w nazywaniu rzeczy. Obejmuje to wiele zasobów oprócz książki, dotyczących rzeczy, o których rozmawialiśmy dzisiaj. Odwołuje się do wielu różnych technik, które omówiliśmy, innych artykułów, które napisałem, które zagłębiają się w niektóre z tych tematów i nieco poszerzają moje myślenie. Jeśli ludzie chcą dowiedzieć się więcej, prawdopodobnie byłoby to najlepsze miejsce do rozpoczęcia.

Drew: To wspaniale. Dziękuję Ci. Dowiedziałem się wszystkiego o Lean Web. O czym się ostatnio dowiedziałeś, Chris?

Chris: Tak, kilka rzeczy. Nawiązałem do tego nieco wcześniej, oglądając wideo Jeremy'ego w progresywnych aplikacjach internetowych. Od kilku lat odkładam naukę pisania własnej progresywnej aplikacji internetowej, ponieważ nie miałem konkretnych potrzeb w zakresie niczego, z czym pracowałem. Niedawno dowiedziałem się od jednego z moich uczniów, który jest w RPA, że mają do czynienia z ciągłymi zaciemnieniami z powodu pewnych rzeczy, które mają tam miejsce. W rezultacie nie jest w stanie pracować nad niektórymi projektami, które prowadzimy regularnie razem, ponieważ gaśnie moc i nie może uzyskać dostępu do portalu edukacyjnego i kontynuować.

Chris: Dla mnie teraz budowanie doświadczenia, w którym działa, nawet jeśli ktoś nie ma internetu, stało się ważniejszym priorytetem niż… Zdałem sobie sprawę, że może tak było wcześniej, więc po prostu zacząłem się w to wgłębiać i mam nadzieję, że uda mi się to połączyć. przez następne kilka tygodni. Zobaczymy. Jednak zasoby Jeremy'ego Keitha w tym zakresie były absolutnym ratunkiem. Cieszę się, że istnieją.

Chris: Wiem, Drew, wspomniałeś, że jednym z powodów, dla których lubisz zadawać to pytanie, jest pokazanie, że ludzie, bez względu na to, jak bardzo są doświadczeni, zawsze się uczą. Tylko mała powiązana anegdota. Jestem web developerem chyba od ośmiu lat. Nadal muszę Google właściwość CSS, aby użyć do tworzenia kursywy, dosłownie za każdym razem, gdy jej używam. Z jakiegoś powodu mój mózg domyślnie wybiera dekorację tekstu, mimo że to nie jest właściwe. Spróbuję kilku kombinacji różnych rzeczy i za każdym razem mam niepoprawne jedno słowo. Czasami piszę kursywę zamiast kursywy. Tak. Jeśli ktokolwiek kiedykolwiek poczuje, że nigdy się tego nie nauczę… po prostu wiedz, że bez względu na to, jak bardzo jesteś doświadczony, zawsze jest jakaś podstawowa rzecz, którą Google ciągle i od nowa.

Drew: Jestem programistą stron internetowych od 22, 23 lat i wciąż muszę wyszukiwać w Google różne właściwości Flexbox, za każdym razem. Chociaż używam tego od 23 lat. Ale tak, niektóre rzeczy po prostu… prawdopodobnie będzie ich więcej, kiedy dorosnę.

Chris: Tak. Szczerze mówiąc, skończyło się na zbudowaniu całej witryny internetowej z rzeczami, które Google wielokrotnie, tylko po to, aby mieć łatwiejsze odniesienie do kopiowania i wklejania, ponieważ było to łatwiejsze niż Google.

Drew: To nie jest zły pomysł.

Chris: Taki jestem leniwy. Zbuduję całą witrynę, żeby zaoszczędzić sobie jak trzy sekundy googlowania.

Drew: Jeśli jesteś słuchaczem, chciałbyś usłyszeć więcej od Chrisa, możesz znaleźć jego książkę w sieci na leanweb.dev, biuletyn z poradami dla programistów i nie tylko na gomakethings.com. Chris jest na Twitterze w Chris Ferdinandi. I możesz sprawdzić jego podcast na vanillajspodcast.com lub gdziekolwiek zwykle otrzymujesz swoje podcasty. Dzięki za przybycie do nas dzisiaj, Chris. Czy masz jakieś pożegnalne słowa?

Chris: Nie. Dziękuję bardzo, że mnie masz, Drew. Miałem absolutnie niesamowity czas. To była świetna zabawa. Naprawdę doceniam możliwość przyjścia na pogawędkę.