Frontend Thursday vol. 90 - Twórca SolidJS dołącza do Netlify i nowości z Microsoft Build

1. Twórca SolidJS dołącza do Netlify

SolidJS to framework, który trochę niespodziewanie przedarł się do JavaScriptowego “mainstreamu”. Kiedy rok temu pojawiły się pierwsze wzmianki na jego temat zgodnie z dziennikarskim obowiązkiem podzieliłem się nimi z Wami w 44 edycji naszego przeglądu. Przyznam się szczerze, że potraktowałem go jako kolejną chwilową ciekawostkę i nie przyłożyłem do niego większej wagi – jak się później okazało niesłusznie. Jeśli jesteście ciekawi dlaczego SolidJS podbił serca deweloperów i dlaczego Virtual DOM już dawno jest passe, to odsyłam Was do 79 edycji naszego przeglądu, gdzie Artur poddał SolidJS dogłębnej analizie.

Większość artykułów w sieci wspominając o SolidJS odnosi się do wyników ankiety State of JS 2021 w kategorii zadowolenia deweloperów. SolidJS wraz ze Svelte zajął w niej egzekwo pierwsze miejsce – oba frameworki otrzymały 90% pozytywnych odpowiedzi. Ja niestety chciałbym poddać lekkiej polemice ten ogólny optymizm. Do korzystania z SolidJS przyznało się tylko 3% respondentów ankiety, czyli około 250 osób. Oznacza to, że zadowolonych z SolidJS było około 225 deweloperów. Dla porównania w przypadku Svelte było to prawie 1500 osób, a w przypadku Reacta ponad 5000 osób.

BTW. Jeśli szukacie złych wykresów na podstawie, których można wyciągnąć złe wnioski to polecam ten artykuł.

Nie oznacza to natomiast, że SolidJS wypadł w State of JS słabo. Statystyką, która szczególnie robi na mnie wrażenie jest chęć do nauczenia się frameworku w nadchodzącym roku. W tej kategorii SolidJS zajął solidne drugie miejsce z wynikiem 56% (ponad 4000 respondentów). Nawet jeśli tylko garstka deweloperów miała już okazję pobawić się SolidJS, to zdecydowanie zdobył on rozgłos niezbędny do dalszego rozwoju.

Rozgłos jaki SolidJS w środowisku nie pozostał bez echa. W minionym tygodniu Netlify ogłosiło, że przyjmie w swoje szeregi Ryana Carniato – twórcę zyskującego na popularności frameworku. Ojciec SolidJS będzie mógł w pełnym wymiarze godzin poświęcić się pracy nad swoim frameworkiem. Na razie nie pojawiła się konkretna roadmapa dla SolidJS, ale liczę na to, że w zbliżających się miesiącach będę miał okazję częściej do niego wracać.

Na zakończenie chciałbym zwrócić jeszcze uwagę na ciekawy trend, który można ostatnio zaobserwować. Ray Carniato nie jest jedynym deweloperem, którego większa firma przygarnęła pod skrzydła wraz z rozwijanym przez siebie frameworkiem. Kilka tygodni temu Vercel ogłosił zatrudnienie Richa Harissa, twórcy Svelte. Szczerze przyznam, że taka forma rozwoju jest ciekawą alternatywą dla tworzenia startupów wokół projektów Open Source lub równie popularnych bibliotek utrzymywanych z datków społeczności.

Źródła:

https://dev.to/ryansolid/when-netlify-asks-you-to-full-time-oss-you-say-yes-5ccf
https://vercel.com/blog/vercel-welcomes-rich-harris-creator-of-svelte
https://www.netlify.com/blog/announcing-serverless-compute-with-edge-functions/
https://www.tekkiwebsolutions.com/blog/jamstack-web-development/

2. Nowości z Microsoft Build

2.1 Ostateczne odliczanie do końca IE11

