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

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.

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.

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.

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

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

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.

Tak jak to się dzieje w aplikacjach frontendowych, komponentowych. Bez Typescript'u cholernie trudno jest tym zarządzać. I to w sumie, jak tak teraz o tym rozmawiamy, to jakby implementacja tego Typescript'a w Angularze, w ujce rozmawialiśmy, wydaje się być naturalnym ruchem, prawda? 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ść w PSTypescript'u, zdecydowanie wygląda ona Średnio 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 Google'a. Dokładnie. Okej, ale tutaj też warto wspomnieć o tym, co się zmienia, bo Typescript jest dla nas w tym momencie standardem, ale Microsoft, który tutaj też powiedzmy to jest twórcą tego nadzbioru dla Javascriptu,

Ten koncept mnie interesuje, bo ta propozycja wyszła od Microsoftu i ta propozycja jest przez Microsoft procesowana. Microsoft, który jak wiemy 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. Myślę, że na to szansa jest mała, szczególnie też 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ę, Mateuszu, żeby gdzieś to było blisko.

Jak już mówimy o innych językach silnie typowanych, to warto też powiedzieć coś o alternatywach dla Typescript'u. Ja znam dwie. Znam Flow i słyszałem o Hegel. Miałeś przyjemność z którymiś? Jak mówię, Flow chyba korzystałeś przy okazji Reacta z tego COO. Tak, dokładnie tak. Był to w pewnym momencie relatywnie często spotykane, prawda? Czy też często spotkanie, rozwiązanie do typowania propsów chociażby w Reaccie. Ale nie miałem jakiegoś głębszego doświadczenia, chociaż z tego co pamiętam jest to coś relatywnie podobnego do ZODA powiedzmy, czyli miejsca, w którym możemy sobie za pomocą takich zwykłych obiektów JavaScript'owych utrudniać te typy, gdzieś tam nałożyć te walidacje na ten nasz kod.

Ale nie powiedziałbym, że miałem jakieś wspaniałe doświadczenia z tego typu narzędziami. Zazwyczaj też to tarcze, które wynikało z korzystania z nich, ilość dodatkowego kodu, specyfiki pisania tego kodu, 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 wypadków bezsensowna i nigdy nie zobaczyłem w tych alternatywach niczego specjalnego, ale może ty Mateusz masz inne doświadczenie. Porównując do Typescript'u np. Hegla,

To tak naprawdę Typescript jest takim językiem, który daje nam, nie tylko wprowadza nam typy, ale dodaje też sporo innych rzeczy, jak np. nowe funkcjonalności do tworzenia klas. Daje nam pewien taki lukiek składniowy, ten 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 dostaniemy w pakiecie z Typescript'em. Natomiast Hegel to tak naprawdę jest tylko type checker, który dodaje do JavaScript'u 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ą Typescript'u 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ę z 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, no 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ę Typescript'u, no 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 już 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. Tak, ale tu w ogóle ciekawy wątek nasz zresztą nam się trochę radzi, o którym też rozmawialiśmy przy okazji Bana i Teno, czyli o łatwości wprowadzenia tego typu rozwiązań do istniejących już projektów.

I jeśli chodzi o Typescript, to przecież też mamy jak najbardziej taką opcję w kompilatorze, ale o JS, prawda? Możemy nawet jeden kliknąć w Typescript'u i teoretycznie wszystko będzie działać. Co więcej, nie musisz mieć żadnego pliku Typescript'owego i mieć Typescript w projekcie. Ale to wynika z natury języka. To jest język, który jest kompilowany czy transpilowany do JavaScript'u ostatecznie. Więc w zasadzie każdy kod JavaScript'owy będzie działał poprawnie w Typescript'ie. To brzmi trochę jak jakiś koszmar z pierwszych dni pracy. Opowiadałem na rozmowie rekrutacyjnej, że mam tekst, w który wchodzę do projektu, otwieram, to jest konflikt i wszystkie pliki przejeżdżają w sobę.

Nie wiem jak u Ciebie Mateuszu, ale ja mam wrażenie ze swojej pracy z Typescript'em, które relatywnie rzadko mi się zdarza przy narzędziach czy rzeczach dodatkowych poza kodem i powiedzmy, że Typescript 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 ja się miałem to w jakiś super specyficznych przypadkach. Zawsze miałem 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. 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 Typescript'u, 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 ja 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.