Blazor czy React? Twarde dane, .NET 8 i .NET 10, polski rynek i kiedy co wybrać

"Do 2027 roku Blazor wyprze Reacta w polskich firmach." Mocna teza, wiem. Taka, przy której jedni od razu kiwają głową, a drudzy sięgają po klawiaturę, żeby napisać, że to bzdura. Dlatego nie będę jej bronił opiniami. Zamiast tego przejdziemy przez twarde dane: ankiety Stack Overflow, liczbę wdrożeń, polski rynek pracy i konkretne zmiany, które przyniosły .NET 8 i .NET 10.

Od razu uprzedzam: werdykt nie jest tak prosty, jak sugeruje sama teza. Plan jest więc następujący. Najpierw twarde dane, bo bez nich to byłby tylko clickbait. Potem pokażę, gdzie Blazor już dziś ma przewagę i dlaczego akurat tam. Uczciwie powiem też, gdzie React nadal jest bezpieczniejszym wyborem i czego Blazor do 2027 roku nie przeskoczy. A na końcu dostaniesz konkretny plan: co z tą wiedzą zrobić, niezależnie od tego, czy piszesz w C#, czy w JavaScripcie.

Stan danych: październik 2026. Dane o popularności frameworków pochodzą z ankiety Stack Overflow Developer Survey 2025, liczba wdrożeń z zestawienia BuiltWith (za Leobit) ze stycznia 2026, a dane o polskim rynku pracy z raportu No Fluff Jobs × HSBC "Rynek pracy IT 2025/2026". Po stronie .NET punktem odniesienia jest .NET 10, wydany w listopadzie 2025 roku.

Czym jest Blazor? 30 sekund teorii

Krótko, dla tych, którzy dopiero poznają temat. Blazor to framework webowy od Microsoftu i oficjalna część ASP.NET Core - nie eksperyment społeczności, tylko pełnoprawny element platformy. Frontend piszesz w nim w C#, a nie w JavaScripcie: komponenty, routing i formularze powstają bez JavaScriptu jako podstawy.

Blazor ma 2 tryby działania:

• WebAssembly. Kod C# działa bezpośrednio w przeglądarce.

• Server. Kod działa na serwerze, a interfejs aktualizuje się w przeglądarce przez połączenie SignalR.

W obu przypadkach to jedna platforma: te same narzędzia, NuGet i Visual Studio, które już znasz. Tak, C# w przeglądarce. Serio.

Jeden język, jeden zespół. I tu jest sedno całej dyskusji. W klasycznym stacku masz 2 światy: React z TypeScriptem z przodu i C# z .NET z tyłu. 2 buildy, 2 zestawy narzędzi, często 2 różne profile ludzi w zespole. W Blazorze frontend i backend to ten sam język. Wspólne mogą być modele, walidacja i logika, a ten sam model danych (DTO) może działać po obu stronach. Mniej przepisywania klas i mniej ręcznego pilnowania, żeby API się nie rozjechało.

Zobacz, jak to wygląda w praktyce. Klasa DTO razem z regułami walidacji leży w projekcie współdzielonym:

using System.ComponentModel.DataAnnotations;

/* Projekt współdzielony - ta sama klasa dla API i dla frontendu */
public class ProduktDto
{
    public int Id { get; set; }

    [Required, StringLength(100)]
    public string Nazwa { get; set; } = "";

    [Range(0.01, 1000000)]
    public decimal Cena { get; set; }
}

Tę klasę przyjmuje backend (kontroler z atrybutem [ApiController] sam sprawdzi reguły walidacji i odrzuci błędne żądanie), a w przeglądarce ta sama klasa obsługuje formularz w komponencie Blazora:

@inject HttpClient Http

<EditForm Model="produkt" OnValidSubmit="Zapisz">
    <DataAnnotationsValidator />
    <InputText @bind-Value="produkt.Nazwa" />
    <InputNumber @bind-Value="produkt.Cena" />
    <ValidationSummary />
    <button type="submit">Zapisz</button>
</EditForm>

@code {
    private ProduktDto produkt = new();

    private async Task Zapisz() =>
        await Http.PostAsJsonAsync("api/produkty", produkt);
}

Te same atrybuty [Required] i [Range] działają w formularzu i na serwerze. W stacku z Reactem ten model zwykle istnieje 2 razy: jako klasa w C# i jako typ w TypeScripcie (przepisany ręcznie albo wygenerowany), a reguły walidacji trzeba powtórzyć po stronie frontendu. Każda zmiana to 2 miejsca do poprawienia i 2 miejsca, w których można się pomylić.

