Mateusz: Cześć! Witamy Cię w kolejnym odcinku podcastu Piwnica IT. Ja nazywam się Mateusz Jabłoński, jest ze mną Wojtek Skorupa. Dzisiaj porozmawiamy o języku, bez którego współczesny frontend development wydaje się niemożliwy. Tematem dzisiejszego odcinka będzie TypeScript nadzór dla JavaScriptu, który dodaje statyczne typowanie do naszego kodu. Przez wiele lat nie tylko bardzo mocno się rozwinął, ale można powiedzieć, że zmienił frontend. Odchodząc od dynamicznej natury JS'a, wprowadził programowanie na frontend na nowy, wyższy poziom. TypeScript stał sięstandardem, poprawił Developer Experience i ułatwił wiele procesów, takich jak testowanie, refaktoryzacji czy tworzenie dokumentacji. Wydawać by się mogło, że nikt do czystego JavaScriptu już nie wróci. A jednak coraz częściej spotkać się można z głosami, że duże projekty porzucają TypeScript. Wojtku, jak myślisz, dlaczego tak się dzieje?

Wojciech: Tak, jest to ciekawa sprawa Mateuszu, ale myślę, że jestem w stanie sobie wyobrazić, że w momencie, kiedy mamy taki ogromny projekt, TypeScript zaczyna sprawiać coraz więcej problemów, szczególnie kiedy musimy zapewnić typy użytkownikowi. I ten nasz kod musi być bardzo generyczny. I tworzenie tych typów, które są bardzo skomplikowane, muszą robić naprawdę wiele rzeczy, może być naprawdę problematyczne. Jestem w stanie sobie to wyobrazić.

Mateusz: Wiele projektów, które działają na rynku, przede wszystkim można tutaj wspomnieć o Svelte w wersji piątej czy SvelteKit, porzuciło TSa na rzecz czystego JavaScriptu i wydaje się, że to porzucenie, to odejście od TS na rzecz czystego JS wynika przede wszystkim z tego, że są to bardziej biblioteki niż aplikacje docelowe, które są używane przez wiele różnych podmiotów. I tutaj zamiennikiem dla takiego typowania w Svelte czy w SvelteKit prawdopodobnie będzie JSDoc, który pozwoli Wam wygenerować typy na podstawie swoich struktur, swojego kodu. W zasadzie wydaje mi się, że to odejście od TS'a ma tutaj swoją wartość. Kod, który dostarczamy będzie miał mniej kroków do wykonania, będzie bardziej, można powiedzieć bardziej generyczny, stanie się łatwiejszy do zaimplementowania w aplikacji. Na pewno miałeś takie doświadczenia, gdzie musiałeś zaimplementować jakąś bibliotekę, jej typy były na tyle rozbudowane i na tyle chaotyczne, że ciężko było znaleźć po prostu najlepszą drogę do tego, aby wprowadzić odpowiednie typy do swojej aplikacji, uwzględniając to, co zostało napisane w danej bibliotece.

Wojciech: Zdecydowanie. Poza tym szczerze powiem, że troszkę przeraża mnie to miejsce usunięcia TS z takiej biblioteki, ale ogólnie usunięcie. Jak myślę o swoich projektach i w momencie kiedy miałbym się pozbyć tego TSa, troszkę przeraża mnie to, jednak zapewnia taką miłą, bezpieczną przestrzeń i bardzo pomaga w pisaniu tego kodu, szczególnie w momencie, kiedy nie jestem tylko ja, osobą, która tworzy ten kod, ale jest to wiele osób, które tworzą ten kod, więc jest to zdecydowanie ciekawy ruch ze strony tych bibliotek. Poza tym jestem ciekawy Twojego zdania w kontekście tych JSDoc'sów. Myślisz, że one będą w stanie zapewnić taką samą pewność tym bibliotekom, jak zapewniał TypeScript.

Mateusz: Z tego co wiem, jest JSDoc można, tak jak powiedziałem, łatwo przerobić na typowanie, na pliki .d.ts, które w zasadzie pozwalają nam wspierać już TypeScript jako taki, więc te typy, które byśmy sobie napisali w TS będzie można łatwo wygenerować z JSDocs. JSDoc ma tą dużą zaletę, że to jest nadal JavaScript, więc nie ma tutaj żadnego dodatkowego narzutu w postaci TypeScript czy jakiegokolwiek innego języka. Więc można tu powiedzieć śmiało, że pod tym względem są na pewno wartościowe. Dużo naszych IDE już wspiera JSDoc na tyle, że jest w stanie wnioskować jaki powinien być typ przy danej zmiennej czy w danym kodzie. Myślę, że takie narzędzia jak Copilot czy inne rozwiązania AI'owe już też mają to wsparcie i też są w stanie nam dosyć fajnie to ograć i korzystać z tych JSDoc'sów, które nam to opisują. Mi osobiście kod napisany w JSDoc kojarzy się, może to głupie porównanie, ale kojarzy mi się ze starym sposobem dokumentowania klas czy funkcji czy metod w klasach w PHP.

