Analizujemy najnowszą wersję ES2020 i najciekawsze elementy wprowadzone do języka i biblioteki standardowej JavaScript. Pojawiło się naprawdę sporo ciekawych rzeczy: lazy loading import, Promise.allSettled, BigInt, globalThis, optional chaining, czy nullish coalescing operator. Szczególnie wprowadzenie 2 nowych operatorów prawdopodobnie mocno wpłynie na tworzony kod. Wiele z wprowadzonych zmian jest już dostępnych od jakiegoś czasu w TypeScript, natomiast wprowadzenie ich do JS to zdecydowanie krok na przód. Wprowadzenie rocznego cyklu ECMAScript pomogło wprowadzać stopniowe zmiany, w przeciwieństwie do rewolucji ES6.

Przydatne Linki

• JavaScript ES2020 Features With Simple Examples: https://medium.com/better-programming/javascript-es2020-features-with-simple-examples-d301dbef2c37

Transkrypt

Marek Piechut: Komisja Standaryzująca Ecmascript’u, czyli inaczej do Javascript’u, przeniosła do stage 4, czyli do stanu takiego wyreleasowanego, w którym już rzeczy są zabetonowane i takie już mają być, standard ES2020, czyli EcmaScript na rok 2020. No i pojawiło się tam dosyć dużo ciekawych rzeczy. No, moim zdaniem, kierunek jest świetny i dużo z tych rzeczy ułatwi nam pracę bez jakiś tam zewnętrznych narzędzi, które do tej pory były do tego używane, gdzieś tam. I z takich najciekawszych rzeczy, które wchodzą do ES2020, będę też mówił przy okazji, czy można już sobie tego użyć czy nie, czy to już jest gdzieś tam zaiplementowane czy nie. To pierwsza rzecz, która jest według mnie ciekawa, to dynamic import, czyli wreszcie lazy loading importowanych rzeczy i ładowanie rzeczy, jakby precyzja tego, co będzie ładowane w Runtime, tak. Bo można tam dynamicznie generować te ścieżki do rzeczy, które będą ładowane, także lazy load i ładowanie dynamicznych źródeł - już teraz w standardzie, właściwie dostępne wszędzie.

Bartek Witczak: No dobra, bo do tej pory było tak, że ten lazy loading był ogrywany przez narzędzia, bo przecież można było Webpack chyba, ogarnąć to, żeby były lazy load.

Marek Piechut: No tak. Trzeba to było robić jakoś przez narzędzia, tak… Można to było robić, gdzieś tam React’owymi narzędziami, albo webpackiem, albo czymś takim… Nie wiem, tam pewnie jakieś inne rozwiązania też były. No, a teraz też jest standard, można, gdzieś tam, te dynamiczne importy wkładać i one będą przez samą przeglądarkę rozwiązywane, także jak ktoś tam nie korzysta z webpacka czy z jakiś frameworków, które na to pozwalają, to teraz może sobie po prostu na tym już takie rzeczy robić.

Bartek Witczak: Super..

Marek Piechut: No dobra, z drugiej ciekawej rzeczy to jest BigInt, który wchodzi do standardu, który pozwala na przechowywanie liczb większych niż number, jest to niestety tylko integer’y czyli tylko liczby całkowite, ale nie ma już ograniczeń pamięciowych. Można sobie wkładać do tego co tylko się chce, więc jakieś różne dziwne rzeczy w stylu: numery kont będą mogły być już numerem, a nie będą musiały być stringami, czy tam jakieś inne numery kart, które wykraczały poza wielkość numberu.

Bartek Witczak: Elegancko, czyli jeżeli będziemy też wysyłali eventy, to mamy teraz trochę więcej numerków dostępnych..

Marek Piechut: Tak, większe liczniki eventów. Z ciekawych rzeczy, na których można się tutaj wywrócić, to jest to, że nie będzie kompatybilności z numberem do końca, więc nie będzie można używać tego zamiast numbera i nie będzie można porównywać string do numbera, czyli 12 jako number nie będzie równe z trzema równa się BigInt’owi 12.

