Smashing Podcast Episode 23 z Guillermo Rauch: Co to jest Next.js?

Dziś mówimy o Next.js. Co to jest i gdzie może pasować do naszego przepływu pracy przy tworzeniu stron internetowych? Aby się dowiedzieć, rozmawiałem ze współtwórcą Guillermo Rauchem.

Pokaż notatki

• Guillermo Rauch na Twitterze
• Next.js

Cotygodniowa aktualizacja

• „Opanowanie rekwizytów i typów propType w React”
  autor: David Adeneye
• „Inspirowane decyzje projektowe z Bradbury Thompson: sztuka projektowania graficznego”
  przez Andy'ego Clarke'a
• „Konfigurowanie interfejsu API za pomocą Flask, Google Cloud SQL i App Engine”
  przez Wole Oyekanmi
• „Formy i walidacja w reakcji jonowej”
  Jerry Navi
• „Jak pomóc swoim klientom uzyskać więcej linków zwrotnych poprzez projektowanie”
  przez Suzanne Scacca

Transkrypcja

Drew McLellan: Jest założycielem i dyrektorem generalnym Vercel, platformy chmurowej dla stron statycznych, która pasuje do przepływu pracy Jamstack. Jest także współtwórcą Next.js. Wcześniej założył LearnBoost i CloudUp i jest dobrze znany jako twórca kilku popularnych bibliotek open source węzłów, takich jak Socket.io, Mongoose i SlackIn. Wcześniej był głównym programistą w MooTools, więc wiemy, że zna się na JavaScript jak własną kieszeń. Czy wiesz, że kiedyś otrzymał królewskie zlecenie od króla Hiszpanii na stworzenie rzeźby lodowej z sałaty lodowej? Moi miażdżący przyjaciele, witajcie Guillermo Raucha. Cześć Guillermo, jak się masz?

Guillermo Rauch: Jestem cholernie dobry, dziękuję, że mnie masz.

Drew: Chciałem z tobą dzisiaj porozmawiać o całym świecie Next.js, ponieważ jest to coś, o czym oczywiście osobiście masz dużą wiedzę, będąc od samego początku zaangażowanym jako współtwórca. Next.js to jedna z tych nazw projektów, które były na moim radarze podczas pracy w przestrzeni Jamstack, ale nie jest to coś, czemu osobiście się przyglądałem lub nad czym pracowałem zbyt blisko wcześniej. Dla ludzi, którzy są tacy jak ja, którzy być może nie są świadomi, czym jest Next.js, być może mógłbyś dać nam trochę informacji na temat tego, co to jest i jakie problemy próbuje rozwiązać.

Guillermo: Next.js jest bardzo interesującym członkiem uniwersum Jamstack, ponieważ Next.js faktycznie zaczął być frameworkiem w pełni skoncentrowanym na SSR. Zaczęło się szeroko stosować poza przestrzenią Jamstack, gdzie ludzie budowali bardzo duże rzeczy, szczególnie wtedy, gdy chcieli mieć treści generowane przez użytkowników lub treści dynamiczne, sieci społecznościowe lub e-commerce, i wiedzieli, że chcą SSR, ponieważ ich zestaw danych był bardzo duże lub bardzo dynamiczne. Myślę, że wypadło to poza radarem wielu ludziom w świecie Jamstack, ale później Next.js zyskał możliwości optymalizacji statycznej.

Guillermo: Z jednej strony, na przykład, gdybyś nie pobierał danych z najwyższego poziomu swojej strony za pomocą Next.js, twoja strona React byłaby… Również przy okazji, dla tych, którzy nie są w pełni świadomi, Next.js jest po prostu frameworkiem React do produkcji, ale ma możliwość wykonania renderowania. Następnie, gdy uzyskasz możliwości optymalizacji statycznej, jeśli nie określisz pobierania danych na najwyższym poziomie strony, zostaną one automatycznie wyeksportowane jako HTML, zamiast próbować robić cokolwiek z renderowaniem serwera.

Guillermo: Później zyskał również możliwość statycznego generowania witryn, co oznacza, że ​​można zdefiniować specjalny hak danych, ale ten hak danych pobiera dane w czasie kompilacji. Next.js stał się hybrydowym, bardzo potężnym dynamicznym i statycznym frameworkiem, a teraz bardzo się rozwija również w przestrzeni Jamstack.

Drew: Ludzie mogą powiedzieć, że React jest już frameworkiem, na pewno słyszeliście, że jest to opisane w ten sposób. Co to właściwie znaczy być szkieletem dla Reacta?

Guillermo: To świetna obserwacja, ponieważ zawsze zwracam uwagę ludziom, że React na Facebooku i React poza Facebookiem to zupełnie inne bestie. React na Facebooku w rzeczywistości jest używany razem z renderowaniem serwera, ale nawet ich renderowanie serwera, na przykład, nie korzysta z Node.js, używa wysoce wyspecjalizowanej maszyny wirtualnej o nazwie Hermes, która komunikuje się z ich rodzajem hackowania produkcyjnego i stosu PHP i odpowiedzi wszystkie te zaawansowane i egzotyczne potrzeby Facebooka.