Komponent = HTML + C#. Tak wygląda prosty komponent Blazora - licznik w pliku Licznik.razor:

<h3>Licznik: @count</h3>
<button @onclick="Increment">Kliknij</button>

@code {
    private int count = 0;
    private void Increment() => count++;
}

HTML i C# w jednym pliku. Stan to zwykłe pole w klasie, a obsługa kliknięcia to zwykła metoda. Bez npm i webpacka - build robi dotnet, jak zawsze. Bez hooków i reducerów. Do tego znajome IDE: IntelliSense, debugger i breakpointy. Dla kogoś, kto zna C#, to jest cała "bariera wejścia" - i jest po prostu dużo niższa niż przy nauce Reacta od zera.

Krótka historia: Blazor dorósł szybciej, niż myślisz. Historia ma tu znaczenie, bo pokazuje, czy to technologia, na której warto budować:

• 2018: eksperyment pokazywany na konferencjach,
• 2019: Blazor Server trafia na produkcję (razem z .NET Core 3.0),
• 2020: Blazor WebAssembly,
• 2023: .NET 8 - SSR, tryby renderowania i wielkie sprzątanie,
• 2025: .NET 10 - dojrzała platforma.

7 lat konsekwentnego rozwoju. To już nie jest ciekawostka z konferencji, tylko dojrzały produkt.

Problem, który firmy chcą rozwiązać

Dlaczego firmy w ogóle patrzą w stronę Blazora? Nie z miłości do C#, tylko z powodu kosztów. Klasyczny podział na frontend w React i backend w .NET generuje 4 konkretne problemy:

• 2 zespoły = podwójne koszty. 2 rekrutacje, 2 pensje, 2 plany rozwoju.

• Handoff między frontem a backendem. Ustalenia, kontrakty API, spotkania i czekanie na siebie nawzajem.

• 1 zmiana, 2 repozytoria. Nowe pole w modelu danych? Poprawiasz backend i frontend osobno.

• 2 stacki do utrzymania. Podwójne aktualizacje, zależności i łatki bezpieczeństwa.

Dlatego na ten temat warto patrzeć z właściwej perspektywy: to nie jest wojna frameworków, tylko arkusz kalkulacyjny CFO. Decyzja o stacku w firmie rzadko zapada na podstawie tego, który framework jest fajniejszy. Zapada na podstawie tego, ile będzie kosztować zbudowanie i utrzymanie aplikacji przez kolejne lata.

Twarde dane: Stack Overflow i liczba wdrożeń

Stack Overflow: Blazor rośnie co roku. Zacznijmy od ankiety Stack Overflow Developer Survey. Użycie Blazora wśród developerów wzrosło z 4,46% w 2022 roku do 7% w 2025. To +57% w 3 lata i 7. miejsce wśród frameworków frontendowych na świecie.

Powoli? Tak. Ale konsekwentnie w jedną stronę. Dla porównania React w tym samym czasie utrzymuje się stabilnie na poziomie ok. 40-45% - do tego jeszcze wrócę.

Wdrożenia: produkcja, nie eksperymenty. Ankiety mówią, czego ludzie używają. Jeszcze ciekawsze jest jednak to, co faktycznie działa na produkcji. Według zestawienia BuiltWith, przywoływanego przez firmę Leobit, liczba stron internetowych działających na Blazorze wzrosła z 10 097 pod koniec 2021 roku do 32 384 w styczniu 2026. To ponad 3 razy więcej w około 4 lata.

W publicznych zestawieniach użytkowników Blazora pojawiają się też znane marki, m.in. Ferrari, lotnisko we Frankfurcie i Celonis. To są sygnały produkcyjnej adopcji, a nie tylko eksperymentów po godzinach.

React nie umiera. Ani trochę

Obiecałem uczciwość, więc teraz druga strona. React nie umiera. Ani trochę. Według Stack Overflow Developer Survey 2025 używa go około 45% developerów na świecie. Do tego React ma 3 atuty, których Blazor długo nie dogoni:

• Największy ekosystem npm. Biblioteka na każdy problem - dziś i za darmo.

• Next.js jako standard w B2C. SEO, edge, ISR - dojrzałe wzorce produkcyjne.

• Ogromny talent pool. Frontendowców od Reacta jest na rynku najwięcej: najłatwiej ich zrekrutować i najłatwiej zastąpić.

