Przyszłość Nuxt: Sébastien Chopin o Nuxt 4, Vercel i Next.js

W 2016 roku Sébastien Chopin postawił sobie tygodniowe wyzwanie: stworzyć odpowiednik Next.js dla Vue.js. Ten prototyp przerodził się w Nuxt, jeden z najpopularniejszych frameworków w ekosystemie Vue.

W rozmowie z Jakubem Andrzejewskim i Szymonem Licau z Monterail Chopin wraca do tej drogi: od swoich początków jako 12-letni programista PHP po niedawne przejęcie NuxtLabs przez Vercel.

Rozmowa dotyczy decyzji technicznych, które ukształtowały Nuxt, między innymi tego, skąd wzięły się routing oparty na plikach i katalog .nuxt oraz dlaczego polecenie nuxt generate pojawiło się już tydzień po pierwszym wydaniu. Chopin wyjaśnia też, jak Nitro ewoluowało w samodzielny silnik serwerowy, co w praktyce oznacza „full-stack Nuxt” z narzędziami takimi jak Nuxt DB i moduły storage, a także przedstawia swoją długofalową wizję „Nuxt Assistant”, który mógłby pomagać programistom tworzyć aplikacje przez wbudowany interfejs AI.

Mówiąc o przejęciu przez Vercel, Chopin odpowiada na pytania, które zadaje sobie wiele osób w społeczności: co się zmieni, co pozostanie bez zmian i jak Nuxt zachowa otwartość, społecznościowy charakter oraz niezależność od hostingu.

Pełny wywiad możesz obejrzeć na kanale Monterail na YouTube albo czytać dalej, by zapoznać się z pełnym zapisem rozmowy.

Jak Sébastien Chopin stworzył Nuxt?

Sébastien: Cześć wszystkim, dzięki za zaproszenie. Cieszę się, że tu jestem i mogę opowiedzieć o kilku rzeczach, którymi chyba jeszcze wcześniej się nie dzieliłem. Nazywam się Sébastien Chopin. Tworzę aplikacje webowe od 12. roku życia. Zaczynałem od PHP i około 19. roku życia przestałem z nim pracować, kiedy odkryłem Node.js. Wtedy zakochałem się w JavaScripcie.

Już wtedy robiłem trochę JavaScriptu razem z PHP, kiedy chciałem wdrożyć ładowanie treści przy przewijaniu z użyciem Ajaxa. Bardzo zależało mi na tym, żeby unikać przeładowywania stron i myślę, że to ostatecznie doprowadziło mnie do stworzenia Nuxt, bo nadal nie znoszę widoku przeładowującej się strony. Mimo że doceniam pracę nad innymi frameworkami, to doprowadza mnie to do szału.

Renderowanie po stronie serwera i optymalizacja pod wyszukiwarki były dla mnie bardzo ważne, kiedy pracowałem nad sklepem internetowym. Możliwość połączenia doświadczenia SPA z renderowaniem po stronie serwera na potrzeby SEO była ogromną ulgą.

To było w 2016 roku, kiedy pracowałem nad sklepem internetowym opartym na Node.js i Vue.js 2 z renderowaniem po stronie serwera, i wszystko działało bardzo dobrze. Musiałem jednak zarządzać konfiguracją Webpacka, a to było naprawdę trudne. W październiku 2016 roku zobaczyłem ogłoszenie Vercel o Next.js. Śledziłem Guillermo Raucha ze względu na jego pracę nad socket.io i Mongoose. Prowadziłem wtedy blog atinux.fr, na którym publikowałem artykuły po francusku, dziś już ich tam nie ma, o Node.js, MongoDB, Elasticsearch i całym tym stosie technologicznym, który wtedy nie był jeszcze popularny w Europie. Lubiłem pisać o socket.io i innych narzędziach.

Naturalnie trafiłem więc na Next.js i od razu to do mnie trafiło: ten model stron znany z PHP, SPA, które wcześniej tworzyłem w Backbone.js, potem Vue, renderowanie po stronie serwera, e-commerce. Pomyślałem: „Tak, zróbmy to samo dla społeczności Vue”. I naturalnie z Vue, litery „U” i Next powstało „Nuxt”, a nazwa była wolna na npm i GitHubie.

Postawiłem więc sobie to wyzwanie i tydzień później miałem już działający pierwszy prototyp. Potem ludzie ze społeczności Vue go zauważyli i zaczęli o nim mówić. No i jesteśmy tutaj dzisiaj, dziewięć lat później, rozmawiając o tym. Nie spodziewałem się tego i cieszę się, jak to się potoczyło.

Co znalazło się w pierwszym prototypie Nuxt i skąd wziął się routing oparty na plikach?

Czym wtedy był Nuxt? Co zawierała ta pierwsza wersja, którą uznałeś za gotową do testów lub wczesnego użycia, a co planowałeś rozbudować później?

Sébastien: Myślę, że da się znaleźć commity, to było chyba tydzień później, czyli pod koniec października. Moim głównym celem było stworzenie CLI. To było dobre, bo inspirowałem się Next.js, więc specyfikacja była prosta: potrzebujesz polecenia do uruchomienia serwera developerskiego. Wtedy było tylko polecenie nuxt i trzeba było mieć katalog pages.

