2.02 (10) Czy to już koniec Typescript'u?

Cześć! Witamy w kolejnym odcinku podcastu Piwnica IT. 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 front-end development wydaje się niemożliwy. Tematem dzisiejszego odcinka będzie Typescript. Nadzbiór dla JavaScript'u, 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 frontendzie na nowy, wyższy poziom. Typescript stał się standardem, poprawił developer experience i ułatwił wiele procesów, takich jak testowanie, refaktoryzację czy tworzenie dokumentacji. Wydawać by się mogło, że nikt do czystego JavaScript'u 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? Jest to ciekawa sprawa Mateuszu, ale myślę, że jestem w stanie sobie wyobrazić, że w momencie, kiedy mamy taki ogromny projekt, ten Typescript zaczyna sprawiać coraz więcej problemów, szczególnie kiedy musimy zapewnić te 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ć. Wiele projektów, które działają na rynku, przede wszystkim można tutaj wspomnieć o Svelte w wersji piątej czy Svelte Kitcie, porzuciło TSA na rzecz czystego JavaScript'u. I wydaje się, że to porzucenie, to odejście od Typescript'u na rzecz czystego JavaScript'u 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 SvelteKit'ie prawdopodobnie będzie JSDocs, który pozwoli Wam wygenerować typy na podstawie swoich struktur, swojego kodu.

No i tutaj to podejście, w zasadzie wydaje mi się, że to odejście od Typescript'u ma tutaj, w zasadzie ma tutaj swoją wartość. Kod, który dostarczamy będzie miał mniej tych 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.

Zdecydowanie. Poza tym szczerze powiem Ci, Mateusiu, że troszkę przeraża mnie ta myśl usunięcia Typescripta z takiej biblioteki, ale ogólnie usunięcie, jak myślę sobie o swoich projektach i w momencie, kiedy miałbym się pozbyć tego Typescripta, troszkę przeraża mnie ta myśl. Jednak jest on takim miłym Pozdrawiam.

Jestem ciekawy Twojego zdania w kontekście właśnie tych JSDocsów. Myślisz, że one będą w stanie zapewnić taką samą pewność tym bibliotekom, jak zapewniał Typescript? Z tego co wiem, JSDocs 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 Typescript'cie będzie można łatwo wygenerować z JSDocsa. JSDocs ma tą dużą zaletę, że to jest nadal JavaScript, więc nie ma tutaj żadnego dodatkowego narzutu w postaci Typescript'u na przykład, czy jakiegokolwiek innego języka, więc można w tym powiedzieć śmiało, że pod tym względem są na pewno wartościowe.

I te JSDocs dokładnie mi to przypominają. Jestem w ogóle ciekawy, bo dla mnie właśnie tak jak wspominasz i tak jak też wskazuje nazwa, to są dziejezdoksy, czyli coś do dokumentacji i nie wiem jakie Ty masz doświadczenie, Mateuszu, ogólne 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ś ta zależność pomiędzy tą dokumentacją właśnie Obok tego kodu opisujący te nasze funkcje, klasy, metody, cokolwiek jest znacznie mniej związana niż jest TypeScript, czyli co chcę powiedzieć, że te typy, które musimy utrzymywać w JS-Docsach jest to dla mnie zdecydowanie mniej naturalne niż utrzymywanie ich w TypeScript'cie.

Zgodzić się muszę, ponieważ sam pamiętam czasy, kiedy się modyfikowały jakąś funkcję i akurat tego fragmentu jakoś o dziwo zapominało się aktualizować. Dokładnie. A tutaj w Typescript'cie rzeczywiście mamy Możemy traktować kod Typescript'owy jako swoistą dokumentację. Jakby to jest naturalne. 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 Markdownie do tego co tworzymy to prawdopodobnie nikt by tego nie pisał. No, dokładnie. Poza tym w ogóle ciekawe, jak się teraz nad tym zastanawiam, ciekawa jest właśnie ta zależność, prawda?

Pomiędzy tym, że jednak Typescript traktujemy jako kod, jako coś, co Jest nierozłączną częścią tego, co piszemy, a jednak te JS docs wydaje 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ć 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ę z boku, jako taka rzecz dodatkowa bardziej. Tylko 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ą.

Poprzez chociażby mechanizmy w Typescript'cie, jak inferencja typów, nie jesteśmy w stanie nadpisać typu, który raz został zadeklarowany. Tutaj wydaje mi się, że JSDocs będą idealnym rozwiązaniem dla osoby, która właśnie wychodzi z tego naturalnego świata front-endu, tego pierwotnego świata front-endu, jakim był JavaScript w wersji takiej dynamicznej, 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 Typescript'cie mamy ten, że tak powiem, taki strict mode, gdzie nie jesteśmy w stanie wyjść poza pewne ramy. Oczywiście mamy eny, ale to już jest trochę inna kwestia. To prawda. Zdecydowanie jest to ciekawy model i jestem ciekawy, jak utrzymywanie tego typu bibliotek rozwinie się dalej. Nie wiem, czy miałeś okazję w ogóle pisać właśnie tego typu kody, gdzie JS Docs'y 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 nadawe zwanie, ż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 Typescript'u. 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 ZOT 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, co czasami jest dysproporcjonalnie większe, same te typy i to, żeby one działały dobrze, jest

