Narodziny i śmierć JavaScriptu

JavaScript działa w przeglądarce z niskimi uprawnieniami. Mimo to napędza serwery, narzędzia budujące i potoki (pipelines). Nie był to plan. To seria łatek nałożonych na decyzję podjętą w 1995 roku.

Zrozumienie tego, dlaczego tak się stało, zmienia sposób, w jaki projektujesz swój stos technologiczny dzisiaj.

Wystąpienie Gary'ego Bernhardta z 2014 roku nie dotyczy nostalgii. To diagnoza tarć architektonicznych. Zauważył on ironiczny łuk: JavaScript był językiem zabawkowym, który przetrwał, ponieważ miał monopol w przeglądarce. Ten monopol uczynił go najczęściej używanym językiem na świecie.

Napięcie jest proste. Przeglądarka musi uruchamiać kod bezpiecznie i szybko. Te dwa cele są ze sobą sprzeczne.

W 2014 roku zakładano, że WebAssembly zastąpi JavaScript. Tak nie do końca się stało. WebAssembly jest stabilne i przydatne w takich rzeczach jak Figma czy Google Earth. Nie zastąpiło jednak JavaScriptu jako języka aplikacji.

Zamiast tego JavaScript uległ mutacji. TypeScript, bundlery i nowe środowiska uruchomieniowe, takie jak Bun, istnieją po to, aby naprawić tarcia, które zidentyfikował Bernhardt.

Nie używaj tego wystąpienia, aby unikać nauki JavaScriptu. Nie używaj go, aby uzasadnić przesiadkę na WebAssembly bez problemów z wydajnością.

Potraktuj je jako listę kontrolną dla swojego stosu technologicznego:

TypeScript pomaga z typami w czasie kompilacji. Nie naprawia jednak luki między Twoimi typami a danymi przychodzącymi przez sieć. Nadal potrzebujesz walidacji w czasie wykonywania (runtime validation).

Najważniejsza lekcja brzmi: dowiedz się, czy Twoja technologia istnieje dzięki swojej wartości, czy dzięki monopolowi.

Nie zmieniaj swojego środowiska uruchomieniowego na podstawie prognozy z 2014 roku. Zmień je, gdy będziesz mieć zmierzone dane wskazujące na wąskie gardło.

Źródło: https://dev.to/jtorchia/the-birth-and-death-of-javascript-2014-what-still-holds-and-what-doesnt-2hae