Na szczęście w społeczności Vue mieliśmy Vue i Vue Router. W praktyce musiałem więc tylko odczytywać system plików. Dzięki doświadczeniu z Node.js dobrze znałem jego API. Odczytywałem system plików, a trudność w porównaniu z Next.js polegała na tym, że przeczytałem kod źródłowy Next i poszedłem w przeciwnym kierunku. Oni mieli własny system routingu.

Na rozwiązanie wpadłem w nocy: a co, gdyby odczytywać system plików, strukturę katalogów, i generować końcowy plik, z którego aplikacja będzie korzystać i który zaimportuje? Właśnie tak powstał katalog .nuxt. Jeśli masz projekt w Nuxt, bardzo polecam zajrzeć do katalogu .nuxt. Znajdziesz tam wszystkie finalne pliki swojej aplikacji. Generowałem tam plik .nuxt/router.js, czyli w praktyce wygenerowany plik Vue Router.

Czyli tak: katalog pages, bez tras dynamicznych, index.vue, about.vue, renderowanie po stronie serwera, bez konfiguracji Webpacka, samo CLI. To był pierwszy prototyp, który uznałem za na tyle dopracowany, żeby pokazać go publicznie.

Jak społeczność Vue zareagowała na Nuxt i dlaczego nuxt generate pojawiło się tak wcześnie?

Pamiętasz pierwsze reakcje społeczności? Były pozytywne czy raczej ludzie czuli, że projekt wymaga jeszcze dopracowania?

Sébastien: Reakcje były właściwie pozytywne, bo społeczność Vue jest naprawdę życzliwa. Bardzo ucieszyłem się z pierwszego zgłoszenia, bo to oznaczało, że ktoś rzeczywiście to przetestował. Myślę, że to była jakaś sugestia, ale nie pamiętam, musiałbym to sprawdzić. Ogólnie odbiór był bardzo dobry i to właśnie motywowało nas do dalszej pracy nad tym projektem.

Pamiętam, że mój brat Alexandre Chopin pracował nad generatorem statycznych stron. Korzystał z Hexo i interesował się statycznymi witrynami, analizowaniem stron internetowych, i powiedział coś w stylu: „A dałoby się zrobić też to?”. A ja na to: „Tak, myślę, że to będzie bardzo proste. Mamy renderowanie po stronie serwera, więc potrzebujemy po prostu kroku, w którym uruchamiamy serwer, wywołujemy stronę, pobieramy HTML i zapisujemy go jako stronę HTML”.

I tak, chyba tydzień później, narodziło się nuxt generate. Pamiętam, że byliśmy na meetupie Vue.js Paris, to był chyba koniec 2016 roku. Evan You był tam, bo miał prezentację, i siedział w pierwszym rzędzie. Pokazaliśmy Nuxt, a potem polecenie nuxt generate, a on powiedział: „Interesujące”. I wydaje mi się, że kilka miesięcy później pojawił się VuePress, generator dokumentacji Vue do statycznych stron.

Myślę więc, że zdecydowanie byliśmy pierwsi, jeśli chodzi o generator statycznych stron oparty na plikach lub komponentach Vue. Bardzo się cieszę, że udało się dodać tę funkcję tak wcześnie.

Dlaczego Nuxt postawił na renderowanie hybrydowe zamiast wyłącznie statycznego generatora stron?

To ciekawe, że w pewnym momencie było dużo ruchu wokół generatorów statycznych stron, które robiły tylko to, jak Gatsby czy Gridsome w ekosystemie Vue. Dziś jednak zarówno Next.js, jak i Nuxt robią to za ciebie, bo wykorzystują renderowanie po stronie serwera. W pewnym sensie od początku przewidziałeś, jaki kierunek stanie się popularny.

Sébastien: Tak, Gridsome. Całkiem go lubiłem, ale dla mnie możliwość uruchomienia serwera zawsze miała większą moc, przy jednoczesnym zachowaniu opcji serwowania statycznych plików. Dlatego bardzo cieszy mnie to renderowanie hybrydowe, możliwość serwowania wersji statycznej tam, gdzie to potrzebne, ale też świadomość, że możesz chcieć zregenerować stronę i nadal serwować statyczne pliki. Ale tak, były też świetne frameworki i wzajemnie się inspirowaliśmy.

Co po Nuxt 4 i czego programiści powinni oczekiwać po Nuxt 5?

Przejdźmy do teraźniejszości i weźmy pod uwagę niedawne wydanie Nuxt 4. Czego możemy się spodziewać po Nuxt 4 w kolejnych etapach? Nuxt 4 nie było wielkim przełomem z dnia na dzień, raczej stopniową zmianą. Czego możemy oczekiwać teraz po Nuxt 5 i przyszłości projektu?

Sébastien: To dobre pytanie i bardzo się cieszę, że Nuxt 4 nie było wielkim przełomem, bo przejście z Nuxt 2 do Nuxt 3 było bolesne. Chcemy, żeby nowa główna wersja była czymś, do czego chcesz się zaktualizować i po tej aktualizacji mieć dobre odczucia.

Mamy wiele pomysłów, a to, co najbardziej lubię w Nuxt, to możliwość pracy z pluginami, które nazywamy modułami, czyli z całym ekosystemem. Sposób, w jaki zdefiniowaliśmy rdzeń Nuxt 2, a potem Nuxt 3, sprawia, że moduł może zastąpić funkcje samego Nuxt. Dzięki modułom możemy więc przekształcać Nuxt w taki framework, jakiego potrzebujemy.