Kto twierdzi, że React umiera, ten po prostu nie patrzy w dane.

Skala? Nadal przepaść. Zderzmy te liczby: ok. 45% kontra 7%. To przepaść i nie ma sensu udawać, że jest inaczej. Skąd więc w ogóle teza o wypieraniu Reacta? Stąd, że globalne statystyki to nie to samo, co polskie firmy. Żeby zobaczyć, co się naprawdę dzieje, trzeba zejść poziom niżej.

Skąd więc ta teza? Trend, polski rynek i .NET w firmach

Po pierwsze: kierunek. React od 2021 roku stoi mniej więcej w miejscu, na poziomie ok. 40-45%. To dojrzały, nasycony rynek - faza plateau. Blazor rośnie rok do roku, z 4,46% do 7%. Z niskiej bazy, więc ma przed sobą dużo miejsca - to faza wzrostu. Rynki rzadko zmieniają się skokiem. Zmieniają się trendem. A tu trend widać gołym okiem: kierunek jest ważniejszy niż obecna pozycja.

Po drugie: polski rynek odbił. Według raportu No Fluff Jobs × HSBC "Rynek pracy IT 2025/2026" rok 2025 przyniósł 44% więcej ofert pracy w IT niż rok wcześniej. Pracodawcy publikowali średnio 17 ogłoszeń, a rok wcześniej 10. Firmy znów częściej szukają ludzi i ruszają z nowymi projektami. A za każdym nowym projektem stoi decyzja: jaki stack i jaki zespół. Dokładnie przy takich decyzjach Blazor wchodzi do gry.

Po trzecie: w Polsce jest dużo .NET-u. Wystarczy spojrzeć na branże, w których C# jest u nas mocno obecny:

• banki i finanse - core systems, obsługa klienta,
• ubezpieczenia - polisy, likwidacja szkód,
• logistyka i produkcja - WMS, planowanie, integracje,
• medycyna - systemy HIS, rejestracje,
• sektor publiczny - e-usługi, rejestry,
• software house'y - projekty dla całej Europy.

Tysiące zespołów C# już istnieją. To jest paliwo tej zmiany: nie trzeba budować wszystkiego od zera, wystarczy dać tym zespołom narzędzie do frontendu.

Główne pole bitwy: aplikacje wewnętrzne

I tu dochodzimy do miejsca, w którym rozstrzyga się cała teza. Ogromna część oprogramowania w firmach nigdy nie trafia do klienta ani do publicznego internetu. To:

• panele administracyjne,
• CRM-y i systemy wewnętrzne,
• dashboardy i raporty,
• narzędzia back-office,
• intranety i portale pracowników.

W takich projektach nie ma walki o SEO, milionów użytkowników ani wojen o 50 KB bundle'a. Jest za to deadline, budżet i zespół, który już masz. A to zupełnie zmienia kryteria wyboru technologii.

Scenariusz z życia. Poniedziałek, firma .NET, ktoś mówi: "potrzebujemy panelu admina". Są 2 opcje:

• Opcja A: React. Czyli rekrutacja frontendowca - 2-3 miesiące procesu - albo drożej: software house. Do tego nowy stack w firmie: build, deploy i utrzymanie kolejnego ekosystemu na lata.

• Opcja B: Blazor. Obecny zespół startuje praktycznie od razu: ci sami ludzie, to samo repozytorium, ten sam pipeline. Komponenty (grid, formularze, wykresy) bierze z półki.

I nagle rozmowa nie jest o frameworku, tylko o budżecie i deadline'ie.

Policzmy jak firma. Weźmy przykładową strukturę zespołu dla tej samej funkcjonalności (skala oczywiście zależy od projektu):

Mniej ról do zgrania, mniej handoffów, krótszy czas do wdrożenia. Dokładnie to słyszy zarząd - i dlatego ta dyskusja toczy się w budżetach, a nie w komentarzach o wyższości jednego frameworka nad drugim.

.NET 8 naprawił Blazora

"Ale Blazor był wolny i słaby pod SEO!" To prawda, był z tym problem. Do .NET 8. W listopadzie 2023 roku przyszedł pierwszy przełom, który wprowadził 4 kluczowe zmiany:

• Statyczny server-side rendering (SSR). Strona renderuje się jak z klasycznego serwera, więc SEO przestaje być domyślną blokadą.

• Streaming rendering. Treść płynie do przeglądarki, zanim skończą się zapytania, więc może pojawić się wcześniej.

