32 odcinek Smashing Podcast: Recenzja Roku 2020

W tym odcinku spoglądamy wstecz na rok 2020. Z kim rozmawialiśmy w naszych odcinkach w tym roku i czego się nauczyliśmy? Posłuchajmy kilku klipów, aby się dowiedzieć.

Pokaż notatki

Wszystkie nasze poprzednie odcinki, w tym pełny zapis każdego wywiadu, można znaleźć na stronie podcast.smashingmagazine.com.

Do zobaczenia w 2021 wszyscy!

Transkrypcja

Drew McLellan: W styczniu rozmawiałem z Amy Hupe o jej pracy nad systemem projektowym rządu Wielkiej Brytanii, aw szczególności o tym, w jaki sposób zespół zwiększył adopcję systemu przez szerszą organizację poprzez zachęcanie do wkładu. Oto Amy.

Amy Hupe: Zaczęliśmy bardzo wcześnie. Tak więc zanim stworzyliśmy rodzaj publicznego systemu projektowania, zaczęliśmy kontaktować się z ludźmi, o których myśleliśmy, że mogą być zainteresowanymi współpracownikami. Powinienem tutaj wspomnieć, że mieliśmy w zespole genialnego projektanta usług. Dołączyła do nas… W tej chwili nie zamierzam podawać prawidłowych dat, ale myślę, że pracowała z nami przez cały rok 2018 i ma na imię Ignacia. Po prostu wykonała fantastyczną robotę, poruszając się i angażując ludzi. Więc jedną z rzeczy, które zrobiła, było zidentyfikowanie wszystkich różnych wzorców w rządzie i wszystkich rodzajów odmian tych wzorców. Wychodzimy więc i mówimy: „W porządku. Istnieje 10 różnych sposobów, aby poprosić o adres w urzędzie. Przyjrzyjmy się im wszystkim razem i zdecydujmy, które według nas jest najbardziej odpowiednie. Jak możemy je połączyć w jedno?”

Amy Hupe: Prowadziła duże warsztaty, aby spróbować zachęcić ludzi do patrzenia na to i robienia tego rodzaju konsolidacji jako zespołu. Myślę, że zdecydowanie jej podejście do budowania współpracy, zanim wydaliśmy cokolwiek publicznie, naprawdę pomogło w tym, ponieważ oznaczało to, że ludzie już mieli tego rodzaju świadomość, a wiele osób już przyczyniło się do tego w jakiś sposób lub inny, zanim faktycznie upubliczniliśmy go. Więc byliśmy już o kilka kroków do przodu. Więc myślę, że to było naprawdę ważne i po prostu wytrwałość, dużo wytrwałości całego zespołu w pomaganiu ludziom w przyczynianiu się do tego.

Amy Hupe: Myślę, że jest taki pomysł, że jeśli zachęcisz ludzi do wniesienia wkładu do systemu projektowania, to całkiem fajna sprawa, ponieważ możesz po prostu sprawić, by ludzie wykonali całą pracę za ciebie, a ty po prostu siedzisz i dokonaj małych poprawek w kodzie, a wszyscy faktycznie dają ci wszystkie dobre rzeczy. Ale w rzeczywistości, jak wie każdy, kto pracował nad systemem projektowania, jest to niesamowicie złożone. Bardzo trudno jest stworzyć scentralizowane rozwiązanie, które działa dla wielu różnych zespołów.

Amy Hupe: Naprawdę, o ile nie pracowałeś nad systemem projektowania, nie jest rozsądne oczekiwać, że ktokolwiek naprawdę zrozumie, czego to wymaga. Więc jest wiele rodzajów trzymania się za ręce. Wspieranie współtwórców wymaga dużo pracy. Myślę, że powiedziałem to już wcześniej, ale myślę, że pomaganie komuś we wniesieniu wkładu do systemu projektowania zajmuje więcej czasu niż zrobienie tego samemu i scentralizowanemu zespołowi. Ale myślę, że uznając wartość, jaką to niesie i wytrwale w swoich wysiłkach, aby uświadomić ludziom swój wkład, pomóc im to zrobić, pomóc im poczuć motywację do tego, myślę, że tak, wytrwałość była naprawdę kluczowa do nasz sukces w tej dziedzinie.

Drew: Dołączyli do nas Stephanie Stimac z Microsoftu i Aaron Gustafson, aby porozmawiać o tym, że Edge przyjął Chromium jako silnik renderujący. Zapytałem Aarona o konkurencyjny krajobraz między przeglądarkami i o to, gdzie wiele przeglądarek połączonych na tym samym silniku renderującym wyeliminowałoby tę zdrową konkurencję, a zatem byłoby szkodliwe dla otwartej sieci.

Aaron Gustafson: Jest to coś, z czym zdecydowanie od dawna jestem osobą zajmującą się standardami sieciowymi, z którą trochę się zmagam. Całkowicie rozumiem uzasadnienie biznesowe. Z punktu widzenia Microsoftu miało to sens. Z perspektywy dewelopera front-endu fajnie jest nie musieć zajmować się wieloma różnymi silnikami. Ogólnie rzecz biorąc, ci z nas, którzy od dłuższego czasu pracują w sieci, z pewnością zauważyli dużą zbieżność pod względem renderowania. Nie mamy tylu problemów, co mieliśmy, powiedzmy w Netscape przez siedem dni, gdzie mieliśmy po prostu… Znałem firmy, które tworzyły unikalne arkusze stylów dla każdej innej przeglądarki, co było po prostu nie do utrzymania.

Aaron Gustafson: Ale myślę, że to, co się teraz zmieniło, to to, że w pierwotnych wojnach przeglądarkowych mieliście wszystkie te zastrzeżone silniki i każdy był w pewnym sensie w grze o jedności, próbując dostarczać nowe funkcje platformy i nowe funkcje JavaScript lub w przypadku Microsoft odwrotnej inżynierii JavaScript w celu stworzenia JScript i próby wymyślenia, jak to wszystko dopasować.

Aaron Gustafson: Ale teraz mamy możliwość współpracy w projektach open source i nadal prowadzimy dialog i nadal… nie wiem. Walka nie jest właściwym słowem, ale poważne dyskusje na temat wpływu różnych podejść i niezgadzanie się ze sobą oraz praca nad naprawdę dobrymi specyfikacjami, a także posiadanie konkurencyjnych podejść do bazowego kodu w kontekście, powiedzmy Chromium projekt lub WebKit lub coś w tym rodzaju lub Missoula w przestrzeni Firefoksa.

Aaron Gustafson: Więc tak. Z jednej strony straciliśmy kolejny silnik renderujący i poczułem ten sam ból, gdy opera zdecydowała się przejść na Chromium. Ale czuję się nieco pokrzepiony, będąc w Microsoft i widząc, jak bardzo jesteśmy zaangażowani w rzeczywiste uczestnictwo w projekcie Chromium w znaczący sposób, a nie tylko siedzenie i akceptowanie wszystkiego, co pochodzi z Chromium, ale właściwie sprawdzanie tego, co się dzieje. platformę i uczestnictwo w tym… Tak.

Aaron Gustafson: Więc trochę mnie to pokrzepia i czuję, że nie jesteśmy tam tylko po to, by czerpać z tego projektu i po prostu akceptować wszystko, co zostało przekazane przez wszystkich różnych ludzi, którzy mają udział w tym projekcie, ale aby rzeczywiście tam również współpracować.

Drew: W lutym rozmawiałem ze Stephanie Walter o pracy z frameworkami interfejsu użytkownika, takimi jak Bootstrap i przyjaciele, i zrównoważeniu tego z niestandardowymi potrzebami użytecznego interfejsu. Zapytałem Stephanie, czy było możliwe stworzenie wysoce użytecznego interfejsu użytkownika podczas korzystania z gotowego frameworka, czy też zawsze będzie to trochę niezręczny kompromis.

