Netlify kupiło Gatsby | Frontend Weekly vol. 123

1. Netlify przejmuje Gatsby

Dewelopment Gatsby rozpoczął się w 2015 roku i po prawie dwóch latach rozwoju doczekaliśmy się stablilnej wersji 1.0. W swoim czasie Gatsby był jednym z pierwszych frameworków, który pozwalał na kompilację Reacta do statycznego HTMLa. Powiedzieć, że Gatsby zdobył pewną popularność to tak jakby nie powiedzieć nic. Społeczność oszalała na jego punkcie. Do dziś Gatsby pozostaje jednym z najbardziej rozpoznawalnych frameworków, o którym słyszał niemal każdy React deweloper.

Ostatnie lata nie były jednak łatwe dla Gatsbiego. Konkurenci tacy jak Next.js czy Remix zaprezentowali znacznie bardziej złożone strategie renderowania po stronie serwera. Oczywiście Gatsby nie pozostawał bezczynny. W październiku 2021 roku ukazał się Gatsby 4.0, który wprowadzał takie funkcje jak Deffered Static Generation czy renderowanie na żądanie. W listopadzie 2022 roku ukazał się Gatsby 5.0. który przyniósł eksperymentalne wsparcie dla Partial Hydration i React Server Components. Niestety, w tym momencie przepaść między Next.js była już bardzo duża. Z moich obserwacji wynika też, że Gatsby wciąć walczy o pozbycie się etykiety prostego generatora statycznych stron.

Szczerze mówiąc, bezpośrednie porównanie Gatsby do Next.js jest trochę niesprawiedliwe. Zespół rozwijający Gatsby zbudował kilka interesujący narzędzi wokół swojego frameworku. Projekt Valhalla jest tego świetnym przykładem. Ma on zapewnić warstwę danych nad wieloma systemami CMS i wyeksponować ją poprzez spójne GraphQL API. W ten sposób możemy całkowicie oddzielić CMS od frontendu. Chcesz zmigrować swój CMS? Żadne zmiany na froncie nie są wymagane! Chcesz zmienić framework na frontendzie? Żadne zmiany w warstwie pobieraniu danych nie są wymagane! Vhcesz stopniowo migrować do innego CMS? Również nie ma problemu.

Wszystkie opisane powyżej osiągnięcia nie byłyby możliwe bez odpowiedniego finansowania. W 2018 roku powstało Gatsby Inc. Na start udało się zgromadzić od inwestorów prawie 4M$. W kolejnych latach Gatsby Inc. pozyskało również dalsze finansowanie z serii A (15M$) oraz serii B (28M$). Podsumowując, firma pozyskała prawie 40M$ na budowę czegoś, co nazwano content-mesh, a co później stało się projektem Valhalla.

W zeszłym tygodniu ogłoszono, że Gatsby Inc. zostało przejęte przez Netlify. Jeśli jeszcze nie słyszałeś o Netlify, jest to platforma która zapewnia hosting stron internetowych, funkcjonalności Continous Integration i Continous Deployment oraz Serverless Functions. Nadrzędną misją Netlify jest ułatwienie programistom budowania, wdrażania i zarządzania ich aplikacjam poprzez integrację z szeregiem zewnętrzych usług. Netlify pozyskał też całkiem spore finansowanie – ponad 200M$ w 7 rundach.

Netlify ma długą historię inwestowania w technologie Open Source powiązane z JAMStack. W lutym 2022 roku zatrudnili Zacha Leathermana do pracy w pełnym wymiarze godzin nad jego generatorem stron statycznych o nazwie Eleventy. W maju 2022 roku zatrudnili Ryana Carniato do pełnoetatowej pracy nad SolidJS – frameworkiem podobnym do Reacta, ale działającym bez VirtualDOM imającym bardzo ciekawe podejście do renderowania po stronie serwera.

Na pierwszy rzut oka można pomyśleć, że Gatsby to tylko kolejny framework w portfolio Netlify. Choć Netlify obiecuje, że rozwój Gatsby będzie kontynuowany, wydaje mi się, że przejęcie to dotyczyło bardziej Gatsby Cloud i Project Valhalla. Niestety, kwota transakcji nie została publicznie ujawniona.