To zależy, bo jesteśmy zespołem odpowiedzialnym za rdzeń i każdy z nas ma własne projekty, a nawet ty, Jakub, masz swój moduł. Eksperymentujemy za pomocą modułów, a na podstawie ich popularności i sposobu użycia zastanawiamy się, czy uczynić z nich moduł rdzeniowy albo od razu domyślną część frameworka.

Z mojej strony pracuję nad full-stackową częścią Nuxt. Jak już mówiłem, dużo pracowałem z Node.js, MongoDB i bazami danych. Chcę mocno rozwinąć ten obszar. Nie chcę, żeby wyglądało to jak Laravel, bo Laravel jest dla PHP. Bardzo podoba mi się ich podejście, ale przynajmniej po stronie Nuxt nie wydaje mi się ono aż tak naturalne.

Jak wygląda full-stack Nuxt z Nuxt DB, storage i modułami AI?

Sébastien: Ostatnio pracowałem nad NuxtHub, które pozwalało tworzyć full-stackowe aplikacje na Cloudflare. Po przejęciu przez Vercel moim celem jest uczynienie modułów Nuxt niezależnymi od platformy, tak żeby baza danych działała także poza Cloudflare, tak samo blob storage i inne elementy.

W ostatnich tygodniach pracowałem nad wydzieleniem części bazodanowej, która stanie się Nuxt DB. Tak samo będzie to moduł, z którego da się korzystać przy niemal zerowej konfiguracji. Wybierasz tylko dialekt. Integrujemy migracje przez Drizzle Kit, ale masz też CLI: nuxt db migrate, nuxt db generate, a migracje uruchamiamy przed wdrożeniem na produkcję, tak samo w środowisku developerskim. To bardzo ekscytujące, nie mogę się doczekać, aż skończę dokumentację i to ogłoszę.

Tak samo będzie z częścią blob, prawdopodobnie pod nazwą Nuxt Drive. Nadal zastanawiamy się nad nazwą. Chcemy więc udostępniać tę full-stackową część jako pluginy i zobaczyć, jak ludzie będą z nich korzystać.

Równolegle mamy Nuxt Hints, które, jeśli się nie mylę, zostało wydane dziś albo wczoraj. Wczoraj miałem wolne, bo we Francji było święto. To pomaga uzyskać lepszą wydajność. Testujemy więc różne rozwiązania i sprawdzamy, co działa najlepiej, utrzymując lekki rdzeń Nuxt i dając ci te rozszerzenia do wypróbowania.

No i oczywiście AI, muszę teraz często używać tego słowa, bo jesteśmy w fazie AI. Mamy moduły LLM, które pozwalają, jeśli masz dokumentację albo stronę internetową, tworzyć pliki llms.txt. Pracujemy też nad modułem Nuxt MCP. Myślimy o systemie agentów, ale idziemy krok po kroku: testujemy to wewnętrznie w aplikacjach i próbujemy wyznaczyć w strukturze katalogów Nuxt właściwy sposób budowania full-stackowych aplikacji i aplikacji AI. To zdecydowanie obszar, nad którym pracujemy, ale społeczność też tworzy własne rzeczy, więc nie da się tego w pełni przewidzieć. Projekt pozostanie jednak istotny dla większości programistów, bo rozwijamy go razem.

Czym jest Nitro i jak zmienia full-stack development?

Całkowicie się zgadzam. Cieszę się, że wspomniałeś o Nuxt Hints, bo też brałem udział w części prac nad tym narzędziem. Powstaje ono ze społecznością, nie tylko z zespołem core, nie tylko z NuxtLabs, ale z udziałem nas wszystkich, którzy dokładamy coś od siebie. Wspomniałeś o full-stack development, a to prawdopodobnie nie byłoby możliwe bez Nitro, o którym nie zawsze się mówi, choć Nuxt korzysta z niego pod maską. Nitro pojawiło się wraz z Nuxt 3. Jak twoim zdaniem Nitro zmienia full-stack development nie tylko w Nuxt, ale też w innych frameworkach?

Sébastien: Tak. Zaczęliśmy pracę nad Nitro dawno temu. Nitro miało wiele nazw. W pewnym momencie nazywało się Sigma Workstation. Zaczęło się od konkretnego problemu, zresztą zawsze zaczyna się od problemu.

Tym problemem było to, że jeśli miałeś aplikację w Nuxt 2 i chciałeś utworzyć trasy API, musiałeś restartować cały serwer Nuxt. Sam serwer działał dobrze, ale przebudowa Webpacka dla klienta i serwerowej części aplikacji, no cóż, nie chciałbyś tworzyć tras API w Nuxt 2.

Zaczęliśmy więc z Pooją Parsą pracę nad czymś, co nazywało się Workstation. Udało nam się mieć osobny worker tylko dla kodu serwerowego, dla twoich tras API. To bywa mylące, gdy mówisz o Nuxt, bo masz aplikację, aplikację Vue, która działa także po stronie serwera. Jest więc serwerowa część aplikacji, ale jest też cały serwer, który obsługuje twoje trasy API i jednocześnie serwuje aplikację Vue.

