W tym artykule opowiem Ci, co mnie najbardziej drażni w JavaScript i dlaczego czasem wolę stworzyć aplikację w C# z wykorzystaniem .NET oraz… Blazora, który pozwala mi uniknąć wielu bolączek związanych z JavaScriptem. Ale o tym później.
Chaos typów i osobliwe konwersje
1. Porównywanie wartości
Największa zmora? Równanie i konwersje typów. W JavaScripcie == i === to zupełnie różne światy.
== porównuje wartości z automatyczną (czasem absurdalną) konwersją.
=== sprawdza równość nie tylko wartości, ale i typu.
Przykład w JavaScript
[] == false // true
[] == ![] // trueNiby niewiele mówi, ale takie "kwiatki" naprawdę istnieją. Nic dziwnego, że tak łatwo o bugi.
Jak wygląda to w C#?
W C# nie ma takich "niespodzianek". Porównanie typów zawsze jest kontrolowane, a konwersje trzeba wykonać jawnie.
int x = 5;
string y = "5";Porównanie wymaga konwersji
bool result = x == int.Parse(y); // true Jest prosto i czytelnie: jeśli chcę porównać liczbę z ciągiem znaków, sam muszę zadbać o konwersję.
2. NaN jest liczbą
Kolejny przykład? NaN (Not a Number) w JavaScripcie… jest typu number.
• typeof NaN zwraca 'number'.
• Na dodatek NaN != NaN, więc NaN nie jest równe samemu sobie.
W C# też mamy double.NaN, ale tam działa to znacznie bardziej przewidywalnie. Nie mamy takich dziwacznych przypadków w codziennych porównaniach.
Brak ścisłego definiowania typów
JavaScript z założenia jest językiem dynamicznie typowanym. Z jednej strony daje to elastyczność, z drugiej – rodzi chaos. Możesz przypisać do zmiennej liczbę, a potem łańcuch znaków, przez co w większych projektach łatwo o pomyłkę.
W C# mamy typy statyczne, a jeśli chcemy elastyczności, możemy użyć słowa kluczowego dynamic. Ale wybór jest nasz i robimy to wtedy, gdy naprawdę ma to sens. Dzięki temu nasze aplikacje w .NET są czytelne i mniej podatne na błędy wynikające z niespodziewanych zmian typu.
Kontekst this – czyli czasem nie wiem, kim jestem
Jeśli programowałeś w JavaScripcie, wiesz, że this potrafi zależeć od sposobu wywołania funkcji, a nie od tego, gdzie ta funkcja jest zdefiniowana. Stąd te wszystkie "bindy" i "apply" w kodzie JS.
W C# this zawsze odnosi się do aktualnej instancji klasy, w której się znajdujemy. Nie ma miejsca na dziwne niespodzianki. Po prostu działa tak, jak byśmy tego oczekiwali.
Hoisting i zmienne bez deklaracji
W JavaScripcie zmienne zdefiniowane przy pomocy var podlegają "hoistingowi" – można się do nich odwoływać, zanim zostaną zadeklarowane (chociaż będą miały wartość undefined). Z kolei omyłkowe pominięcie var/let/const w deklaracji powoduje utworzenie zmiennej globalnej!
W C# albo deklarujesz zmienną, albo dostajesz błąd kompilacji. I w sumie dobrze – taka dyscyplina kodu prędzej chroni nas przed głupimi wpadkami.
Dlaczego mimo wszystko (czasem) kochamy JavaScript?
Trzeba być uczciwym:
• JavaScript jest wszędzie – w przeglądarkach, na serwerach (Node.js), w narzędziach do automatyzacji.
• Ma gigantyczny ekosystem bibliotek i frameworków.
• Daje się lubić, kiedy nauczymy się jego pułapek.
Jednak jeśli jesteś programistą C#, to pewnie nie raz zastanawiałeś się, czy da się pisać aplikacje webowe bez "czystego" JavaScriptu.
Owszem – Blazor na .NET pozwala tworzyć interaktywne SPA bez konieczności "dotykania" JS w takim stopniu, jak w tradycyjnych projektach front-endowych.
A gdyby tak… ominąć JavaScript?
Skoro nasz temat to "co mnie najbardziej wkurza w JavaScript", to nie byłbym sobą, gdybym nie wspomniał o alternatywie, która pozwala zachować front-endowy charakter aplikacji, ale w C#.
Z pomocą przychodzi Blazor – framework od Microsoftu, który umożliwia pisanie logiki front-endowej w C#. Na dodatek można uruchamiać kod w przeglądarce dzięki WebAssembly (Blazor WebAssembly) albo serwerowo (Blazor Server).
I właśnie dla osób, które chcą zredukować liczbę potencjalnie niebezpiecznych "ficzerów" JavaScriptu w swoich projektach, przygotowałem kompletne szkolenie online – "Szkoła Blazora". Znajdziesz tam praktyczne przykłady tworzenia aplikacji bez uciążliwego zmagania się z dziesiątkami dziwactw JS. Krótko mówiąc – mniej frustracji, więcej produktywności.
Podsumowanie
JavaScript – choć tak powszechny – potrafi doprowadzić dewelopera do białej gorączki swoimi paradoksami, niekonsekwencjami i nadmiarem swobody. W porównaniu do C#, gdzie mamy ściśle zdefiniowane typy i przewidywalną składnię, JavaScript może wydawać się królestwem chaosu.
Na szczęście, dla fanów .NET istnieją alternatywy, takie jak Blazor, w którym możemy wykorzystać ulubiony C# do tworzenia aplikacji webowych, ograniczając konieczność używania klasycznego JavaScriptu do minimum. Jeśli chcesz zobaczyć, jak to działa w praktyce – zachęcam do zapoznania się z kompletnym szkoleniem: "Szkoła Blazora".
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.