Guillermo: Kiedy otwierają React, to prawie tak, jak open source'owy komponent. Zawsze nazywam to jak otwarte pozyskiwanie silnika, ale nie dawanie samochodu. To, co się wydarzyło, to to, że ludzie naprawdę chcieli jechać i jeździć z nim, chcieli docierać do miejsc z Reactem. W społeczności ludzie zaczęli tworzyć samochody i osadzili Reacta jako silnik, który był głównym celem kierowcy, dewelopera, aby React stał się podstawową częścią samochodu. Rzeczy takie jak Next.js i Gatsby i React Static oraz wiele innych frameworków zaczęły się pojawiać, które rozwiązywały potrzebę w stylu: „Właściwie chcę tworzyć w pełni załadowane strony i aplikacje”.

Guillermo: Podczas gdy React bardziej przypominał komponent i silnik dla określonych widżetów na stronie, z pewnością tak było w przypadku Facebooka. Szeroko i publicznie przyznają, że wymyślili go dla takich rzeczy, jak wsad powiadomień, widżet czatu, komponent kanału informacyjnego, a te komponenty były trasami React, które zostały osadzone w treści istniejącej aplikacji produkcyjnej z mnóstwem wierszy kodu a nawet inne biblioteki i frameworki JS.

Guillermo: Co to znaczy stworzyć ramy dla Reacta, oznacza to, że React stanie się fundamentalną częścią historii, miejmy nadzieję, i to jest coś, co spróbujemy zrobić z Next.js, krzywa uczenia się dotyczy głównie Reacta z kilkoma dodanymi powierzchnia dla Next.js, szczególnie w zakresie pobierania i routingu danych. Robimy też wiele optymalizacji produkcji, więc kiedy dostajesz Reacta, kiedy dostajesz aplikację Create React, która jest trochę jak, lubię nazywać to samochodzikiem, który daje ci Facebook, może potrzeby produkcyjne nie są tak naprawdę spełnione . Lub jeśli spróbujesz zrobić to sam, konfigurując Webpack i konfigurując Babel oraz konfigurując renderowanie serwera i generację statyczną, również ciężko jest złożyć samochód od zera. Next.js da ci tę zerową konfigurację, a także zoptymalizowany pod kątem produkcji zestaw ustawień domyślnych wokół budowania wielkich rzeczy za pomocą Reacta.

Drew: To tak, jakby tworzyło rodzaj ekosystemu wokół Twojej aplikacji React z kolekcją wstępnie skonfigurowanych narzędzi, które umożliwiają:

Guillermo: Zgadza się.

Drew: Ruszaj do przodu i wykonuj statyczne generowanie witryn lub renderowanie lub routing na serwerze.

Guillermo: Zgadza się i użyłeś tam słowa, które jest bardzo, bardzo kluczowe do tego wszystkiego, które jest wstępnie skonfigurowane. Mamy szczęście, że jako współtwórca Next.js zwrócił na siebie uwagę Google Chrome. Jedna z liderek tego projektu, jej chodzi o to, że kiedy pracowali nad frameworkami wewnętrznie w Google, napotykali wiele takich samych problemów, z jakimi borykają się dziś społeczność i open source. W Google było wiele różnych konkurencyjnych inicjatyw dotyczących skalowania i tworzenia naprawdę wydajnych aplikacji internetowych po wyjęciu z pudełka.

Guillermo: Dołączysz jako Googler i otrzymasz framework, dzięki któremu stworzysz naprawdę duże, gotowe do produkcji aplikacje o bardzo wysokiej wydajności. Shubie brała udział w wielu z tych inicjatyw i odkryła, że ​​istnieją dwa kluczowe składniki, dzięki którym framework odniesie sukces na dużą skalę. Pierwsza to konfiguracja wstępna, co oznacza, że ​​przychodzisz do pracy, masz zamiar uruchomić zupełnie nową aplikację, powinieneś otrzymać coś, co jest już gotowe do pracy i spełnia wiele wymagań produkcyjnych, które są znane w danym momencie w samą porę.

Guillermo: Z drugiej strony, innym naprawdę ważnym krokiem, nad którym pracujemy, jest zgodność. Możesz otrzymać najbardziej zoptymalizowany, gotowy do produkcji, wstępnie skonfigurowany framework, ale jeśli pójdziesz dalej i, na przykład, zaczniesz wprowadzać wiele ciężkich zależności lub skryptów stron trzecich lub użyj bardzo nieefektywnych układów, których malowanie zajmuje dużo czasu i tak dalej i tak dalej, wtedy sprawisz, że ta wstępna konfiguracja poszła na marne. Mieszając konfigurację wstępną z zachowaniem zgodności w czasie, programista nie tylko ma świetny punkt wyjścia, ale także prowadzi do sukcesu z biegiem czasu.

Drew: Wygląda na to, że cechą Next.js jest to, że jest dość uparty, warstwa interfejsu użytkownika to React, używa skryptu typu, używa Webpacka i to wszystko wybory, których dokonał projekt i to jest to, co otrzymujesz. Popraw mnie, jeśli się mylę, ale nie możesz zamienić React na Vue, na przykład w Next.js.

