JavaScript czy .NET - co wybrać? 5 problemów ekosystemu JS i 8 argumentów za .NET

We wrześniu 2025 roku ktoś przejął paczki npm, które łącznie były pobierane około 2 miliardów razy tygodniowo. 2 miliardy. Tygodniowo. Jeśli w złym tygodniu odpaliłeś npm install, mogłeś zainstalować sobie malware, który kradnie kryptowaluty.

I wiesz, co jest w tym najlepsze? To nie był wypadek przy pracy, tylko kolejny odcinek serialu, który leci od ponad dekady. Od 8 lat piszę w C# i .NET i uważam, że zdanie "JavaScript to chaos" to nie zaczepka, tylko teza, którą da się obronić dowodami. Spokojnie, to nie będzie narzekanie - same fakty: daty, liczby i kod.

Plan jest prosty. Najpierw 5 obszarów chaosu w ekosystemie JavaScriptu, potem 8 powodów, dla których wybrałem .NET, a na koniec pełna szczerość: kiedy .NET nie jest dobrym wyborem. Bo nie chodzi o fanbojstwo, tylko o inżynierię. I jedno zastrzeżenie na start: to nie jest hejt na programistów JavaScriptu. Znam świetnych devów JS. Porównuję ekosystemy, nie ludzi - a każdy fakt z tego artykułu możesz samodzielnie sprawdzić.

Stan danych: październik 2026. Opisane ataki na npm to incydenty z lat 2016-2025, a rozmiar node_modules czy liczby pobrań traktuj jako rzędy wielkości, nie stałe wartości. Po stronie .NET punktem odniesienia jest aktualna wersja LTS, czyli .NET 10.

Chaos #1: karuzela frameworków

Chcesz zrobić frontend w JavaScripcie? Super. Najpierw wybierz framework:

React, Angular, Vue, Svelte, SolidJS, Qwik, Astro, Next.js, Nuxt, Remix, Gatsby, Ember, Meteor, Backbone, Preact, Alpine.js, Lit, htmx...

To 18 nazw, a do tego dochodzą meta-frameworki i osobna półka bibliotek do zarządzania stanem: Redux, MobX, Zustand, Jotai. Który wybierasz? Nie spiesz się. Za 2 lata i tak pojawi się nowy.

20 lat karuzeli. Najlepiej widać to na osi czasu:

• 2006: jQuery,
• 2010: Backbone, AngularJS,
• 2013: React,
• 2014: Vue,
• 2016: Angular 2 (przepisany od zera), Next.js,
• 2019: hooki w React, Svelte 3,
• 2021: Remix, Solid,
• 2022: Astro, Qwik,
• 2023: Server Components,
• 2026: ???

Co 2-3 lata branża ogłasza nową "jedyną słuszną drogę", a wszystko, co znasz, nagle staje się legacy. Angular 2 nie był aktualizacją, tylko nowym frameworkiem - kod z AngularJS nadawał się do kosza. Sam React co kilka lat zmienia filozofię: najpierw klasy, potem hooki, teraz server components. Ta sama biblioteka, 3 różne światy. Uczysz się w kółko tego samego, a zmienia się tylko opakowanie.

JavaScript fatigue. To zjawisko ma nawet swoją nazwę: JavaScript fatigue, czyli zmęczenie JavaScriptem - ciągłą pogonią za narzędziami, które za chwilę i tak będą przestarzałe. To moment, w którym samo nadążanie za ekosystemem staje się osobnym problemem. Zatrzymaj się nad tym na chwilę: branża wymyśliła osobny termin na własny chaos. To powinno dawać do myślenia.

Chaos #2: dżungla narzędzi, czyli konfigurowanie zamiast programowania

Zanim napiszesz w JavaScripcie pierwszą linijkę kodu, podejmujesz serię decyzji:

• Runtime: Node, Deno czy Bun?
• Menedżer paczek: npm, yarn czy pnpm?
• Bundler: webpack, Vite, Rollup, esbuild, Parcel czy Turbopack?
• Transpiler: Babel, SWC czy tsc?
• Do tego: ESLint, Prettier, tsconfig, .env i pytanie, czy robisz monorepo.