Chcieliśmy więc wprowadzić taki podział, żeby twoje trasy API mogły korzystać z hot module reload bez restartowania całego systemu Webpacka. Pracowaliśmy nad projektem Workstation w Nuxt 2. Byliśmy już bardzo blisko działającego rozwiązania, ale wtedy zaczęliśmy prace nad Nuxt 3.

Postawiłem też przed Pooją wyzwanie: „Dobrze, chcę, żeby Nuxt działał w Cloudflare Workers”. To było duże wyzwanie, bo całość musiała się zmieścić, jeśli dobrze pamiętam, niemal w jednym megabajcie, taki był rozmiar aplikacji. To oznaczało, że oprócz serwera z hot module reload po stronie serwera musimy jeszcze bundlować aplikację razem z twoim serwerem, czyli całe śledzenie modułów Node. Końcowy wynik jest więc czymś w rodzaju binarki. To minimalny katalog wyjściowy, który można wdrożyć na różnych platformach.

Nuxt 2 nie wspierał zbyt dobrze platform serverless, bo za każdym razem przy uruchomieniu serwera ładowaliśmy bundle twojej aplikacji. A czasem, jeśli chcesz tylko wywołać trasę API, nie chcesz ładować bundle'a aplikacji tylko po to, by obsłużyć tę trasę, zwłaszcza w serverless, gdzie wszystko startuje od nowa za każdym razem. Nitro wprowadziło więc także code splitting po stronie serwera. Każda trasa API jest dzielona na osobne części kodu, więc ładowany jest tylko JavaScript potrzebny do obsługi danej trasy. A gdy serwowana jest aplikacja, ona również korzysta z code splittingu. To coś w rodzaju optymalizacji bundlowania pod serverless i edge oraz hot module reload po stronie serwera.

To więc duży projekt. Początkowo był częścią Nuxt, a ponieważ nasz zespół lubi oddawać rzeczy społeczności i innym frameworkom, myślę, że zaczynamy być już z tego znani dzięki różnym projektom. UnJS to też świetny przykład: zebraliśmy wszystkie małe narzędzia, których używaliśmy w Nuxt, wydzieliliśmy je i zamieniliśmy w biblioteki, z których można korzystać gdzie indziej.

Później mamy Nitro, które również postanowiliśmy rozwijać jako samodzielny projekt, choć początkowo obsługiwało Nuxt, bo właśnie tam powstało. Dziś to świetny projekt wykorzystywany także przez inne frameworki webowe. Współpracujemy więc nad nim wspólnie.

Od Nitro v3 można go też używać jako pluginu do Vite. Jeśli więc masz aplikację Vite i chcesz dodać SSR albo trasy API, wystarczy dodać plugin Nitro do Vite i wszystko jest gotowe. To więc kolejny nowy framework, który mamy, i który służy różnym celom. To bardzo ekscytujące, a Nuxt również na tym korzysta.

Projekt prowadził Pooya, który na tamtym etapie był twórcą Nuxt 3. Bardzo intensywnie nad tym pracowaliśmy, a teraz prowadzi go Daniel Roe, który wykonuje świetną robotę. Mam więc szczęście, że spotkałem tak wspaniałych ludzi i tak świetną społeczność jak wy. Mam nadzieję, że dobrze wyjaśniłem, czym jest Nitro.

Dlaczego zespół Nuxt udostępnia swoje narzędzia jako open source także innym frameworkom?

To także świetne, że kiedy tworzyliście coś rozwiązującego konkretny problem, nie powiedzieliście po prostu: „Rozwiązaliśmy ten problem. To nasz produkt. Jest objęty naszą licencją i jeśli chcesz mieć coś podobnego, musisz to skopiować i zbudować samodzielnie”. Zdecydowaliście się wydzielić te mniejsze, a czasem większe części, jak Nitro, ale też znacznie mniejsze paczki do konfiguracji, łączenia obiektów, hooków czy innych rzeczy, których można użyć właściwie w dowolnym frameworku. UnJS jest tu dobrym przykładem.

Sébastien: Dokładnie. Ponieważ pracowaliśmy nad Nuxt 3, musieliśmy wspierać Vite i Webpack. Musieliśmy więc stworzyć ogólny sposób budowania pluginów do Vite i Webpacka. Mała uwaga: czasem to było świetne. Daliśmy społeczności bardzo dużo i każdy mógł korzystać z tych bibliotek. Czasem bywało to też dla nas trudne, bo ktoś wpadał na świetny pomysł dotyczący biblioteki, której używaliśmy, a my nie zauważaliśmy, że w ten sposób wprowadza błąd, bo nie używaliśmy jej w sposób, którego ta biblioteka się nie spodziewała. Niekiedy to nas spowalniało, ale myślę, że w długim terminie najlepiej było udostępnić wszystkie te narzędzia wszystkim.

Dlaczego NuxtLabs dołączyło do Vercel?

Przejdźmy do przejęcia przez Vercel, które kilka miesięcy temu było głośnym ogłoszeniem i bardzo gorącym tematem. Osoby spoza społeczności Vue i Nuxt często mówią: „Słyszałem, że Vercel kupił Nuxt. Co?”. Czy możesz to trochę wyjaśnić? Widzieliśmy zbyt wiele nieporozumień wokół tej sprawy. Co właściwie się wydarzyło? Co to oznacza dla frameworka? I co sprawiło, że uznałeś, że takie partnerstwo ma sens? Dlaczego to dobry kierunek dla firmy i dla Nuxt jako całości?

