Frontend Thursday vol. 39

1. WebContainers, czyli Node.js natywnie w przeglądarce

StackBlitz od jakiegoś czasu zapowiadał, że na Google I/O pokaże coś dużego, nad czym pracowali od dawna. Nikt nie spodziewał się jednak, że będzie to najciekawsze ogłoszenie dotyczące JavaScriptu na całej konferencji. O WebContainers huczał w zeszłym tygodniu cały internet (albo przynajmniej bańka, w której ja się obracam). Jeśli jeszcze o nich nie słyszeliście, to zaraz przybliżę Wam ogólną koncepcję i powiem, dlaczego nie podzielam wszechobecnej ekscytacji.

WebAssembly to potężne narzędzie i zespół StackBlitz postanowił wykorzystać je do stworzenia środowiska uruchomieniowego Node.js. Oczywiście samo działające w przeglądarce środowisko uruchomieniowe to nie wszystko i aby uwolnić pełny potencjał Node.js trzeba zapewnić poprawne działanie integracji z systemem operacyjnym. Na tym polu nie jest idealnie, ale trzeba przyznać, że udało się dowieść całkiem sporo (np. emulacja fs jest możliwa dzięki wykorzystaniu File System Access API). Wiemy już jak to możliwe, że Node działa w przeglądarce, ale jak się z nim połączyć? Tutaj do gry wchodzi ServiceWorker, który przechwytuje odpowiednie requesty i przekierowuje je do naszego WebContainer. Obecność ServiceWorkera zapewnia również, że całość rozwiązania może działać w 100% offline.

Architektura wygląda ciekawie, ale po co to wszystko? To co najbardziej ze mną rezonuje, to pięciokrotne przyśpieszenie czasu instalacji dependencji i bezpieczeństwo całego rozwiązania (nie od dziś wiadomo, że przeglądarki dążą do stworzenia jak najbezpieczniejszego i najbardziej odizolowanego SandBoxa). StackBlitz stał się właśnie idealnym narzędziem do przygotowania minimalnej reprodukcji Buga i podesłania go na StackOverflow, gdzie osoby chcące pomóc będą w stanie bardzo szybko i bezpiecznie wskoczyć w nasz kod.

Co budzi moje wątpliwości w całym tym zamieszaniu? WebContainers (czasami w pokrętny sposób) emulują wiele systemowych metod, co spokojnie może doprowadzić do różnic w zachowaniu między wersją odpaloną w przeglądarce i lokalnie. Kolejny mankament to wspierane przeglądarki. Na ten moment WebContainers działają tylko w silnikach opartych na Chromium, więc nie uświadczymy ich chociażby na mobilnych urządzeniach z jabłuszkiem czy w Firefox (co może boleć podwójnie, bo to właśnie Mozilla utrzymuje zdaniem wielu najlepszy silnik WASM). Oprócz tego lista wspieranych frameworków jest raczej krótka (aczkolwiek trzeba przyznać, że zawiera chyba wszystkie najpopularniejsze opcje): Express.js, Koa, NestJS, Next.js, Nuxt.

Deweloper widząc listę przeglądarek na których działają WebContainers – 2021 koloryzowane

Na koniec zostawiłem sobie gwóźdź do trumny. Z poziomu WebContainers nie połączymy się z bazą danych, bo przeglądarki nie mogą komunikować się za pomocą niestandardowych protokołów (tutaj zespół StackBlitz liczy na pojawienie się w przeglądarkach Native Sockets, ale na razie nie wiadomo, czy i kiedy możemy się ich spodziewać). Brak tej funkcjonalności wykluczył prawdopodobnie większość backendów z tego narzędzia. Jeśli WebContainers aspirują do zostania domyślnym środowiskiem deweloperskim to przed nimi jeszcze długa droga, ale jak na wersję beta to jest naprawdę nieźle.

Źródła:

https://blog.stackblitz.com/posts/introducing-webcontainers/
https://twitter.com/stackblitz/status/1395409316270772224

2. Typescript 4.3

O TypeScript 4.3 mogliście przeczytać już przy okazji Bety i Release Candidate, ale ja obiecałem sobie, że nie będę Wam zawracał głowy dopóki nie pojawi się wersja stabilna. W tym tygodniu wreszcie się doczekałem i nowy TypeScript został opublikowany. Mamy tutaj do czynienia z kolejną wersją minor, więc nie powinniśmy oczekiwać cudów, ale mimo wszystko Microsoft wcisnął tu kilka ciekawych usprawnień.