Wojciech: To samo. Może nie w PHP, ale w JS jak najbardziej.

Mateusz: Moja przygoda z programowaniem rozpoczęła się od PHP, a więc gdzieśtam rzeczywiście pierwszy backend'owy kod, który widziałem był właśnie tak opisany, udokumentowany. I JSDoc dokładnie mi to przypominają.

Wojciech: Jestem w ogóle ciekawy, bo dla mnie tak jak wspominasz i tak jak ktoś wskazuje nazwa to są JSDocs, czyli coś do dokumentacji i nie wiem jakie Ty masz doświadczenia ogólnie z dokumentacją, ale dla mnie jest to zawsze coś, szczególnie jeśli chodzi o coś co jest gdzieś przy kodzie, co jest kolejną rzeczą, którą trzeba utrzymywać i jakoś tę zależność pomiędzy tą dokumentacją właśnie obok tego kodu opisującą te nowsze funkcje, klasy, metody, cokolwiek, jest znacznie mniej związana niż jest TypeScript. Czyli coś co chcę powiedzieć, że te typy, które musimy utrzymywać w JSDoc są dla mnie zdecydowanie mniej naturalne niż utrzymywanie ich w Typescript'cie.

Mateusz: Zgodzić się muszę, ponieważ sam pamiętam czasy, kiedy się modyfikowało jakąś funkcję i akurat tego fragmentu jakoś o dziwo zapominało się aktualizować. A tutaj w Typescript rzeczywiście możemy traktować kod TS'owy jako swoistą dokumentację.

Wojciech: Tak, jakby to jest naturalne.

Mateusz: Tak, piszesz kod i automatycznie tworzy się dokumentacja do tego kodu. Więc pod tym względem TypeScript na pewno ma dużo większą wartość niż wszelkie narzędzia do tworzenia dokumentacji. Zresztą jakbyśmy tworzyli dokumentację w Markdown'nie do tego co tworzymy, to prawdopodobnie nikt by tego nie pisał.

Wojciech: Dokładnie. Poza tym w ogóle ciekawe, jak się teraz nad tym zastanawiam, ciekawa jest właśnie ta zależność pomiędzy tym, że jednak TypeScript traktujemy jako kod, jako coś, co jest nierozłączną częścią tego, co piszemy. A jednak JSDocs wydają mi się być trochę z boku, jako taka rzecz dodatkowa, więc jestem ciekawy jak to będzie wyglądać utrzymanie takiej biblioteki. W momencie kiedy musisz uważać i jeszcze na tą rzecz, która przynajmniej dla mnie, nie wiem jak dla Ciebie i dla pozostałych programistów, jest taka trochę wydaje się jako taka rzecz dodatkowa bardziej.

Mateusz: Tutaj też chyba należałoby zwrócić uwagę na fakt, że JavaScript jako język jest językiem dynamicznie typowanym, a zatem daje bardzo dużo swobody programiście. Pozwala na wiele rzeczy, na które języki statycznie, silnie typowane nie pozwolą. I teraz z perspektywy klasycznego frontend developera, który wyszedł z JavaScriptu i to był jego pierwszy język, to jest bardzo komfortowa sytuacja. Możemy wprowadzać co chcemy, pisać jak chcemy i w zasadzie JavaScript nam na to pozwoli, skoryguje nasze błędy. A jeżeli jakieś już popełnimy krytyczne, to wyrzuci nam jakieś reference error i na tym się w zasadzie skończy. Trudniej będzie to zdebuggować oczywiście. Natomiast z perspektywy wprowadzenia języka silnie typowanego musimy zwrócić większą uwagę na to, co piszemy. Musimy bardziej się skupić na tym, co my chcemy napisać, ponieważ raz zadeklarowany typ już taki z nami zostanie. Poprzez chociażby mechanizmy w TypeScript'cie jak inferencja typów nie jesteśmy w stanie nadpisać typu, który raz został zadeklarowany i tutaj wydaje mi się, że JSDoc'sy będą idealnym rozwiązaniem dla osoby, która właśnie wychodzi z tego naturalnego świata frontendu, tego pierwotnego świata frontendu jakim był JavaScript w wersji takiej dynamicznej i w zasadzie nadal jest w wersji dynamicznej, gdzie możemy sobie dodać coś, co nam podpowie jakie były zamierzenia autora tego kodu. Niekoniecznie, że tak to musi zostać, ale cel był bardzo prosty i ten cel opisujemy w postaci dokumentacji. W TypeScript'cie nie ma już tej elastyczności. W TS mamy ten, że tak powiem taki, strict mode, gdzie nie jesteśmy w stanie wyjść poza pewne ramy. Oczywiście mamy any, ale to już jest trochę inna kwestia.

