Nuxt 3 | Frontend Weekly vol. 114

1. Nuxt 3, czyli prawdziwy SSR dla Vue 3

Myślę, że gdyby pokazać sztucznej inteligencji Frontend Weekly z ostatnich miesięcy, to stwierdziłaby, że jest to newsletter na temat renderowania po stronie serwera. Nic nie poradzę na to, że cały świat oszalał ostatnio na tym punkcie. W tym tygodniu po raz kolejny dolewamy oliwy do ognia, bo po ponad dwóch latach developmentu ukazał się Nuxt 3. A to oznacza, że Vue 3 wreszcie może być renderowane po stronie serwera! Dlaczego na Nuxt 3 musieliśmy czekać tak długo? Czy Nuxt przerasta Next.js pomimo mniejszego budżetu? Na te pytania postaram się odpowiedzieć w dzisiejszym przeglądzie.

Nie jest tajemnicą, że Nuxt garściami czerpie inspiracje z Next.js. Jak zapewne się domyślacie, oznacza to, że routing w Nuxt oparty jest o strukturę katalogów. W najnowszej wersji frameworku niewiele się w tej kwestii zmienia. Zarówno nazwnictwo jak i sposób dopasowywania ścieżek działają bez większych zmian. Do dyspozycji mamy więc katalog `pages`, gdzie umieszczamy nasze strony, `components`, gdzie umieszczam współdzielone komponenty, czy `layouts` gdzie umieszczamy “opakowania” na nasze strony (tak, Nuxt 2 obsługiwało funkcjonalność `layouts` na długo przed Next.js).

To co szybko rzuca się w oczy przeglądając dokumentację Nuxt 3, to całkowity brak importów. Jak się okazuje, nie jest to ani celowe uproszczenie, ani tym bardziej niedopatrzenie ze strony autorów dokumentacji. Nuxt 3 wykorzystuje bibliotekę `unjs/unimport`, która odpowiedzialna jest za automatyczne generowanie importów. W przypadku wystąpienia konfliktu rzucony zostanie błąd, którego pozbyć można się ręcznie definiując dany import.

<script setup>
  /* ref() and computed() are auto-imported */
  const count = ref(1)
  const double = computed(() => count.value * 2)
</script>

Kolejną nowością jest natywne wsparcie dla plików Markdown na sterydach. Co mam przez to na myśli? Nuxt 3 pozwala w plikach Markdown wykorzystywać komponenty Vue. Co ważne, komponenty te możemy dowolnie parametryzować, a nawet przekazywać do nich wyrenderowane fragmenty Markdown. Funkcjonalności takie jak ta, może i nie wywracają świata do góry nogami, ale na pewno docenią je wszyscy autorzy blogów i dokumentacji.

// pages/[...slug].vue
<template>
  <main>
    <ContentDoc />
  </main>
</template>

// content/index.md
# Nuxt Content Hello World

[About](/about)

::app-button{variant=”filled”}
Hello **World**!
::

Przeglądając strukturę katalogów Nuxt 3 (swoją drogą dokumentacja ta jest naprawdę dobra i czytelna) natrafić możemy jeszcze na jedną nowość – katalog `server`. W katalogu tym zdefiniować możemy nasze REST API. Podobnie jak w przypadku katalogu `pages`, umiejscowienie plików definiuje ścieżkę endpointa. Nuxt wygeneruje za nas odpowiednie typy. Kiedy w `useFetch` wywołamy nasz endpoint automatycznie będzie on w pełni type-safe.

// server/routes/hello.ts
export default defineEventHandler(() => 'Hello World!');

// pages/index.vue
<script setup>
  const response = useFetch(‘/hello’); // response will automatically have string type
</script>

Ostatnią dużą funkcjonalność to alternatywne tryby działania Nuxt 3. Domyślnie framework renderuje strony po stronie serwera. Przy pomocy konfiguracji możemy zmienić to zachowanie. Wśród dostępnych opcji znajdziemy statyczne generowanie strony, renderowanie po stronie klienta, ale też bardziej zaawansowane opcje takie jak inkrementalne budowanie.

