/
Published on 28.10.2024
TLDR: Next.js 15 wprowadza wsparcie dla React 19, stabilny Turbopack Dev oraz przełomowe zmiany w semantyce cachowania i asynchronicznych API.
Next.js 15 to jedno z najbardziej znaczących wydań frameworka, które przynosi fundamentalne zmiany w architekturze i wydajności. Najważniejszą nowością jest wsparcie dla React 19, który nadal znajduje się w fazie Release Candidate, ale Next.js już teraz oferuje eksperymentalne wsparcie dla React Compiler w wersji beta. To pokazuje, jak blisko współpracują zespoły - Vercel zatrudnia znaczną część zespołu React.
Stabilizacja Turbopack Dev to przełomowy moment dla wydajności developmentu. Nowy bundler pokazuje imponujące wyniki - dla dużych aplikacji jak vercel.com osiąga do 76% szybszy start lokalnego serwera, do 96% szybsze odświeżanie kodu i do 45% szybszą kompilację początkowych tras. To nie są marginalne usprawnienia, ale rzeczywiste zmiany w codziennej pracy programistów.
Semantyka cachowania przeszła rewolucję - GET Route Handlers i Client Router Cache nie są już domyślnie cachowane. To odpowiedź na frustracje deweloperów, którzy często walczyli z nieprzewidywalnym zachowaniem cache'u. Asynchroniczne Request APIs to kolejny krok w kierunku uproszczonego modelu renderowania, gdzie serwer może przygotowywać treści przed nadejściem żądania.
Nowe CLI @next/codemod automatyzuje migracje między wersjami, co jest krytyczne dla ekosystemu, który rozwija się tak szybko. To narzędzie może być różnicą między płynną migracją a tygodniami refaktoringu dla większych zespołów.
Link: Next.js 15
TLDR: Turbopack Dev osiąga status stabilny po latach rozwoju, oferując drastyczne usprawnienia wydajności dla dużych projektów Next.js.
Historia Turbopack to fascynująca opowieść o tym, jak ograniczenia istniejących narzędzi mogą zmusić do rewolucyjnych decyzji. Webpack, który przez 8 lat był fundamentem Next.js, po prostu nie nadążał za potrzebami nowoczesnych aplikacji. Zespół Vercel próbował go optymalizować, ale w pewnym momencie zwrot z inwestycji przestał być zadowalający.
Wymagania dla nowego bundlera były ambitne: minimalne breaking changes, wsparcie dla App Router i Pages Router, szybsze kompilacje dla projektów każdej wielkości, buildy deweloperskie zbliżone do produkcyjnych. Istniejące rozwiązania miały kompromisy niekompatybilne z wizją Next.js, więc zespół zdecydował się na budowę od zera.
Wyniki są imponujące, szczególnie dla dużych aplikacji. Vercel.com, jako duża aplikacja Next.js, pokazuje 76% szybszy start serwera, 96% szybsze odświeżanie kodu i 45% szybszą kompilację tras. To nie są teoretyczne benchmarki, ale realne metryki z produkcyjnej aplikacji.
Interesujące jest podejście do dogfooding - Vercel używa Turbopack w swoich własnych aplikacjach, co daje im natychmiastową informację zwrotną o problemach wydajnościowych. To strategia, którą więcej firm technologicznych powinno adoptować.
Dla architektów i zespołów oznacza to możliwość pracy z większymi bazami kodu bez degradacji developer experience. Szybsze feedback loops przekładają się bezpośrednio na produktywność i jakość kodu.
Link: Turbopack Dev is Now Stable
TLDR: Microsoft zmniejszył rozmiar swojego JavaScript monorepo z 178GB do kilku GB, identyfikując i eliminując główne źródła bloat'u w Git.
Ta historia z Microsoft to mistrzowski kurs optymalizacji Git dla dużych organizacji. Repozytorium 1JS przekroczyło 1000 aktywnych użytkowników miesięcznie, 2500 pakietów i 20 milionów linii kodu - to skala, z którą większość firm nigdy nie będzie musiała się zmierzyć, ale lekcje są uniwersalne.
Pierwszy problem to tysiące plików w jednym folderze - Beachball change files tworzyły ogromne tree objects przy każdym dodaniu nowego pliku. To klasyczny przykład tego, jak pozornie niewinne decyzje architektoniczne mogą mieć dramatyczne konsekwencje na skalę. Rozwiązanie było dwuetapowe: zmiana w samym Beachball żeby grupować zmiany oraz pipeline automatycznie czyszczący folder.
Drugi problem okazał się bardziej podstępny - CHANGELOG.md i CHANGELOG.json rosły bez kontroli, a Git musiał przechowywać każdą wersję tych plików. W monorepo z setkami pakietów, gdzie każdy release generuje zmiany w changelog'ach, to szybko staje się problemem. Git nie jest zoptymalizowany pod kątem plików, które rosną liniowo - każda zmiana tworzy nowy blob.
Rozwiązanie wymagało git filter-branch do przepisania historii, co jest operacją wysokiego ryzyka w aktywnym repozytorium. Ale efekt - redukcja z 178GB do kilku GB - pokazuje, że czasami drastyczne środki są uzasadnione.
Dla zespołów oznacza to konieczność świadomego projektowania struktury repozytorium i monitorowania jego wzrostu. Narzędzia jak git-sizer powinny być częścią regularnych audytów.
Link: How we shrunk our Javascript monorepo git size by 94%
TLDR: Svelte wprowadza zunifikowane CLI łączące create-svelte i svelte-add, oferujące łatwą konfigurację Tailwind, auth, baz danych i innych dodatków.
Nowe Svelte CLI to eleganckie rozwiązanie problemu fragmentacji narzędzi. Wcześniej deweloperzy musieli pamiętać o svelte-check, npx svelte-migrate i innych osobnych narzędziach. Teraz wszystko jest pod jednym dachem - sv.
Proces tworzenia projektu stał się znacznie bardziej intuicyjny. Zamiast ośmiu kroków konfiguracji Tailwind z dokumentacji, teraz wystarczy zaznaczyć opcję podczas inicjalizacji projektu. To może wydawać się drobnym usprawnieniem, ale dla nowych użytkowników Svelte to różnica między godzinami konfiguracji a natychmiastowym rozpoczęciem pracy.
Integracja z community-led svelte-add pokazuje dojrzałość ekosystemu Svelte. Zamiast konkurować z społecznościowymi rozwiązaniami, zespół Svelte przejął najlepsze narzędzia i uczynił je oficjalnymi. Manuel (manuel3108) i Adrian (CokaKoala) zostali maintainerami Svelte - to świetny przykład tego, jak open source może ewoluować.
Planowane wsparcie dla community add-ons to strategiczny ruch. Zamiast centralizować wszystko, Svelte tworzy platformę, na której społeczność może budować. To podejście, które React mógłby zaadoptować - zamiast pozostawiać create-react-app w limbo.
Dla zespołów oznacza to szybsze onboarding nowych projektów i mniej decyzji o tooling'u na początku. Standaryzacja konfiguracji może też ułatwić przechodzenie między projektami.
Link: Introducing the new Svelte CLI
TLDR: Nowoczesny CSS pozwala tworzyć komponenty, które automatycznie dostosowują swój layout w zależności od ilości i typu zawartości bez JavaScript.
Ten artykuł pokazuje, jak daleko zaszedł CSS w kierunku prawdziwie deklaratywnego stylingowania. Quantity queries Heydona Pickeringa z 2015 roku to genialna technika, ale dopiero CSS :has() czyni ją naprawdę praktyczną dla systemów designu.
Problem jest realny - komponent Simple List musi radzić sobie z różnymi scenariuszami: krótki tytuł z jedną odznaką wygląda świetnie, ale długi tytuł z wieloma odznakami tworzy wizualny chaos. Tradycyjnie wymagałoby to JavaScript do liczenia elementów i conditionally applying styles.
Rozwiązanie CSS jest eleganckie: quantity queries wykrywają liczbę odznak, a :has() pozwala na dostosowanie layoutu rodzica. .simple-list-item:has(.simple-list-item-badge:last-child:nth-child(-n + 3)) to może wyglądać skomplikowanie, ale robi dokładnie to, czego potrzebujemy - wykrywa czy są 3 lub mniej odznak i dostosowuje grid layout.
Kluczowa obserwacja to fault tolerance CSS vs JavaScript. Jeśli CSS nie zadziała, zawartość pozostanie czytelna. Jeśli JavaScript nie zadziała, cały komponent może się zepsuć. To argument za przenoszeniem logiki wizualnej do CSS tam, gdzie to możliwe.
Dla systemów designu oznacza to możliwość tworzenia bardziej inteligentnych komponentów bez dodawania złożoności JavaScript. Komponenty mogą być self-aware i adaptive, co redukuje potrzebę micromanagement ze strony deweloperów używających systemu.
Link: Making content-aware components using CSS :has(), grid, and quantity queries
TLDR: PostHog wyjaśnia dlaczego mobile session replay zajęło im 4 lata - brak standardów jak rrweb, problemy z wydajnością i złożoność prywatności na urządzeniach mobilnych.
Historia mobile replay w PostHog to fascynujący wgląd w to, dlaczego niektóre problemy techniczne są trudniejsze niż wyglądają. Web session replay w dużej mierze opiera się na rrweb - open source'owej bibliotece, która standaryzuje nagrywanie i odtwarzanie. Dla mobile takiej biblioteki po prostu nie ma.
Problem platform jest realny - zamiast jednego JavaScript SDK, potrzebujesz osobnych implementacji dla iOS, Android, React Native, Flutter. Każda platforma ma swoje quirks - Jetpack Compose vs tradycyjny Android, SwiftUI vs UIKit. To nie jest kwestia portowania kodu, ale przepisywania logiki dla każdej platformy.
Wydajność to kolejny level złożoności. Telefony są słabsze od desktopów, a użytkownicy są mniej tolerancyjni na degradację performance'u. Nagrywanie ekranu na starszym telefonie może uczynić aplikację praktycznie nieużywalną. Deweloperzy muszą wspierać szeroki zakres urządzeń, więc każda degradacja user experience jest nie do przyjęcia.
Prywatność bez DOM to prawdziwy nightmare. Web ma standaryzowane elementy jak <input type="password"> i hierarchiczną strukturę DOM. Mobile nie ma żadnych z tych standardów. Accessibility identifiers są niekonsekwentnie implementowane. Identyfikacja sensitive information wymaga heurystyk zamiast jasnych reguł.
PostHog w końcu dostarczył bety dla wszystkich głównych platform, ale historia pokazuje dlaczego mobile development jest inherentnie trudniejszy od web development. Dla zespołów oznacza to konieczność budżetowania więcej czasu i zasobów na mobile features.
Link: How we built mobile replay (and why it took so long) - PostHog
Disclaimer: This article was generated using newsletter-ai powered by claude-sonnet-4-20250514 LLM. While we strive for accuracy, please verify critical information independently.