Na zakończenie tej części chciałbym podzielić się z Wami moją małą obserwacją. Małe startupy budowane w ostatnich latach wokół technologii Open Source powoli zaczynają szukać parasola w postaci większych i lepiej ugruntownaych firm. Wystarczy spojrzeć na przejęcie Remix przez Shopify, przejęcie Ionic przez OutSystems, czy przejęcie TurboRepo przez Vercel. Wszystkie te przejęcia mają sporo sensu, ale gdzieś w głębi duszy czuję, że żadne z nich nie miałoby miejsca kilka lat temu, gdy globalna gospodarka kwitła. Z drugiej strony, nie jestem ekonomistą ani badaczem rynku, więc nie przykładajcie do mojej opinii zbyt dużej wagi.

Odkryj więcej treści IT dopasowanych do Ciebie

W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!

2. Przyszłośc Create React App

Create React App to narzędzie CLI, które umożliwia skonfigurowanie nowoczesnej aplikacji internetowej poprzez uruchomienie jednego polecenia (nie bijcie – to cytat z oficjalnej strony CRA). Niestety, przez ostatnie kilka lat narzędzie zostało mocno porzucone. Około 2 tygodnie temu popularny celebryta JavaScript Theo Browne tweetował tak:

Tweet dostał tak dużo reakcji, że Theo naprawdę postanowił otworzyć Pull Request do repozytorium React zmieniając rekomendację z Create React App na Vite. Wywołało to ogromną falę dyskusji.

• „Theo zrobił ten PR tylko po to, żeby zyskać więcej obserwatorów. Wszystkie poruszane tu kwestie zostały już omówione gdzie indziej”
• „Create React App nie jest najlepszym narzędziem, ale pomaga początkującym wykonać pracę bez wchodzenia w szczegóły skomplkowancy narzędzi”
• „Zespół React nie powinien wybierać swoich faworytów – Rollup to równie dobra propozycja jak Vite, a Remix to dobra alternatywa dla Next.js”
• „Dokumentacja React powinna być prosta dla zupełnie początkujących, którzy nie wiedzą jeszcze, czym są narzędzia do budowania aplikacji czy meta frameworki”
• „React nie powinien polecać przestarzałych narzędzi. Żadna rekomendacja jest lepsza od przestarzałej rekomendacji”

Jak widać, problem nie jest prosty, a rozwiązanie nie jest oczywiste. W tym tygodniu Dan Abramov (członek zespołu React Core i facet stojący za React Hoosk i React Server Components) postanowił zabrać głos. Jego komentarz mógłby z łatwością służyć za RFC lub być osobnym wpisem na blogu. Przechodzi on przez historię Create React App, wymienia wszystkie jego problemy i proponuje różne ich rozwiązania. Jeśli masz trochę wolnego czasu to naprawdę polecam przeczytać. TLDR dla wszystkich wyjątkowo zajętych. Create React App stanie się „App Launcherem” zadającym deweloperom pytania o poszczególne narzędzia. Obecna implementacja będzie dostępna jako opcja „klasyczna” i zaoferuje początkującym łatwy punkt startowy. W nadchodzących miesiącach możemy się spodziewać pełnego szczegółów RFC.

3. Evan You opowiada o Vue w 2023

Zacznijmy od tego, że nagrania z Vue.js Nation są już publicznie dostępne w sieci! Jeśli jesteś Vue Developerem to na pewno znajdziesz tu coś dla siebie. Ja napomknę tu tylko o kilku prelekcjach, które rzuciły mi się w oczy:

• „You’re probably using Lighthouse wrong: How we misuse most common tool to measure web performance?” by Filip Rakowski
• „Decoding web accessibility through testing” by Anuradha Kumari
• „Let’s talk about Security in Vue & Nuxt” by Jakub Andrzejewski

Nie jesteśmy tutaj jednak, aby porozmawiać o Vue.js Nation i chciałbym skupić się na keynote od Evana You na temat Vue w 2023 roku. Zacznijmy od tego, że żegnamy się z Reactivity Transform. Jeśli nie słyszałeś wcześniej tego terminu, Reactivity Transform był sporą paczką usprawnień do Reactivity API. Zasadniczo wszystkie metody, takie jak ref czy computed, miały otrzymać wersję poprzedzoną $, która nie wymagałaby wywołań .value.