Stephanie Walter: Tak. Myślę, że to jest. Ale zależy to również od poziomu kompromisu, jaki jesteś w stanie poczynić, i to jest kompromisem po obu stronach. W tej chwili kompromituję wiele przycisków, na przykład, ponieważ masz naprawdę specyficzne przyciski w materialnym interfejsie użytkownika. Nie podoba mi się efekt ripple na przycisku. Myślę, że działa to świetnie na urządzeniach mobilnych, ponieważ na urządzeniach mobilnych potrzebujesz pewnego rodzaju dużej informacji zwrotnej, gdy użytkownik kliknie lub dotknie przycisku. Ale potem wkraczają w ten rodzaj efektu falowania, który przechodzi aż do przycisku. To trochę przesada, zwłaszcza gdy jest dużo przycisków. Ale nadal zamierzamy zachować ten efekt, ponieważ usunięcie go byłoby bardzo skomplikowane, ponieważ zostało to wbudowane w framework React i aby mieć kolejny efekt najechania na ten przycisk, coś bardziej subtelnego, co nie byłoby tak krzaczaste tutaj. To byłoby bardzo złożone. Więc to jest rodzaj kompromisów, które robisz.

Drew: Etyczny projekt był tematem mojej rozmowy z Triną Felber i Martinem Michaelem Fredricksonem. Zapytałem, czy przyjmowanie etycznego podejścia do projektowania i unikanie ciemnych wzorców było kwestią długoterminowego myślenia o kondycji i rozwoju firmy, a nie tylko krótkoterminowych celach sprzedażowych. Oto Martin.

Martin Michael Fredrickson: To prawda. Myślę, że musisz patrzeć na biznes, który prowadzisz w Internecie, jak na sklep przy głównej ulicy w średniej wielkości mieście, w którym musisz zachować nienaruszoną reputację. Jeśli nie traktujesz swoich klientów dobrze, to jeśli nie traktujesz swoich klientów dobrze, na dłuższą metę skończy Ci się biznes, ponieważ ludzie pójdą do innego sklepu lub będą kupować w Internecie. Więc cokolwiek robisz online, naprawdę musisz myśleć, że ma to długofalowy efekt, a także, że istnieje ukryty koszt robienia rzeczy, które są złożone lub rzeczy, które manipulują. Jeśli posprzątasz, jak mówi Trina, zaoszczędzisz na dłuższą metę, a to nigdy nie jest obliczane, gdy mówisz o modelu biznesowym. Zawsze mówisz o tym, ile możesz zarobić. Nigdy nie mówisz o kosztach zarobienia takiej sumy pieniędzy.

Drew: W marcu rozmawiałem z Eduardo Boucasem o narzędziu open source o nazwie Sourcebit, które zbiera treści z różnych źródeł i udostępnia je generatorowi stron statycznych. Zapytałem Eduardo, czy może to poprawić wrażenia użytkownika związane z autoryzacją SSG poprzez umożliwienie integracji z narzędziami, takimi jak bezgłowy CMS.

Eduardo Boucas: Dokładnie. Tak. Sposób, w jaki mogłoby… Widzę dwa różne sposoby wykorzystania narzędzia, które może pomóc programistom. Jednym z nich jest włączenie Sourcebit do procedury wdrażania. Więc jeśli używasz platformy hostingowej, takiej jak Netlify, na przykład, i skonfigurujesz swoje polecenia wdrażania tak, aby były, nie wiem, kompilacją Hugo, czy to jest poleceniem kompilacji dla Hugo lub czymś podobnym, rodzajem polecenia, które generuje pliki statyczne dla Hugo. W ramach tej procedury miałbyś również inne polecenie. To byłoby coś w stylu pobierania Sourcebit. Tak więc w czasie kompilacji Sourcebit pobierze wszystkie inne dane, wygeneruje wszystkie pliki, których potrzebuje Hugo, a następnie całe wdrożenie będzie już używało tych plików i wdrożyło całą zawartość pochodzącą z CMS.

Eduardo Boucas: To jeden z możliwych przypadków użycia Sourcebita. Drugim jest użycie Sourcebit jako lokalnego rozwoju w przepływie pracy lokalnego rozwoju. Możesz więc uruchomić Sourcebit z czymś, co nazywamy trybem zegarka. Więc Sourcebit wciąż szuka zmian w zdalnym źródle danych, czyli w tym przypadku bezgłowym CMS. Więc za każdym razem, gdy opublikujesz artykuł lub zmienisz wpis w CMS, Sourcebit to potwierdzi i zregeneruje wszystkie pliki lokalnie.

Eduardo Boucas: Dla programisty pracującego lokalnie oznacza to, że możesz mieć swoje okno CMS obok swojej witryny Hugo działającej lokalnie, a następnie możesz obserwować zmiany zachodzące w czasie rzeczywistym. Zmieniasz coś w CMS, a potem możesz zobaczyć, jak ta zmiana jest odzwierciedlona na lokalnej stronie, co uważam za bardzo przydatne. To są dwa sposoby na wykorzystanie Sourcebit.

Drew: Optymalizacja konwersji była tematem dnia. Kiedy rozmawiałem z doświadczonym podcasterem i konsultantem, Paulem Boagiem. Rozmawialiśmy o niektórych technikach używanych przez witryny do przekształcania odwiedzających w klientów. Ale chciałem zapytać Paula, jak mierzysz wpływ wprowadzanych zmian. Paweł wyjaśnił.

Paul Boag: Tak. Absolutnie. Myślę, że jest to coś, w czym wiele organizacji jest dość słabych, jeśli chodzi o jasne, jak będą mierzyć sukces. Teraz tak, Twój współczynnik konwersji to jedna metryka. Powinieneś bezwzględnie podążać. Ale nawet przy konwersji musisz być trochę bardziej wyrafinowany niż to, ile osób kupuje. Należy również zwrócić uwagę na średnią wartość zamówienia. Musisz zwrócić szczególną uwagę na wartość życiową, prawda? A więc ile jest wart klient przez całe życie, ponieważ może się okazać, że masz dość dużą rotację klientów, jeśli użyjesz ciemnych wzorów i tym podobnych rzeczy. Ale tak naprawdę konwersja powinna być tylko jednym z mierzonych wskaźników.

Paul Boag: Są też takie rzeczy, jak musisz zwracać uwagę na zaangażowanie, jak bardzo ludzie są zaangażowani w twoją treść, ponieważ ma to duży wpływ na to, czy w końcu dokonają konwersji. Patrzysz więc na takie rzeczy, jak: ile kosztują Twoje filmy, czy oglądają, ile czasu spędzają w Twojej witrynie i na co patrzą, kiedy to robią? Czy angażują się w media społecznościowe i tego typu rzeczy? Ostatnim aspektem jest oczywiście użyteczność. Musisz mierzyć, jak szybko ktoś może wykonać określone zadanie na swojej stronie internetowej i jak łatwo jest mu korzystać z systemu i różnych innych kryteriów.

Paul Boag: Istnieje wiele mechanizmów, których możesz użyć do pomiaru tych różnych rzeczy. Istnieje kilka świetnych narzędzi, a także dobre wskaźniki, które możesz zastosować. Na przykład w przypadku użyteczności istnieje coś, co nazywa się skalą użyteczności systemu, która może być bardzo przydatną miarą do pomiaru. Ale równie dobrze istnieją narzędzia takie jak maze.design, z których często korzystam, które mierzą, ile czasu zajmuje komuś dokonanie zakupu, na przykład przejście do kasy. Więc tak. Mając tak szeroki zakres metryk, nie skupiasz się tylko na tym, ile sprzedaży zarobiliśmy w tym kwartale? Musisz spojrzeć na szerszy obraz.

Drew: W kwietniu rozmawiałem z Laurą Kalbag z Better Blocker o prywatności w Internecie. Rozmawialiśmy o coraz cieńszych granicach między tym, co jest publiczne, a tym, co prywatne, oraz o tym, jak rzeczy, które uważamy za prywatne, mogą nie być postrzegane w ten sposób przez firmy, którym powierzamy nasze dane. Oto Laura.