Sébastien: To dużo pytań, ale dobrych pytań, na które powinienem odpowiedzieć. Zaczęło się od pomysłu, żeby połączyć z nimi siły. Guillermo Rauch skontaktował się ze mną i zapytał: „Hej, czy byłbyś zainteresowany?”. Poświęciłem kilka tygodni na zastanowienie się nad tą możliwością, nad tym, co to będzie oznaczać dla społeczności, jakie będą moje warunki i warunki naszego zespołu w NuxtLabs, żeby mieć pewność, że nie chcemy wypaczyć Nuxt. Chcieliśmy znaleźć sposób, by uspokoić społeczność i samych siebie w kwestii tej wizji.

Widzieliśmy już różne rzeczy związane z Vercel i Next.js. Kiedy prowadziłem NuxtLabs, sytuacja była bardzo złożona, bo chcesz rozwijać open source i kochasz open source, to właśnie motywuje mnie każdego dnia, ale jednocześnie musisz płacić ludziom za pracę nad open source. Trzeba więc znaleźć równowagę.

Nie chcieliśmy nazywać firmy Nuxt. W pewnym momencie zmieniliśmy nazwę na NuxtLabs i próbowaliśmy tworzyć produkty, które nie są niezbędne do zbudowania świetnej strony, ale oszczędzają czas. Trudno zbudować trwały model działania, kiedy trzeba płacić programistom, bo programiści są dość drodzy, a świetni programiści są bardzo drodzy. Jednocześnie to nie programiści najchętniej płacą za produkty. Jak więc to zrobić, kiedy tworzysz narzędzia dla programistów? Musisz płacić drogim specjalistom, ale oni sami nie chcą płacić. Programiści nie chcą płacić za open source. Musimy więc znaleźć tu właściwą równowagę.

Byłem całkiem zadowolony z produktów, które mieliśmy w NuxtLabs. Mieliśmy przychody, byliśmy blisko rentowności, ale w pewnym momencie trudno było skupić się na jednej rzeczy, czyli ostatecznie na frameworku. Nie chcę rozdrabniać się na zbyt wiele projektów.

Rozmawialiśmy z Guillermo. Widziałem wtedy, jak rozwijał się SvelteKit i jak zachował niezależność od platformy. A do tego, szczerze mówiąc, podziwiam wizję technologiczną Vercel. Jak mówiłem, śledziłem socket.io, Mongoose, ich podejście do developer experience, a także sam Next.js. Nie interesuje mnie ostatnia wersja Next.js, App Router, nie używam go, ale developer experience, marketing i design mają na najwyższym poziomie. Pomyślałem, że to może nam też pomóc stać się lepszymi w marketingu i dokumentacji, bo chodzi o to, żeby dobrze tłumaczyć swój projekt i dobrze go rozumieć.

Więc współpraca z tymi ludźmi mogłaby być naprawdę dobra. No i AI, o AI też muszę powiedzieć. v0 to świetny produkt i na pewnym poziomie chcieliśmy, a ja chciałem, wejść głębiej w obszar AI, czy to pod kątem generowania kodu, czy zrozumienia kodu, na przykład tego, by AI rozumiało Nuxt. Możliwość bycia blisko zespołów, które często pracują nad AI, zdecydowanie zwiększyłaby nasze możliwości w tym obszarze.

Zaczęliśmy więc rozmawiać i pomyślałem: dobrze, zobaczmy, jakie są korzyści i wady. Ostatecznie przekonała mnie, a także cały zespół, ich wizja otwartego webu, czyli to, że chcą pozycjonować Vercel jako platformę hostingową niezależną od konkretnego frameworka, a nie tylko platformę dla Next.js. To dobrze wpisuje się w tę wizję. Chcieliśmy zachować autonomię i możliwość realizowania własnej roadmapy jako framework rozwijany przez społeczność. Myślę, że SvelteKit jest tu świetnym przykładem. Miałem wcześniej okazję porozmawiać z Richem Harrisem i ostatecznie wszyscy uznaliśmy, że wchodzimy w tę przygodę. Vercel jest dobrze znane z projektów open source i jak dotąd bardzo się z tej decyzji cieszę.

Co przejęcie przez Vercel zmienia dla programistów Nuxt?

To ma sens. Większość programistów ma już dziś lepszy obraz tego, co się wydarzyło, a co się nie wydarzyło. Ale ludzie będą przyglądać się temu uważniej, próbować oceniać decyzje i lepiej je rozumieć. Może więc w kilku krótkich słowach: co powinno lub będzie się zmieniać dla programistów Nuxt, a co się nie zmieni?

Sébastien: Szczerze mówiąc, dla nich nic się nie zmieni. Myślę, że udowodniliśmy to w ostatnich trzech miesiącach. Vercel nie chce, żebyśmy cokolwiek zmieniali. Chce raczej korzystać z naszej wiedzy o developer experience i wykorzystywać ją także na swojej platformie.

Rozmawialiśmy z nimi o funkcji runtime cache i zastanawiali się, jakie podejście byłoby najlepsze dla twórców frameworków, którzy chcą z niej korzystać. Potem rozmawiamy z różnymi twórcami frameworków i mówimy: „To mi się podoba, tego nie lubię”, a oni wracają do pracy i pytają nas: „Co sądzicie o tym?”. Ta bliskość pomaga im budować jak najlepszą platformę. A potem to już twój wybór, czy uznasz ją za najlepszą, czy nie.