// Without Reactivity Transform
<script setup>
import { ref } from 'vue'

let count = ref(0)

console.log(count.value)

function increment() {
  count.value++
}
</script>

<template>
  <button @click="increment">{{ count }}</button>
</template>

// With Reactivity Transform
<script setup>
let count = $ref(0)

console.log(count)

function increment() {
  count++
}
</script>

<template>
  <button @click="increment">{{ count }}</button>
</template>

Po zebraniu opinii od społeczności zespół Vue postanowił zrezygnować z Reactivity Transform. Wielu osobom nie spodobała się nowa funkcjonalność, co skolei wywołało obawy o potencjalną fragmentację społeczności. Jeśli już używasz Reactivity Transform nie masz się jednak czym martwić. Istniejąca implementacja zostanie wyeksportowana do osobnego pakietu/pluginu. Eksperymentalne API będzie wspierane w Vue Core aż do Vue 3.4. Na koniec warto wspomnieć jeszcze, że jest jedna funkcja z Reactivity Transform, która zostanie wydzielona i wyląduje w Vue 3.3. Jest nią Reactive Props Destructure.

// Vue 3.2
const props = withDefaults(
  defineProps({ foo: number }>(),
  { foo: 1 }
)

props.foo

// Vue 3.3 (Reactive Props Descructure)
const {
  foo = 1
} = defineProps({ foo: number }>();

foo //stays reacitve!

W pierwszym kwartale 2023 roku zespół Vue chce skupić się na naprawianiu błędów i dostarczeniu Vue 3.3. Ogólnie rzecz biorąc, w 2023 roku zespół chciałby dostarczać więcej mniejszych i bardziej inkrementalnych wydań. Spore opóźnienie Vue 3.3 ujawniło problemy z obecnym procesem releasów i w 2024 Vue chciałoby ich uniknąć.

W drugim kwartale 2023 roku zespół Vue skupi się na usprawnieniach renderowania po stronie serwera. Jedyną wspomnianą na ten moment funkcjonalnością jest Lazy Hydration. Niestety, aby uzyskać więcej szczegółów na ten temat, będziemy musieli poczekać na RFC.

W trzecim i czwartym kwartale 2023 roku zespół Vue chce się skupić na Vapor Mode – kompilatorze inspirowanym Solid. Wykorzyszta on format Vue Single File i skompiluje go do bardziej optymalnego formatu. W efekcie nasz kod będzie szybszy, będzie zużywa mniej pamięci i będzie wymaga mniej kodu w runtime (przynajmniej w porównaniu do obecnego rozwiazania opartego na Virtual DOM). Przed Vapor Mode jest jeszcze długa droga, ale na pewno usłyszycie o nim w niejednym z naszych weekly.

Odkryj więcej treści IT dopasowanych do Ciebie

W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!

Bonus: Don’t use return types (?)

Przez ostatnie kilka dni w mojej bańce Twittera mówi się o jednej rzeczy – o filmie Matta Pottocka „Don’t use return types, unless…”. Teza jest dość prosta: Jeśli twoja funkcja ma tylko jeden return, to nie powinieneś dla niej deklarować typów i pozwolić TypeScriptowi zrobić to za Ciebie.

Społeczność Twittera wybuchła. Niektórzy zupełnie nie zgadzali się z postawioną tezą i sugerowali, że zawsze pownniśmy deklarować zwracane typy:

Inni poszli o krok dalej i rozszerzyli tezę do: „Nigdy nie deklaruj zwracanych typów”

Jeśli chcecie zanurzyć się trochę bardziej w temacie, to polecam fragment poniższego streama na którym Theo i Prime wdają się w prawie godzinną dyskusję na temat preferowanego rozwiązania.

Niektórzy z was mogą mieć wrażenie, że takie dyskusje są nieco toksyczne. Ja osobiście czuję, że śledzenie tej dramy nauczyło mnie trochę o TypeScript i jeszcze więcej o perspektywach innych ludzi. No i bez tej dramy nie bylibyśmy świadkami pierwszej TypeScriptowej bitwy na memy.