TypeScript czy JavaScript: czy typy są naprawdę potrzebne?

TypeScript stał się domyślnym wyborem w wielu nowych projektach JavaScriptowych i są ku temu rozsądne argumenty. Ale „czy dodać TypeScript” to nie pytanie, na które każdy powinien odpowiedzieć „tak”. To kompromis i warto rozumieć, co dokładnie się wymienia, zanim przeniesie się na niego cały kod.

Czym właściwie jest TypeScript

TypeScript to JavaScript z nałożonym na niego opcjonalnym systemem typów. Piszecie zwykły JavaScript, a następnie opisujecie zmienne, parametry funkcji i zwracane wartości kształtem danych, jakich się spodziewają. Kompilator sprawdza te adnotacje, zanim kod w ogóle zostanie uruchomiony, a potem je usuwa, generując czysty JavaScript, który działa wszędzie tam, gdzie działa JavaScript.

Główna idea: zamiast dowiadywać się w trakcie działania programu, że przekazaliście tekst tam, gdzie funkcja oczekiwała liczby, dowiadujecie się o tym jeszcze podczas pisania kodu – często, dzięki integracji z edytorem, zanim w ogóle zapiszecie plik.

Co faktycznie dają typy

• Wcześniej wychwycone błędy. Cała kategoria błędów – niewłaściwe typy argumentów, literówki w nazwach właściwości, nieobsłużona wartość null – zostaje wychwycona przez kompilator, a nie przez użytkownika na produkcji.
• Autouzupełnianie, które naprawdę trafia. Edytor zna dokładny kształt obiektu, więc podpowiada rzeczywiste właściwości i metody, zamiast zgadywać.
• Bezpieczniejszy refaktoring. Zmieńcie nazwę pola albo sygnaturę funkcji, a TypeScript wskaże każde miejsce, które wymaga aktualizacji – zamiast odkrywania ich po jednym przy kolejnych awariach.
• Typy jako dokumentacja. Sygnatura funkcji mówi, czego ona oczekuje i co zwraca, bez potrzeby komentarza – a w przeciwieństwie do komentarza nie może się po cichu zdezaktualizować.

Ile to kosztuje

Nic z tego nie jest za darmo. Na starcie pisze się więcej kodu – adnotacje typów, interfejsy, a przy bardziej złożonych przypadkach typy generyczne. Krzywa uczenia się jest realna, zwłaszcza przy bardziej zaawansowanych wzorcach typowania. TypeScript dodaje też do procesu pracy etap kompilacji, czyli kolejną rzecz, która może się zepsuć, i kolejną, którą muszą zrozumieć nowe osoby w zespole.

W przypadku krótkiego skryptu, szybkiego prototypu albo projektu, który za tydzień trafi do kosza, ten narzut zwykle się nie opłaca. Czysty JavaScript pozwala ruszyć szybciej i nic nie tracicie, bo nie ma czego długoterminowo chronić.

Kiedy TypeScript zarabia na siebie

Bilans odwraca się w chwili, gdy kod musi przetrwać pracę więcej niż jednego programisty albo żyć dłużej niż kilka miesięcy. Typy zamieniają niejawne założenia dotyczące danych w coś, co kompilator aktywnie sprawdza – a to ma ogromne znaczenie, gdy zespół przekroczy pewną wielkość albo projekt wyjdzie poza pierwsze tygodnie. Błąd typu wychwycony w edytorze kosztuje sekundy. Ten sam błąd znaleziony na produkcji kosztuje sesję debugowania, hotfix i być może niezadowolonego klienta.

Praktyczna odpowiedź

W przypadku wszystkiego, co zamierzacie utrzymywać, rozwijać albo przekazać innemu programiście – czyli większości prawdziwych produktów – TypeScript jest wart tej inwestycji. W przypadku naprawdę jednorazowych skryptów jest opcjonalny. W nowych projektach webowych i programistycznych domyślnie wybieramy TypeScript właśnie dlatego, że koszt błędu typu rośnie wraz z wiekiem kodu, a większość tego, co budujemy, ma działać latami, a nie tygodniami.