Sam bundler to co najmniej 6 opcji do wyboru. Dorzuć linter, formatter i stosik plików konfiguracyjnych. To nie jest programowanie. To jest konfigurowanie.

A jak to wygląda w .NET? Tak:

dotnet new webapi

Enter. Działa. 1 komenda, zero decyzji na start, zero bundlerów i transpilerów, zero ręcznego sklejania configów. Siadasz i piszesz kod.

Start projektu w obu światach wygląda więc mniej więcej tak: w JavaScripcie masz ok. 6 decyzji, kilkanaście narzędzi do zainstalowania i 5+ plików konfiguracyjnych - i to wszystko przed pierwszą linijką kodu. W .NET: 1 komenda i 0 decyzji.

Chaos #3: node_modules - czarna dziura na Twoim dysku

Zakładasz prosty projekt frontendowy, a folder node_modules potrafi szybko urosnąć do:

• ok. 300 MB na dysku,
• ponad 30 000 plików,
• setek paczek, których nigdy nie widziałeś na oczy.

Krąży mem, że node_modules to najcięższy obiekt we wszechświecie. To mem - ale ten rząd wielkości naprawdę się zdarza.

npm w pigułce: is-odd. Mój ulubiony przykład to paczka is-odd. Sprawdza, czy liczba jest nieparzysta. W praktyce to walidacja i modulo 2, a sedno całej paczki wygląda tak:

/* node_modules/is-odd/index.js - sedno całej paczki */
return (n % 2) === 1;

Za tę jedną linijkę logiki paczka ma setki tysięcy pobrań tygodniowo. Bonus: is-odd ma własną zależność - paczkę is-number. A paczka is-even? Zależy od... is-odd. To nie jest żart, to produkcyjny ekosystem. Witaj w świecie mikropaczek, w którym jedna paczka ciągnie za sobą kolejną, a Ty masz w projekcie setki zależności napisanych przez obcych ludzi.

Chaos #4: ruletka zależności, czyli ataki na npm

Do tej pory było trochę śmiesznie. Tu przestaje być śmiesznie, bo każda z tych setek zależności to cudzy kod, który uruchamiasz u siebie.

2016: left-pad. Programista w proteście usuwa z npm swoją paczkę left-pad - 11 linijek kodu, które dopełniały tekst spacjami. Efekt? Tysiące projektów nie mogły się zbudować, łącznie z Babelem i Reactem. 11 linijek zatrzymało spory kawałek JS-owego świata.

2018: event-stream. Popularna paczka event-stream zostaje przejęta przez "pomocnego" nowego opiekuna, który dokleja do niej kod celujący w użytkowników portfela Copay i ich bitcoiny. Paczka zdążyła mieć miliony pobrań, zanim ktokolwiek to zauważył.

2022: colors.js i faker.js. Autor tych bibliotek celowo psuje własne paczki i wpuszcza nieskończoną pętlę do tysięcy projektów na całym świecie. Zrobił to w proteście - ale Twoje CI tego nie wiedziało.

To nie są pojedyncze incydenty. To wzorzec.

Wrzesień 2025: rekord wszech czasów. Wystarczył phishing na konto jednego maintainera. Przejęte zostały m.in. paczki chalk i debug, pobierane łącznie około 2 miliardów razy tygodniowo. Zainfekowane wersje zawierały malware, który podmieniał adresy portfeli kryptowalut. Tydzień później pojawił się robak Shai-Hulud: kradł tokeny i sam publikował kolejne zainfekowane wersje paczek. Zainfekował ponad 500 paczek i był pierwszym samopowielającym się atakiem na npm.

Wszystko to sprowadza się do jednego zdania:

"npm install to w praktyce umowa: uruchamiam na swoim komputerze kod setek obcych ludzi i ufam, że żaden z nich nie miał dziś złego dnia."

Chaos #5: sam język (i TypeScript)

Ostatni obszar chaosu to sam JavaScript. Kilka słynnych "ficzerów":

[] + []       /* "" */
typeof NaN    /* "number" */
typeof null   /* "object" - bug z 1995 r. */
"11" + 1      /* "111" */
"11" - 1      /* 10 */

