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.

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.

Dużo naszych ID już wspiera JSDocs'a na tyle, że jest w stanie wnioskować, jaki powinien być typ przy danej zmiennej, Czy przy 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 JS-Docsów, które nam to opisują. Mi osobiście kod napisany w JDocsach 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. To samo. Może nie w PHP, ale w JS jak najbardziej. Moja przygoda z programowaniem rozpoczęła się od PHP, więc gdzieś tam rzeczywiście pierwszy backendowy kod, który widziałem, był właśnie tak opisany, udokumentowany.

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.

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.

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.

No i tutaj mamy do dyspozycji właśnie JSDocs. Jeśli chodzi o przyszłość JavaScript'u i Typescript'u, warto wspomnieć o właśnie ECMAScript Proposal, na temat właśnie tworzenia typów w JavaScript'cie. 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 Typescript'u.