O tym, że Internet Explorer umiera wiedzieliśmy już od dawna. Najpierw twórcy frameworków i bibliotek masowo zaczęli rezygnować ze wsparcia dla IE11, a później sam Microsoft ogłosił, że nie zamierza już dłużej wspierać starszego brata Edge. Oczywiście zmiana nie mogła nastąpić od razu, więc deweloperzy z Redmond wyznaczyli odległą datę 16 czerwca 2022. Jak się okazuje, czas leci szybciej niż mi się wydawało i oficjalny pogrzeb IE11 odbędzie się już za niecałe 2 tygodnie.

No dobra, z tym oficjalnym pogrzebem to trochę koloryzowane (ale na swoją obronę powiem, że Microsoft sam prowadzi podobną narrację). IE11 nie będzie już wspierany na standardowym Windows 10, ale w wersjach serwerowych będzie żyć jeszcze do 2029 roku.

Jeśli w Waszej firmie nadal wykorzystywany jest IE11 to… jak najszybciej zacznijcie szukać sobie jakiejś lepszej posady. A tak zupełnie serio, to Microsoft przygotował dla takich firm specjalny tryb w Microsoft Edge, który umożliwia emulację IE11. Jeśli mieliście okazję pobawić się tą emulacją to koniecznie dajcie znać jak to działa w praktyce (niestety wersja Edge na macOS nie posiada tej funkcjonalności)

Koniec Internet Explorer oznacza również powolną śmierć silnika Chakra. Na konferencji Microsoft ogłosił, że WebView2, czyli komponent umożliwiający uruchomienie webowej aplikacji wewnątrz C#, trafi do kolejnych frameworków i bibliotek. Zmiana silnika JavaScript spowodowała spore optymalizacje wydajności – kod wykonuje się nawet 85% szybciej przy mniejszym zużyciu zarówno procesora jak i pamięci RAM.

Sporą część swojej prezentacji Microsoft poświęcił również PWA. Te od jakiegoś czasu dostępne są w Microsoft Store, a teraz dostały również swoją specjalną zakładkę wewnątrz Microsoft Edge. To nie jedyny ruch rozszerzający gamę aplikacji na Windows. Na tej samej konferencji, gigant z Redmond ogłosił, że dogadał się z gigantem z Seattle (Amazon) i w swoim sklepie umożliwiał będzie wyszukiwanie aplikacji Androidowych (które już od jakiegoś czasu można uruchamiać na Windows 11)

2.2 Xamarin nie żyje, niech żyje .NET MAUI

Ostatnimi czasy panuje niesamowita moda na tworzenie międzyplaformowych frameworków. Chyba każda większa firma walczy aktualnie o kawałek tego tortu. Google promuje Fluttera (który kilka tygodni temu przy okazji Google I/O otrzymał stabilne wsparcie dla macOS i Linuxa), Facebook wspiera React Native (którego wersję na macOS i Windows rozwija Microsoft), a JetBrains rozwija Jetpack Compose (w którym stabilne wsparcie dla desktopowej wersji przesunęło się trochę w czasie, ze względu na sytuację za wschodnią granicą). Nawet środowisko Open Source ma swojego Electrona (i nie przekonacie mnie, że Slack czy Figma to słabo działające aplikacje). Do tego zacnego grona dołącza również Microsoft, który przy okazji swojej konferencji opublikował .NET Multi-platform App UI.

Wszyscy mają ochotę na kawałek tortu, jakim jest posiadanie międzyplaformowego frameworku. Ja natomiast trochę powątpiewam, czy na rynku aby na pewno jest tak popyt na tego typu technologię, czy też jest to trochę sztuczne pompowanie balonika

W notatce Microsoftu dotyczącej ich nowego dziecka próbowałem doczytać się, co ma wyróżnić je na tle dostępnych już rozwiązań. Szczerze mówiąc, mnie nie przekonały argumenty giganta z Redmont. Nagłówków takich jak “łatwa personalizacja”, “wydajność” czy “niesamowity developer experience” nie potrafię traktować na poważnie. Jedyną ciekawostką, którą udało mi się wygrzebać, jest wsparcie dla systemu operacyjnego Tizen. Jeśli chcecie pisać aplikacje na Smart TV, to może rzeczywiście jest to ciekawa opcja.

Źródła:

https://news.microsoft.com/build-2022-book-of-news/
https://devblogs.microsoft.com/dotnet/introducing-dotnet-maui-one-codebase-many-platforms/
https://blogs.windows.com/msedgedev/2022/05/24/microsoft-edge-build-2022/

3. Animacje przejść między statycznymi stronami

Statyczne, renderowane po stronie serwera aplikacje wracają ostatnio do łask i trendy takie jak HTML Over Wire są tego najlepszym przykładem. Jednym z argumentów obrońców podejścia Single Page Applications były jak do tej pory animacje przejść między stronami. Dotychczasowe API przeglądarek nie umożliwia kontroli ani nad znikającą stroną, ani nad tą która zaraz ją zastąpi. Oznacza to, że przygotowanie jakichkolwiek animacji jest niemożliwe. Google pracuje jednak nad rozwiązaniem tego problemu i pierwsze efekty możecie zobaczyć w najnowszym Google Chrome Canary 101.

Aby skorzystać z nowego API, zamiast ze standardowego sposobu nawigacji, należy odpowiednio wykorzystać nowe metody dodane do obiektu document.

const transition = document.createDocumentTransition();
await transition.start(...);

Po wywołaniu kodu powyżej przeglądarka wykona dwa screenshoty: jeden strony znikającej z ekranu i drugi strony, która za chwilę ma się pojawić na ekranie . Następnie przy pomocy standardowych animacji CSS możemy zaimplementować naszą własną tranzycję. O powstałej w ten sposób strukturze można myśleć w następujący sposób:

<!-- ::page-transition=container(root)  -->
<transition-container>
  <!-- ::page-transition-image-wrapper(root)  -->
  <image-wrapper>
    <!-- ::page-transition-outgoing-image(root) -->
    <outgoing-image />
    <!-- ::page-transition-incoming-image(root) -->
    <incoming-image />
  </>
</>

Prosta animacja fadeIn przy użyciu nowego API wygląda następująco:

@keyframes fadein {...}

@keyframes fadeout {...}

::page-transition-outgoing-image(root) {
    animation: fadeout 2s;
}
::page-transition-incoming-image(root) {
    animation: fadein 2s;
}

Wykorzystując opisany powyżej mechanizm nie jesteśmy w stanie zaimplementować zaawansowanych animacji (takich jak na przykład miniaturka rozszerzająca się do pełnego wideo). Na szczęście Google pomyślał też o takich przypadkach i umożliwia podzielenie strony na dowolne mniejsze części, a następnie animowanie ich osobno. W takim wypadku zamiast screenshotu całej strony, będziemy mieć do czynienia z screenshotem tylko jej fragmentu. Aby wydzielić kawałek strony należy do jego styli dodać `page-transition-tag: <part-name>;`, a następnie odwołać się do nich za pomocą odpowiednich pseudo elementów.

Przykład animacji jakie będzie można tworzyć przy użyciu nowego API

.video-miniature {
  page-transition-tag: video-miniature;
  contain: paint;
}

@keyframes fadein {...}

@keyframes fadeout {...}

@keyframes scaleUp {...}

@keyframes showAtTheEnd {...}

::page-transition-outgoing-image(root) {
    animation: fadeout 2s;
}
::page-transition-incoming-image(root) {
    animation: fadein 2s;
}

::page-transition-outgoing-image(video-miniature) {
    animation: scaleUp 2s;
}
::page-transition-incoming-image(video-miniature) {
    animation: showAtTheEnd 2s;
}

Na razie nie wiadomo kiedy i czy nowe API trafi do zwykłej wersji Chrome. Nawet wersja dostarczona w Canary nie jest w pełni kompletna, bo wspiera tylko Single Page Application… Trzymam jednak kciuki za standaryzację propozycji Google, bo możliwości jakie otwiera nowe API wyglądają naprawdę ciekawie.

PS: Jeśli macie odrobinę więcej czasu to gorąco polecam 15 minutowe wideo na temat nowego API z ostatniego Google I/O. Jake Archibald tłumaczy niuanse nowego API zdecydowanie lepiej niż ja.