Pusta tablica plus pusta tablica? Pusty string. typeof NaN? "number" - "to-nie-liczba" jest liczbą. typeof null? "object" - to bug z 1995 roku, którego nie da się naprawić, bo poprawka zepsułaby internet. String "11" plus 1? "111". Minus 1? 10.

Każda z tych linijek przechodzi bez błędu i wybucha dopiero na produkcji. W tutorialu to śmieszne, na produkcji kosztowne. To nie są ciekawostki na rozmowę kwalifikacyjną, tylko miny na produkcji.

Jeden typ liczbowy. W JavaScripcie domyślny typ liczbowy to Number, czyli 64-bitowy float. Nie ma osobnego inta. Nie ma decimala. Jest BigInt, ale nie zastępuje decimala do pieniędzy - a bez decimala przy kwotach robi się ślisko. W C# masz int, long, double i decimal, a decimal dobrze nadaje się właśnie do pieniędzy. Każdy typ do swojej roboty.

TypeScript - przyznanie się branży do winy. Najlepszym dowodem na problemy JavaScriptu jest... TypeScript. Duża część branży przyznała, że bez typów trudno to skalować, i w dużych projektach sięga właśnie po TypeScript. Tyle że TypeScript to plaster, nie lekarstwo:

• Typy znikają w runtime. To kostium, nie zbroja - w środku i tak działa czysty JavaScript.

• Dochodzi kolejna warstwa. Kompilacja do JS i jeszcze jeden plik konfiguracyjny (tsconfig).

Kto stał za TypeScriptem? I teraz moje ulubione pytanie: kto był głównym architektem TypeScriptu? Anders Hejlsberg - człowiek od C#. C# to rok 2000, TypeScript - 2012. Przeczytaj to jeszcze raz: człowiek od C# pomagał naprawiać największy ból JavaScriptu. Nie mam nic do dodania.

Chaos w pigułce. Podsumujmy pierwszą część:

1. Karuzela frameworków.
2. Dżungla narzędzi.
3. node_modules bez dna.
4. Ruletka zależności.
5. Język pełen min.

To codzienne środowisko pracy milionów programistów. Da się inaczej.

Dlaczego .NET? Powód #1: jeden spójny stack

No dobra. To dlaczego .NET? Poniżej 8 powodów, zero marketingu.

Pierwszy to jeden spójny stack:

• 1 język: C#,
• 1 narzędzie: dotnet CLI,
• 1 menedżer paczek: NuGet,
• 1 framework webowy: ASP.NET Core,
• 1 główny ORM: Entity Framework Core.

Najważniejsze decyzje są już podjęte, a Ty skupiasz się na budowaniu. Tak wygląda start projektu:

dotnet new webapi -n MojeApi
cd MojeApi
dotnet run

/* info: Now listening on: http://localhost:5000 */

3 komendy i masz 1 działające API, bez ani jednego pliku konfiguracyjnego do ręcznego sklejania. Bez bundlera, bez transpilera, bez 10 configów.

Powód #2: typowanie, które naprawdę działa

W C# błędy łapiesz przy kompilacji, a nie na produkcji o 3:00 w nocy. Kompilator to Twój pierwszy code reviewer: darmowy, nieprzekupny i pracuje 24/7.

Zobacz różnicę na zwykłej literówce. Najpierw JavaScript:

const user = { name: "Jan" };
console.log(user.nmae.length);

/* TypeError: Cannot read properties of undefined
   → w runtime, u klienta */

user.nmae to undefined, które leci dalej i wybucha gdzieś u klienta jako TypeError. Ta sama literówka w C#:

var user = new User { Name = "Jan" };
Console.WriteLine(user.Nmae.Length);

/* CS1061: 'User' nie zawiera definicji "Nmae"
   → kod się nie skompiluje */

Kod się nawet nie skompiluje, a czerwone podkreślenie widzisz w edytorze, zanim zapiszesz plik. To jest różnica między "znajdę błąd za tydzień" a "znajdę błąd za sekundę".

Powód #3: baterie w zestawie