Bartek Witczak: Ok.

Marek Piechut: ..także z tym trzeba uważać. No i przy tych wszystkich autokonwersjach trzeba też uważać, bo one będą eksplodowały, nie będą automatycznie robione, także jest tam trochę rzeczy na które trzeba uważać, ale rozwiązuje trochę problemów jakiś tam naukowych aplikacji i tak dalej, gdzie tam tych numerów brakowało i trzeba było samemu te rzeczy implementować. To będzie w tym momencie wbudowane i pewnie wydajność też będzie dramatycznie lepsza w porównaniu z przechowywaniem tego w stringach czy w jakiś tam innych wynalazkach, gdzie przechowujesz fragmenty tych liczb i samemu na tym obliczenia robisz.

Bartek Witczak: Jednym słowem robi się poważnie…

Marek Piechut: Tak, robi się poważnie, robi się poważnie. Blockchainy już będą w Javascripcie

Bartek Witczak: Cały świat niedługo będzie…

Marek Piechut: Cały świat..

Bartek Witczak: Wspaniale.

Marek Piechut: Dobra, kolejna ciekawa rzecz to jest Promise.allSettled . Może nie być bardzo ekscytujące, jeżeli używałeś tam Bluebird czy jakiś bibliotek do promise’u, bo to już tam było, ale generalnie, to o co chodzi to, żeby można było sobie zrobić Promise.all, który nie będzie fail’ował cały przy pierwszym fail’u. Dostaniesz po prostu odpowiedź z promise’ami, które się udało ukończyć i takimi, które fail’ował i samemu masz to spokojnie przetworzyć…

Bartek Witczak: O.., to jest bardzo fajne. Taki niby mały util, a rzeczywiście może pomóc w części przypadków.

Marek Piechut: No tak, wydaje mi się, ze też znowu sprawia, że te wszystkie biblioteki obsługujące pomise’y, znowu można je gdzieś tam usuwać, znowu trochę mniejszy bundle size.

Bartek Witczak: Jasne.

Marek Piechut: Bo nie musisz już dodatkowych bibliotek wkładać, żeby coś takiego obsłużyć. Także, mi się wydaje, że fajnie, że takie rzeczy się dzieją. To też można używać praktycznie wszędzie. Takim outsiderem jest androidowy Firefox, nie wiem jaka jest część rynku, która używa androidowego Firefox’a , ale…

Bartke Pewnie coś mniej więcej między 80 a 90 procent rynku…

Marek Piechut: Tak może być, także myślę, nie ma co się bardzo przejmować tym, że w Firefox’ie tego nie ma, androidowym. Z ciekawych rzeczy dalej – globalThis – to może wyglądać, jak coś zbędnego, ale ułatwia trochę życie, jak piszesz kod, który ma działać w przeglądarce i w Node.js, i w wielu innych miejscach, bo teraz nie będzie tego całego if window to window, jak nie window to inny global, jak nie taki global to trzeci global, takiego odnośnego kodu nie trzeba będzie pisać.

Bartek Witczak: Aaa, rozumiem. Trochę to pokrętnie zrozumiałem, ale okej, To jest global, który jest dostępny wszędzie po prostu, bez względu na środowisko

Marek Piechut: Tak, on się nazywa globalThis nie musisz szukać czy to jest window czy nie window, czyli jakieś tam globalne funkcje, które są zdeklarowane, one są w Node.js i na window w przeglądarce, że to wszystko będzie pod tym globalThis

Bartek Witczak: Yhy…

Marek Piechut: Także, jak to usłyszałem, znaczy przeczytałem, to pomyślałem „po co to komu, w ogóle”, że globalThis, trzeba uciekać. Ale z drugiej strony do tych wszystkich rzeczy, które Ci środowisko dostarcza to jest potrzebne…

Bartek Witczak: No ja, jak powiedziałeś na początku to się przeraziłem, po prostu…

