Dlaczego typy w JavaScript mnie nie cieszą

Kilka tygodni temu, jak grom z jasnego nieba, rozniosła się wieść, że JS w końcu będzie miał własny system typów. Zespół, którego członkowie są m.in. odpowiedzialni za tworzenie TypeScripta, przygotował dokument, proponujący wprowadzenie typowania do JavaScriptu. Środowisko rozochocone takim obrotem sprawy zaczęło świętowanie… podszyte jednak wątpliwościami. Natomiast ja, jak ten smerf maruda, mruczę pod nosem: “niecierpię typów w JavaScript”! Zapraszam do luźnego, bo urlopowego, felietonu o zmianach, które nadciągają, a które mogą nie być takie kolorowe.

Wyczekany…

Nie da się ukryć, co podkreślają twórcy proposala, że typowanie to jeden z najbardziej wyczekiwanych feature’ów JS. W dokumentacji nowej funkcjonalności pojawiają się nawet wykresy potwierdzające tę tendencję. Biorąc pod uwagę rzetelność zestawień z serii State of JavaScript, jest to imponujący wynik. Pocieszające jest również to, że opisywany przeze mnie niedawno pattern matching jest na trzeciej pozycji, tuż za wprowadzeniem Standard Library. Obie pozycje są jednak zdominowane przez statyczne typowanie, które odskakuje od konkurencji o 800 oczek. Nie jest natomiast niczym nowym fakt, że czasem bardzo chcemy czegoś, czego w zupełności nie potrzebujemy.

Nie dziwnym jest, że ktoś w końcu się nad problemem pochylił. Pochylili się ludzie znający temat. Pracujący dotychczas nad TypeScriptem. Supersetem, który daje super możliwości dosyć prostemu językowi, jakim jest JS. I o ile nadawanie innemu językowi supermocy za pomocą dodatkowego kompilatora jest efektywne i przyjemne we wdrażaniu, o tyle wprowadzanie takich zmian w istniejącym języku - języku z zaszłościami - to zupełnie inna para kaloszy.

Bo o to wdrażanie mi głównie chodzi. W chwili obecnej TypeScript jest rozwiązaniem, które ktoś może zaaplikować, a ktoś inny nie. W środowisku robi się spory rozjazd z tego powodu, bo często projekty bez TS, z miejsca są uznawane za legacy. Natomiast wprowadzenie typów ma spowodować, że takie brzydkie kaczątko zamieni się w łabędzia i problem przestanie istnieć. Wszyscy będą pisać type-strong aplikacje i zamiast przepisywać je po raz setny, po prostu je będziemy refaktorować. Oczywiście, nikt w to nie wierzy. Ta branża stoi na przepisywaniu aplikacji.

Koniec TS, jakiego znamy?

Sam przykład tego, w jaki sposób zaproponowany został pomysł z typami, pokazuje nam, jak może to wyglądać w przyszłości. Podanie. 4 zdjęcia. Dziennik podawczy. Nabranie mocy urzędowej. 5 spotkań. 4 etapy. I jest! Po pół roku, w końcu mamy nowy, generyczny Omit, do poprawnego typowania. Nie brzmi zachęcająco. Porównując to z cyklem wydawniczym TS, gdzie otrzymujemy nowe wersje z poprawkami/funkcjonalnościami co kilka tygodni, wygląda to nawet niepokojąco.

TypeScript jest biblioteką. Tak możemy go traktować, nawet pomimo swojej specyfiki. Dodając go do projektu, sami mamy kontrolę nad tym, której wersji chcemy użyć. Jeśli nie jesteśmy gotowi na pewne rozwiązania, możemy zostać przy starszej wersji i wciąż cieszyć się kompatybilnością. Jak będzie to wyglądało, gdy rozwój będzie centralnie sterowany przez TC39? Ktoś będzie musiał odpuścić i prawdopodobnie będzie to JS, który będzie musiał postawić na kompatybilność wsteczną. A ona raczej nie jest katalizatorem rozwoju.

Nie doszukałem się jednoznacznych deklaracji, żeby wprowadzenie statycznego typowania miało zakończyć rozwój TS. Biorąc jednak pod uwagę, że głównym pomysłodawcą są ludzie z ramienia Microsoftu, odpowiedzialni za TypeScript, można przypuszczać, że motywacje się zmienią. Jedna technologia automatycznie będzie konkurować z drugą, więc powstanie impas, którego rozwiązanie w długim terminie samo nasuwa się na myśl.

Czy jest na co czekać?

Tutaj dochodzimy do mojej największej obawy. Czy warto? Nie widzę realnych korzyści z tego, że w JavaScriptcie nagle pojawi się statyczne typowanie. Przynajmniej nie w tej formie. Warto zauważyć, że anotacje typów będą sprawdzane w trakcie budowania aplikacji, jednak będą traktowanie jak komentarze, gdy aplikacja będzie w runtime. Funkcjonalności znane z TS, które wpływają na kod JS (np. enumy), nie będą przedstawione w pierwszej iteracji tego proposala - właśnie ze względu na ich “komentarzowy” typ. Mało tego, type-checker będzie “external to JavaScript”. Nie będzie częścią interpretera, tylko… supersetem? Pojawia się wiele niejasności. Można odnieść wrażenie, że głównym celem tej propozycji jest ujednolicenie takich narzędzi jak TypeScript czy Flow. Czy to jest naprawdę to, za czym głosowali respondenci ankiety State of JavaScript?

Statyczne typowanie w runtime, które mogłoby rozwiązywać problemy niepewności danych IO, a w konsekwencji wyręczyć biblioteki takie jak io-ts, byłoby game-changerem, którego oczekujemy. Natomiast dostajemy nieco bardziej rozbudowaną składnię, zbliżoną do TypeScript, sprawdzaną przez zewnętrzne narzędzie. Jak na moje oko, nie brzmi to wyjątkowo solidnie.

Nie jesteśmy skazani na porażkę

Pomimo wszystkiego, co powyżej napisałem: Trzymam kciuki za twórców tego proposala, by wypracowali model, który spełni oczekiwania community. Statyczne typowanie to jest faktycznie to, czego JavaScript potrzebuje. Najlepszym tego dowodem jest ogromna popularność TS. Chcąc jednak dojść do satysfakcjonującego nas poziomu, będziemy musieli przejść przez serię dziwacznych iteracji, które na pozór niewiele wniosą, a będą jedynie podłożem dla dalszych zmian. Temat typowania nie jest nowy. W specyfikacji niewydanej nigdy EcmaScript 4, pojawiły się zapisy z tym związane. Miały zrywać z dotychczasowym JS i wprowadzić zupełnie nowy porządek bez kompatybilności wstecznej. Obawiano się, że wtedy (rok 2008) będzie to zbyt duży przełom. Teraz już wiemy, że była to zmarnowana szansa. Dzisiaj nie pozostaje nic innego, jak tylko nadrabiać te lata, próbując uzupełnić lukę.