Wojciech: To prawda. Zdecydowanie jest to ciekawy model i jestem ciekawy jak utrzymywanie tych bibliotek rozwinie się dalej. Nie wiem czy miałeś okazję w ogóle pisać tego typu kod, gdzie JSDoc'sy traktujesz jako TypeScript i ten Twój kod wynikowy będzie TypeScript'em, czy też będą oprócz niego zapewniane jeszcze typy? Czyli piszemy w JS i mamy te typy obok. Domyślam się, że będzie to nie lada wyzwanie, żeby to wszystko działało tak jak trzeba. Chociaż tak jak mówię, nie miałem jeszcze okazji z takim podejściem pracować. Też widziałem kod bibliotek, które korzystają z TSa i wiem, jak ciężkie potrafią być te generyczne typy, które są potrzebne do tego, żeby ta biblioteka działała dobrze. Można sobie rzucić okiem na taką bibliotekę typu ZOD i typy, które działają tam pod maską są naprawdę skomplikowane. I ten język, i to co jest napisane dookoła samego kodu czasami jest dysproporcjonalnie większe. Same typy i to, żeby one działały dobrze, jest zaskakująco dysproporcjonalnie większe w porównaniu do samej logiki biznesowej.

Mateusz: Problem nie dotyczy tylko ZODa, w zasadzie każda większa biblioteka, która jest udostępniana na zewnątrz, ma dokładnie ten sam problem. Niejednokrotnie jak spojrzysz w kod dokumentacji, czyli kod typów, których w zasadzie widzisz pierwszy, kiedy sobie wejdziesz do node_modules. Na pierwszy rzut oka wydaje się to mega chaotyczne, niezrozumiałe, skomplikowane, zwał jak zwał i trzeba się naprawdę skupić, żeby zrozumieć, co autor miał na myśli. Wydaje mi się, że w tym momencie to, co zrobiło z Svelte w wersji piątej czy SvelteKit, odchodząc od Typescript'u, ale jednocześnie nie zamykając tej furtki, to jest całkiem fajny ruch i pomimo wszystko należy to uszanować. Oni nie powiedzieli, że nie doceniają silnego typowania. Oni wręcz doceniają w swoich aplikacjach. Natomiast w przypadku samej biblioteki potwierdzają, że większą użyteczność dla użytkownika będzie miało stworzenie do tego JSDoc'ów i napisanie tego w JSie czystym niż męczenie się, bo to tak trzeba nazwać. Kombinowanie z Typescriptem na poziomie biblioteki. W samej aplikacji, którą już finalnie tworzymy z wykorzystaniem tych bibliotek, prawdopodobnie typy będą najlepszym rozwiązaniem, więc TypeScript czy jakikolwiek inny język silnie typowany, w tym wypadku zdecydowanie nam pomoże.

Wojciech: Jestem ciekawy Twojego zdania jeszcze Mateuszu w tym kontekście, że wiem, że Svelte jest takim dość specyficznym frameworkiem frontendowym. Jest powiedzmy takim trochę chuliganem, można go nawet nazwać, który stwierdził, że ma trochę inne podejście do tego, jak podchodzimy do kodu. Przypomina oczywiście to, co znamy z naszych środowisk frontowych, ale jednak te pliki w większości przypadków kończą się .svelte i to nie jest to samo co Angular, React, nawet Vue. I czy uważasz, że taki ruch odejścia od Typescript'u jest możliwy, czy też widzisz go, czy też taka decyzja będzie podejmowana przez biblioteki, które bardziej kojarzysz sobie ze JS/TS? Mówię tutaj o takich bibliotekach typu Next, Remix, React Query. coś podobnego typu ZOD, o którym wspominaliśmy.