Marek Piechut: No druga sprawa jest jeszcze, że część jakiś tam starych, ładuje się i pakuje sobie rzeczy na global, więc też łatwiejszy będzie dostęp do tego, w kodzie, który musi działać i w Node.js i w przeglądarce, także mała rzecz, ale może coś tam ułatwi. Z rzeczy, które dla mnie są na przykład świetne, to będzie eksport z pliku, czyli będzie, eksport wszystko z czegoś jako coś tam…

Bartek Witczak: W końcu…

Marek Piechut: Tak, w końcu, coś co jest w TypeScripcie, chyba Flow też to już ma w tym momencie, no a teraz będzie relatywnie po prostu w Javascripcie. Moim zdaniem bardzo fajna rzecz, bo to znowu promuje, żeby mieć takie prywatne moduły, które nie są gdzieś tam ukryte w jakiś większych paczkach i nikt tam nie sięga, a ty eksportujesz tylko rzeczy, które są dla Ciebie jakieś tam publiczne, nie?

Bartek Witczak: Jasne, no to zdecydowanie…, znaczy wydaje mi się, że idziemy troszkę w tą stronę takiej większej dojrzałości języka, po to, żeby ,powiedzmy, paczki pakować w jakiś tam indeks, eksportować tylko to co potrzebujemy na zewnątrz. No to trochę…, coraz bardziej już idziemy w tą stronę, że te projekty po prostu się zwiększają, rosną i fajnie już zadbać o to, żeby ta widoczność była rzeczywiście tylko na poziomie jednego pliku i jakby importować te rzeczy tylko przez ten package czy folder cały, nie?

Marek Piechut: No tak, no właśnie widać, że ta komisja standaryzująca już tam bierze pod uwagę te rzeczy, że Javascript’u nie jest już tylko jeżdżący pasek albo migające napisy, tylko te aplikacje zaczynają się robić bardzo duże i trzeba, gdzieś tam, dawać ludziom narzędzia do tego, żeby tą złożoną ilość ogarniać, nie?

Bartek Witczak: No, to są bardzo fajne, takie małe, ale bardzo potrzebne zmiany.

Marek Piechut: No i jeszcze jedna rzecz, która jest moim zdaniem bardzo fajna, czyli wreszcie dochodzi optional chaining, czyli operator „Elvis bez oka”, czyli coś, co sprawdza czy coś jest nullem i wywołuje kod po kropce, tylko jeżeli nie jest nullem, także te wszyskie null checki będzie można gdzieś tam… No oczywiście mam nadzieję, że nasi słuchacze nie używają za dużo typów, które mogą mieć tam nulla, gdzieś tam. Jeżeli używają TypeScript, albo gdzieś tam type system ich pewnie uratuje, no ale gdzieś tam jest cały czas kod, który te nulle ma, ma głębokie struktury i takie rzeczy, i trzeba z nim jakoś żyć - i dzięki temu będzie dużo łatwiej. Można nim nie dość, że wyciągać atrybuty na obiektach, to można też wywołać funkcje, które nie wiadomo czy będą na obiektach i używać tych obliczeniowych atrybutów. Wszystkie te rzeczy są obsłużone i to będzie short circuit, nie wiem jak to po polsku nazwać, ale że po prostu nie wykonuje się cały kod po znaku zapytania, jeżeli to było nullem, także też, moim zdaniem to jest dobry kierunek

Bartek Witczak: Bardzo fajnie, to już w backlogu zadań było dosyć długo, dosyć długo już Community czekało na to, żeby operator wszedł…

Marek Piechut: …w Typeskripcie już było dawno chyba, Flow też już jakiś czas miał, na tych wszystkich tam Elm’ach też już chyba było jakiś czas, nie?

Bartek Witczak: Co ciekawe, jakby to też może powodować ten negatywny element czyli jakby mocne zagnieżdżenie struktur…

Marek Piechut: Tak, bo taniej teraz będzie…

Bartek Witczak: Teraz będzie dużo taniej, bo będzie jeden operator, który załatwi nam to, że jeżeli czego nie będzie, będziemy mogli łatwo się z tego wypiąć, a mimo wszystko, tak jak mówiłeś, w Typescripcie też jednak, ja jestem zdania, że warto jednak te typy mocno rozróżniać i nie stosować za dużo optional’y, żeby jakby nie zagnieżdżać tych struktur za mocno tylko rozróżniać je bardziej na poziomie typów i bardziej bazować, po prostu na strukturach, które wymagają danych zmiennych, no nie?