Guillermo: To dobry moment, w którym podejmowanie decyzji technicznych spotyka się ze sztuką. Z jednej strony chciałbym twierdzić, że Next jest bardzo nieocenione, a powodem tego jest to, że jeśli wejdziesz konkretnie na github.com/vercel/nextjs i katalog przykładów, zobaczysz, że jest to prawie jak kombinatoryczna eksplozja technologii, które możesz wykorzystać razem z Next.js. Zobaczysz Fire-based, zobaczysz Graphic UL, zobaczysz Apollo, zobaczysz Redux, zobaczysz MobX, w przestrzeni CSS jest jeszcze więcej opcji.

Guillermo: Mamy domyślny port CSS, który jest osadzony, ale możesz użyć dwóch jego odmian, jednego z importem, drugiego z tagami stylu, które nazywamy Style JSX, co bardzo przypomina podejście platformy internetowej do Shadow CSS. Powodem, dla którego mam na myśli brak opinii, jest to, że chcemy, aby Next.js był bardzo blisko „gołego metalu” sieci i nie wprowadzał wielu prymitywów, z którymi gdyby sieć za 10 lat była niekompatybilna. Następnie, jeśli spojrzysz na przykłady, zobaczysz, że istnieją wszystkie inne technologie, które możesz podłączyć.

Guillermo: Podstawowym poziomem opinii jest to, że jest React i nie będziesz w stanie go zastąpić, przynajmniej w najbliższym czasie. Jest też koncepcja, że ​​powinieneś być w stanie tworzyć strony, a to było jak nowa rzecz, kiedy ją uruchomiliśmy po raz pierwszy, czyli wszyscy próbują tworzyć aplikacje jednostronicowe. Zdaliśmy sobie sprawę, że internet składa się z witryn z wieloma stronami, które tworzą odrębne punkty wejścia za pośrednictwem wyszukiwarek, Twittera, Facebooka, sieci społecznościowych, towarzyszących e-maili, tak jak zawsze prowadzisz osobę do punktu wejścia. i ta osoba, która przechodzi przez ten punkt wejścia, nie powinna być zmuszona do pobierania całego obciążenia aplikacji.

Guillermo: Następnie ta ścieżka doprowadziła nas do wdrożenia renderowania serwerowego, a następnie generowania statycznego dla wielu stron, i tak dalej, i tak dalej. Ten inny podstawowy poziom opinii jest Next, powinien być frameworkiem, który działa w sieci, a nie przeciwko sieci. Co więcej, w React brakowało prymitywów pobierania i routingu danych, które dodaliśmy. Istnieje pewien poziom opinii, z którym trzeba sobie radzić, ponieważ każdy potrzebuje routera, więc równie dobrze można mieć wbudowany router domyślnie.

Drew: Wielką zaletą posiadania tych ustawień domyślnych jest to, że pozbawiają one wiele złożoności wyboru, że po prostu tam są, są skonfigurowane i możesz po prostu zacząć ich używać, nie myśląc zbyt wiele, ponieważ myślę, że wszyscy -

Guillermo: Dokładnie.

Drew: Byłem w sytuacjach, w których jest zbyt wiele możliwości wyboru, jakich komponentów użyć i może to być przytłaczające i przeszkadzać w osiągnięciu produktywności.

Guillermo: Dokładnie.

Drew: Do jakiego rodzaju projektów widzisz ludzi używających Next.js? Czy jest to w zasadzie każda sytuacja, w której możesz zbudować produkcyjną aplikację React, czy może jest bardziej odpowiednia dla określonych rodzajów witryn o dużej zawartości treści? Czy to ma znaczenie w tym sensie?

Guillermo: Tak, więc to była odwieczna debata w sieci, czy internet dla aplikacji, czy internet dla witryn, czy jest to hybryda? Jaka jest rola JavaScript, et cetera, et cetera? Ciężko jest udzielić prostej odpowiedzi, ale uważam, że sieć zawsze ewoluowała, aby być hybrydą treści, która ewoluuje, by być coraz bardziej dynamiczną i osobistą dla użytkownika. Nawet jeśli mówisz jak witryna z treścią, witryny internetowe z najwyższej półki na świecie mają bazy kodu, które są bardzo porównywalne z aplikacjami.

Guillermo: Świetnym przykładem jest tutaj New York Times, który daje osadzone widżety z narzędziami do analizy danych i interaktywną animacją, a także zaleci, którą historię przeczytać dalej, i ma wbudowany model subskrypcji, który czasami daje część treści, a czasami liczy, ile artykułów przeczytałeś. Na przykład, gdybym ci to powiedział, kiedy wynaleziono sieć, tak jak Tim Berners-Lee powiedziałby: „Nie, to szalone, to nie jest możliwe w sieci”, ale to jest sieć, którą mamy dzisiaj.

Guillermo: Next.js odpowiada na wiele z tych złożonych współczesnych potrzeb, co oznacza, że ​​zobaczysz wiele zastosowań e-commerce, zobaczysz z tym wiele treści. Nawiasem mówiąc, e-commerce oznacza nie tylko kupowanie przedmiotów, ale doświadczenia, takie jak największe witryny z nieruchomościami w sieci, realtor.com, zillow.com, trulio.com, cała ta kategoria to Next.js, a następnie treść witryny. Właśnie wprowadziliśmy washingtonpost.com jako klient Vercel i Next.js, mamy wtedy trzecią kategorię, która jest bardziej wyłaniająca się, ale bardzo interesująca, czyli pełne aplikacje i treści generowane przez użytkowników, jak tiktok.com, i trochę jak ty pomyślałby, że oryginalny jednostronicowy przypadek użycia aplikacji jest tam dość reprezentowany.

