JavaScript to bez wątpienia jeden z najpopularniejszych języków programowania na świecie. Jest wszechobecny – każda przeglądarka internetowa go obsługuje, a ponad 95% stron w sieci korzysta z JavaScriptu po stronie klienta. Mimo to wielu programistów (zwłaszcza backendowców) ma z nim trudną relację. Z jednej strony doceniamy możliwości, jakie daje w przeglądarce, z drugiej – nieraz doprowadza nas on do szału swoimi dziwactwami. W tym artykule, opowiem dlaczego JavaScript potrafi solidnie zirytować programistów. Będzie krótko, konkretnie i na temat – bez zbędnego lania wody.
Pełen niespodzianek i pułapek
Pierwsze, co przychodzi na myśl mówiąc o „urokach” JavaScriptu, to jego nieprzewidywalne zachowania. Ten język ma trochę magicznych zasad, które początkujących przyprawiają o ból głowy, a doświadczonych potrafią zaskoczyć.
Przykłady? Proszę bardzo: operator + potrafi zarówno dodawać, jak i łączyć tekst – w zależności od kontekstu. Jeśli zsumujesz liczbę i string, JavaScript uprzejmie potraktuje wszystko jak tekst:
console.log(2 + "2"); // wynik: "22" (string, konkatenacja)Ale już odejmowanie zadziała inaczej, bo - nie jest zdefiniowany dla stringów, więc JavaScript spróbuje zamienić je na liczby:
console.log("5" - 3); // wynik: 2 (jako number, bo "5" -> 5)Efekt? Dla niewprawionych – konsternacja, dla reszty – codzienność. Podobnych pułapek jest więcej: równość podwójna vs potrójna (== vs ===), konwersje typów w locie, automatyczne wstawianie średników... To wszystko sprawia, że w JavaScript łatwo o bugi, które trudno wychwycić. Język czasem próbuje być sprytniejszy od programisty, zgadując co miał na myśli – niestety nie zawsze trafnie.
W C# czy Java takie sytuacje po prostu nie mają miejsca – kompilator od razu zatrzyma programistę przy próbie dodania liczby do napisu. W JavaScript błędny wynik zauważysz dopiero podczas uruchomienia aplikacji (albo, co gorsza, po wypuszczeniu jej na produkcję). Nic dziwnego, że JavaScript bywa nazywany językiem pełnym niespodzianek.
Dynamiczny znaczy nieprzewidywalny
JavaScript jest językiem dynamicznie typowanym, co oznacza, że nie musisz deklarować z góry, jakiego typu dane przechowujesz w zmiennej. Brzmi wygodnie – do czasu. W większych projektach brak statycznego typowania oznacza mniej kontroli i więcej pułapek. Prosty błąd literówki w nazwie zmiennej może sprawić, że zamiast wyjątku (który w C# dostałbyś od razu przy kompilacji) aplikacja JavaScript po cichu utworzy nową zmienną globalną o błędnej nazwie. W rezultacie część kodu zacznie działać inaczej lub wcale, a Ty możesz długo szukać przyczyny.
Dynamiczność oznacza też, że do jednej zmiennej możesz w trakcie działania programu przypisać różne typy danych. Łatwo wtedy o niejawne konwersje i trudne do wykrycia błędy. Programista musi być bardzo czujny i pisać masę testów jednostkowych, żeby wychwycić problemy, które przy statycznym typowaniu zostałyby wyeliminowane na starcie. Nic dziwnego, że społeczność wymyśliła rozmaite nadstawki i transpilery (np. TypeScript), które dodają statyczne typowanie do JavaScriptu. To pomaga, ale wciąż – gdzieś pod spodem czai się ten sam JavaScript ze swoimi zasadami. W praktyce używanie TypeScriptu oznacza dodatkowy krok kompilacji, a dynamiczna natura języka i tak może dać o sobie znać w momencie wykonywania kodu.
Chaotyczny ekosystem i zmienna moda
Język to jedno, ale ekosystem JavaScriptu również bywa męczący. Przede wszystkim front-end ciągle się zmienia. Co kilka lat (czasem miesięcy) pojawia się nowy framework lub biblioteka, która „rozwiązuje wszystkie problemy” – do czasu, aż wyjdzie kolejna. Programista webowy musi więc ciągle gonić trendy: Angular, React, Vue, Svelte... – lista zdaje się nie mieć końca. Do tego dochodzą narzędzia do budowania, bundlery, transpilery, menedżery paczek (NPM, Yarn, pnpm) i niezliczone wersje zależności. JavaScript potrafi przyprawić o zawrót głowy ilością wyborów i ciągłych aktualizacji.
Kolejna sprawa to zależności i modularność. Sam język historycznie miał dość ubogą bibliotekę standardową, więc społeczność open-source stworzyła tysiące pakietów rozszerzających możliwości. To świetne, dopóki... nie przestaje być. Głośna stała się historia paczki o nazwie left-pad – 11 linijek kodu do dopełniania tekstu spacjami – której autor pewnego dnia ją usunął. Okazało się, że mnóstwo innych bibliotek pośrednio z niej korzystało, przez co pół internetu przestało działać poprawnie. Pokazuje to, jak kruchy bywa ekosystem JavaScriptu, oparty na masie małych zależności. Jeden drobny pakiet, jedna zmiana wersji, i aplikacja może się wysypać. W świecie .NET raczej nie spotykamy tak skrajnych sytuacji – wiele funkcjonalności jest dostępnych “od ręki” w ramach bogatego .NETa, a zależności zewnętrzne są zwykle większe i stabilniejsze.
Oczywiście nie zrozum mnie źle – JavaScript jako taki ma też swoje plusy. Jest uniwersalny (może działać zarówno w przeglądarce, jak i na serwerze – Node.js) i dzięki ogromnej społeczności znajdziesz w nim rozwiązanie prawie każdego problemu. Ale codzienna praca z nim bywa specyficzna i jeśli ktoś przychodzi ze świata statycznie typowanego C# czy Javy, może czuć się w JavaScript jak na rollercoasterze bez zapiętych pasów.
Podsumowanie
Czy JavaScript jest faktycznie „do bani”? Prawda, jak zwykle, leży pośrodku. To język pełen wad i dziwactw, który jednak stał się fundamentem nowoczesnego webu. Ma swoje za uszami: brak typów, osobliwości składni, chaotyczny ekosystem... a jednak wciąż miliardy urządzeń na świecie uruchamiają codziennie kod JavaScriptu. Jako programiści musimy go trochę zaakceptować z dobrodziejstwem inwentarza – albo poszukać sposobów, by obchodzić jego ograniczenia.
Na szczęście dzisiejszy świat daje już alternatywy. Jeśli należysz do grona osób, które najchętniej ominęłyby JavaScript szerokim łukiem, to pewnie ucieszy Cię wiadomość, że możesz tworzyć aplikacje webowe używając wyłącznie C# i .NET, dzięki technologii Blazor. To stosunkowo nowe podejście (oparte o WebAssembly), które pozwala uruchamiać kod C# w przeglądarce, eliminując potrzebę pisania logiki w JavaScript. Sam jestem wielkim fanem tego rozwiązania. Ba, na tyle, że przygotowałem własny kurs online – Szkoła Blazora – dla programistów, którzy chcą tworzyć nowoczesny frontend w C#, bez użerania się z pułapkami JS. Jeśli brzmi to dla Ciebie ciekawie, zachęcam do sprawdzenia kursu.
Podsumowując: JavaScript bywa irytujący, zwłaszcza z perspektywy osób przyzwyczajonych do innych języków. Ma sporo braków i dziwności, ale trzeba mu oddać jedno – pozwolił na stworzenie niesamowicie interaktywnego internetu i na razie nic nie zapowiada, by miał całkiem odejść do lamusa. Warto znać jego słabości, śmiać się z nich (czasem przez łzy), a jednocześnie śledzić nowe rozwiązania, które czynią pracę z frontendem przyjemniejszą. Czy to będzie TypeScript, WebAssembly, Blazor czy cokolwiek innego – celem przecież jest pisać lepszy kod i dostarczać świetne aplikacje... bez nadmiernej frustracji. Powodzenia.
To wszystkie na dzisiaj. Jeżeli taki artykuł Ci się spodobał, to koniecznie dołącz do mojej społeczności – darmowe zapisy, gdzie będziesz również miał dostęp do dodatkowych materiałów i przede wszystkim bonusów. Do zobaczenia w kolejnym artykule.