Aż zaskakująco właśnie dysproporcjonalnie większe w porównaniu do samej logiki biznesowej. Problem nie dotyczy tylko Zoda. W zasadzie każda biblioteka, 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óry 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. Więc wydaje mi się, że w tym momencie to co zrobiło Svelte w wersji piątej, czy SvelteKit odchodząc od Typescript'a, 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 JSDocsów. I napisanie tego w JS czystym, niż męczenie się, bo to tak trzeba nazwać, kombinowanie z Typescript'em na poziomie biblioteki. W samej aplikacji, którą my 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. Jestem ciekawy Twojego zdania, Mateuszu, w tym kontekście, że wiem, że Svelte jest takim dość specyficznym frameworkiem front-endowym, 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 frontendowych, 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 właśnie odejścia od Typescript'u

Jest możliwe, czy też widzisz go, czy też taka decyzja będzie podejmowana przez biblioteki, które bardziej kojarzysz sobie z JavaScript'em? Mówię tutaj o takich bibliotekach typu, nie wiem, Next, Remix, React Query, coś podobnego typu Zot, o którym wspominaliśmy. 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, czyli to odejście od Typescript'u na rzecz właśnie czystego JS i JS-Docsów, to jest ciekawy kierunek rozwoju.

Nie powiedziałbym, że wszyscy w tym kierunku pójdą, bo to na pewno tak to nie będzie wyglądało. Widać to chociażby po 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 To co się wydarzyło w 2015-2014 roku, kiedy Angular wprowadzał Typescript na rynek, inaczej wypromowywał Typescript na rynku front-endowym,

No to 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 angularem wchodząc w Typescript wymusił na użytkownikach wprowadzenie. W zasadzie stało się takim Przodownikiem pokazywał, jakie są cechy, zalety Typescript'u i dzisiaj pomimo wielu jego wad, o których sobie 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, z którymi możemy się spotkać. I wydaje mi się, że takie frameworki jak Next czy właśnie biblioteki jak Zot czy jakakolwiek inna będą dalej szły w kierunku rozwijania swojego kodu z Typescript'em, bo pomimo wszystko nawet dla deweloperów będzie to łatwiejsze.

Będzie to przyjemniejsze. Sam wiesz, jak się pisze z czystym JS-em, a jak się pisze z Typescript'em. Obaj zaczynaliśmy od czystego JS-a. Pierwsze projekty, które robiliśmy, były związane z czystym JS-em. Dopiero po czasie, zresztą obaj mamy takie doświadczenie, że weszliśmy w Angular'a jako pierwszy projekt z Typescript'em. 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 przychodząc później na Reacta, gdzie pierwszym moim językiem w Reaccie był JavaScript i dopiero po chwili dodało się do tego Typescript, Okazywało się, wow, no to ten Typescript jednak zmienia.

Jednak wprowadza pewne ułatwienia w pisaniu i pomimo tego, że wydaje się dla klasycznego front-end dewelopera czymś nienaturalnym może, to jednak po pewnym czasie każdy albo większość z nas docenia go. 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 wyrazić 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łem, że jest problematyczny i bardzo spowalnia

Proces tworzenia. Nie wiem, czy Ty też miałeś 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 zrozumiesz te plusy, które daje ten Typescript i nauczysz 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. 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 front-endu w postaci HTML, CSS, JavaScript.

Zaczynamy od wprowadzenia na przykład Reacta albo jakiegokolwiek innego frameworka, fragmentu wiedzy frontendowej z wykorzystaniem czystego JS-a. 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 pokazuje ten sam kod w JS-ie i pokazuje ten sam kod w Typescript'ie. Dla osób, tak jak wspomniałem, które mają przede wszystkim background javowy czy też backendowy 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-a, 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 tworząc kod w Javascriptie od wielu lat byliśmy trochę inaczej traktowani. Często się mówiło, że Frontend to nie programiści, a ten Javascript to do robienia animacji. A żeby tam się kręcił jakiś loaderek, to ten Javascript spokojnie wystarczy.

Te role dzisiaj przejął CSS, tak jak być powinno. Wprowadzając wiele różnych funkcjonalności, funkcji, sposobu obliczeń, takich animacji, możemy tworzyć te keyframesy 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 backendowych. No i teraz z perspektywy takiego wprowadzenia Typescript'u, czy też zmian w Javascript'cie na przestrzeni lat, Javascript zmierza w kierunku właśnie rozwijania się i też udowadniania całemu światu, że no sorry, ale my jesteśmy, 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 właśnie jak na przykład typy generyczne, no to pozwala nam właśnie, czy gardy właśnie pozwala nam 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.