Laura Kalbag: Mam klasyczny przykład, który przydarzył mi się kilka lat temu. Byłem więc na Facebooku, a moja mama właśnie zmarła, i otrzymywałem reklamy firm pogrzebowych. Pomyślałem, że to naprawdę dziwne, ponieważ nikt z mojej rodziny nie powiedział nic na platformie mediów społecznościowych w tym momencie. Nikt z mojej rodziny nie powiedział nic na Facebooku, ponieważ ustaliliśmy, że nikt nie chce dowiedzieć się czegoś takiego o przyjacielu lub członku rodziny za pośrednictwem Facebooka. Więc nie powiedzieliśmy o tym.

Laura Kalbag: Zapytałam więc moje rodzeństwo: „Och, czy ktokolwiek powiedział na Facebooku coś, co mogłoby spowodować to dziwne”. Ponieważ zwykle otrzymuję tylko reklamy makijażu, sukienek, testów ciążowych i wszystkich tych zabawnych rzeczy, o których lubią mówić. To kobiety w pewnym wieku. Zamiast tego wróciła do mnie moja siostra. Powiedziała: „Cóż, tak. Mój przyjaciel mieszka w Australii”. Wysłałem jej więc wiadomość na Facebook Messengerze i powiedziałem jej, że nasza mama zmarła. Oczywiście Facebook wiedział, że jesteśmy siostrami. Ma to połączenie relacji, które możesz tam dodać. To znaczy, pewnie i tak można by się domyślić, że i tak byłyśmy siostrami, po miejscach, w których byliśmy razem, po tym, że mamy wspólne nazwisko i zdecydowaliśmy: „Och, to właściwa reklama, którą można jej postawić”.

Drew: To otrzeźwiające, czyż nie myśleć, że technologia podejmuje te decyzje za nas, co faktycznie wpływa na ludzi potencjalnie w tym przykładzie w dość wrażliwym lub wrażliwym czasie?

Laura Kalbag: Tak. Mówimy, że to przerażające. Często ludzie mówią: „Och, to prawie tak, jakby mikrofon w moim telefonie lub laptopie mnie słuchał, ponieważ właśnie rozmawiałem o tym konkretnym produkcie i nagle pojawia się on w moim kanale wszędzie”. Myślę, że to, co jest naprawdę przerażające, to fakt, że większość z nich nie ma dostępu do twojego mikrofonu. Ale chodzi o to, że twoje inne zachowania, twoje wyszukiwanie, fakt, że wie, z kim rozmawiasz, ze względu na twoją bliskość i lokalizację na twoich urządzeniach. Może łączyć wszystkie te rzeczy, których my sami nie połączymy ze sobą, aby po prostu powiedzieć: „Och, może zainteresują się tym produktem, ponieważ prawdopodobnie już o tym myśleli, rozmawiali”.

Drew: Gdy wybuchła pandemia koronawirusa, a wiele krajów popadło w jakąś formę blokady, rozmawiałem z Rachel Andrew o tym, jak Smashing dostosowywał swoją osobistą konferencję, która ma się odbyć online. Właśnie musiałem przełożyć konferencję Smashing w San Francisco, zapytałem Rachel, jaki jest plan przeniesienia nadchodzących konferencji i warsztatów do domeny wirtualnej.

Rachel An Drew: Bardzo, bardzo szybko, kiedy zdaliśmy sobie sprawę, że będziemy musieli przełożyć San Francisco, oczywiście mamy warsztaty, zarówno ja, jak i Witalij prowadzimy warsztaty w smash i comp, i zostały wyprzedane w San Francisco. nasze warsztaty. Oczywiście mamy wielu innych ludzi, którzy przychodzą i prowadzą dla nas warsztaty, ludzi, z którymi pracujemy od dłuższego czasu i stwierdzili, że wszystkie ich warsztaty, a ci z nas robią warsztaty, mają właściwie kluczowa część naszych dochodów.

Rachel An Drew: Przemawiając publicznie, zwykle nie zarabiasz dużo pieniędzy, występując i przemawiając publicznie. Większość ludzi nie zarabia dużo, nie biorąc pod uwagę czasu potrzebnego na pisanie przemówień i tak dalej. Warsztaty wydają się być całkiem fajnym sposobem dla ludzi, którzy są dobrzy w nauczaniu tych rzeczy, aby zarobić trochę pieniędzy. Reprezentują więc dochód ludzi. Więc nie tylko potrzebowałem siebie, a Witalij stracił nasze warsztaty na początku tego roku. Zdaliśmy sobie również sprawę, że wielu naszych mówców Smashing również polegało na tych warsztatach.

Rachel An Drew: Pomyśleliśmy więc: „Cóż, dlaczego po prostu nie zamieścić ich w Internecie?” Bardzo, bardzo szybko, naprawdę w ciągu kilku dni od tego wydarzenia, zdecydowaliśmy, że ja i Witalij jako pierwsi nadstawimy głowy nad mocą, ale biorąc pod uwagę, że to my, moglibyśmy wymyślić, jak to zrobić. Mamy też bardzo różne warsztaty. Witalij jest o wiele bardziej współpracownikiem. Ma zajęcia grupowe i inne rzeczy. Uczę stylu szkolnego. Więc między nami pomyśleliśmy: „Cóż, w pewnym sensie pokrywamy wszystkie podstawy”. Pomyśleliśmy więc: „Po prostu zróbmy to. Zobaczmy, czy to zadziała”. Więc je reklamujemy. W pewnym sensie ustaliliśmy, ile czasu trwają, a potem usiedliśmy i powiedzieliśmy: „No, jak naprawdę wyglądają warsztaty internetowe? Co to jest?"

Drew: Myślę, że z technicznego punktu widzenia, jako twórcy stron internetowych, którzy od razu myślą, jak u licha zamierzamy dostarczyć coś takiego, to znaczy, musi być wiele różnych platform, na które patrzyłeś. Jakie były różne rzeczy, na które patrzyłeś i co ostatecznie przyniosło Smashing?

Rachel An Drew: Więc przyjrzeliśmy się różnym rzeczom i wciąż jesteśmy w trakcie robienia tego. W tej chwili używamy Zoom. Powodem, dla którego używamy Zoom, jest dostępność. Była to najbardziej dostępna z platform. Oczywiście nie chcemy odcinać ludzi ze względu na wybraną przez nas platformę. Myślę, że inne platformy są coraz lepsze, a ludzie… Myślę, że na wiele platform ludzie przychodzili do nich i mówili: „Tak, wyglądasz świetnie. Ale musisz być dostępny. Tak więc zoom jest obecnie najłatwiejszy dla ludzi”. Dlatego właśnie ich używamy. Nie wiem, czy będziemy to robić na zawsze. Ale tego właśnie używamy w tej chwili i działa to całkiem nieźle jako sposób na zrobienie tego.

Drew: Gdy pojawiło się zmęczenie Zoomem i świat zaczął dostosowywać się do tego, co szybko nazwano nową normą, rozmawiałem z Philem Smithem o tym, jak technologia może pomóc nam reagować na sytuacje takie jak COVID-19. Zbuduj aplikację React Native CardMedic w zaledwie 10 dni. Zapytałem Phila, jak radzi sobie z wyważeniem wyboru najlepszej technologii do pracy w porównaniu z technologiami, które zna iz którymi może szybko pracować.

Phil Smith: To dobre pytanie. Myślę, że jak tylko wspomniano o projekcie, pomyślałem, że dokładnie wiem, jak mam to wszystko zbudować. Gdybym nie miał dzieci i siedział w ciemnym pokoju, myślę, że mógłbym to wszystko odwrócić w około pięć dni, gdybym pracował nad tym solidnie, solidnie, solidnie, ponieważ wymagania były bardzo zgodne z moim doświadczeniem w tworzeniu aplikacji. Zbudowałem podobne rzeczy, w których wywołuje API, przechowuje wyniki w stanie i przedstawia je. Jestem teraz w sytuacji, w której są pewne fragmenty, w których mówię: „OK, muszę się cofnąć i zmienić to”.

