Frontend Thursday vol. 26

1. Typescript 4.2

W minionym tygodniu miało miejsce wydarzenie, które zawsze jest nie lada gratką dla wszystkich ~~frontend developerów patrzących z wyższością na maluczkich używających JavaScriptu i nie mających pojęcia o systemie typów~~ TypeScript deweloperów. Po kilku iteracjach bety i release candidates, Microsoft w końcu opublikował wersję 4.2 ich flagowego języka (jeśli pomyśleliście w tym momencie o C# to znaczy, że nie płynie w Was czysta frontendowa krew!). Mamy do czynienia z minor release, więc nie należy oczekiwać rewolucji, a raczej małych usprawnień. Jeśli macie więcej czasu, to koniecznie przeczytajcie cały artykuł zamieszczony w źródłach, bo Microsoft jak zwykle zadbał o to, żeby świetnie wytłumaczyć i zakomunikować, co nowego. Dla tych, którzy nie mają czasu i łakną wiedzy tu i teraz postaram się streścić najważniejsze moim zdaniem zmiany.

Frontend Deweloperzy widząc nową wersję TypeScriptu

Zacznijmy od dwóch zmian w inferowaniu typów. Pierwsza z nich, to poprawa wnioskowania typów, która powinna znacząco poprawić czytelność (ciężko to zwięźle wytłumaczyć, więc najlepiej zerknijcie na przykład zamieszczony poniżej). Druga zmiana to rozwinięcie krotek (uwielbiam to spolszczenie od `Tuple`), umożliwiające zdefiniowanie typu ‘reszty’ elementów w tablice. Wspomniana reszta może znajdować się na początku, w środku lub na końcu tabeli, ale krotka może posiadać tylko jedną ‘resztę’.

type BasicPrimitive = number | string | boolean;
// In Typescript 4.1 inferred return type was number | string | boolean | undefined
// In Typescript 4.2 infers return type BasicPrimitive | undefined
export function doStuff(value: BasicPrimitive) {
    if (Math.random() < 0.5) {
        return undefined;
    }
    return x;
}

let bar: [boolean, ...string[], boolean];
bar = [true, false];
bar = [true, "some text", false];
bar = [true, "some", "separated", "text", false];

Kolejną interesującą zmianą, jest umożliwienie zadeklarowania funkcji będącej konstruktorem abstrakcyjnej klasy lub interfejsu. Aż ciężko uwierzyć, że do tej pory taka deklaracja nie była możliwa.

abstract class Shape {
    abstract getArea(): number;
}
interface HasArea {
    getArea(): number;
}
// Not Works! :(
let Ctor: new () => HasArea = Shape;
// Works! :D
let Ctor: abstract new () => HasArea = Shape;

Na zakończenie tematu (oczywiście nie wyczerpałem całej listy zmian, ale po więcej odsyłam Was do źródła) chciałem podzielić się z Wami nową flagą do kompilatora tsc. Po dodaniu `–explainFiles`, kompilator postara się wytłumaczyć nam, dlaczego plik znalazł się w wynikowym bundlu. Brzmi interesująco i na pewno nie raz przyda się w debugowaniu skomplikowanych zależności.

$ tsc --explainFiles > expanation.txt
TS_Compiler_Directory/4.2.2/lib/lib.es5.d.ts
  Library referenced via 'es5' from file 'TS_Compiler_Directory/4.2.2/lib/lib.es2015.d.ts'
TS_Compiler_Directory/4.2.2/lib/lib.es2015.d.ts
  Library referenced via 'es2015' from file 'TS_Compiler_Directory/4.2.2/lib/lib.es2016.d.ts'
TS_Compiler_Directory/4.2.2/lib/lib.es2016.d.ts
  Library referenced via 'es2016' from file 'TS_Compiler_Directory/4.2.2/lib/lib.es2017.d.ts'
TS_Compiler_Directory/4.2.2/lib/lib.es2017.d.ts
  Library referenced via 'es2017' from file 'TS_Compiler_Directory/4.2.2/lib/lib.es2018.d.ts'
TS_Compiler_Directory/4.2.2/lib/lib.es2018.d.ts
  Library referenced via 'es2018' from file 'TS_Compiler_Directory/4.2.2/lib/lib.es2019.d.ts'
TS_Compiler_Directory/4.2.2/lib/lib.es2019.d.ts
  Library referenced via 'es2019' from file 'TS_Compiler_Directory/4.2.2/lib/lib.es2020.d.ts'
TS_Compiler_Directory/4.2.2/lib/lib.es2020.d.ts
  Library referenced via 'es2020' from file 'TS_Compiler_Directory/4.2.2/lib/lib.esnext.d.ts'
TS_Compiler_Directory/4.2.2/lib/lib.esnext.d.ts
  Library 'lib.esnext.d.ts' specified in compilerOptions
... More Library References...
foo.ts
  Matched by include pattern '**/*' in 'tsconfig.json'

Czy Vived będzie wkrótce korzystał z TypeScriptu w wersji 4.2? Prawdopodobnie tak, ale wynika to bardziej z naszego zamiłowania do korzystania ze wszystkiego co najnowsze, niż z obecności którejkolwiek z nowych funkcjonalności. Nie zdziwię się natomiast, jeśli TypeScript 4.2 przejdzie dla wielu niezauważenie i nie traktuję tego jednak jako wadę. Powolna ewolucja to dobra droga dla dojrzałego języka, jakim jest już od dawna TypeScript.

Źródła:

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

2. Vite 2.0

Zeszły tydzień obfitował w nowości, bo oprócz nowego TypeScriptu, ukazała się też nowa wersja Vite. Do tej pory mogliście kojarzyć to narzędzie przede wszystkim z budowaniem aplikacji korzystających z Vue, ale z nową wersją otwiera się ono też na inne biblioteki i frameworki.

Przyznam, że z ciekawością śledziłem twitty Evana You (twórcy Vue, który stoi również za Vite), pokazujące Vite w akcji. Natychmiastowy start serwera deweloperskiego i niesamowicie szybki HMR brzmią jak mokry sen większości z deweloperów. W ostatecznym rozrachunku nie mogłem się oprzeć, że gdzieś już słyszałem te wszystkie zapewnienia…

Niespełna kilka tygodni temu dzieliłam się z Wami informacją o pojawieniu się Snowpack v3 i jeśli sięgnięcie w dalekie zakamarki swojej pamięci (albo wrócicie tutaj), to przypomnicie sobie, że obietnice były podobne. Czyżby Evan You stworzył narzędzie, które dostępne jest już na rynku? Detektyw, który się we mnie obudził nie mógł zostawić tego pytania bez odpowiedzi.

Po burzliwym śledztwie udało mi się ustalić fakty i zmuszony jestem oczyścić Evan You ze stawianych mu zarzutów. Podobna wydajność i zbiór funkcji obu narzędzi wynika z zastosowania pod spodem esbuild, który odpowiedzialny jest za większość efektu wow. Jeśli zastanawia Was natomiast, dlaczego ten diabeł działa tak szybko, to dzieje się to za sprawą zastosowania wielowątkowego go (który bije w wydajnoiści JavaScript) i wykorzystania esmodules. Jaka jest więc różnica między Snowpackiem i Vite? ~~Ten pierwszy korzysta z Webpacka/Parcela, a ten drugi z Rollupa~~*. Jeśli wierzyć obietnicom, pisanie Pluginów to Vite powinno być też prostsze niż do Snowpacka, ale tutaj opieramy się na razie tylko na słowie samego twórcy.

Śledztwo zakończone, sprawa rozwiązana. Zarówno Vite jak i Snowpack oferują wydajność nieporównywalną z innymi narzędziami obecnymi aktualnie na rynku. Ja tymczasem wracam do budowania Angulara i mam subiektywne wrażenie, że cały proces spowolnił się, co najmniej kilkukrotnie od kiedy zacząłem swoje małe śledztwo…

Twórca Frontendowego Czwartku czekający na uruchomienie się serwera deweloperskiego Angulara

Źródła:

https://dev.to/yyx990803/announcing-vite-2-0-2f0a

*- Jak słusznie wytknięto mi na facebookowej grupie JS News (gorąco zapraszam jeśli bo zdażają się tam ciekawe dyskusje) minąłem się tutaj trochę z prawdą Snowpack pozwala wybrać budnler przez dobranie pluginu (aktualnie wspierany jest webpack i Rollup, nie ma natomiast wsparcia dla Parcela). Vite jest natomiast ściśle powiązany z Rollupem przez co ma oferować wydajność i optymalizację out-of-the box oraz lepsze wsparcie dla Pluginów.

3. Benchmark of WebAssembly runtimes

Na koniec dzisiejszego podsumowania mam coś dla wszystkich, którzy zdążyli stęsknić się za tabelkami i wykresami. Twórca Libsodium (biblioteki do szyfrowania) postanowił wykorzystać swoją pracę do sprawdzenia wydajności różnych środowisk uruchomieniowych WebAssembly. Jeśli nie siedzicie w temacie, to raport może okazać się dla Was trochę zbyt suchy, ale wnioski powinny już zaciekawić wszystkich.

W tej edycji testu wszystkie implementacje poradziły sobie poprawnie z wykonaniem kodu. Nie udało mi się znaleźć poprzednich edycji, ale powołując się na słowa autora, jeszcze nie tak dawno nie było to oczywiste. Oznacza to, że WebAssembly powoli osiąga dojrzałość.

Drugi ciekawy wniosek to rekomendacja Node.js jako domyślnego środowiska. Wsparcie dla WebAssembly jest tam, co prawda nadal eksperymentalne, ale NodeJs właściwie we wszystkich kategoriach uplasował się tuż za czołówką. Ciekawe, czy wyjście z fazy experimental wypchnie Nodea na pierwsze miejsce…