Guillermo: Next.js błyszczy, gdy trzeba mieć dużo treści, które muszą być udostępniane bardzo, bardzo szybko, muszą być zoptymalizowane pod kątem SEO, a pod koniec dnia są mieszanką dynamiki i statyki.

Drew: Rozmawiałem wcześniej z Marcy Sutton o Gatsby, który wydaje się być w podobnej przestrzeni. Wspaniale jest widzieć więcej niż jedno rozwiązanie problemu i mieć możliwość wyboru jednego projektu do następnego. Czy powiedziałbyś, że Next.js i Gatsby działają w tej samej przestrzeni problemowej i jak bardzo są podobne lub niepodobne?

Guillermo: Myślę, że niektóre przypadki użycia nakładają się na siebie. Na przykład mój osobisty blog rauchg.com działa na Next.js, mógł to być również świetny blog Gatsby'ego. Jest to takie nakładanie się w mniejszej, statycznej przestrzeni witryny, i przez małe nie mam na myśli nieistotne. Wiele dotcomów, które są super, super ważne, działa w praktycznie statycznej sieci, więc moim zdaniem to jest piękno Jamstack. Ponieważ Next.js może statycznie optymalizować Twoje strony, a następnie możesz dzięki temu uzyskać świetne wyniki Lighthouse, możesz go używać do nakładających się przypadków użycia.

Guillermo: Myślę, że granica zaczyna się rysować, gdy zaczynasz wchodzić w bardziej dynamiczne potrzeby i masz dużo stron, musisz je aktualizować za jednym razem. Chociaż Gatsby tworzy dla nich rozwiązania, Next.js ma już gotowe do produkcji rozwiązania na żywo, które działają z dowolnym rodzajem bazy danych, dowolnym zapleczem danych do „generowania” lub „drukowania” wielu, wielu stron. To tam klienci przechodzą dziś do Next.js zamiast Gatsby.

Drew: Jednym z problemów, na który każdy zdaje się napotykać, gdy ich rozwiązanie oparte na JavaScript staje się coraz większe, jest wydajność i to, jak sprawy mogą zacząć działać dość wolno, masz duże rozmiary pakietów. Tradycyjnie rzeczy takie jak dzielenie kodu mogą być dość skomplikowane, aby zostały poprawnie skonfigurowane. Widzę, że jest to jedna z funkcji, która wyskoczyła na mnie z Next.js, twierdzi, że dzielenie kodu jest automatyczne. Co robi Next.js w zakresie dzielenia kodu, aby to zadziałało?

Guillermo: Twoja obserwacja jest w 100% słuszna. Jedną z największych rzeczy w sieci i jedną z największych wag w sieci jest JavaScript i tak jak różne materiały mają różne gęstości i wagi, niezależnie od rzeczywistej objętości fizycznej, JavaScript wydaje się być bardzo gęstym, ciężkim elementem. Nawet niewielkie ilości JavaScriptu w porównaniu do, na przykład, obrazów, które mogą być przetwarzane asynchronicznie i poza głównym wątkiem, JavaScript wydaje się być szczególnie uciążliwy.

Guillermo: Next.js zainwestował ogromną ilość wysiłku w automatyczną optymalizację Twoich pakietów. Pierwszą intuicją, która była moją pierwszą intuicją, kiedy po raz pierwszy wpadłem na pomysł na Next.js, było to, że zamierzasz zdefiniować na przykład 10 tras. W świecie Next.js tworzysz katalog stron i umieszczasz tam swoje pliki Index.js, About.js, Settings.js, Dashboard.js, Termsofservice.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: Kiedy je wprowadzisz, chcemy dać ci przede wszystkim JS, który jest odpowiedni dla tej strony, a potem być może wspólny pakiet, aby kolejne nawigacje w systemie były bardzo szybkie. 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. Wiele osób mówi: „Dlaczego po prostu nie skorzystać z aplikacji Create React, jeśli wiem, że mam może kilka tras?” Zawsze im mówię: „Słuchaj, możesz je znaleźć jako strony, a ponieważ Next.js automatycznie pobierze z wyprzedzeniem te, które są połączone, w końcu otrzymasz aplikację jednostronicową, ale jest ona lepiej zoptymalizowana pod kątem początkowego malowania , ten początkowy punkt wejścia.”

Guillermo: To było początkowe podejście do dzielenia kodu, ale z czasem stało się o wiele bardziej wyrafinowane. Google dostarczyło bardzo fajną optymalizację o nazwie Module and No Module, która zapewni różnicowy JS nowoczesnym przeglądarkom oraz starszy JS, który jest obciążony wielopolami w innych przeglądarkach. Ta optymalizacja jest w 100% zautomatyzowana i daje ogromne oszczędności. Daliśmy go jednemu z naszych klientów, którego hostujemy na Vercel, zwanym Parnaby's. Myślę, że jeśli się nie mylę, było to coś bardzo, bardzo znaczącego. Może to być około 30% oszczędności w rozmiarze kodu, a to tylko dlatego, że zaktualizowali Next.js do wersji, która lepiej zoptymalizowała pakiety JS.