Marek Piechut: No tak, żeby nie budować takich struktur mocno zaniżonych, bo to jest taki code smell, że rzeczy są jakieś strasznie mocno zagnieżdżone, bo pewnie te obiekty wtedy mają trochę za dużo odpowiedzialności, gdzieś tam sięgają po tysiąc rzeczy, których pewnie nie powinny mieć, dlatego gdzieś tam płaskie struktury są z reguły lepszym rozwiązaniem, no i nie mają też takich problemów, że musisz sięgać po 57. kropkę w głąb, żeby wyciągnąć jakąś wartość.

Bartek Witczak: Dokładnie, myślę, że to nie spowoduje jakiegoś wzrostu takiego kodu, a raczej – powiedzmy - w tym starszym kodzie będzie można zastosować ten operator, żeby bardziej się po prostu z tym po ludzku obejść.

Marek Piechut: No tak, cały czas, gdzieś tam pewnie, musisz korzystać z takich czy innych bibliotek, które są napisane w ten sposób, no i gdzieś łatwiej będzie z tym żyć. Z takich rzeczy, to jeszcze w tym temacie, chciałem może Ci powiedzieć to, jedna ważna rzecz jest taka, że nie będzie destructure z tymi optional’ami, także to też takie elementy na których można się wywalić, czyli nie będzie można destruct bezpośrednio zrobić na czymś co jest tam optional po drodze, bo to się skończy pointerem, tak?

Bartek Witczak: Aha, okej.

Marek Piechut: Czyli on…, w tym nie da się tego ostatniego warunku jakoś tam sprawdzić automatycznie, nie?

Bartek Witczak: Jasne

Marek Piechut: Także tego problemu nie rozwiązali. No i znowu ten Firefox Android jest jedynym outsiderem, tam nie ma obsługi tego…

Bartek Witczak: No trudno, no…

Marek Piechut: Poczekamy na niego…

Bartek Witczak: Będziemy musieli zmienić przeglądarkę.

Marek Piechut: A reszta, reszta działa. No i trochę, w związku z tym, dochodzi też taki operator dwuznak zapytania, który ma zastąpić w znacznej mierze, moim zdaniem, gdzieś tam pewnie w 95 procentach, zastąpi podwójny type, czyli takiego ora do sprawdzania nulli i jedyna różnica w nim jest taka, że tylko null i undefined jest dla niego falsy bo to zawsze był taki problem, ze robiło się A lub B, a okazywało się, że A jest zerem, a nie wcale nullem…

Bartek Witczak: Dokładnie!

Marek Piechut: .. i zero gdzieś tam wypadało, na przykład w reakcie, gdzieś tam się pojawiało, bo ono już było renderowane. Te właśnie przypadki gdzieś tam będą obsłużone. No i to jest mniej więcej ES2020. Moim zdaniem dużo ciekawych zmian, tym bardziej, patrząc wstecz niewielkie były te release’y TypeScript’u, niewiele się działo, to wydaje mi się, że takie duże, ciekawe zmiany i można zacząć korzystać już z tych rzeczy, bo one są praktycznie we wszystkich przeglądarkach, poza nieszczęsnym Androidem i Firefoxem, no nie jak ktoś jeszcze używa jakieś Opery Mobile, ale to pozdrawiamy Borysa …

Bartek Witczak: To tylko jednego takiego hardkorowca mieliśmy