Jak dla mnie najciekawszą nowością jest dodanie słowa kluczowego override, które nie tylko uchroni nas przed literówkami, ale też pomoże przy refactorowaniu kodu (jeśli zmienimy nazwę metody tylko w klasie bazowej, to metoda w klasie dziedziczącej oznaczona jako override spowoduje pojawienie się błędu kompilacji). Wraz z nowym słowem kluczowym dochodzi też nowa flaga `–noImplicitOverride`. Pozwala ona wymusić dodawanie nowego słowa kluczowego tam, gdzie rzeczywiście nadpisujemy jakąś metodę.

class SomeComponent {
    show() {
    	// ...
    }
    hide() {
    	// ...
    }
}
class SpecializedComponent extends SomeComponent {
    override show() {
        // ...
    }
    override hide() {
        // ...
    }
}

Druga ciekawa zmiana to rozdzielenie typów setterów i getterów, co ma pozwolić na wygodną konwersję typów w setterach. Jedynym ograniczeniem jest tu wystąpienie typu z gettera w setterze. Jeśli brzmi to dla Was mgliście, to zerknijcie na snippet poniżej.

class Thing {
	#size = 0;
    get size(): number {
    	return this.#size;
    }
    set size(value: string | number | boolean) {
        let num = Number(value);
        // Don't allow NaN and stuff.
        if (!Number.isFinite(num)) {
        	this.#size = 0;
        	return;
        }
        this.#size = num;
    }
}
let thing = new Thing();
// Assigning other types to `thing.size` works!
thing.size = "hello";
thing.size = true;
thing.size = 42;
// Reading `thing.size` always produces a number!
let mySize: number = thing.size;

Oczywiście nie jest to koniec zmian. Nowa wersja dostarcza usprawnienia do string literals znanych z TypeScript 4.1, rozszerza listę elementów w klasie, które mogą zostać oznaczone jako prywatne, czy ulepsza wnioskowanie typów generycznych. Jeśli jesteście ciekawi szczegółów, to zachęcam do przeczytania podlinkowanego poniżej artykułu bo Microsoft, jak zwykle w swoich release notesach, trzyma poziom.

Źródła:

https://devblogs.microsoft.com/typescript/announcing-typescript-4-3/

3. Angular DevToos

Jeśli kiedyś musieliście debugować zaawansowaną angularową aplikację, to prawdopodobnie kojarzycie wtyczkę Augry, umożliwiającą zaawansowane debugowanie drzewa komponentów. W tym tygodniu zyskała ona poważnego konkurenta, bo Google ogłosiło powstanie Angular DevTools, które już na starcie posiada wszystko, co posiadał Augry i nawet odrobinę więcej. Jest tu więc możliwość podglądania drzewa komponentów, wybierania komponentu kursorem czy możliwość edycji parametrów wejściowych komponentów. Ponadto, ciekawie wyglądają opcje profilowania, które umożliwiają podejrzenie czasów ChangeDetection czy renderowania poszczególnych komponentów.

Jeśli współpraca między zespołem odpowiedzialnym za samego Angulara i Angular DevTools będzie przebiegała sprawnie, to myślę, że możemy spokojnie pożegnać się z Augry. Mam nadzieję, że taka symbioza sprawi, że nowe wersje Angulara będą wspierane od dnia zero, a wsparcie dla starszych nie będzie stanowiło problemu (w przeszłości miałem takie problemy z Augry). Ponadto, po cichu liczę trochę na to, że kolejne iteracje nad Angular DevTools pozwolą nam lepiej analizować, to co dzieje się wewnątrz Angulara i dzięki temu jeszcze lepiej optymalizować nasze aplikacje.

Unikalne nagranie przedstawiające przyszłość Augry

Źródła:

https://angular.io/guide/devtools
https://www.youtube.com/watch?v=d1SJL51FFxQ

4. Chrome 91

Na zakończenie mam dla Was pojawienie się nowego Chrome’a oznaczonego numerem 91. Co prawda lista nowości jest krótka, ale zdecydowanie jest ona konkretna. Do `showSaveFilePicker` dodano parametr `suggestedName`, a do `showOpenFilePicker` parameter `startIn`. Umożliwiają one odpowiednio nadanie domyślnej nazwy pliku do zapisu i wybranie domyślnego katalogu do którego użytkownik zostanie przeniesiony przy wyborze pliku do otwarcie. To nie koniec zmian dotyczących interakcji z plikami, bo w Chrome wreszcie pojawia się też zana z Safari możliwość wklejenia pliku skopiowanego do schowka. Niby małe rzeczy, a sumarycznie mogą mocno ulepszyć doświadczenia użytkownika.

Oprócz powyższych zmian ciekawie wygląda też możliwość oznaczenia stron, między którymi współdzielone powinno być sugerowanie haseł. Odpowiednia konfiguracja wymaga trochę pracy (wymagane jest stworzenie pliku assertlinks.json i dodanie go do .well-known), ale z łatwością przychodzą mi do głowy aplikacje, w których takiej opcji mi brakowało.