Cześć, w dniu dzisiejszym zaskakująco duży upgrade do Safari (naprawdę robi wrażenie!), ciąg dalszy prac nad nową architekturą React Native oraz odpowiedź na pytanie – czym do diaska jest Solid.js?
Cześć wszystkim! Tomek jest na urlopie w związku z czym dzisiejsza edycja jest pisana przeze mnie.
1. Olbrzymia aktualizacja dla WebKit w Safari 15.4
Wczoraj pojawiła się nowa wersja systemów operacyjnych od Apple i przynoszą one zaskakująco dużo ciekawego jak na tego typu wydanie pośrednie (w końcu pojawiło się choćby długo wyczekiwane Universal Control). Z punktu widzenia programistów frontendu chyba najciekawszą, a również najbardziej zaskakującym dodatkiem do nowego wydania jest szereg nowości, jakie pojawiły się w Safari. Przeglądarka wydaje się próbować pozbyć swojej opinii nowego Internet Explorera – i ja wiem, że Tomek studził entuzjazm, ale ja w dalszym ciągu 🔥 się perspektywą sensownego wsparcia dla notyfikacji, nawet jeśli przed nami jeszcze daleka droga.
No dobra, ale co też Safari w wydaniu 15.4 przynosi? Tak jak już wspomniałem, zmian jest naprawdę wiele, dlatego pozwolę sobie przejść wyłącznie przez te z mojej perspektywy najistotniejsze – pełną listę znajdziecie pod tym linkiem.
To, co przyciąga od razu uwagę (nie tylko ze względu nabycie na górze Release Notes), to informacja o natywnym wsparciu dla Lazy Loadingu. W innych przeglądarkach (czytaj… w Firefoxie oraz forkach Chromium) funkcjonalność jest już dostępna od kilku lat, teraz zaś będzie można jej używać bez dodatkowych polyfilli.
Masę zmian doczekało się też wsparcie funkcjonalności CSS. Atrybut :has, Cascade Layers (świeżynka, która dopiero co pojawiła się w konkurencji, więc jak na Safari mówimy tutaj o wręcz błyskawicznym wdrożeniu), czy też palet kolorów poprzez font-palette (tych nie ma chyba jeszcze nigdzie… caniuse.com nie pokazuje mi ich w ogóle, a chromestatus.com informuje o tym, że wdrożone zostaną dopiero w wydaniu 101 przeglądarki). Ilość zmian dla CSS naprawdę robi wrażenie.
Jednak to, co chyba najciekawsze to nowe API przeglądarki. Web Locks API i BroadcastChannel to funkcjonalności, które w znacznym stopniu umożliwiają pracę jednej aplikacji w wielu oknach i tabach poprzez zapewnienie kontroli nad współbieżnością, co daje twórcom aplikacji masę nowych, potężnych możliwości (czasem można by się zastanowić, czy aż nie za potężnych – deadlock między oknami przeglądarki brzmi jak ciut niepokojąca perspektywa). Usprawnieniom uległo również wsparcie standardów Internacjonalizacji, Web Extensions, WebRTC, czy Web App Manifest. Wisienką na torcie jest zaś operacje findLastIndex() i findLast() dodane do JavaScripta.
Zmian w całości jest masa, to o czym wspomniałem to wierzchołek góry lodowej, więc jeszcze raz zachęcam do sprawdzenia oryginalnego linku. A tak na zakończenie – nie wydaje Wam się dość zabawne, że WebKit i Safari są numerowane zgodnie z systemami mobilnymi (iOS, iPadOS 15.4), a nie desktopowym (MacOS 12.3)?
Zainstaluj teraz i czytaj tylko dobre teksty!
2. Prace nad nową architekturą React Native mają się ku końcowi
Dzieje się w świecie React Native. Dopiero co informowaliśmy o znacznych usprawnieniach w wersji Windowsowej, początkiem tygodnia opublikowane został update na temat wydania jego nowej architektury używającej Fabrica (sposobu renderowania przy użyciu nowego Concurrency API Reacta) i TurboModules (nowego standardu wywoływania kodu natywnego w ramach konkretnych platform). Pracę są już wyraźnie na dość zaawansowanym poziomie, ponieważ większość zapowiedzi nie dotyczy prac inżynierskich per se, a raczej kierunki, w którym twórcy będą pracować ze społecznością. Dlatego też większość zapowiedzi dotyczy takich rzeczy jak min. powstania nowej grupy roboczej, przewodnika do migracji czy zapowiedzi pracy z twórcami bibliotek. Jest to bardzo dobry znak – widać, że prace mają się powoli ku końcowi. Powoli stabilizuje się także Hermes, stworzony na potrzeby projektu, specjalnie dokrojony silnik JavaScript. Twórcy zarzekają się, że całość jest na tyle stabilna, że wraz z nową architekturą Hermes stanie się rozwiązaniem domyślnym.
A jak jak już jesteśmy przy temacie uniwersalnych frameworków, to pozwolę sobie dorzucić jeszcze jeden artykuł. Otóż początkiem tygodnia trafiło do sieci bardzo ciekawe porównanie o znamiennej nazwie: Flutter is better than React Native… in all the ways that don’t matter. Jest to mocno kompleksowe porównanie tych dwóch rozwiązań. Ogólnie konkluzja jest taka, że o ile Flutter jest rozwiązaniem bardziej kompleksowym i po prostu obiektywnie lepszym, to jednak fakt, że React i JavaScript są technologiami znanymi i kochanymi – choć zaraz będę się rozpisywał o chwilowo jeszcze bardziej ukochanym Solid.js – sprawia, że bardzo ciężko w większości przypadków jest umotywować użycie rozwiązania od Google.
Ostateczną decyzję, na ile ten argument jest do Was przemawiający, zostawiam Wam, ale przed ferowaniem wyroków polecam zapoznać się z publikacją, bo jest bardzo przekrojowa i po prostu dobrze napisana.
Zainstaluj teraz i czytaj tylko dobre teksty!
3. Na czym polega fenomen Solid.js?
Jak regularnie byśmy (wraz ze sporą częścią społeczności) nie obalali mitu o tym, że każdego dnia pojawia się nowy framework JS, tak jest on wiecznie żywy i wraca jak bumerang w branżowych rozmowach, zwłaszcza z przedstawicielami społeczności innych języków. Jak każda (miejska) legenda, posiada on jednak ziarnko prawdy, bo to właśnie w świecie Frontendu najłatwiej chyba obserwuje się hurraoptymizm w stosunku do nowo powstałych rozwiązań.
Niby z taką brodą, ale zawsze śmieszne 😄
Od pewnego czasu to Solid.js wydaje się być “new darling” frontendowego światka, a informacje o nim przeciekły również do mojej backendowej jaskini, dlatego stwierdziłem, że się tematem trochę zainteresuje – dopytywałem nawet delikatnie regularnie piszącego te przeglądy Tomka w ramach nigdy nie wypuszczonym odcinku drugiego sezonu naszego podcastu (tak, przymierzamy się, ale trochę sytuacja na świecie nam opóźnia całe przedwsięwzięcie). Dlatego też przygotowując dzisiejszą edycję, nie mogłem sobie odpuścić przyglądnięcia się tematowi. Wydarzyła się zresztą ku temu dobra okazja, bo pod koniec lutego mocno trendującym w szeroko rozumianych social media okazał się być artykuł “Solid.js feels like what I always wanted React to be”, który mnie samem pozwolił wreszcie zrozumieć główną filozofię stojącą za tą technologią .
Tak, wiem, tego kwiata jest pół świata, ale znajdowanie najlepszego artykułu na jakiś temat technologiczny zawsze jest problem, nieprawdaż? Dlatego zamiast poddawać się paradoksowi wyboru, postanowiłem użyć tego, który wpadł mi prosto w łapy. I całość pozwoliła mi zrozumieć, że z Świętego Graala reactowe Hooki stały się już rozwiązaniem z grona mniejszego zła. Jak się okazuje, to właśnie one prezentowane są przez autora (w dość przekonujący sposób) jako “przegadane” oraz potencjalnie błędogenne. Okazuje się, że Solid bierze z API Reacta to co najlepsze (JSX i ogólny sposób użycia frameworku), równocześnie tworząc własną alternatywę dla hooków, zwaną sygnałami, z perspektywy twórców znacznie wygodniejsze (i na takie zresztą wyglądają – jestem pewien, że fani programowania funkcyjnego polubią się z tym konceptem).
Jednak nie na samym “słodziku składniowym” Solid chce budować swoją popularność. Framework przemyca też sporo reaktywności i… olaniu VirtualDOMu. Twórcy twierdzą, że są w stanie w inkrementalny sposób zapewnić lepszą wydajność niż reactowy wirtualny DOM (a pamiętam te czasy, kiedy to właśnie z powodu tego rozwiązania mieliśmy osiągnąć wręcz magiczny poziom szybkości aktualizacji DOMa…). No cóż, benchmarki wydają się wskazywać, że podejście twórców Solid.js może mieć sens. Podlinkowany artykuł dobrze wyjaśnia, skąd wynika wspomniana prędkość rozwiązania – TLDR: React najpierw musi zrobić heurystykę w ramach swojego wirtualnego drzewa, aktualizacje DOM Solid.js pomijają ten krok. Przyznam jednak, że chętnie znalazłbym jakąś dogłębniejszą analizę tego zagadnienia.
Tak, zdaje sobie sprawę, że wielu z Was już wcześniej zapoznało się z Solid.js, ale chciałem trochę podsumować to, czego się o nim dowiedziałem – w sam raz dla osób które chcą zrozumieć skąd ten cały nagły buzz wokół tej technologii.