Mateusz: Wydaje mi się, że w kontekście tego, jak rozwija się JavaScript, warto docenić go jako język i to, co zaproponował tutaj chociażby zespół Svelte. To odejście od tego Typescript'u na rzecz czystego JSa i JSDoc'sów. To jest ciekawy kierunek rozwoju. Nie powiedziałbym, że wszyscy w tym kierunku pójdą, bo na pewno tak to nie będzie wyglądało. Widać to chociażby po tym, że TypeScript nadal jest tym głównym językiem, w którym tworzone są biblioteki różnego rodzaju i aplikacje. I tak zostanie prawdopodobnie. Chyba że jedna propozycja dotycząca wprowadzenia typów do JS zostanie ostatecznie opublikowana i wejdzie z którymś kolejnym standardem ECMA. No, ale do tego czasu myślę, że TypeScript nadal będzie bardzo popularny i to, co się wydarzyło w 2015 / 14 roku, kiedy Angular wprowadzał TypeScript na rynek, inaczej: wypromowywał TypeScript na rynku frameworków na rynku frontendowym, od tamtego czasu sukcesywnie TypeScript zyskuje. Microsoft jako ogromna organizacja nie miał takiej siły przebicia, żeby go tak wypromować, ale zwróć uwagę, że Google ze swoim Angular'em, wchodząc w TypeScript wymusił na użytkownikach wprowadzenie go. W zasadzie stał się takim przodownikiem. Pokazywał jakie są cechy, zalety TypeScriptu i dzisiaj, pomimo wielu jego wad, o których wspomnieliśmy, czyli tej chaotycznej dokumentacji, łatwości w budowaniu bałaganu, ale też wielu zalet. Jednak te zalety są bardziej wartościowe i bardziej widoczne niż te wady, które z którymi możemy się spotkać. I wydaje mi się, że takie frameworki jak Next czy właśnie biblioteki jak ZOD czy jakakolwiek inna będą dalej szły w kierunku rozwijania swojego kodu z TypeScript, bo pomimo wszystko nawet dla developerów będzie to łatwiejsze, będzie to przyjemniejsze. Sam wiesz jak się pisze z czystym JSem, a jak się pisze z Typescript'em? Obaj zaczęliśmy od czystego JS'a. Pierwsze projekty, które robiliśmy były związane z czystym JSem, dopiero po czasie, zresztą obaj mamy takie doświadczenie, że weszliśmy w Angulara jako pierwszy projekt z TS i to było coś nowego. To było coś można powiedzieć, świeżego, które trochę irytowało, ale jednak pomimo wszystko po jakimś czasie zaczęliśmy doceniać zalety i nawet przechodząc później na React'a, gdzie pierwszym moim językiem w React był JavaScript i dopiero po chwili dodało się do tego TypeScript. Okazywało się wow. Ten TypeScript jednak zmienia, jednak wprowadza pewne ułatwienia w pisaniu i pomimo tego, że wydaje się dla klasycznego frontend developera czymś nienaturalnym może, to jednak po pewnym czasie każdy albo większość z nas docenia go.

Wojciech: To prawda. Myślę, że już na ten moment jest to taki standard, od którego ciężko się oderwać. Szczerze powiedziawszy ciężko sobie wyobrazić pisanie aplikacji jakiejkolwiek bez Typescript'u, ale pamiętam taki czas, kiedy ten TypeScript przerażał mnie, może nie przerażał, ale zdecydowanie myślałam, że jest problematyczny i bardzo spowalnia proces tworzenia. Nie wiem czy Ty też masz takie doświadczenie, ale ja na samym początku byłem wręcz przerażony, tak jak wspominałeś ile dodatkowego kodu trzeba utworzyć. Ale potem, gdy zrozumie się te plusy, które daje ten TypeScript. I nauczy się go trochę pisać, rozumieć. I przejdzie się przez tą pierwszą barierę, która wcale nie jest taka wysoka. Naprawdę wszystko zmienia się tylko na pozytywne.

Mateusz: Z mojej perspektywy podam Ci przykład szkoleń, które prowadziłem dla Java Developerów. Zazwyczaj takie szkolenia odbywają się w ten sposób: to są najczęściej osoby, które mają jakieś podstawy frontendu w postaci HTML, CSS, JavaScript. Zaczynamy od wprowadzenia np. React albo jakiegokolwiek innego frameworka, fragmentu wiedzy frontendowej z wykorzystaniem czystego JSa i najczęściej po jednym, po dwóch dniach wprowadzamy do tego TypeScript. Najczęściej wynika to z prośby użytkowników czy też studentów, którzy chcą się czegoś nauczyć. Więc pokazuję ten sam kod w JSie i pokazuje ten sam kod Typescript'cie. Dla osób, tak jak wspomniałem, które mają przede wszystkim background java'owy czy też backend'owy z silnie typowanymi językami, jest to tak naturalne pisanie typów, że w zasadzie dochodzą do wniosku, że oni nie chcą się uczyć tego klasycznego JS, bo ten TypeScript da im o wiele więcej wartości, o wiele jest dla nich bardziej naturalny w tworzeniu, w pisaniu niż czysty JS. I to chyba też jest kierunek, w którym poszedł frontend jakby nie patrzeć. Zwróć uwagę, że my w JavaScripcie, tworząc kod w JavaScripcie, od wielu lat byliśmy trochę inaczej traktowani. Często się mówiło, że "a tam frontend to nie programiści", "a ten JavaScript to tam do robienia animacji", "a tam żeby tam się kręcił jakiś loader, to ten JavaScript spokojnie wystarczy". Tę rolę dzisiaj przejął CSS. Tak jak być powinno. Wprowadzając wiele różnych funkcjonalności, funkcji, sposobu obliczeń, takich animacji, możemy tworzyć keyframes i wiele innych elementów, na które CSS nam pozwala. A. JavaScript stał się językiem, który służy nam do opisania logiki biznesowej, w większości przypadków. Tak jak to się dzieje na językach backend'owych. I teraz, z perspektywy takiego wprowadzenia Typescriptu czy też zmian w JavaScripcie na przestrzeni lat. JavaScript zmierza w kierunku rozwijania się, udowadniania całemu światu, że "sorry, ale JavaScript jest pełnoprawnym językiem programowania" i w nim też można tworzyć rozsądnie. Nie tylko chaotycznie, nie tylko dynamicznie w cudzysłowiu, ale tworzyć narzędzia, które dają Ci poczucie tego, że stworzyłeś coś stabilnego. TypeScript przede wszystkim poprzez to właśnie, że dodaje to silne typowanie, ale też daje wiele różnych funkcjonalności, takie jak np. typy generyczne czy guard'y, to pozwala nam właśnie na bardziej stabilne i wyważone tworzenie tych aplikacji. Można powiedzieć, że jest bardziej dedykowany dla dojrzałych projektów, które mają być stabilne w długim okresie czasu.