Guillermo: To był rodzaj punktu, który omawialiśmy wcześniej, czyli wybierasz Next.js, a z czasem będzie on tylko lepszy i bardziej optymalny, będzie nadal optymalizował rzeczy w Twoim imieniu. To znowu wstępne konfiguracje, z którymi nigdy nie musiałbyś się zajmować ani nie zawracać sobie głowy, a badania, których nawet nie chcesz robić, szczerze mówiąc. Jakbym oczywiście nie był tym bardzo zaangażowany, ale przyglądam się niektórym wewnętrznym dyskusjom i omawiali wszystkie te wielopola, które miały znaczenie tylko dla Internet Explorera X i Soho, pomyślałem: „Nawet nie chcę wiedzieć , po prostu uaktualnijmy Next.js i uzyskajmy wszystkie te korzyści.”

Drew: Czasami trzymanie się wartości domyślnych i trzymanie się najczęstszej konfiguracji rzeczy, co wydaje się być podejściem Next.js, przynosi czasem ogromne korzyści. Pamiętam, jak zacząłem pisać PHP na początku lat 2000. i wszyscy używali PHP i MySQL, a ja wtedy dopiero zaczynałem pisać z Windowsa, więc chciałem używać PHP i Microsoft Sequel Server. Możesz to zrobić, ale przez całą drogę płyniesz pod prąd. Potem, jak tylko przesiadłem się na MySQL, cały ekosystem zaczął dla mnie działać i nie musiałem o tym myśleć.

Guillermo: Tak, wszystko po prostu klika, to świetna obserwacja. Widzimy, że cały czas, podobnie jak ekosystem Babel, jest teraz tak potężny, że możesz stać się, na przykład, trochę szybszym, zamieniając Babel na coś innego, ale potem rezygnujesz z tej niesamowitej kompatybilności ekosystemu. To jest coś, o czym wspomniałeś wcześniej, i jak dla wielu ludzi, wydajność budowania i generowanie statyczne jest dużym wąskim gardłem i jest to coś, w czym bardzo sumiennie poprawiamy wydajność naszych narzędzi.

Guillermo: Na przykład jedną z rzeczy, które teraz robi Next.js, jest aktualizacja domyślnego pakietu Webpack 4 do Webpack 5, który ma kilka przełomowych rzeczy i dlatego najpierw oferujemy go ludziom jako opcję we fladze, ale później stanie się domyślnym. Webpack 5 wprowadza niesamowitą poprawę wydajności, ale nie poświęcamy ekosystemu Webpack, ulepszamy go stopniowo. Jasne, było kilka bardzo małych rzeczy, które trzeba było poświęcić, ale jest to niesamowita korzyść dzisiejszego ekosystemu JS, którą wielu ludzi przemilcza, myślę, ponieważ może widzą: „Och, mogliśmy zrobić X w Soho może było trochę szybciej, a może MPM w Soho zajęłoby mniej czasu.” Wychwytują pewne szczegóły i tracą większy obraz, czyli wartość ekosystemu jest ogromna.

Drew: Wartość posiadania całej konfiguracji, konserwacji i tej strony za pomocą projektu takiego jak Next.js, zamiast brania tego na siebie przez zamianę na coś innego, jest niesamowita, ponieważ jak tylko odejdziesz od tych domyślnych , bierzesz na siebie ciężar utrzymywania wszystkich zgodności i robienia tego samodzielnie. Jedną z rzeczy, którymi naprawdę interesowałem się Next.js, jest to, że dostępne są opcje tworzenia statycznego generowania witryn lub renderowania po stronie serwera, a może hybrydy tych dwóch. Myślę, że w ostatniej aktualizacji wprowadzono w tym zakresie pewne zmiany. Czy możesz nam o tym trochę opowiedzieć i kiedy możesz wybrać jedno lub drugie?

Guillermo: Tak, na pewno. Jednym z kluczowych elementów tego hybrydowego podejścia połączonego z systemem stron, który opisałem wcześniej, jest to, że możesz mieć strony w pełni statyczne lub strony renderowane przez serwer. Strona, która jest w pełni statyczna, ma niesamowitą zaletę tego, co nazywam statycznym podnoszeniem, co oznacza, że ​​możesz wziąć ten zasób i automatycznie umieścić go na krawędzi. Umieszczając go na krawędzi, mam na myśli to, że możesz go buforować, możesz zapobiegawczo buforować, możesz to replikować, możesz sprawić, że gdy nadejdzie żądanie, nigdy nie dotknie serwera, ponieważ wiemy z wyprzedzeniem.” Hej, Slash Index jest statyczny.”

Guillermo: To bardzo, bardzo interesująca korzyść, jeśli chodzi o obsługę globalnej publiczności. Zasadniczo otrzymujesz automatyczny CDN po wyjęciu z pudełka, zwłaszcza gdy wdrażasz nowoczesne sieci brzegowe, takie jak Vercel, AWS Amplify lub Netlify i tak dalej. Next.js ma tę przesłankę, że jeśli może być statyczny, powinien być statyczny. Kiedy po raz pierwszy zaczynasz projekt i pracujesz nad pierwszą stroną lub kopiesz opony frameworka, równie dobrze możesz wszystko uczynić statycznym.