Możesz się natomiast spodziewać tego, że skoro z nimi współpracujemy i pomagamy im budować świetną platformę, a ja korzystałem z Vercel jeszcze zanim stworzyłem Nuxt, kiedy śledziłem Zeit, i naprawdę lubię tę platformę, to chcemy dopilnować, żeby Nuxt na Vercel było świetnym miejscem do hostowania aplikacji Nuxt. To prowadzi do usprawnień takich jak pakiet Workflow. Jeśli więc używasz Vercel, będziesz bardziej zadowolony, bo rzeczy, których wcześniej nie wspieraliśmy, już wspieramy albo zaczniemy wspierać bardzo szybko. Będziesz mógł z tego wygodnie korzystać.

Jeśli nie korzystasz z Vercel, nic się dla ciebie nie zmieni. Jeśli używasz Cloudflare, sytuacja wygląda tak samo. Pakiet nuxt-cloudflare nadal będzie działał, a ty nadal będziesz mieć możliwość wdrażania na różnych platformach. Pozostajemy niezależni od dostawcy, a jednocześnie uwzględnimy doświadczenie wdrożeniowe na Vercel.

Czy Nuxt i Next.js będą teraz współdzielić funkcje, skoro oba zespoły są w Vercel?

Jak dziś widzisz relację między Nuxt a Next.js? Czy to oznacza, że frameworki będą przejmować od siebie najlepsze praktyki? Czy wyobrażasz sobie na przykład, że Next.js zacznie korzystać z niektórych funkcji Nuxt?

Sébastien: Tak, rozważam dodanie App Router do Nuxt. Żartuję.

Nie wiem, czy tak będzie, ale nie, myślę, że i tak mamy pełne ręce pracy. To, o czym głównie rozmawiamy, dotyczy ich procesów, może najlepszych praktyk, tego, jak dokumentują swoją pracę, jakie mają procesy, może kwestii związanych z designem, jak zbierają feedback od firm klasy enterprise, czego na tym poziomie być może trochę nam brakowało.

Bo jeśli chodzi o same funkcje, od dawna mocno się wzajemnie inspirowaliśmy, ale teraz jesteśmy już na etapie, na którym po stronie full-stack to są różne kierunki. Planujemy mieć serwerowe funkcje RPC, ale możemy czytać dokumentację i samodzielnie wymyślać funkcje.

Więcej przestrzeni do współpracy może być przy Nitro, bo być może pewnego dnia Vercel i Next.js będą korzystać z Nitro, ale to jeszcze potrwa. Bardziej realna wydaje się współpraca przy pakietach niższego poziomu, na przykład przy tym, jak możemy współdzielić wspólne pakiety. Myślę, że na poziomie funkcji wszystko jest na razie mocno ukierunkowane na Vue i React.

Ale kto wie? Chciałbym, żeby Nuxt Content działało także w Next.js, podobnie jak Nuxt Studio czy Nuxt DB. Byłoby naprawdę świetnie móc zaimportować Nuxt DB do projektu Next.js. Ale to oczywiście nie jest dla mnie najwyższy priorytet. Użytkownicy Nuxt i użytkownicy Nitro już teraz mają świetne własne rozwiązania. Społeczność Vue jest jednak czymś, co od dawna mam szczególnie blisko serca.

Może jeszcze krótki komentarz, bo myślę, że to bardzo ważne, zwłaszcza dla osób sceptycznych albo zaniepokojonych tym przejęciem przez Vercel. To prawdopodobnie także największa szansa na bardziej bezpośrednią współpracę, wspólne planowanie, a być może nawet współkształtowanie tego, jak będziemy pracować z webem w przyszłości. Bo chociaż wszyscy to wiedzą i, jak sam powiedziałeś, Sébastien, frameworki od dawna się wzajemnie inspirowały, tak właśnie działa open source, to nie było bezpośredniej współpracy, nie w takim sensie, że zespoły siadają przy jednym stole i wspólnie podchodzą do nowej funkcji albo specyfikacji dla webu. Myślę więc, że to naprawdę duża szansa.

Sébastien: Zgadzam się. Jest tu miejsce na współpracę i to pozwoli nam zaoszczędzić mnóstwo czasu. To bywa frustrujące, bo myślisz: „Nie mam teraz na to czasu, mam tysiące zgłoszeń”. Ale jeśli poświęcisz jedno czy dwa spotkania, żeby usiąść razem, to w przyszłości oszczędzisz czas, bo będziecie współpracować nad jedną biblioteką, której da się użyć ponownie. Jesteśmy tam dopiero od trzech miesięcy, ale jestem przekonany, że w ciągu najbliższego roku zaczniemy tworzyć wspólne biblioteki.

Jakie miejsce zajmuje Nuxt w strategii Vercel związanej z AI cloud?

Na koniec jeszcze jedno pytanie z mojej strony dotyczące Vercel. Jak widzisz miejsce Nuxt w całej strategii Vercel? Bo Vercel to nie tylko Next.js, nie tylko hosting, ale też v0. Jak więc postrzegasz Nuxt w szerszej strategii Vercel?