Rzeczy, po które w JavaScripcie sięgasz do npm, w .NET są wbudowane w platformę i rozwijane przez Microsoft:

• JSON,
• klient HTTP,
• LINQ,
• dependency injection,
• logowanie,
• konfiguracja,
• kryptografia,
• testy.

I dużo więcej. Nie potrzebujesz lodasha, axiosa, dotenva i 15 innych paczek, żeby w ogóle zacząć.

LINQ - perełka od 2007 roku. Filtrowanie, sortowanie i top 10 - czytelnie, w jednym łańcuchu:

var top = users
    .Where(u => u.IsActive)
    .OrderByDescending(u => u.Points)
    .Take(10)
    .ToList();

LINQ jest w C# od 2007 roku i wygląda dziś tak samo. Umiejętność sprzed 19 lat jest wciąż aktualna i wciąż należy do rdzenia platformy. Pokaż mi coś takiego w świecie JS.

Bonus: async/await. Zresztą działa to też w drugą stronę. Async/await, czyli dziś standardowy sposób na czytelny kod asynchroniczny, C# miał już w 2012 roku (C# 5.0). JavaScript dodał go w 2017 (ES2017). Ten mechanizm trafił do JS 5 lat później.

Powód #4: wydajność - benchmarki, nie opinie

• TechEmpower. W niezależnych benchmarkach frameworków webowych TechEmpower ASP.NET Core od lat osiąga bardzo wysokie wyniki.

• Wielokrotnie szybszy niż Node + Express. W wybranych testach, zwłaszcza plaintext i JSON, ASP.NET Core potrafi być wielokrotnie szybszy od Node z Expressem.

• Każda wersja szybsza od poprzedniej. Microsoft co roku publikuje długi raport z optymalizacji, które weszły do nowej wersji .NET (seria "Performance Improvements in .NET" na blogu .NET).

Szybkość masz w standardzie.

Powód #5: przewidywalność

W .NET znasz przyszłość na lata do przodu:

• Nowa wersja co roku w listopadzie. Harmonogram jest znany z wyprzedzeniem.

• Wersje parzyste to LTS, czyli 3 lata wsparcia. .NET 8, .NET 10... wybierasz i masz spokój.

• Prosta migracja. Przejście z .NET 8 na .NET 10 w wielu projektach zaczyna się od zmiany 1 linijki w pliku projektu (.csproj) - z net8.0 na net10.0:

<TargetFramework>net10.0</TargetFramework>

Dla porównania: w świecie JS "migracja" potrafi oznaczać pół przebudowy aplikacji.

Powód #6: jeden język do wszystkiego

Uczysz się C# raz, a drzwi otwierają się wszędzie:

• Web API: ASP.NET Core,
• frontend: Blazor,
• desktop: WPF, WinUI,
• mobile: MAUI,
• gry: Unity, Godot,
• chmura: Azure, AWS,
• AI: ML.NET, Semantic Kernel,
• IoT: Raspberry Pi.

1 język, 8 obszarów. Uczysz się C# raz - używasz wszędzie.

Powód #7: rynek pracy

.NET to banki, fintechy, ubezpieczenia, logistyka, medycyna i e-commerce. Systemy, które zarabiają prawdziwe pieniądze i mają działać latami, a więc długie, stabilne projekty. Mniej hype'u na Twitterze, więcej stabilnej pracy.

Nudne? Może. Nudne jak regularny przelew na konto i spokojnie spłacane raty.

Powód #8: nowoczesny C#

Jeśli kojarzysz C# z korporacyjną Javą z 2005 roku, spójrz na to. Całe działające Web API w kilku linijkach:

var app = WebApplication.Create(args);

app.MapGet("/", () => "Hello z .NET!");
app.MapGet("/users/{id}", (int id) => new { id });

app.Run();

Zero ceremonii. Do tego rekordy, pattern matching, minimal APIs i top-level statements. To język rozwijany szybko, ale z głową - bez wywracania stołu co 2 lata.

Mit: ".NET = płatne, Windows i korpo". Przy okazji rozprawmy się z najpopularniejszym mitem. Dzisiejszy .NET to:

• open source (licencja MIT) - cały kod platformy jest na GitHubie,
• darmowy - język, runtime i SDK kosztują 0 zł,
• cross-platform - Linux, macOS i Windows, w pełni od 2016 roku,
• Docker i Kubernetes - produkcyjny standard w chmurze.

Produkcyjne API w .NET na Linuksie to dziś norma, nie egzotyka.

Szczerze: kiedy .NET nie jest najlepszym wyborem

Obiecałem łyżkę dziegciu, więc teraz pełna szczerość. Są obszary, w których JavaScript wygrywa, i trzeba to uczciwie przyznać:

• Frontend w przeglądarce. To jego królestwo. Blazor istnieje i jest fajny, ale to wciąż nisza.

• Gigantyczny ekosystem. Paczka na wszystko i błyskawiczne innowacje.

• Szybki efekt "wow". U początkującego pierwszy efekt przychodzi szybciej - pierwszy interaktywny projekt można mieć w godzinę.

• Prototypy. Jeden język na froncie i backendzie ma tu sens.

To są uczciwe punkty i warto je mieć z tyłu głowy.

To nie jest wojna "albo-albo". Prawda jest taka, że nie musisz wybierać jednego obozu na zawsze. Solidny backend w C# + podstawy TypeScriptu na froncie = komplet, na który rynek pracy patrzy bardzo łaskawie.

Bieżnia czy procent składany? Jeśli jednak pytasz, na czym budować karierę, spójrz na to tak:

• Ekosystem JS to bieżnia. Ciągle dochodzą nowe narzędzia, praktyki i warstwy, część z nich szybko się starzeje i łatwo utknąć w samej pogoni.

• .NET to procent składany. Umiejętności się kumulują, a wiedza z czasem zyskuje na wartości. LINQ z 2007 roku to nadal podstawa.

Od czego zacząć naukę .NET? Ścieżka w 5 krokach

Jeśli chcesz spróbować, oto konkretna kolejność:

1. Podstawy C#.
2. Programowanie obiektowe i LINQ.
3. ASP.NET Core i pierwsze Web API.
4. Entity Framework Core i baza danych SQL.
5. Własny projekt do portfolio.

Tyle. Każdy krok to działający kod, a nie sama teoria. Nie potrzebujesz 15 kursów naraz - potrzebujesz kolejności.

JavaScript vs .NET - ściąga

Całe porównanie w jednej tabeli:

Podsumowanie

JavaScript to chaos - i da się to pokazać na faktach:

• 5 obszarów chaosu: karuzela frameworków, dżungla narzędzi, node_modules bez dna, ruletka zależności (od left-pad po Shai-Hulud) i język pełen min.

• 8 powodów za .NET: spójny stack, typowanie, baterie w zestawie, wydajność, przewidywalność, jeden język do wszystkiego, stabilny rynek pracy i nowoczesny C#.

• Uczciwie: frontend w przeglądarce to królestwo JavaScriptu, a bardzo mocny zestaw na rynku pracy to backend w C# plus podstawy TypeScriptu.

• Ścieżka nauki: C# → OOP i LINQ → ASP.NET Core → EF Core i SQL → projekt do portfolio.

Czy JavaScript zniknie? Nie. Czy masz go nienawidzić? Też nie. Ale jeśli budujesz karierę na lata i chcesz, żeby Twoje umiejętności zyskiwały na wartości, zamiast szybko się przeterminowywać, .NET to wybór, którego ja nie żałuję ani jednego dnia. JavaScript to chaos. .NET to spokój. A spokój w programowaniu to nie nuda - to przewaga.

Jeśli chcesz iść tą drogą ze mną, dołącz do mojej społeczności .NET - jest nas już ponad 10 000 programistów. Raz w tygodniu wysyłam jednego maila: najważniejsze newsy ze świata .NET, konkretne porady i rabaty na moje kursy, których nie ma nigdzie indziej. Zero spamu, sama treść - a wypisujesz się jednym kliknięciem.

Wystarczy, że zostawisz swój adres tutaj: modestprogrammer.pl/vip. Do zobaczenia w środku :)