Guillermo: Nawet w przypadku zaawansowanych potrzeb, na przykład vercel.com, nasze własne użycie Next.js jest w pełni statyczne. Jest to połączenie w pełni statycznego i statycznego generowania witryn, więc wszystkie nasze strony marketingowe są statyczne, nasz blog jest statycznie generowany z dynamicznego źródła danych, a następnie z naszego pulpitu nawigacyjnego, który zawiera wiele dynamicznych danych, ale możemy je dostarczyć jako powłoki lub szkielety , wszystkie strony związane z przeglądaniem wdrożeń, przeglądaniem twoich projektów, przeglądaniem twoich dzienników, itd., itd., są w zasadzie statycznymi stronami z JavaScriptem po stronie klienta.

Guillermo: Służy nam to niesamowicie dobrze, ponieważ wszystko, co wymaga bardzo szybkiego działania w pierwszym okienku, jest już wstępnie renderowane, wszystko, co wymaga SEO, jest już wstępnie renderowane i wszystko, co jest niezwykle dynamiczne, musimy tylko martwić się o bezpieczeństwo, ponieważ na przykład z perspektywy strony klienta, która korzysta z tych samych wywołań API, z których korzysta np. nasz CLI lub nasze integracje, i tak dalej, i tak dalej. W pełni statyczna strona internetowa, bardzo tania w obsłudze, niesamowicie skalowalna i tak dalej i tak dalej.

Guillermo: Teraz jedną szczególną rzeczą, której potrzebowaliśmy na naszym blogu, było to, że chcieliśmy bardzo szybko zaktualizować dane. Chcieliśmy bardzo szybko naprawić literówkę i nie czekać, aż powstanie cała kompilacja, a to jest bardzo istotna zaleta Next.js, ponieważ przechodząc od statycznego do dynamicznego, zapewnia to również między rozwiązaniami . W naszym blogu wykorzystaliśmy przyrostowe generowanie statyczne, więc zasadniczo możemy odbudować jedną stronę na raz, gdy zmieni się zawartość.

Guillermo: Wyobraź sobie, że mieliśmy nie tylko kilkaset postów na blogu, ale cały czas generowaliśmy wiele postów na blogu i ciągle aktualizowaliśmy, tak jak wspomniałem o jednym z naszych klientów, Washington Post, w takim przypadku musisz iść bardziej w kierunku pełnego SSR, zwłaszcza gdy zaczynasz dostosowywać zawartość dla każdego użytkownika. Ta podróż złożoności, którą właśnie opisałem, zaczęła się od tego, że mam jedną stronę marketingową, mam bloga, który ma kilka tysięcy stron, aż do dziesiątek tysięcy lub milionów stron. To podróż Next.js, którą możesz przebyć we własnym biznesie.

Guillermo: Następnie zaczynasz jako programista, aby wybrać między być może mniejszą odpowiedzialnością a większą odpowiedzialnością, ponieważ kiedy decydujesz się na korzystanie z SSR, teraz wykonujesz kod na serwerze, wykonujesz kod w chmurze, jest większa odpowiedzialność z więcej mocy. Fakt, że możesz decydować, gdzie używasz każdego rodzaju narzędzia, jest moim zdaniem bardzo, bardzo interesującą zaletą Next.

Drew: Tylko w praktycznych aspektach łączenia statycznego generowania witryn i renderowania po stronie serwera, jak to działa w odniesieniu do elementu serwera? Czy potrzebujesz dedykowanej platformy, takiej jak Vercel, aby móc to osiągnąć, czy jest to coś, co można zrobić prościej i prościej?

Guillermo: Next.js daje ci serwer deweloperski, więc pobierasz Next i uruchamiasz Next Dev, i to jest serwer deweloperski. Serwer deweloperski jest oczywiście niesamowicie zoptymalizowany pod kątem rozwoju, na przykład ma najnowszą technologię szybkiego odświeżania wydaną przez Facebooka, gdzie… Właściwie to Facebook go nie wypuścił, Facebook używa go wewnętrznie, aby uzyskać najlepszą i najbardziej wydajną oraz najbardziej niezawodną wymianę modułu gorącego , taki, że po prostu piszesz, a zmiany odzwierciedlają się na ekranie, więc to jest serwer deweloperski.

Guillermo: Then Next udostępnia serwer produkcyjny o nazwie Next Start, a Next Start ma wszystkie możliwości frameworka do samodzielnego hostowania. Ciekawą rzeczą w Vercel jest to, że po wdrożeniu Next jest automatycznie optymalizowany i jest w 100% bezserwerowy, co oznacza, że ​​nie ma żadnej odpowiedzialności za administrację, skalowanie, kasowanie i walidację kasy, czyszczenie, replikację, globalne przełączanie awaryjne i tak dalej i tak dalej, że musiałbyś się podjąć, gdy sam uruchomisz Następny start.

