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

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?

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.

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 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, np. mamy 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 chwilkę porozmawiamy.

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ę.