Marek Piechut: Nie wiem, czy ktoś więcej jeszcze takich rzeczy używa… I tak poza tym z tego standardu, to co chciałem poruszyć jeszcze taki temat , który mnie zaciekawił apropo przeglądania tych właśnie nowinek w standardzie, to pojawiły się proposal’e dla niemutowalnych typów danych i to też jest moim zdaniem dosyć ciekawa sprawa, bo ma pojawić się tryb record, który będzie takim niemutowalnym objectem i typ tuple, który będzie niemutowanym array’em, no i to jest, mi się wydaje, taki kierunek w stronę FP, taki uśmiech do jakby społeczności FP, żeby mogła wreszcie jakoś efektywniej implementować rzeczy związane z FP. Ta gwarancja wszystkich niemutowalności, to że kolekcja będzie można wreszcie robić niemutowalne i tak dalej, bazując na typach wbudowanych, już bez tych tam freeze’ów i takich rzeczy, które są bardzo wolne i jeszcze kod brzydzą, nie…

Bartek Witczak: No, zdecydowanie to było by coś, co ułatwiło by, a nawet po prostu wyczyściło by ten kod, że było by to po prostu jasne przy czytaniu, jak to wygląda. Tym bardziej, że ja mam takie wrażenie, że coraz więcej bibliotek idzie w tą stronę, że działa na niemutowalnych typach danych i czy to daty czy właśnie jakieś takie elementy zaczynają bazować na tym, że mamy jednak te niemutowalne typy danych, nie?

Marek Piechut: No właśnie, to najbardziej mi się podoba, z punktu widzenia tych narzędzi gdzieś tam reaktowo- reduksowych, że pewnie będzie można wreszcie otypować w ten sposób Redux, żeby mieć tę gwarancję, że te typy będą niemutowalne, także ludzie przestaną wreszcie wpadać na minę taką, że będą zmieniać stan tam środku i dziwić się potem „oj przerenderowuje się raz kiedyś, a nie zawsze”, ale dlaczego to, nie?

Bartek Witczak: No, zdecydowanie.

Marek Piechut: Bo teraz to się może okazać po prostu niemożliwe, bo teraz zostaniesz wyjątkiem, kiedy spróbujesz takie coś zrobić, a nie gdzieś tam później, później okazuje się, że któryś tam komponent w głębi się nie odświeża, nie? Także ja jestem bardzo za, bardzo fajnie było by, żeby te rzeczy weszły wcześniej niż później. Zobaczymy jak to będzie szło. Także, też jestem zadowolony z tych zmian, które weszły w 2020, bo tak miałem wrażenie, że od ES6 takie rzeczy się działy drobne, drobne, drobne, a w tym momencie weszły jakieś takie grubsze zmiany i będzie coraz lepiej.

Bartek Witczak: Dobra, a powiedz mi wiesz co, bo ja bym pociągnął ten temat dalej. Bo wydaje mi się, że jeszcze jest taki aspekt - ogólnie - rozrastania się tej biblioteki standardowej. Też pamiętam, że kiedyś były takie dyskusje, czy rozbudowywać bibliotekę standardową czy lepiej, żeby to właśnie, biblioteki jakieś dodatkowe miały te funkcjonalności. Co o tym sądzisz?

Marek Piechut: Mi się wydaje, że to jest z jednej strony problematyczne z tą biblioteką standardową, jej rozwijanie, no bo jeżeli ona się tak rozbuduje do jakiś ogromnych rozmiarów no to…, to też jest taka kwestia, że nigdy nie da się zaspokoić wszystkich potrzeb. I tak się okaże, że jakiegoś API brakuje, nie? Albo API jest niewygodne, bo zawsze musi działać na this, no i ty tam potem nie możesz go używać, bo nie możesz referencji do funkcji gdzieś tam używać, I te rzeczy mi się wydaje z reguły jest lepiej gdzieś tam wyciągać do bibliotek zewnętrznych, gdzieś tam operacje na array’ach, operacje na obiektach i tym podobne sprawy, ale takie rzeczy jak promise’y jest…, to znaczy da się rozwiązać poza biblioteką standardową, ale one będą dużo wydajniej będą rozwiązane na tylnym kodzie, gdzieś tam. Promise’y, dobra są jakieś tam dyskusyjne, ale typy niemutowalne, tego już się nie da zrobić, bez zmian w samych silnikach, nie?

Bartek Witczak: Yhy, yhy…