Guillermo: To także wielka zaleta Next.js, więc na przykład apple.com ma kilka różnych właściwości, poddomen i stron w dotcom na Next.js, które hostuje samodzielnie, ze względu na bardzo, bardzo zaawansowane i rygorystyczne potrzeby w zakresie bezpieczeństwa i prywatności . Z drugiej strony washingtonpost.com korzysta z Vercel, więc mamy tego rodzaju szerokie grono użytkowników i jesteśmy niezmiernie szczęśliwi, że możemy wspierać ich wszystkich. Moim zdaniem fajną rzeczą w tym, dokąd zmierza serverless, jest to, że może dać ci to, co najlepsze z obu światów pod względem najbardziej optymalnej wydajności, która z czasem staje się coraz lepsza, z najlepszym doświadczeniem dla programistów, takim jak: „Hej, nie mam martwić się o jakąkolwiek infrastrukturę”.

Drew: Next.js to projekt open source, który jest rozwijany przez zespół Vercel. Czy są inni współtwórcy poza Vercel?

Guillermo: Tak, więc Google Chrome jako główny, który aktywnie przesyła PR serwera, pomaga nam w optymalizacji i testowaniu go z partnerami, takimi jak bardzo duzi użytkownicy Next.js, którzy są już częścią ekosystemu Google, na przykład z powodu używania wielu i wiele aplikacji, więc muszą być ściśle zaangażowani jako partnerzy. Facebook, utrzymujemy świetne relacje z zespołem Facebooka. Na przykład szybkie odświeżanie, byliśmy pierwszym frameworkiem React, który to wylądował i pomogli nam przeprowadzić nas przez wszystkie rzeczy, których nauczyli się podczas używania Reacta i szybkiego odświeżania na Facebooku.

Guillermo: Współpracujemy z wieloma partnerami, którzy mają bardzo duże wdrożenia aplikacji Next.js na wolności z różnego rodzaju przypadków użycia, takich jak wyobraź sobie e-commerce i treści. Potem jest tylko wielu niezależnych współpracowników, ludzi, którzy osobiście korzystają z Next.js, ale także edukatorów i członków zespołów zajmujących się infrastrukturą frontową w dużych firmach. To bardzo, bardzo szeroki wysiłek społeczności.

Drew: Brzmi to jak obawa, że ​​ktoś może mieć, że jest to w znacznej części rozwijane przez Vercel, że może obawiać się, że zostanie unieruchomiony we wdrożeniu na tej konkretnej platformie, ale brzmi w dużym stopniu tak nie jest, a oni mogliby stworzyć witrynę i wdrożyć ją w Firebase lub Netlify lub…

Guillermo: Tak, absolutnie. Bardzo lubię to porównywać do Kubernetes z epoki Front Endu w pewnym sensie, ponieważ ostatecznie jestem głęboko przekonany, że … Kubernetes to coś, czego prawie każdy potrzebuje, gdy potrzebuje uruchomić procesy Linuksa , jak mówiłeś o opinii i mówisz, że to dobra technologia, jest bardzo nieuparty, ale jest pewna opinia, o której trochę zapominamy. To tak, jakby pod koniec dnia wyrosło z uruchamiania konkretnych demonów programów linuksowych spakowanych jako kontenery.

Guillermo: Next jest w podobnej sytuacji, ponieważ to, co uważamy za uniwersalny prymityw świata jako komponent React, jest oczywiście uparty, ale uważamy, że dla wielu przedsiębiorstw, tak jak one wszystkie skłaniają się ku Linuksowi, jesteśmy widząc to samo w stosunku do Reacta i Vue, ale Vue na szczęście ma też Nuxt, co jest bardzo niesamowitym rozwiązaniem, jest odpowiednikiem idei i zasad jak Next. Zbliżamy się do takich platform jak Next.js, jak Nuxt, jak Sapper dla ekosystemu Svelte.

Guillermo: Myślę, że powinny to być otwarte platformy, ponieważ znowu, jeśli wszyscy będą tego potrzebować, równie dobrze może nie wynaleźć koła na nowo w całej branży, prawda? Bardzo cieszymy się z tego stanowiska, zapraszamy ludzi do wdrażania go i rekonfiguracji, odbudowy i redystrybucji i tak dalej.

Drew: Niedawno została wydana nowa wersja Next.js, myślę, że wersja 9.5. Jakie znaczące zmiany pojawiły się w tym wydaniu?

Guillermo: Najbardziej niesamowita jest, jak mówiłem wcześniej, wiele rzeczy zaczyna się statycznych, a następnie staje się bardziej dynamicznych, gdy rzeczy się rozwijają. Nawiasem mówiąc, to było przedsięwzięcie WordPressa. WordPress na początku był oparty na statycznym podejściu do bazy danych, a potem wyrósł na potrzebę bazy danych, coś w rodzaju tego, co opisałeś, kiedy PHP ewoluowało, by stać się coraz bardziej MySQL. Zaletą Next.js 9.5 jest to, że sprawia, że ​​przyrostowe generowanie statyczne jest funkcją gotową do produkcji, więc usunęliśmy go z flagi niestabilnej.

Guillermo: Ta funkcja umożliwia przejście od statycznego do dynamicznego, nie rezygnując ze wszystkich korzyści statycznych i bez konieczności pełnego korzystania z dynamiki renderowanej przez serwer, co wydłuża użyteczny czas życia statycznego. Na przykład sposób, w jaki używamy go w Vercel, jak wspomniałem, wygląda tak, jakby nasz blog został w pełni wstępnie wyrenderowany w czasie kompilacji, ale na przykład za kilka minut mamy zamiar opublikować ważne ogłoszenie, a kiedy piszemy o tym na blogu, chcemy móc to poprawiać, naprawiać, przeglądać i tak dalej bez konieczności publikowania kompilacji trwającej od 5 do 10 minut za każdym razem, gdy zmieniamy jedną literę w jednym poście na blogu.