Wojciech: No tak, albo nad którym pracuje wiele osób.

Mateusz: Albo nad którymi pracuje wiele osób. Chociażby problem refaktoryzacji.

Wojciech: To prawda. Wyobrażasz sobie taką sytuację, że coś zmieniasz, instalujesz nową bibliotekę albo zmieniasz jakiś typ. Projekt jest napisany w czystem JSie i po prostu jest cisza i musisz teraz się przeklikać przez pół aplikacji, żeby znaleźć to miejsce. OK. To tam w tamtym konkretnym przypadku to nie działa.

Mateusz: A wyobraź sobie teraz, że to jest aplikacja reaktywna.

Wojciech: No tak.

Mateusz: Która w zasadzie wiele rzeczy ma ukrytych i nie masz jasno napisane co się dzieje. Po prostu dzieje się magia i jest logika rozproszona po całej aplikacji, tak jak to się dzieje w aplikacjach frontendowych komponentowych. Bez Typescript'u cholernie trudno jest tym zarządzać.

Wojciech: W sumie jak tak teraz o tym rozmawiamy: jakby implementacja tego Typescript'u w Angularze dwójce, tak jak rozmawialiśmy wydaje się być naturalnym ruchem. Po prostu nie wyobrażam sobie, szczególnie, gdy chcemy, żeby nasz framework był traktowany poważnie i chcemy, żeby na jego podstawie były tworzone jakieś ogromne aplikacje. To w momencie kiedy wyobrażamy sobie tą rzeczywistość bez Typescriptu zdecydowanie wygląda ona średnio.

Mateusz: Też wydaje mi się, że Angular czy też Google doskonale wiedział co robi wprowadzając TypeScript do swojego frameworka. Wydaje mi się, że wprowadzenie TypeScript'u dało im tą gwarancję, że ludzie będą to tworzyli w taki sposób, w jaki oni chcieliby, żeby to było tworzone. Sama architektura tego rozwiązania już sporo narzuciła, ale TypeScript tak naprawdę to zabetonował, spowodował, że trudno, bardzo trudno jest odejść od tego zaproponowanego sposobu pisania przez developerów Googla.

Wojciech: Dokładnie.

Mateusz: OK, ale tutaj też warto wspomnieć o tym co się zmienia. Bo TypeScript jest dla nas w tym momencie standardem, ale Microsoft, który to jest twórcą tego nadzbioru dla JavaScriptu, w 2023 roku w marcu wysunął ECMAScript proposal, gdzie zaproponował wprowadzenie silnego typowania do JavaScriptu, który składniowo dość mocno przypomina to, co się dzieje w Typescript'cie. Więc mamy podobną składnię do deklarowania typów, mamy podobne nowe typy, tak jak wprowadzenie tupli. Pewnych rzeczy nie wprowadza ten standard, ale można śmiało powiedzieć, że on faworyzuje TypeScript. Natomiast prawie wszystkie propozycje przyniosłyby też korzyści dla użytkowników innych języków silnie typowanych nadzbiorów silnie typowanych, takich jak np. Flow, który też jest obecny na rynku. O nim pewnie sobie za chwilę chwilkę porozmawiamy. Myślisz, że to jest dobry kierunek, żeby JavaScript jako JavaScript stał się językiem, może się nie stanie statycznie typowany, ale żeby wprowadził możliwość deklaracji typów już w swoim kodzie źródłowym.

Wojciech: Myślę, że jest to naturalny kierunek, który widać też w innych językach programowania. Pierwszy przykład, o którym wiem, przychodzi mi do głowy. Niestety nie jestem aż tak dobrze zaznajomiony z historią, którym jest Python. W którym dokładnie zadziała się prawie identyczna sytuacja, gdzie pojawiła się opcja typów, które oczywiście nie wyglądają tak samo jak czy też nie będą działać w taki sam sposób jak w tym proposal'u, ale droga jest mniej więcej taka sama. Czyli mamy język dynamicznie typowany, w którym coraz więcej użytkowników zaczyna z niego korzystać, coraz większe projekty powstają, coraz więcej ludzi pracuje nad aplikacjami i nagle pojawia się wprowadzenie tych typów, które pomagają wszystkim, nie dość, że użytkownikom i konsumentom kodu pythonowego, czy ludziom, które pracują nad bibliotekami i aplikacjami, to jeszcze dodatkowo IDE, które muszą to wszystko kompilować, wspierać i jest to zdecydowanie cięższe w momencie, kiedy tych typów nie ma. Więc jak dla mnie jest to naturalny kierunek JSa i myślę, że fajnie, że będzie to wspierane natywnie, bo pozwoli to na dużo dodatkowych opcji. Co o tym sądzisz Mateuszu?