Phil Smith: Mówiłem o wpisywaniu cyny, ale w rzeczywistości typy mogą być dość luźne w aplikacji i należy to zaostrzyć. Jeśli chodzi o zaplecze, nie ma zbyt wielu testów, a teraz zaczynamy wycofywać zaplecze, ponieważ wiele osób zgłosiło się i powiedziało: „Właściwie to jest świetne źródło informacji. Chciałbym zgłosić się na ochotnika do przetłumaczenia tego na mój język ojczysty”. Końcówki są używane przez więcej ludzi, więc myślę tylko: „Chwileczkę, potrzebuję tutaj jeszcze kilku testów, aby upewnić się, że nic nie może się zepsuć, ponieważ są ludzie, którzy używają tego teraz w produkcji”. Myślę, że odpowiedziałem na twoje pytanie. Zasadniczo nie było podejmowania decyzji. Po prostu musiałem to zrobić tak szybko, jak to możliwe.

Drew: Ponieważ miejsca pracy zostały zamknięte, a wielu z nas przystosowało się do pracy w domu, rozmawiałem z Benem Frainem o tym, że optymalizacja domowego miejsca pracy tak, aby była wygodnym i produktywnym miejscem, nie spowoduje długotrwałych problemów ze zdrowiem fizycznym. Mając ograniczone budżety dostępne na ustawienie w domu, zapytałem Bena, czy dobre krzesło byłoby najlepszym miejscem do rozpoczęcia.

Ben Frain: To byłaby moja rada. Tak. To znaczy, nie mogę twierdzić, że jestem autorytetem w tych sprawach, ale wydaje się, że jest to prawdopodobnie najważniejsza rzecz, jaką możesz zrobić, aby czuć się komfortowo przez cały dzień. Możesz zacząć od czegoś dość drogiego. Popełniłem ten sam błąd i skończyło się na tym, że dostałem od Amazona 45-funtowe krzesło biurowe i nie zdawałem sobie sprawy, że nie jest ono pochylone do przodu, niezależnie od tego, jakie jest właściwe słowo na to, na osi. Więc odkryłem, że wbijało się w spód moich ud, coś w rodzaju za kolanami, i pomyślałem: „Dlaczego moje nogi umierają po 45 minutach siedzenia w tym czymś?”

Ben Frain: Myślę, że szczególnie, jeśli pracujesz dla firmy, która zapewnia przyzwoite krzesła biurowe, po prostu uważasz je za coś oczywistego i dopiero wtedy, gdy spojrzysz na tę konkretną markę i markę, mówisz: „O mój Boże, to jest krzesło za 700 dolarów”. Kiedy zdajesz sobie sprawę, że to szaleństwo, ludzie myśleli o tym i wiele dla ciebie zrobili, a potem oczywiście przychodzisz do swojego domowego środowiska i myślisz: „Dlaczego nie wydać Xset dolarów na krzesło?” Ale może warto. Zwłaszcza jeśli jesteś tu na dłuższą metę.

Drew: A na dłuższą metę mamy. Coś, co jest dostępne na dłuższą metę, to Drupal. W czerwcu rozmawiałem z Angie Byron o zmianach w Drupal 9. 20 lat od pierwszego wydania Drupal przeszedł długą drogę. Zapytałem Angie, jak wyglądał proces aktualizacji istniejącej witryny Drupal po przejściu na Drupala 9 i czy może to być dużym obciążeniem dla osób z długimi witrynami.

Angie Byron: Myślę, że są w zasadzie trzy scenariusze. Tak więc jeden z nich jest taki, że uruchomiłeś Drupala 8 i za każdym razem, gdy pojawiało się nowe, pomniejsze wydanie Drupala 8, od razu aktualizowałeś go do wersji i zacząłeś korzystać z nowych rzeczy. Twoja ścieżka będzie w zasadzie niczym. Wykonałeś już całą pracę i wszystko w porządku. Jeśli jakiś czas temu przeniosłeś się na Drupala 8 i nie nadążałeś za zmianami w BC, czeka Cię trochę pracy.

Angie Byron: I tak jest to zdecydowanie najłatwiejsze uaktualnienie w ciągu ponad dekady naszego oprogramowania, a my mamy mnóstwo różnych narzędzi, które mogą Ci w tym pomóc. Dostępny jest pulpit nawigacyjny, który pokazuje wszystkie przesłane moduły i ich sytuację w Drupal 9. Są zautomatyzowane narzędzia do przeglądania i sprawdzania kodu oraz oznaczania wszelkich przestarzałych funkcji, które posiadasz, a także narzędzia do automatycznego uruchamiania i znajdowania: „Och, to jest najnowsza wersja Twojego modułu i jest gotowy na Drupal 9? Powinieneś go pobrać”, tego rodzaju rzeczy.

Angie Byron: Więc od Drupala 8 do 9, powiedziałabym, że ta część jest całkiem dobrze opisana. Jeśli przechodzisz z wcześniejszej wersji Drupala, powiedz Drupal 7 lub niższy do Drupala 9, to zaczyna wyglądać trochę trudniej. Wśród zmian, które wprowadziliśmy w Drupal 8, na przykład, przenieśliśmy się całkowicie na PHP zorientowane obiektowo i zaczęliśmy wykorzystywać wzorce projektowe, które zostały znalezione w innych projektach oprogramowania, co jest naprawdę mądrą rzeczą do zrobienia pod względem architektonicznym, ale tak się dzieje. oznacza to, że jeśli miałeś mnóstwo niestandardowego kodu w swoim starym życiu, to w Drupal 9 będziesz musiał znaleźć alternatywę dla tego.

Angie Byron: Acquia to produkt i rozwój o nazwie Acquia Migration Accelerator, który ma na celu rozwiązanie tego problemu, w którym tworzymy ładną aplikację zdefiniowaną w React, która odczytuje twoje stare dane Drupal 7, tworzy dla Ciebie równoważne dane Drupal 8 wraz ze wszystkimi modułami, których będziesz potrzebować, tę mapę do starych modułów Drupala 7, jeśli to możliwe, aby spróbować przyspieszyć ten proces, ponieważ chcemy mieć pewność, że każdy, kto korzysta ze starszych wersji, nadal może przejść do nowy porządek świata, w którym wszyscy są na tej samej wersji i wszyscy pracujemy razem.

Angie Byron: W dodatku rozszerzyliśmy także Drupala 7… Społeczność open source Drupala, ich koniec życia w Drupal 7 od listopada przyszłego roku. W każdym razie obecnie musimy przedyskutować, czy COVID ma na to wpływ, czy nie. Ale jest wiele różnych firm, a Acquia jest jedną z nich, która oferuje rozszerzone wsparcie dla Drupala 7, przynajmniej do 2024 roku. Dzięki temu ludzie, którzy mają łatwą aktualizację, mają półtora roku na to, aby to zrobić, ludzie mają mniej łatwą aktualizację, potencjalnie mają trzy i pół roku na wykonanie lub dłużej, jeśli zajdzie taka potrzeba, i naprawdę bardzo się staramy, aby każdy mógł przejść, a następnie zbudować narzędzia, takie jak Acquia Migrate Accelerator, aby przyspieszyć ten proces.

Drew: Nauka React była tematem rozmowy z Miną Markham. Mina i ja po raz pierwszy mieliśmy okazję uczyć się Reacta. Zastanawiając się nad tym, jak bardzo frameworki, takie jak React, nakładają na przeglądarkę, zapytałem Minę, czy oddanie tak dużej kontroli w ręce klienta było błędem.

Mina Markham: Chcę powiedzieć tak, z zastrzeżeniem, że moje doświadczenie ogranicza się głównie do statycznych stron internetowych. Nie zajmuję się dużo rozwojem produktu. Więc może w tej sferze ma to więcej sensu. Ale z mojej perspektywy wydaje mi się, że często używamy siekiery, gdy potrzebujemy tylko noża do masła. Nie wiem, dlaczego musimy to wszystko umieścić w przeglądarce, włożyć tyle pracy i tyle presji na klienta, skoro możemy wiele zrobić… Czuję, że moglibyśmy to zrobić o wiele prościej. Jedną z rzeczy, które zawsze sprawiały, że trochę wahałem się przed użyciem Reacta, lub mówię, wahałem się, ale co mam na myśli, gdy mnie to rozgniewało i aktywnie się temu sprzeciwiałem, było to, gdy wszedłem na stronę internetową i dosłownie nic by się nie wyświetlało, ponieważ wystąpił jeden błąd lub coś takiego, tak naprawdę cała strona jest zepsuta, ponieważ jedna funkcja się zepsuła.