Guillermo: Dzięki przyrostowemu generowaniu statycznego można odbudować jedną stronę na raz. To, co może zająć minuty, a nawet sekundy, w zależności od wielkości witryny, teraz zajmuje milisekundy. Ponownie, nie musiałeś rezygnować z żadnych zalet statyki. Być może to jest to, co mnie najbardziej ekscytuje, że stało się stabilne na Next.js 9.5, a konkretnie dlatego, że społeczność JS i społeczność React oraz społeczność frameworka i społeczność generowana przez strony statyczne mówiły o tym jednorożcu o tworzeniu statycznego przyrostu dla a long time, so the fact that Next.js did it, it's being used in production and it's there for everybody to use, I think it's a major, major, major milestone.

Guillermo: There's lots of little DX benefits. One that's really nice in my opinion is Next.js, as I said, has a page system. You would argue, “Okay, so let's say that I'm uber.com and I've decided to migrate on Next.js, do I need to migrate every URL inside over to Next.js in order to go live?” This has become a pretty important concern for us, because lots of people choose Next.js, but they already are running big things, so how do you reconcile the two?

Guillermo: One of the things that Next.js allows you to do in 9.5 is you can say, “I want to handle all new pages that I created with Next.js with Next.js, and the rest I want to hand off to a legacy system.” That allows you incremental, incremental is the keyword here today, incremental adoption of Next.js. You can sort of begin to strangle your legacy application with your Next.js optimized application one page at a time, when you deploy and you introduce in your Next.js page, it gets handled by Next. If it doesn't match the Next.js routing system, it goes to the legacy system.

Drew: That sounds incredibly powerful, and the incremental rendering piece of that, I can think of several projects immediately that would really benefit that have maybe 30-minute build times for fixing a typo, as you say. That sort of technology is a big change.

Guillermo: We talked to one of the largest, I believe, use cases in Jamstack in the wild, and it was basically a documentation website and their build times were 40 minutes. We're doing a lot in this space, by the way, like we're making pre-rendering a lot faster as well. One of my intuitions for years to come is that as platforms get better, as the primitives get better, as the build pipelines get better we're going to continue to extend the useful lifetime of statics. Like what ended up taking 40 minutes is going to take four.

Guillermo: A great example is we're rolling out an incremental build cache, as well, system. I sort of pre-announced it on Twitter the other day, we're already seeing 5.5 times faster incremental builds. One of the things that I like about Jamstack is that the core tenet is pre-render as much as possible. I do think that's extremely valuable, because when you're pre-rendering you're not rendering just in time at runtime. Like what otherwise the visitor would incur in in terms of rendering costs on the server gets transferred to build time.

Guillermo: One of the most exciting things that's coming to Next is that without you doing anything as well, the build process is also getting faster. On the Vercel side, we're also taking advantage of some new cloud technology to make pre-rendering a lot faster as well. I think we're always going to live in this hybrid world, but as technology gets better, build times will get better, pre-rendering will get better and faster, and then you'll have more and more opportunities to do kind of a mix of the two.

Drew: Sounds like there's some really exciting things coming in the future for Next.js. Is there anything else we should know before we sort of go away and get started working with Next.js?

Guillermo: Yeah. I think for a lot of people for whom this is new, you can go to nextjs.org/learn, it'll walk you through building your first small static site with Next.js, and then it'll walk you through the journey of adding more and more complexity over time, so it's a really fun tutorial. I recommend also staying tuned for our announcement that I was just starting to share on twitter.com/vercel, where we share a lot of Next.js news. Specifically we highlight a lot of the work that's being done on our open source projects and our community projects and so on. For myself as well, twitter.com/rauchg if you want to stay on top of our thoughts on the ecosystem.

Drew: I've been learning all about Next.js today, what have you been learning about lately, Guillermo?

Guillermo: As a random tangent that I've been learning about, I decided to study more economics, so I've been really concerned with like what is the next big thing that's coming in terms of enabling people at scale to live better lives. I think we're going through a transition period, especially in the US, of noticing that a lot of the institutions that people were “banking on”, like the education system, like the healthcare system, a lot of those, like where you live and whether you're going to own a house or rent and things like that, a lot of these things are changing, they have changed rapidly, and people have lost their compass.

Guillermo: Things like, “Oh, should I go to college? Should I get a student loan?” and things like that, and there is a case to be made for capitalism 3.0, and there is a case to be made for next level of evolution in social and economic systems. I've been just trying to expand my horizons in learning a lot more about what could be next, no pun intended. I've found there's lots of great materials and lots of great books. A lot of people have been thinking about this problem, and there is lots of interesting solutions in the making.

Drew: To fascynujące. If you, dear listener, would like to hear more from Guillermo, you can find him on Twitter at @RauchG, and you can find more about Next.js and keep up to date with everything that goes on in that space at nextjs.org. Thanks for joining us today, Guillermo. Czy masz jakieś pożegnalne słowa?

Guillermo: No, thank you for having me.