No dobra, wszystkie nowe funkcjonalności wyglądają ciekawie, ale co zajęło deweloperom aż dwa lata? Dlaczego nie zastosowano bardziej inkrementalnej strategii, która umożliwiłaby renderowanie Vue po stronie serwera bez tych wszystkich “szmerów-bajerów”? W momencie releasu Vue 3, zespół stojący za Nuxt podjął bardzo ważną architektoniczną decyzją – poświęcić bezcenny czas na uczynienie Nuxt kompatybilnym z Vue 3, czy też wykorzystać okazję i przebudować cały framework tak, aby możliwy był jego dynamiczny rozwój w przyszłości. Wybór padła na tą drugą opcje, czego efektem jest Nitro.

Nitro to serwer JavaScript, który może być uruchamiany na dowolnym środowisku. Należy przez to rozumieć, że można go uruchomić zarówno w Node.js jak i w Deno, ale także we wszelakich środowiskach chmurowych ze szczególnym uwzględnieniem Edge Functions. Poprzez implikację oznacza to, że Nuxt 3 bez większych problemów może być uruchamiany tak blisko klienta jak to tylko możliwe. Właściwie wszystkie funkcjonalności, o których mogliście przeczytać wyżej, nie byłyby osiągalne, gdyby nie powstanie nowego silnika.

Czy zastosowana strategia była słuszna? Vue 3 bardzo straciło na braku dobrej biblioteki do renderowania po stronie serwera przez pierwsze dwa lata swojego życia. Z drugiej jednak strony, Vue 3 pełne było breaking changes, które po nocach śniły się autorom bibliotek do Vue 2. Kto wie, czy stworzenie Nuxt 2 kompatybilnego z Vue 3, byłoby w ogóle możliwe, a jeśli tak, to czy nie zajęłoby porównywalnej ilości czasu.

Źródła:

https://nuxt.com/v3
https://www.youtube.com/watch?v=cSjlefuZlaI
https://www.youtube.com/watch?v=noq-ZHTD2Cg
https://nuxt.com/docs/guide/concepts/
https://nitro.unjs.io/
https://www.vuemastery.com/blog/new-nuxt-3-feature-incremental-static-generation/

2. Nx zgarnia 8.5 miliona dolarów

Nrwl, czyli firma stojąca za Nx, została założona przez dwóch deweloperów z zespołu Angulara. Początkowo działałą ona jak typowa firma konsultingowa pomagająca dużym korporacjom budować aplikacje przy użyciu frameworka od Google. Z czasem w portfolio firmy zawitał Nx, czyli narzędziem ułatwiające pracę z Angularowymi mono-repo. Powstało ono z myślą o klientach firmy, a przy jego projektowaniu deweloperzy wykorzystali swoje doświadczenie przy pracy z dużymi projektami jakie nabyli w Google.

Nx działał na tyle dobrze, że dwójka deweloperów postanowiła porzucić działalność konsultingową i skupić się na jego rozwoju. Na przestrzeni lat, Nx przestał być narzędziem dedykowanym dla Angulara i stał się narzędziem rozwijanym z myślą o JavaScript . Deweloperzy stopniowo pokochali Nx i obecnie jest on najpopularniejszym narzędziem w swojej kategorii.

Interesującym epizodem w najnowszej historii Nx jest przejęcie pieczy nad lerną – narzędziem, które jeszcze 2 lata temu było tym najpopularniejszym jeśli chodzi o zarządzanie monorepo. Projekt ten przestał być rozwijany i przez około rok dogorywał w swoistym limbo. Z stanu tego wyrwał go dopiero Nx, który objął pieczę nad przywróceniem go do życia. Krótkoterminowo firma zamierzała skupić się na naprawieniu krytycznych błędów i podatności. Długoterminowy plan zakładał wprowadzeni funkcjonalnościi, które umożliwią bezproblemową integrację między Lerną i Nx’em. Jak pokazał czas,obietnice zostały zrealizowane. Kilka tygodni temu zobaczyliśmy pierwszą dużą wersję Lerny. Wszystkie duże funkcjonalności, takie jak … zbudowane zostały w oparciu o Nx.