Mina Markham: Po prostu denerwowało mnie to, że często było to podejście „wszystko albo nic”. Jedna z przemówień, które wygłosiłem w AEA w przeszłości i innych miejscach w przeszłości, dotyczyła tego, jak uwzględnić progresywne ulepszanie, a nie tylko rozwój, ale także większy kierunek artystyczny i projektowanie witryn. Wskażę konkretnie przykłady stron internetowych, które nie dokonały progresywnego ulepszania ani żadnego rodzaju wdzięcznej degradacji. Albo masz uruchomiony JavaScript w przeglądarce, albo nie dostajesz absolutnie nic. Byłaby to po prostu prosta strona, która przedstawiałaby informacje o historii projektowania stron internetowych, która była jedną z witryn, o których faktycznie mówiono, historii projektowania stron internetowych od 1990 roku do teraz. To była piękna strona internetowa z dużą ilością osi czasu, animacją rzeczy. Ale mógł być również renderowany statycznie za pomocą samej listy. Były kroki pomiędzy pokazaniem niczego, a pokazaniem tego pięknie ulepszonego doświadczenia, które moim zdaniem zostało utracone z powodu sposobu, w jaki podchodzimy do nowoczesnego tworzenia stron internetowych.

Drew: Rozmawiałem z Andym Bellem o CUBE CSS, metodologii stylizacji w stylu BEM, SMACSS i OOCSS. Wiele podejść CSS próbuje działać przeciwko naturalnym właściwościom CSS, takim jak kaskada. CUBE bardzo akceptuje to zachowanie. Oto Andy.

Andy Bell: Dobra analogia do tego, że SCSS, podobnie jak Sass, jest rozszerzeniem naturalnego języka CSS, prawda? Nadal masz rację w CSS. Więc CUBE CSS jest właśnie taki. Jest to więc rozszerzenie CSS. Powinniśmy więc nadal pisać CSS, ponieważ CSS powinien… cóż, powinien być napisany. Powiedzmy sobie szczerze, że tak ma być napisane. Nazwa to zdradza, Kaskadowe Arkusze Stylów. Więc znowu to obejmuje, ponieważ odkryłem, że przeszedłem aż do poziomu mikrooptymalizacji. Byłem na ścieżce, którą widzę ostatnio wielu ludzi, gdzie… Wspominałem o tym również w artykule, gdzie widzę… Ostatnio są na to pewne dowody. Zauważyłem, że ludzie tworzą elementy dystansowe i takie tam, i rozumiem ten problem. Byłem w takiej sytuacji.

Andy Bell: Sposób, w jaki to naprawiłem, polegał na tym, że zamiast drążyć i próbować mikro-optymalizacji, zacząłem myśleć o rzeczach na poziomie kompozycyjnym, ponieważ nie ma znaczenia, jak małe są twoje komponenty. W pewnym momencie będą to strony. Będą poglądami. Nie możesz tego uniknąć. Tak to będzie. Więc zamiast próbować powiedzieć: „Tak, potrzebuję tych malutkich pomocników do wykonania tego układu”, mówisz: „Tak, mam widok strony kontaktowej lub widok strony produktu, a to jest szkieletowa kompozycja układu. Następnie w środku mogę umieścić w nim dowolne komponenty”.

Andy Bell: Mamy teraz takie rzeczy jak Grid i Flexbox, które sprawiają, że jest to o wiele bardziej osiągalne, i zasadniczo możesz umieścić wszystko, co chcesz, w układzie szkieletu. To nie ma znaczenia. W tym momencie komponenty powinny zachowywać się tak, jak chcesz, z zapytaniami kontenerowymi lub bez nich.

Drew: Gatsby był tematem mojej rozmowy z Marcy Sutton. Podczas gdy większość statycznych generatorów witryn jest niezależna od kodu front-endu, Gatsby używa Reacta, dzięki czemu kod Gatsby'ego jest uruchamiany jako część ostatecznego doświadczenia w sieci. Zapytałem Marcy, co to za kod i jaką funkcjonalność zapewnia.

Marcy Sutton: Tak. Powiedziałbym, że największym elementem jest routing po stronie klienta. Więc Gatsby teraz używa pod maską bieżnikatora. To po prostu rodzaj własnej realizacji. Ale to jest fragment, w którym po pierwszym załadowaniu statycznej witryny znajdują się tam pliki HTML. Jeśli więc użytkownik z jakiegoś powodu wyłączy JavaScript, Twoja witryna powinna nadal tam być, nadal zawierać treść. Ale jeśli JavaScript jest włączony, to wtedy ma miejsce ten etap nawadniania, kiedy użyjesz linków w swojej witrynie Gatsby, pobierze zasoby z tej strony. Więc ładuje się szybciej. To wszystko jest włączone dzięki tej warstwie JavaScript, którą daje Gatsby.

Marcy Sutton: Poza tym to naprawdę zależy od tego, czego używasz w swojej witrynie, co trafi do tego pakietu JavaScript. Ale dla rzeczy, które wykorzystują dużo interaktywności, takich jak dostępne interfejsy, jest to dobre miejsce. Dla mnie naprawdę lubię mieć dostęp do JavaScript przez cały czas, a mój znacznik jest po prostu w dobrym miejscu. Wiem, że to kwestia preferencji, czy chcesz, aby Twój HTML, JavaScript i CSS były zgrabnie połączone, i jest miejsce na wariacje w budowaniu Gatsby'ego. Nie zawsze musisz używać czegoś takiego jak CSS i JS. Ale tak naprawdę chodzi o to, aby podczas pisania witryny była dostępna moc tej dynamicznej warstwy JavaScript. To nie jest taki dodatek w osobnym pliku.

Drew: Kiedy myślę o tym, jak zwykle działa generator stron statycznych, myślę o treści w plikach przecen, a generator przechodzi przez tę treść i łączy ją z szablonami i tworzy dziesiątki, setki, tysiące plików HTML, które są strony Twojej witryny. Kiedy myślę o witrynie lub aplikacji React, myślę bardziej o doświadczeniu na jednej stronie, gdzie interfejsy są tworzone przez React w locie. Więc mówisz, że Gatsby robi obie te rzeczy? Tworzy wszystkie strony, a także ulepsza je za pomocą JavaScript?

Marcy Sutton: Tak, tak. Gatsby użyje Node.js w czasie kompilacji, przejrzy twoje komponenty React i skompiluje je do plików HTML, co szczerze mówiąc, kiedy pierwszy raz spojrzałem na Gatsby'ego, nie wyłączyłbym JavaScript i powiedział: „W porządku, czy są tu inne strony? Co to jest?" Byłem bardzo szczęśliwy, że Gatsby domyślnie działa w ten sposób. Utworzy zbudowane pliki z twoich komponentów React, co jest niesamowite.

Marcy Sutton: Zbadałem bardziej progresywne podejścia do ulepszania, ponieważ jest to w JavaScript, na przykład, co jeśli chcesz wypisać coś stopniowo ulepszanego dla użytkowników, gdzie jeśli mają wyłączony JavaScript, nie chcesz całego tego zepsutego kodu, który zakłada JavaScript jest tu. Więc jest z tym kilka dziwactw. Ale możesz obejść tego rodzaju rzeczy, przynajmniej w przypadku podstawowych przepływów użytkowników, w których chcesz, aby ktoś nadal mógł coś kupić. Może być konieczne dodanie wsparcia i dla tych przypadków użycia. Ale byłem mile zaskoczony, że Gatsby domyślnie to wprowadza.