• Tryb renderowania per komponent. Server, WebAssembly albo czysty HTML - wybierasz punktowo.

• Tryb Auto. Start z serwera, potem WebAssembly w tle. Najlepsze z 2 światów.

Tryb renderowania ustawiasz dosłownie na poziomie pojedynczego komponentu:

@page "/panel"

<h1>Panel sprzedaży</h1>

<Licznik @rendermode="InteractiveServer" />
<Wykres @rendermode="InteractiveAuto" />
<Stopka />

Strona i stopka renderują się statycznie jako zwykły HTML, licznik działa interaktywnie na serwerze, a wykres w trybie Auto. Interaktywność dokładasz tylko tam, gdzie jest naprawdę potrzebna. Dzięki temu kilka największych zarzutów wobec Blazora z lat 2020-2022 jest dziś dużo słabszych.

Jak działa tryb Auto? W 3 krokach:

1. Pierwsze wejście. Komponent renderuje serwer, bez czekania na pobranie WebAssembly.

2. W tle. Przeglądarka ściąga runtime WebAssembly i pliki aplikacji.

3. Kolejne wejścia. Komponenty mogą działać już lokalnie w przeglądarce, co zmniejsza obciążenie serwera.

Użytkownik nie widzi tej mechaniki. Widzi aplikację, która po prostu startuje szybciej.

.NET 10: Blazor na sterydach

Drugi przełom przyszedł w listopadzie 2025 roku razem z .NET 10. Najważniejsze nowości dla Blazora:

• Lżejszy główny skrypt. Plik blazor.web.js może być mniejszy nawet o ok. 76%, a mniejszy skrypt to szybszy start aplikacji.

• ResourcePreloader. Zasoby mogą pobierać się wcześniej i równolegle.

• Hot Reload w WebAssembly. Zapisujesz plik, a przeglądarka się aktualizuje - development bliższy temu, co znasz ze świata JavaScriptu.

• Passkeys w szablonie. Logowanie bez haseł od pierwszego dnia projektu.

• Wznawianie sesji (circuit persistence). Zerwane połączenie nie kasuje pracy użytkownika.

2 duże wydania z rzędu, które celują dokładnie w największe bolączki frameworka. Microsoft naprawdę w to inwestuje.

Ekosystem: nie budujesz UI od zera

Framework to jedno, a gotowe komponenty to drugie. W aplikacjach biznesowych nikt nie chce pisać od zera gridu z filtrowaniem. Na szczęście nie musi:

• MudBlazor. Open source, Material Design, ulubieniec społeczności.

• Radzen Blazor. Ponad 90 darmowych komponentów i generator aplikacji.

• Telerik UI for Blazor. Komercyjny standard w enterprise, z pełnym wsparciem.

• Syncfusion. Ogromna biblioteka: gridy, wykresy, edytory, PDF.

Grid z filtrowaniem, wykresy i formularze często masz w godzinę, a nie w tydzień. A to mocno zmienia matematykę projektu - zwłaszcza w aplikacjach wewnętrznych, które w dużej mierze składają się właśnie z tabel i formularzy.

Gdzie React nadal miażdży

Teraz druga strona medalu. Są obszary, w których React nadal wyraźnie wygrywa:

• Publiczne aplikacje B2C. Miliony użytkowników, a liczy się każdy kilobajt i każda milisekunda.

• Ekosystem npm. Biblioteka na wszystko: mapy, animacje, edytory, płatności.

• Next.js i SEO. Dojrzałe wzorce (SSG, ISR, edge) sprawdzone na wielką skalę.

• Talent pool. Frontendowców Reacta jest po prostu wielokrotnie więcej.

• Startupy i MVP. Szybko, tanio, łatwo znaleźć ludzi - i łatwo ich wymienić.

Tu Blazor nie wygra do 2027 roku. I pewnie długo później też nie.

Kiedy Blazor, a kiedy React? Ściąga

Wszystko powyższe da się zamknąć w prostej ściądze, która przyda się przy następnej dyskusji o stacku w Twoim zespole:

Proste. Jeśli w Twoim projekcie przeważają punkty z lewej kolumny, Blazor jest poważnym kandydatem. Jeśli z prawej - React nadal będzie bezpieczniejszym wyborem.

Słabości Blazora

Żeby nie było, że sprzedaję bajkę - Blazor ma też konkretne słabości:

• Ekosystem mniejszy niż npm. Nietypową kontrolkę czasem napiszesz sam.