W tym momencie możemy zastanowić się jak na dzień dzisiejszy wygląda sytuacja jeśli chodzi o narzędzia do zarządzania JavaScriptowymi monorepo. W rękach dobrze dofinansowane firmy Nrwl znajdują się dwa najpopularniejsze narzędzia w postaci `Nx` oraz `lerna`. W rękach jeszcze lepiej dofinansowanej firmy Vercel (tej samej która stoi za Next.js) znajduje się narzędzie Turborepo. Co prawda na razie brakuje mu jeszcze trochę do konkurencji, ale wciąż prężnie się rozwija no i stoi za nim naprawdę duża firma. Ciężko przewidywać na którą stronę przechyli się szala zwycięstwa w przyszłości.

Źródła:

https://techcrunch.com/2022/11/17/with-8-6m-in-seed-funding-nx-wants-to-take-monorepos-mainstream/

3. Arrow.js – dni od pojawienia się nowego frameworku: 0

Czasy, kiedy nowe frameowrki i biblioteki wyrastały jak grzyby po deszczu mamy już na szczęście za sobą. Wciąż jednak od czasu do czasu jakaś biblioteka wzbudzi zainteresowanie w tej naszej nudnej i ustatkowanej społeczności. Taka sytuacja miała miejsce w zeszłym tygodniu, kiedy to wszyscy zaczęli mówić o Arrow.js.

Nowy framework (a właściwie bardziej bibliotekę) wyróżnia przede wszystkim prostota oraz postawienie na natywne funkcjonalności JavaScript. Spójrzcie tylko na poniższy fragment:

import { reactive, html } from '@arrow-js/core'

const data = reactive({
  clicks: 0
});

html`
  <button @click="${() => data.clicks++}">
    Fired ${() => data.clicks} arrows
  </button>
`

Metoda reactive, za pomocą Proxies tworzy obiekt, w którym zmiany można obserwować za pomocą metody `.$on()`. Do renderowania wykorzystane zostały Tagged Templates. Magiczny prefix html (tak naprawdę jest najprostszą na świecie funkcją) sprawia, że obserwowane są zmiany w reaktywnych obiektach.

Jakkolwiek szokujące może się to wydawać, to już wszystko co oferuje Arrow.js. Czy wygryzie on Reacta, Vue, Angulara albo chociaż Svelte? Szanse na to są raczej małe, jeśli nie zerowe. Mimo wszystko wydaje się on ciekawym narzędziem. Jeśli macie wolne 15 minut to polecam zanurzenie się w dokumentację, chociażby po to, żeby lepiej zrozumieć jak działa pełnoprawny framework mający mniej niż tysiąc linii kodu.

Źródła:

https://www.arrow-js.com/

4. Czas oddać swój głos w State of JS 2022

Powoli zbliżamy się do tego czasu w roku, kiedy nasze przeglądy będą poświęcone głównie wszelkiego rodzaju podsumowaniom i statystykom (czyt. koniec roku 2022). Zanim to jednak nastąpi, wszyscy musimy wypełnić całą masę ankiet, które dostarczą danych do wszelakich raportów. Nie prosiłbym Was o wypełnienie losowej ankiety, gdybyście nie mogli wynieść z niej czegoś dla siebie. Podobnie jak w przypadku State of CSS, State of JS jest najlepszy miejscem, żeby nadrobić biblioteki jak i natywne funkcjonalności, które przeszły poza naszym radarem na przestrzeni ostatnich lat. Pod koniec całej ankiety otrzymacieprocentowy wynik i listę linków, które pozwolą Wam szybko uzupełnić braki.