Marcy Sutton: Więc to jest wybór, którego podjęli, aby budować witryny w ten sposób, i zawsze oceniamy, czy to nadal najlepszy sposób? Co musimy zrobić, aby dać naszym użytkownikom to, o co proszą? Dlatego prowadzimy pewne wewnętrzne badania, aby upewnić się, że Gatsby wykonuje najlepszą pracę, jaką może, przy tworzeniu strony internetowej, więc utrzymuj małe rozmiary pakietów i upewniając się, że kompromisy dla tego, co mówimy, jest wydajnym kodem z pre -pobieranie, czy mamy dane, aby to zrobić? Mnie bardzo interesuje, jako rzecznika programistów, upewnienie się, że to, co pakujemy i łączymy na stronach internetowych, jest rzeczywiście potrzebne i naprawdę stworzy najlepszą witrynę Gatsby, jaką może stworzyć.

Drew: Rozmawiając z Chrisem Ferdinandim w lipcu, zapytałem, czy współczesne najlepsze praktyki są złe dla sieci. Chris backs a movement known as the Lean Web, and I asked him what that entailed. Here's Chris.

Chris Ferdinandi: When I look at the way we build for the web today, it feels a little bit like a bloated over-engineered mess. Doszedłem do przekonania, że ​​wiele z tego, co dzisiaj uważamy za najlepsze praktyki, może w rzeczywistości pogarszać działanie sieci. The Lean Web is an approach to web development that is focused on simplicity, on performance, and the developer experience over… I'm sorry, not the developer experience, the user experience rather, over the developer experience and the ease of building things from a team perspective, which is what I think where we put a lot of focus today.

Chris Ferdinandi: As we'll probably get into in our conversation, I've actually come to find that a lot of these things we think of as improving the developer experience do so for a subset of developers but not necessarily everybody who's working on the thing you're building. So there's a whole bunch of kind of issues with that too that we can kind of dig into. 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: In August, Chris Coyier joined us to talk about all things serverless. I asked him what sort of the tasks they were putting serverless to over at CodePen?

Chris Coyier: Well, there's a whole bunch of things. One of them is, I think, hopefully fairly obvious is, I need… The point of CodePen is that you write each HTML, CSS, and JavaScript in the browser, and it renders it in front of you, right? Ale możesz również wybrać języki preprocesora. Powiedzmy, że lubisz Sassa. Włączasz Sassa w CSS i piszesz Sassa. Cóż, coś musi przetworzyć Sassa. W dzisiejszych czasach Sass jest napisany w Dart czy coś takiego. Theoretically, you could do that in the client. Ale te biblioteki, które wykonują wstępne przetwarzanie, są dość duże. Nie sądzę, że chcę ci wysłać całą bibliotekę Sassa, tylko po to, żeby to uruchomić. I don't want to. That's not the right architecture for this necessarily. Maybe it is down the road. I mean, we could talk about offline crap, yada, yada, web workers.

Chris Coyier: There's a million architectural things we could do. Ale oto jak to teraz działa, czy jest lambda. Przetwarza Sassa. Ma jedną malutką, malutką, malutką, małą pracę. You send it this blob of Sass, and it sends you stuff back, which is the processed CSS, maybe a site map, whatever. It has one tiny little job, and we probably pay for that lambda like four cents or something. Because lambdas are just incredibly cheap, and you can hammer it too. Nie musisz się martwić o skalę. You just hit that thing as much as you want, and your bill will be astonishingly cheap.

Chris Coyier: There is moments where serverless starts to cross that line of being too expensive. I don't know what that is. I'm not that master of stuff like that. But generally, any serverless stuff we do, we basically all nearly count as free, because it's that cheap. Ale jest jeden dla Sassa. Jest jeden za mniej. Jest jeden dla Babbel. Jest jeden dla TypeScript. Jest jeden dla… Wszystkie to indywidualne lambdy, które uruchamiamy. Here's some code, give it to the lambda. It comes back, and we do whatever we're going to do with it. Ale używamy go do znacznie więcej, nawet ostatnio.

Chris Coyier: Here's an example. Każde pióro w CodePen ma zrzut ekranu. To całkiem fajne, prawda? So the people make a thing, and then we need a PNG or a JPEG, or something of it, so that we can… that way when you tweet it, you get the little preview of it. Jeśli udostępnisz go w Slacku, otrzymasz jego mały podgląd. We use it on the website itself to render… Instead of an iframe, if we could detect that the Pen isn't animated, because an iframe's image is much lighter, so why not use the image? I tak nie jest animowany. Po prostu zyskuje wydajność.

Chris Coyier: So each of those screenshots has a URL to it, obviously. We've architected it so that that URL is actually a serverless function. To pracownik. So if that URL gets hit, we can really quickly check if we've already taken that screenshot or not. That's actually enabled by CloudFlare Workers, because CloudFlare Workers are not just a serverless function, but they have a data store too. They have this thing called key-value store. So the ID of that, we can just check really quick, and it'll be, “True or false, do you have it or not?”

Chris Coyier: If it's got it, it serves it, and it serves it over CloudFlare, which is super fast to begin with and then gives you all this ability too because it's an image CDN, you can say, “Well, serve it in the optimal format. Służcie temu jako te wymiary”. Nie muszę robić obrazu w tych wymiarach. You just put the dimensions in the URL, and it comes back as that size, magically.

Drew: I talked to Next.js co-creator, Guillermo Rauch about the features on offer in Next.js and asked about its automated code splitting functionality. As the size of our JavaScript bundles can have quite an impact on performance, I was interested to know if Next had ways to tackle that. Here's Guillermo.

Guillermo Rauch: Yeah. Your observation is 100% right. So one of the biggest things with the web and one of the biggest weights on the web is JavaScript. Just like different materials have different densities and weights, irrespective of the actual physical volume, JavaScript tends to be a very dense, heavy element. Even small amounts of JavaScript compared to, for example, images that can be processed asynchronously and off the main thread, JavaScript tends to be particularly bothersome.

Guillermo Rauch: So Next.js has invested a tremendous amount of effort into automatically optimizing your bundles. So the first one that was my first intuition when I first sort of came up with the idea for Next.js was, okay, you're going to define, for example, 10 routes. In the Next.js world you create a pages directory, and you drop your files in there, index.js, about.js, settings.js, dashboard.js, terms-of-service.js, signup.js, login.js. Stają się one punktami wejścia do Twojej aplikacji, które możesz udostępniać za pośrednictwem wszelkiego rodzaju mediów.

Guillermo Rauch: When you enter those, we want to give you JS that is relevant for that page, first and foremost, and then perhaps a common bundle so that subsequent navigations within the system are very snappy. Next.js, co jest bardzo, bardzo ładne, automatycznie wstępnie pobiera pozostałe strony połączone z tym punktem wejścia, tak że wygląda jak aplikacja jednostronicowa. So a lot of people say like, “Why not just use Create React app if I know that I have maybe a couple routes?” I always tell them, “Well, look. You can define those as pages, and because Next.js will automatically pre-fetch ones that are connected, you end up getting your single-page application, but it's better optimized with regards to that initial paint, that initial entry point.”

Drew: In September, I had the pleasure of talking to Cassie Evans about SVG animation. We talked about the approachability of SVG for developers who are already familiar with HTML. Here's Cassie.

Cassie Evans: I think that that's what I love the most about SVG is I'm really into creative coding and also teaching people, and I found that teaching people who are more of a creative leaning, they sometimes get a little thrown off when you immediately jump in with JavaScript or Python or something like that for creative coding. But without fail, I've managed to get anyone that I taught on board with SVG because there some really approachable entry points because it does look like HTML.

Cassie Evans: So you can give someone with an understanding of HTML and how to build websites SVG, and it looks the same, but it's the graphics instead of documents, and then you can animate that with CSS to start off with, which is also a little bit more comfortable, and then you can kind of progress to animating it with JavaScript. So it's a really good learning curve.

Drew: Of course, it can be dynamic. It's not just a case of creating motion. You can actually make the properties of it dynamic. So one of the interesting things I've seen SVG used for, and it's a grand term, but data visualization, dataviz, and drawing graphs and charts and of course things like dashboards that we seem to have everywhere these days. SVG is sort of perfect for that, isn't it?