Marek Piechut: Jeżeli VN nie będzie tego sprawdzał to jest to niewiele warte, jeżeli jest niemutowalne.

Bartek Witczak: Jasne, mnie też się wydaje, że akurat te zmiany, które są robione, to są w taką bardzo fajną stronę …

Marek Piechut: Tym bardziej, że większość tych zmian jest w samym języku, Jeżeli popatrzymy na to, to są to albo jakieś operatory, albo eksport, albo takie rzeczy, które…, dobra eksport…, no, nie no… to jest zmiana w języku…

Bartek Witczak: No, to jest w języku…

Marek Piechut: Także, to są zmiany w języku, one nie mają wpływu na bibliotekę standardową za bardzo, no taki BigInt, na przykład, już jest dyskusyjny, chociaż on pewnie ze względów optymalizacji lepiej jest, żeby był zaimplementowany w przeglądarce niż w samym środku, bo rozwiązania takie są już teraz, ale podejrzewam, że ich wydajność jest dyskusyjna, nie…

Bartek Witczak: Yhy..

Marek Piechut: Jest dosyć mała, bo to musi być w runtime’ie na jakiś tam albo stream’ach albo wielu różnych liczbach implementować samodzielnie te operacje, gdzie tam dużo szybciej było by to zrobić na jednym kodzie, nie…

Bartek Witczak: Znaczy, mnie to się wydaje, że akurat te zmiany, które tutaj są, to są bardzo in plus i dużo dobrych rzeczy wchodzi. Ja ogólnie, jeżeli chodzi o bibliotekę standardową, wydaje mi się, że takie lekkie rozwinięcie tego co jest – to jest fajna opcja, bo jednak nie zawsze potrzebujemy dociągać dużo tych zależności, a na ten moment, teraz jest to dosyć takie, jak to powiedzieć, ubogie środowisko. Jednak prawie w każdym projekcie te parę bibliotek wchodzi i prawie, że out of the box do projektu.

Marek Piechut: Znaczy, mnie się wydaje, że od czasu ES6 - no to dużo bibliotek okazało się nagle, że można tam bez nich żyć, że jasne, jak robisz większy projekt, to pewnie wsadzisz lodasha, bo nie będzie Ci się chciało z tym męczyć, ale, że właśnie wiele takich drobnych rzeczy da się spokojnie zrobić bazując na tym, co jest w bibliotece standardowej, nie? Bo wtedy podochodziło bardzo dużo fajnych rzeczy i operacji na obiektach, na array’ach i to można sobie tam zrobić biblioteką standardową z reguły albo jakimś małym utils na około biblioteki standardowej, nie?

Bartek Witczak: No zdecydowanie, mnie takie release jak ten, nowe wersje czy jak ES6 to zdecydowanie jestem za…

Marek Piechut: I fajne jest właśnie to, że to jest już zaimplementowane, że tak jak kiedyś był problem, jak wychodził jakiś nowy standard i czekało się, czekało się i tak trzeba było tam Babel’em jeździć, jeździć, jeździć, bo tam dopiero adopcja była za dwa, trzy lata. No to w tym momencie, z tych rzeczy, które przeglądałem, no to tak naprawdę wszystko już jest. To jest dostępne. Przeglądarki teraz aktualizują się same praktycznie, więc ryzyko, że ludzie są na starych wersjach, też jest już znikome, no i można coś z tych rzeczy używać w miarę szybko. Nie mówie, żeby od razu z tych ES2020, ale tych rzeczy, które na przykład wyszły rok temu – coś takiego, mi się wydaje, bez większego ryzyka… No chyba, że wspieramy Internet Explorera…, życie jest smutne, życie jest przykre po prostu

Bartek Witczak: Znaczy na pewno pomógł cały ten release cycle.

Marek Piechut: Tak, tak, no, no jedna rzecz, że release cycle, że przeglądarki, które się same aktualizują. Już nie trzeba liczyć na to, że ktoś wejdzie na stronę i ściągnie nową wersję, czego nikt nie zrobi - no wytłumacz to teraz swojej mamie… i tyle, tak..

Bartek Witczak: No dobra