Mateusz: Myślę, że sporo wyzwań przed tym proposal'em. On jest w tej chwili chyba w stage 1 z tego co kojarzę. Natomiast - dlaczego sporo wyzwań? Przede wszystkim dlatego, że ECMA jako organizacja bardzo chciałaby i dąży do tego, żeby każda nowa propozycja, każda nowa funkcjonalność, która wchodzi do JavaScriptu, miała pełną kompatybilność wsteczną, żeby kod, który jest, że tak powiem, zastany, działał w dokładnie ten sam sposób, żeby zachować te stare funkcjonalności i stary sposób pisania. JavaScript przez wiele lat wprowadził bardzo dużo różnych rzeczy i teraz dodanie do tego typowania już jest utrudnione. Nie niemożliwe, ale na pewno będzie to spore wyzwanie i ten proposal na pewno kilka lat najbliższych jeszcze będzie się rozwijał i będzie zbierał z rynku różnego rodzaju komentarze zanim zostanie wdrożony, ale mam odczucie podobne do Twojego, że to jest dobry kierunek. Dobry kierunek, ponieważ zagwarantuje użytkownikom kodu czy też programistom, to, co daje TypeScript, jednocześnie nie zabierając im tej elastyczności JavaScriptu. Bardziej mnie tu zastanawia dlaczego Microsoft to zaproponował? Ten koncept mnie nie interesuje, bo ta propozycja wyszła od Microsoftu. I ta propozycja jest przez Microsoft procesowana. Microsoft, który jak wiemy jest jest twórcą Typescript'u. Być może mają w planach porzucenie tego projektu. Chociaż kto wie, może nie. Nic na ten temat nie znalazłem.

Wojciech: Myślę, że na to szansa jest mała, szczególnie patrząc na to, jak prężnie rozwija się Typescript. Teraz już jesteśmy gdzieś tam w wersji piątej i zdecydowanie porusza się to do przodu. Więc nie sądzę, żeby gdzieś to było blisko, ale rzeczywiście jest to ciekawe. I niestety nie mam dla Ciebie odpowiedzi dlaczego może tak być, nawet pomysłu. Czy Ty masz jakieś przypuszczenia, jakieś podejrzenie?

Mateusz: Bawimy się w detektywów trochę. Nie, nie mam. Aczkolwiek tak jak mówię, dla mnie to jest ciekawe, skąd się to wzięło. I dlaczego to z ich strony wyszło. Microsoft zaskakuje pod wieloma względami w ostatnich latach. Więc zobaczymy. Zobaczymy, może rzeczywiście mają jakiś fajny plan na to, jak wesprzeć społeczność JavaScriptu i jak sprawić, żeby rzeczywiście ten język rozwijał się w dobrym kierunku, szedł w dobrym kierunku, rozwijał się podobnie jak Python, w stronę bardziej stabilnego, dojrzałego rozwiązania, jeszcze dojrzalszego niż jest w tym momencie.

Wojciech: Może my patrzymy na to trochę w zły sposób. Może powinniśmy zadać pytanie, czy Microsoft nie jest idealną osobą do wprowadzenia tego proposal'u, skoro oni wiedzą o tym typowaniu najwięcej teoretycznie w związku z tym, że tworzyli ten projekt? My tu doszukujemy się jakiegoś drugiego dna, a może to jest po prostu najbardziej odpowiednia osoba, powiedzmy do zrobienia tego? W związku z tym, że mają teoretycznie największe doświadczenie.

Mateusz: W zasadzie z tej perspektywy możesz mieć rację. Nie ma chyba w świecie JavaScriptu podmiotu, który miałby większe doświadczenie w tworzeniu takiego narzędzia. No a jak już mówimy o innych językach, silnie typowanych, to warto też powiedzieć coś o alternatywach dla Typescriptu. Ja znam dwie, znam Flow i słyszałem o Hegel. Miałeś przyjemność z którymś? Flow chyba korzystałeś przy okazji Reacta z tego co pamiętam.