Cassie Evans: Yes, definitely. SVG is great for dataviz. All the way from kind of small dataviz up to D3 which is very well known dataviz library that uses SVG under the hood. But you could also just, if you've got a little bit of data that you wanted to show on a web page, you could create a chart in a graphics editing program, and then you could just use JavaScript to change those values and kind of change how your graph looks. So you don't have to go all in with a massive database library. You can kind of just start off small.

Drew: The Jamstack framework, RedwoodJS was the topic of conversation with Anthony Campolo. I asked Anthony what it meant to be a full-stack Jamstack framework in practical terms.

Anthony Campolo: Yeah, it's pushing the boundaries of what a Jamstack application can be. So by calling it full-stack Jamstack, it's about, how do we go beyond just the front end to having the same sort of deployment paradigm of just get pushed, getting your whole code deployed? How do we get that but also with our back end and have it all connected?

Drew: Vue.js version three was released in October, and I caught up with Natalia Tepluhina from the Vue core team. Discussing the new version, I was curious if the major version bump was just a result of a few backward incompatible modifications or if this was a very clear revisiting of Vue to make deeper changes to the framework.

Natalia Tepluhina: No. I think it was an idea to create a new version due to a few very important things. Więc przede wszystkim pojawiła się motywacja do zmiany reaktywności. Previous one was built upon Object.defineProperty, and it had a few caveats. They're all documented, but still, even if you document something that people shouldn't do, they will do it anyway, and you would need to point them to the documentation. Nobody reads documentation, by the way. For some reason, it just happens. Until you point people out, it doesn't exist in docs, it does. Ale dobra. I tak cię nauczymy.

Natalia Tepluhina: So reactivity was one of the things. Performance was the next. Vue 2 still had and has not the worst performance, but we had a few ideas about how to make Vue faster, and also, there was one pain point for a particular part of our, let's say audience, people that use Vue. To był TypeScript. Vue 2 internally was written in Flow, which is still strongly typed one, but typing with TypeScript were a real nightmare especially if you were working with our state management Vuex.

Natalia Tepluhina: Więc znowu była to duża część. Ostatnim z nich było to, że w pewnym sensie przegapiliśmy funkcjonalność logiki abstrakcyjnej, nie chodziło o komponenty, ale o kompostowalne części logiki, takie jak pomocniki funkcji i tak dalej, ale powinny one również być w stanie uwzględnić aktywność Vue. Dobrym przykładem mogą być React Hooki, prawda? Pozwalają wyabstrahować części funkcjonalności, czego wyraźnie brakowało w Vue. Wiem, że teraz brzmi to jak „Ukradłeś funkcję z React”. W rzeczywistości nie. Uważam, że zapylenie krzyżowe pomysłów jest dużą i przyjemną częścią naszego ekosystemu, a także pomaga programistom przełączać się między ulubionymi, prawda? Dlatego pracowaliśmy nad tymi głównymi funkcjami, aby stworzyć Vue 3 jako główną wersję.

Drew: Następnie zagłębiliśmy się w TypeScript ze Stefanem Baumgartnerem, aby dowiedzieć się, jak może on pomóc nam napisać lepszy kod z mniejszą liczbą błędów. Obserwując trend, w którym organizacje przenoszą swój kod całkowicie na JavaScript, zapytałem Stefana, czy TypeScript jest czymś, z czego większe zespoły skorzystałyby więcej niż pojedyncze osoby.

Stefan Baumgartner: A więc jestem obecnie w tej samej fazie przejściowej. Mamy więc wielu programistów Java i C++, którzy w przyszłości będą pisać dużo JavaScriptu. TypeScript może być swego rodzaju przewodnikiem po tych przerażających obszarach nowego języka programowania. JavaScript ma wiele dziwactw, wiele historii i wiele uprzedzeń, jeśli pochodzisz z innego języka programowania. Tak więc TypeScript może być przewodnikiem, ponieważ istnieją pewne pojęcia, które znasz w systemie typów.

Stefan Baumgartner: Ale myślę, że szczególnie, gdy masz wiele osób pracujących w tej samej bazie kodu lub wiele osób, które muszą ze sobą współpracować, może to być dodatkowa warstwa wskazówek w twoim projekcie, gdzie nie w końcu nie mam żadnych przykrych niespodzianek. Oczywiście technologia nie rozwiązuje żadnych problemów komunikacyjnych. Nie do tego służy TypeScript. Ale może się obniżyć lub zrobić o wiele więcej miejsca na właściwą dyskusję, niż jeśli nie musisz rozmawiać o tym, czego oczekujesz ode mnie w swoim kodzie, ale raczej, co powinien zrobić twój kod lub co powinien twój kod biblioteka zrobić?

Stefan Baumgartner: Zawsze powtarzam, że jeśli kiedykolwiek napiszesz kod dla innych ludzi lub jeśli piszesz kod z wieloma osobami lub jeśli piszesz kod tylko dla siebie, musisz wrócić następnego dnia, rozważ TypeScript, ponieważ może ci to pomóc w długi bieg. To nie jest tylko inwestycja na kolejny projekt w przyszłym tygodniu, ale bardziej dla kogoś, kto powie „w porządku”, zwłaszcza jeśli masz długotrwałe projekty na miesiąc, dwa lub lata, zdecydowanie to zaoferuj. Nigdy nie dowiesz się, o czym myślałeś, kiedy pisałeś ten mały fragment kodu rok temu, ale typy mogą dać ci podpowiedź, co miałeś na myśli.

Drew: W listopadzie rozmawiałem z Davidem Darnesem o generatorze statycznych stron, Eleveny. Rozmawialiśmy o szablonach i o tym, jak wiele statycznych generatorów witryn jest dość mocno przekonanych o tym, jakiego rodzaju szablonów należy używać. Zastanawiałem się, czy Jedenaście miało takie same silne przekonania. Oto Dave.

David Darnes: Nie, muszę powiedzieć, że jest tak blisko, jak bez opinii, jak tylko możesz. Trochę osobisty pogląd, ale z trudem dostrzegam jakiekolwiek ramy lub cokolwiek, co może być nieprzemyślane, ponieważ aby coś stworzyć, musisz mieć opinię na temat tego, jak chcesz coś zrobić. To rodzaj oksymoronu. Jestem pewien, że ludzie mogliby mnie w tym poprawić. Ale tak. Możesz przełączyć się na dowolny język szablonów, z którym czujesz się najbardziej komfortowo. Chodzi mi o to, że właśnie rozmawialiśmy o językach, z którymi czujesz się komfortowo. Jedenaście odwołuje się do tego w pewnym sensie za pomocą tego, jakie języki szablonów używają w twoim HTML, a nawet w CSS, jeśli chcesz.

David Darnes: Dla mnie po prostu poszedłem od razu do nunjucków, ponieważ nunjucks to domyślny język szablonów w Eleveny. Oznacza to, że mogę użyć rozszerzenia HTML z kropką i pozostawić je bez zmian. Teraz po prostu jeszcze bardziej zdezorientuję ludzi i powiem: „I tak możesz to nazwać, jak chcesz. Możesz się z tym naprawdę dobrze bawić.” Ale możesz użyć kierownicy. Myślę, że możesz po prostu użyć zwykłego szablonowania JavaScript i iterować go w ten sposób. Kierownice dość popularne i płynne. Nie mogę myśleć o nich wszystkich z głowy, ale jeśli ustawisz to wszystko w konfiguracji, możesz po prostu wybrać, jak chcesz.

David Darnes: Powiedziałbym, że jestem wielkim fanem tylko szablonowania języków w ogóle. Nie tak dawno temu dowiedziałem się, że możesz używać gałązki w WordPressie i to mnie zaskoczyło. Pomyślałem: „Och, dzięki Bogu. Nie muszę obsługiwać pętli for w PHP.” Znowu myślę, że coś nieco wygodniejszego i bardziej zrozumiałego, a także bardziej czytelnego. Więc tak. Jedenaście ma wiele różnych opcji szablonów i powinno spodobać się ludziom, którzy czują się komfortowo z tymi różnymi.