• Pierwsze ładowanie WebAssembly. Po .NET 10 jest dużo lepiej, ale na słabym łączu wciąż może być zauważalne.

• Mało seniorów Blazora. C#-owców jest mnóstwo, ale ludzi z 5-letnim doświadczeniem w Blazorze - niewielu.

• JS interop bywa potrzebny. Od JavaScriptu nie uciekniesz w 100%, czasem trzeba zbudować mostek.

Znasz wady - podejmujesz decyzję biznesową, a nie akt wiary.

Werdykt: czy Blazor wyprze Reacta?

Czas odpowiedzieć na pytanie z początku. Czy Blazor wyprze Reacta?

Globalnie i w publicznym B2C - nie. React zostaje liderem. Kropka.

W aplikacjach wewnętrznych polskich firm .NET - tak. Tu Blazor ma realną szansę wypierać Reacta projekt po projekcie i stawać się domyślnym wyborem.

Teza o "wypieraniu Reacta" to więc skrót myślowy. W rzeczywistości jest o niszy - tyle że ta nisza to tysiące projektów.

Moje 3 zakłady na 2027. Żeby nie skończyć na ogólnikach, stawiam 3 konkretne prognozy:

1. Blazor domyślny "wewnątrz". W firmach .NET przy nowym wewnętrznym projekcie Blazor będzie naturalnym kandydatem, a to React trzeba będzie mocniej uzasadnić - nie odwrotnie.

2. Blazor wprost w ogłoszeniach. W ofertach "Fullstack .NET" coraz częściej pojawi się Blazor zamiast "dowolnego frameworka JS".

3. React dalej numerem 1 globalnie. I to jest w porządku. Mówimy o niszy - wielkiej, ale niszy.

Zapisz sobie ten artykuł. W 2027 roku wrócimy do tych zakładów i rozliczymy każdy punkt.

Co z tym zrobić? Plan dla .NET developera i frontendowca

Jesteś .NET developerem? Masz najprostszą sytuację. 3 kroki:

1. Ucz się Blazora teraz. To najtańsza droga do "fullstacka" w CV, bo zostajesz w swoim ekosystemie.

2. Zbuduj 1 konkretny projekt. Panel z CRUD-em, logowaniem i wykresem. Tyle wystarczy, żeby mieć o czym opowiadać na rozmowie rekrutacyjnej.

3. Zaproponuj Blazora w pracy. Wewnętrzne narzędzie w obecnej firmie to idealny, bezpieczny poligon - i gotowy case do portfolio.

Rynek płaci za ludzi, którzy domykają całość - od bazy danych po UI.

Jesteś frontendowcem? Tu też 3 rzeczy:

1. Bez paniki. React z TypeScriptem to nadal najbezpieczniejszy zestaw na rynku pracy.

2. Ale obserwuj. Zwłaszcza jeśli pracujesz w firmie .NET - Blazor może wejść do Twojego zespołu szybciej, niż myślisz.

3. Idź w stronę produktu. API, dane, autoryzacja. Im szerzej rozumiesz system, tym trudniej Cię zastąpić.

Framework to tylko narzędzie. Wartość dowozi ten, kto rozumie problem.

Podsumowanie

Jeśli masz zapamiętać z tego artykułu tylko 3 rzeczy, niech to będą te:

• Trend jest realny. Blazor urósł z 4,46% do 7% developerów w ankiecie Stack Overflow, a liczba stron na Blazorze z ok. 10 tys. do ponad 32 tys. To nie moda.

• Bitwa toczy się wewnątrz firm. W panelach, CRM-ach i dashboardach, a nie na landing page'ach. Tam Blazor wygrywa rachunkiem, nie ideologią.

• Fullstack C# to przewaga. Dla .NET-owca to dziś najtańsza inwestycja w karierę.

Blazor nie zabije Reacta. Ale w polskich firmach .NET ma największą szansę wygrać tam, gdzie React wcale nie jest oczywistym wyborem: w aplikacjach wewnętrznych. A to oznacza konkretne projekty i konkretne oferty pracy.

Jeśli chcesz być na bieżąco z tym, co dzieje się w Blazorze i w całym .NET, dołącz do mojej społeczności - jest nas już ponad 10 000 programistów. Raz w tygodniu wysyłam jednego konkretnego maila: najważniejsze newsy ze świata .NET, bez szumu i lania wody. Członkowie społeczności dostają też rabaty na moje kursy, których nie znajdziesz nigdzie indziej. Zero spamu - wypisujesz się jednym kliknięciem.

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