Sébastien: Pracuję w zespole frameworków w Vercel, więc nie jestem bezpośrednio związany z produktami. Oczywiście jednak, ponieważ sam prowadziłem firmę, interesuje mnie ten temat. Podoba mi się też zwrot w stronę AI cloud, co oznacza, że chcą wspierać więcej frameworków backendowych, i widać to po ostatnich ogłoszeniach.

Cieszy mnie też wsparcie dla Workflow, bo to jeden z najbardziej uciążliwych obszarów, kiedy trzeba budować backend. Mieliśmy kiedyś produkt o nazwie Volta, w którym musieliśmy obsługiwać webhooki, webhooki GitHuba, a potem potrzebny jest system kolejek i, o Boże, trzeba jeszcze obsługiwać ponowienia. Oni znaleźli dobry sposób, żeby to uprościć, a jednocześnie zachować dużą niezawodność i możliwość self-hostingu, co też bardzo mi się podoba.

Dla mnie najważniejsze jest to, że oszczędza mi to czas, bo wyścig AI, budowanie aplikacji, które zaraz wyrzucasz i tworzysz kolejne, będzie coraz silniejszy. Podoba mi się więc sposób, w jaki oni to ujmują.

Skoro mówimy o AI cloud i większej liczbie frameworków backendowych, to ja chcę, żeby AI potrafiło dostarczać aplikacje Nuxt. Ale żeby to było możliwe, AI musi umieć dostarczać aplikacje full-stack i dawać taką możliwość przy tworzeniu full-stackowych aplikacji, które można wdrożyć na Vercel albo u innych dostawców. Dla mnie perspektywa wdrożenia jednym kliknięciem, które wspiera bazę danych, Workflow i AI gateway, jest bardzo ekscytująca. Muszę też powiedzieć, że AI gateway, które zbudowali, bardzo mnie cieszy, bo pozwala łatwo dodać AI do aplikacji.

Na razie nie mam jeszcze wielu pomysłów na aplikacje AI, które mógłbym zbudować, ale sama możliwość dania ludziom narzędzi do stworzenia kolejnego pomysłu na aplikację AI w Nuxt ekscytuje mnie najbardziej.

Czym jest „Nuxt Assistant” i czy AI będzie budować aplikacje Nuxt?

O przyszłości Nuxt rozmawialiśmy już trochę w kontekście Vercel, Nuxt 4 i Nitro. Ale gdybyś miał wskazać jedną rzecz, która najbardziej cię ekscytuje i która mogłaby pojawić się w Nuxt za, powiedzmy, dwa lub trzy lata, nie coś, nad czym pracujesz dziś i co wyjdzie jutro, ale coś długofalowego, na co my jako społeczność możemy czekać i czego możemy wypatrywać.

Sébastien: Chciałbym zobaczyć asystenta.

Czyli rozwiązanie, w którym można zacząć lokalnie, z lokalnymi modelami AI. Powinieneś móc wybrać model działający lokalnie albo w chmurze, na przykład przez AI gateway albo OpenRouter czy inne rozwiązania. A potem mieć coś podobnego do tego, co daje Cursor, tylko w formie asystenta pomagającego budować aplikację.

Chciałbym jednak, żeby od pierwszego dnia była tam swego rodzaju rozmowa, coś jak w naszej aplikacji powitalnej Nuxt. Masz prompt i możesz od razu zacząć z nim rozmawiać. Przesuwasz go w lewo albo w prawo jak w Nuxt Studio. To byłby komponent webowy, z którym możesz rozmawiać i przekształcać swoją aplikację. To stanie się możliwe, kiedy będziemy mieć full-stackowy framework z CMS-em, bazą danych, a wtedy on stworzy ci stronę. To coś w rodzaju wbudowanego v0 albo Cursor.

Nie wiem, czy to dobry, czy zły pomysł, ale „Nuxt Assistant” mógłby mówić ci: „Masz takie podpowiedzi”, a potem sugerować aktualizację jednym kliknięciem, jeśli sam jej nie wykona, oczywiście z poszanowaniem najlepszych praktyk. Dzięki temu moglibyśmy dbać o to, by strony były jak najlepsze i jak najbardziej wydajne.

Ale tak, nadal nie wiem jeszcze, jak dobrze trenować AI. Próbujemy RAG, ale pewne rzeczy już wiem. Pozostaję otwarty i obserwuję to wszystko, a kiedy w mojej głowie to się ułoży, może przyjdzie właściwy moment, żeby to zrobić. Ale tak, Nuxt Assistant. Tylko najpierw chcę, żeby kodowanie jeszcze sprawiało ci frajdę, zanim zniknie.

Właściwie planowałem zapytać cię więcej o AI i przyszłość Nuxt, ale wygląda na to, że nie bardzo muszę. Sam już mocno kierujesz to właśnie w tę stronę. A jeśli chodzi o sam pomysł Nuxt Assistant, już teraz wyobrażam sobie moduły, które mogłyby się do niego wystawiać. Dzięki temu wszystko działałoby razem płynnie i bezboleśnie, ale oczywiście ktoś najpierw musi to zbudować.

Sébastien: Tak, Atinux pracuje nad modułem MCP. Ja pracuję nad modułem DB, który można rozszerzać modułami. Możesz więc mieć moduł Nuxt CMS korzystający z Nuxt DB albo moduł Nuxt Auth, który używa Nuxt DB do tworzenia swoich tabel w bazie danych. Możesz też mieć moduł Nuxt MCP, który tworzy narzędzia do komunikacji z warstwą uwierzytelniania. Możesz wylistować użytkowników, a potem po prostu masz ten interfejs.