Wojciech: Dokładnie tak. Flow, był w pewnym momencie relatywnie często spotykany czy też często spotykane rozwiązanie do tego typowania propsów, chociażby w React, ale nie miałem jakiegoś głębszego doświadczenia, chociaż z tego co pamiętam jest to coś relatywnie podobnego do ZODa powiedzmy. Czyli miejsce, w którym możemy sobie za pomocą takich zwykłych obiektów Javascriptowych definiować te typy, gdzieś tam nałożyć walidację na nasz kod. Ale nie powiedziałbym, że miałem jakieś wspaniałe doświadczenia z tego typu narzędziami. Zazwyczaj to tarcie, które wynikało z korzystania z nich, ilość dodatkowego kodu, specyfiki pisania tego kodu, czy też to jak on wyglądał było raczej nieciekawe dla mnie i wydawało mi się zazwyczaj, że to przynosi więcej dodatkowej pracy, która jest w większości przypadków bezsensowna. Nigdy nie zobaczyłem w tych alternatywach niczego specjalnego. Ale może Ty Mateusz masz inne doświadczenie?

Mateusz: Porównując do Typescriptu np. Hegla, to tak naprawdę TypeScript jest takim językiem, który nie tylko wprowadza nam typy, ale dodaje też sporo innych rzeczy, jak np. nowe funkcjonalności do tworzenia klas. Daje nam pewien pewien taki lukier składniowy - syntax sugar i daje nam jakieś funkcjonalności dodatkowe do składni, jak chociażby elementy zabezpieczające metody w klasach jak private, protected czy public. Więc te wszystkie operatory dodatkowe, które się pojawiają, to wszystko dostajemy w pakiecie z Typescriptem. Natomiast Hegel to tak naprawdę jest tylko Type Checker, który dodaje do JavaScriptu typy i na tym polega jego zadanie, więc wydaje mi się, że to są bardziej narzędzia dla osób, które nie potrzebują TSa w takiej postaci, w jakiej on jest dostarczony. Nie potrzebują tak potężnego narzędzia. Chcą po prostu dać coś prostego do swojego kodu. Wiadomo w dzisiejszych czasach TypeScript jest zintegrowany z o wiele większą liczbą bibliotek czy też aplikacji, a zatem o wiele łatwiej jest chociażby taką aplikację ze Typescriptem uruchomić. Natomiast w momencie, kiedy mamy aplikację czysto JSową i możemy wybrać co chcemy, ale nie chcemy wchodzić zbyt głęboko i przebudowywać całej naszej apki. To taki Hegel czy Flow pewnie się nada i da nam to, czego oczekujemy na samym początku. Pytanie czy na dalszych etapach nie będziemy chcieli pójść w stronę Typescriptu, bo jeżeli nam się spodoba to silne typowanie i da nam sporo wartości, to czy ten TypeScript nie będzie naturalnym następnym krokiem? To jest pewnie kwestia bardziej zespołu, który musi podjąć decyzję o tym, w czym chce pisać, jak chce pisać, ale też pewnie decyzja biznesowa.

Wojciech: Tak, ale to w ogóle ciekawy wątek myślę, że nam się trochę rodzi, o którym też rozmawialiśmy przy okazji Bun'a i Deno, czyli łatwości wprowadzenia tego typu rozwiązań do istniejących już projektów. I jeśli chodzi o Typescript to przecież mamy jak najbardziej taką opcję w kompilatorze "allowJS" i możemy nawet jednym plik mieć typescriptowy i teoretycznie wszystko będzie działać.

Mateusz: Co więcej nie musisz mieć żadnego pliku typescriptowego i mieć TypeScript w projekcie. Ale to wynika z natury języka. To jest język, który jest kompilowany czy transpilowany do JavaScriptu ostatecznie, więc w zasadzie każdy kod Javascriptowy będzie działał poprawnie w tym TS.

Wojciech: To brzmi trochę jak jakiś koszmar z pierwszych dni pracy. Opowiadali na rozmowie rekrutacyjnej, że mają TS, wchodzę do projektu, otwieram test config i wszystkie pliki JSowe.

Mateusz: A co! Tutaj jeszcze mi się tak skojarzyło, bo są też takie narzędzia, takie języki silnie typowane, które możemy kompilować np. do JavaScriptu jak np. Hexa. Więc w zasadzie po co JavaScript czy TypeScript? Jak możemy sobie wykorzystać narzędzie, język, który będzie, jak to jest napisane na stronie języka Hexa, tym, czym JavaScript powinien być. Więc z tej perspektywy w świecie, gdzie JavaScript jest głównym językiem w Web Development'cie, a jednocześnie mamy tak dużo różnych kompilatorów i transpilerów wykorzystanie jakiegokolwiek języka silnie typowanego, który będzie ostatecznie i tak czystym Javascriptem jest w zasadzie tylko i wyłącznie czystą formalnością. Z mojego doświadczenia TypeScript to jest mega fajne narzędzie do pracy. Dużo ułatwia, dużo poprawia i daje nam sporo zabezpieczeń na etapie developmentu, które pozwalają nam tą pracę wrzucić na trochę inny poziom. Tak jak mówiłem na samym początku poprawia nam ten developer experience i ułatwia te procesy, które są trochę irytujące dla programistów, jak chociażby refaktoryzacja, tworzenie dokumentacji czy właśnie testowanie, pisanie testów jednostkowych chociażby.