Drew: Rozmawiałem z Leslie Cohn-Wein o tym, jak Netlify używa własnej platformy do budowania Netlify i jak ich funkcja Deploy Preview staje się efektywną platformą do wprowadzania zmian front-end.

Leslie Cohn-Wein: Może moją ulubioną częścią tego całego procesu jest magia Deploy Previews, którą otrzymujemy za pośrednictwem Netlify. Więc co się dzieje, gdy pracujesz w GitHub, podnosisz swój PR. Otwierasz więc swój PR w GitHub, a to automatycznie tworzy kompilację twojego podglądu wdrożenia aplikacji. Dlatego używamy podglądów wdrażania samej aplikacji do testowania, aby upewnić się, że wszystko działa tak, jak powinno. Przeprowadzamy nasze testy. Tego właśnie używamy do ręcznej weryfikacji podczas przeglądu kodu. Mamy więc wszystko to, co jest ciągłe, skonfigurowane bezpośrednio z GitHub.

Leslie Cohn-Wein: Jedną z innych fajnych rzeczy, które stworzyliśmy, jest to, że faktycznie mamy kilka różnych witryn Netlify, które pobierają z tego samego repozytorium, w którym znajduje się nasza aplikacja. Mamy więc obie naszą aplikację. Mamy instancję Storybook, która ma coś w rodzaju naszych komponentów interfejsu użytkownika dla aplikacji. Mamy więc obie naszą aplikację. Mamy komponenty Storybook UI i zasadniczo mamy witrynę Netlify, która pokazuje nasz Storybook UI, a także mamy trzecią witrynę, która uruchamia analizator pakietów internetowych. Jest to więc rodzaj wizualnego interfejsu użytkownika, który zapewnia wizualizację mapy drzewa wszystkich pakietów aplikacji, a my możemy określić ich rozmiar, i jest to dla nas tylko przypomnienie, aby dokładnie sprawdzić, jak przebiega każde wdrożenie aplikacji na zewnątrz, możemy sprawdzić i upewnić się, że nie robimy nic dziwnego z naszym rozmiarem pakietu.

Leslie Cohn-Wein: Tak więc wszystkie trzy z tych witryn są generowane w ramach jednego żądania ściągnięcia aplikacji. Otrzymasz więc linki do podglądu, czyli zasadniczo do Twoich podglądów wdrażania, zarówno aplikacji Storybook, jak i do tego profilu aplikacji, abyśmy mogli je sprawdzić.

Drew: W grudniu rozmawiałem z Chrisem Murphym o projektowaniu produktów io tym, co to znaczy, że biznes jest skoncentrowany na projektowaniu. Rozmawialiśmy o tym, czy poszczególni założyciele koncentrują się na projektowaniu, czy przenika to do biznesu i czy produkt jest naturalnie przedłużeniem osoby, która go stworzyła.

Chris Murphy: Myślę, że to naprawdę dobre pytanie, Drew, i myślę, że odpowiedź na nie zależy. Myślę, że to zależy od tej osoby i od skali firmy. Jeśli przyjrzysz się Hiut Denim i często używam Hiut w moim nauczaniu, to jest to naprawdę dobry przykład firmy, która robi jedną rzecz dobrze, a jest to ich rodzaj dżinsów z paskiem. Myślę, że jeśli spojrzysz na poprzednie… Davida i Clare, ponieważ są spółką partnerską. Jeśli spojrzysz na poprzednią firmę Davida Hieatta i Clare Hieatt, czyli Howies, ta firma rozrosła się tak bardzo, że było w nią zaangażowanych tak wielu ludzi.

Chris Murphy: Kiedy zaczyna się wkradać skala, bardzo trudno jest mieć oko na wszystkie małe punkty styku, które mają znaczenie w podróży klienta. Myślę, że to naprawdę wymowne, kiedy opuścili Howies, bo Howies został kupiony przez… To skomplikowane. Przeczytaj to w Internecie. Ale to był Timberland, a Timberland został kupiony, i cała ta historia.

Chris Murphy: Myślę, że to naprawdę interesujące, że teraz skupiają się na dżinsach. Otóż ​​to. Opowiadają niesamowicie dobrą historię o dżinsach. Oni również pakują wszystko naprawdę, bardzo dobrze, a dżinsy są jak pojazd do opowiadania historii. Myślę, że to, Drew, stanie się ważniejsze, gdy wyjdziemy na drugi koniec COVID, z którego mam nadzieję wyjdziemy na drugim końcu. Każdy, kto robi te dżinsy, otrzymuje odpowiednią pensję. Jednym z problemów, które mam w tej chwili, kiedy patrzę na świat, jest to, że nie każdemu płaci się odpowiednią pensję, i wydaje mi się, że to trochę niepokojące, jako ktoś… Słuchaj, mam 51 lat. Mój syn ma 25, 24 lata , 25, coś takiego. To jest straszne. Powinienem o tym wszystkim wiedzieć. Jest fotografem ślubnym. Fotograf ślubny zajmuje się od około roku. Jego interes jest całkowicie zdziesiątkowany, ponieważ nikt tak naprawdę nie bierze ślubu w tej chwili, bo to po prostu trudne. Nie ma pensji, ponieważ nie miał wystarczającej liczby samozatrudnionych książek, aby otrzymać wsparcie.

Chris Murphy: On wpadł przez te pęknięcia i jest wielu innych ludzi, którzy wpadli przez te pęknięcia. Twierdzę, że jest to problem projektowy, że musimy patrzeć na to jak na problem projektowy. Ale jeśli przyjrzę się także szerszemu problemowi COVID i rządu i wszystkim tym wszystkim bez wdawania się w politykę, przeczytałem wczoraj artykuł w Guardianie o sąsiedzie Matta Hancocka i każdym, kto słucha, kto nie jest z Wielkiej Brytanii, Matt Hancock jest Sekretarz Zdrowia. Jego sąsiad, który prowadził firmę, pisał do niego SMS-y z prośbą o poradę na temat: „Jak mogę dostarczać produkty związane z COVIDem?” Wokół chumokracji, jak nazywają to gazety, jest strasznie dużo pomruków, przyjaciół przyjaciół ministrów rządu, którzy wydają się zdobywać pracę, ponieważ znają właściwych ludzi.

Chris Murphy: Wyczuwam, że przejdziemy na drugi koniec tego i zobaczymy to… Ludzie to widzą i myślą: „Dokąd idą te pieniądze i czy ludzie są odpowiednio opłacani? Ile kosztuje ta jednofuntowa koszulka ze sklepu X?” Nie chcę wymieniać żadnych marek. Ale za wszystko trzeba zapłacić, a za wszystko, co zostało zrobione, trzeba zapłacić ludziom, żeby to zrobić. Myślę, że ludzie są coraz bardziej zainteresowani, czy ludzie są uczciwie opłacani?

Drew: GraphQL był tematem naszego ostatniego, pełnego odcinka roku. Porozmawiałem z Eve Porcello i zapytałem, gdzie GraphQL pasuje do stosu deweloperskiego.

Ewa Porcello: Tak. GraphQL wpasowuje się pomiędzy front end a backend. Jest to więc rodzaj życia pomiędzy tymi dwoma i daje wiele korzyści programistom front-end i backend developerom. Jeśli jesteś programistą frontonu, możesz zdefiniować wszystkie wymagania dotyczące danych frontonu. Więc jeśli masz na przykład dużą listę komponentów React, możesz napisać zapytanie, które zdefiniuje wszystkie pola, które będziesz musiał wypełnić danymi dla tej strony.

Eve Porcello: Teraz, jeśli chodzi o backend, jest naprawdę własny, ponieważ możemy zebrać wiele danych z wielu różnych źródeł. Mamy więc dane w interfejsach API REST i bazach danych oraz we wszystkich tych różnych miejscach, a GraphQL zapewnia nam tę przyjemną, małą warstwę orkiestracji, aby naprawdę zrozumieć chaos, w którym znajdują się wszystkie nasze dane. Więc jest to naprawdę przydatne dla każdego rodzaju stosu.