Mamy Nuxt UI, czego w praktyce nie ma żaden inny framework frontendowy, tę bibliotekę UI. Dodajemy też więcej narzędzi AI. Powstaje także edytor. Tak, idziemy w tym kierunku.

Kiedy tworzyłem sklepy internetowe jako SPA w Node.js, bardzo to lubiłem. Kto wie, może za trzy lata powiemy: „Tak, jasne, przecież nad tym pracowałeś. To od początku było tworzone z myślą o tej wizji”. Ja jednak jeszcze tej wizji nie znam, ale pewnie za kilka lat wszystko nabierze sensu.

Tak, za kilka lat będzie to wyglądało jak bardzo szczegółowy, zaplanowany plan działania.

Sébastien: To był mój wielki plan. Tak, wszystko było zaplanowane.

Ale ostatecznie to feedback społeczności daje ci pomysł. Łączy się to z twoją osobistą historią. Powstaje nowy pomysł. Zbudujemy go razem.

Jakie przesłanie Sébastien Chopin ma dla społeczności Vue i Nuxt?

Czy jest coś, czym chciałbyś podzielić się ze społecznością Vue i Nuxt, zanim zakończymy rozmowę?

Sébastien: Dziękuję. Dziękuję za wasz czas, całą energię i za to, że jesteście z nami od początku, od kilku lat albo może dopiero od kilku tygodni. Działajcie dalej, korzystajcie dalej, dawajcie nam feedback. Budujcie dalej.

To bardzo wiele dla mnie znaczy, że te projekty istnieją i że mają tak dużą społeczność. Naprawdę uważam, że Vue już wkrótce zyska większy rozgłos. Ale może to będzie już inna wiadomość, którą podzielę się później.

Gdzie można śledzić Sébastiena Chopina w sieci?

Gdzie słuchacze mogą cię znaleźć, jeśli będą chcieli? Na X? Na Discordzie, LinkedInie czy może jeszcze gdzieś indziej?

Sébastien: Mogą mnie znaleźć na X, Bluesky, YouTube, choć nie publikuję tam zbyt wielu filmów, na Discordzie, i wszędzie występuję jako @atinux. Mam też atinux.com, gdzie są wszystkie linki. Na atinux.com jest też mój adres e-mail, ale śmiało napiszcie do mnie na X, myślę, że mam otwarte wiadomości prywatne, więc chętnie pogadam.

Co przyszłość Nuxt oznacza dla zespołów tworzących w Vue?

Dla zespołów budujących w Vue przyszłość Nuxt wygląda stabilniej, niż mogły sugerować nagłówki o przejęciu. Framework pozostaje otwarty, działa niezależnie od miejsca hostingu i przejmuje coraz więcej pracy backendowej, którą w innym przypadku trzeba byłoby zbudować i utrzymywać samodzielnie. Jeśli to ty odpowiadasz za stos technologiczny produktu, właśnie te elementy tej rozmowy warto zapamiętać.

Pytanie o Vercel zwykle pojawia się jako pierwsze i nie bez powodu: framework powiązany z jednym hostingiem to ryzyko biznesowe. Odpowiedź Chopina jest taka, że dla programistów, którzy nie korzystają z Vercel, nic się nie zmienia, a samo ogłoszenie Vercel zawiera zobowiązanie, że Nuxt i Nitro pozostaną na licencji MIT, z publiczną roadmapą i otwartym modelem zarządzania. Na podstawie tej rozmowy tak wygląda to w zależności od tego, gdzie hostujesz:

Nitro już dziś pozwala aplikacji Nuxt udostępniać trasy API i kod serwerowy z podziałem kodu na poziomie poszczególnych tras, co dobrze sprawdza się w hostingu serverless i edge. Moduły opisane przez Chopina, czyli Nuxt DB, moduł do przechowywania blobów oraz moduły MCP i LLM, wprowadzają bazy danych, przechowywanie plików i interfejsy AI do tego samego projektu i w ramach tych samych konwencji. Dla zespołu produktowego mniej osobnych usług oznacza mniej punktów integracji do utrzymania i jeden zestaw wzorców w całej bazie kodu.

Po kosztownym przejściu z Nuxt 2 na Nuxt 3 Chopin chce, by kolejne główne wersje były aktualizacjami, na które zespoły czekają z chęcią, dlatego Nuxt 4 celowo rozwijano ewolucyjnie. Dzięki temu łatwiej planować utrzymanie w długim okresie.

Od czasu tej rozmowy, która odbyła się około trzech miesięcy po przejęciu w lipcu 2025 roku, część z tych planów poszła już naprzód. Funkcje baz danych, blobów i magazynu KV w NuxtHub działają teraz u wielu dostawców chmurowych, w tym na Vercel i Netlify, a Nitro v3 weszło do publicznej bety w marcu 2026 roku jako fundament Nuxt 5.

Jeśli rozważasz Nuxt w nowym produkcie albo planujesz aktualizację istniejącego, nasz zespół tworzący oprogramowanie w Vue.js i Nuxt chętnie to z tobą omówi. Stoimy za raportami State of Vue.js i od lat pomagamy firmom budować oraz skalować produkty z użyciem Vue. Powiedz nam, co tworzysz.