Wojciech: No i nie wiem jak u Ciebie Mateuszu, ale ja mam wrażenie ze swojej pracy z Typescriptem, które relatywnie rzadko mi się zdarza w narzędziach czy rzeczach dodatkowych poza kodem i powiedzmy, że TS jest taką rzeczą, bo mamy te typy i tak dalej, to też o to trzeba dbać. Nigdy nie miałem wrażenia, że to jest niepotrzebne i że robię coś bez sensu, a jeśli miałem, to w jakichś super specyficznych przypadkach. Zawsze mam wrażenie, że ta wartość, którą on dodaje, mimo tego, że tej dodatkowej, drobnej pracy, którą trzeba w niego włożyć, jest zdecydowanie warta tego, co dostaje z powrotem.

Mateusz: Z biegiem lat myślę, że masz dużo racji, ale ja też z biegiem lat nauczyłem się, że nie zawsze należy dopisywać te typy. Są takie miejsca, gdzie po prostu lepiej polegać na mechanizmach wnioskowania TSa. Gdzie to Typescript podejmie decyzję jaki typ danej wartości jest wpisany, czy też powinien być w kodzie niż samodzielne dopisywanie tych typów w każdym możliwym miejscu. I to jest coś, czego się nauczyłem przez ostatnie lata. I daje mi to takie poczucie, że mam możliwość tworzenia kodu statycznie typowanego, ale mam też poczucie, że nie jest on niepotrzebny, bo kod nie staje sięprzeładowany, jeśli ja dobrze rozumiem ten TypeScript i wiem, kiedy TypeScript jak zadziała, czy też jakie będzie jego wnioskowanie na temat typów. I w pewnych miejscach rzeczywiście czasami daje to dużo, dużo możliwości. I to poczucie, o którym ty mówiłeś, gdzie wydawało się to niepotrzebne było u mnie, ale w początkowych dniach, etapach mojej pracy z Typescriptem jako takim.

Wojciech: Mimo to myślę, że to co opisujesz Mateuszu i na samym początku opisywałeś to myślę, że jest to idealny sposób wykorzystania Typescript'a, czyli zakładanie tych barier i pisanie tych typów tak naprawdę w jak najmniejszej ilości miejsc i staranie się, żeby ten TypeScript działał tak naprawdę, czy powiedzmy w tym momencie, kiedy on rzeczywiście jest potrzebny i kiedy przysłowiowo możemy sobie strzelić w kolano, kiedy coś w tym obiekcie, zmiennej, funkcji zostanie zwrócone czy trafi do nas coś innego.

Mateusz: Zaczęliśmy od wniosku, w zasadzie od hipotezy, że TypeScript może nie jest już potrzebny, ponieważ wiele projektów porzuca go na rzecz czystego JavaScriptu. Ale chyba oboje się zgodzimy, że to porzucenie nie jest takie jednoznaczne, ponieważ TypeScript jest jednym z najpopularniejszych języków frontendu. Jest językiem, który daje sporo wartości i ułatwia wiele rzeczy, a te najbardziej newralgiczne elementy, takie jak tworzenie dokumentacji w bibliotekach mogą być rozwiązywane na różnorakie sposoby. I tutaj mamy do dyspozycji właśnie JSDoc. Jeśli chodzi o przyszłość JavaScriptu i TypeScriptu warto wspomnieć o właśnie ECMAScript proposal na temat właśnie tworzenia typów w JavaScripcie i wydaje mi się, że to jest fajny kierunek, zresztą podobnie jak Tobie, że jest to fajny kierunek rozwoju tego języka. Podobnie zresztą jak to miało miejsce w przypadku chociażby Pythona. Inne języki warto poznać, warto się zaznajomić, natomiast chyba w tym momencie nie ma nic, co mogłoby zagrozić pozycji tej TS. Ze swojej strony na pewno myślę, że warto korzystać z tego Typescriptu i warto poznać go, jeżeli nie mieliście jeszcze takiej okazji, ponieważ TypeScript daje naprawdę sporo możliwości i naprawdę wiele ułatwia, wprowadzając te doświadczenia, tą przyjemność z programowania na trochę inny poziom.

Wojciech: Super podsumowanie Mateuszu. Myślę, że ostatnia myśl to w momencie, kiedy jeszcze nie mieliście okazji skorzystać ze Typescriptu i jesteście na projekcie, które jest napisane w Javascript, to chyba trzeba uciekać, bo to już najwyższa pora. To już jest standard.

Mateusz: Takie małe faux pas. Dziękujemy wszystkim słuchaczom. Dziękujemy Tobie słuchaczu, za to, że byłeś z nami przez te kilkadziesiąt minut. Zachęcamy do subskrybowania, polubienia, komentowania i wszelkich kontaktów z nami. Będziemy bardzo wdzięczni za udostępnienie naszego podcastu i do usłyszenia za jakiś czas.