Co to jest Blazor?

Przy tworzeniu aplikacji internetowych zazwyczaj korzysta się z zupełnie innych technologii na poziomie front-endu i back-endu. Potrafi to mocno skomplikować pracę programistów… i między innymi dlatego Microsoft stworzył Blazora. W dzisiejszym wpisie wyjaśnimy, jak działa i w jakich projektach ma sens – zapraszamy do lektury.

Blazor – inny sposób na budowę aplikacji webowych

Blazor to nowoczesny framework do budowania interaktywnych interfejsów aplikacji webowych, który pozwala pisać kod front-endu (warstwy, którą widzi użytkownik) w języku C#, a nie, tak jak się to robi najczęściej, w JavaScript. Opiera się na platformie programistycznej .NET, czerpie też wiele z frameworka ASP.NET Core – całe środowisko zostało opracowane przez Microsoft, który mocno wspiera jego rozwój (choć warto przy tym zaznaczyć, że jest to framework open source).

Główna idea jest taka, aby umożliwić programistom pracę nad całą aplikacją w jednym języku – w tym przypadku w C#. JavaScript ma swoje ograniczenia przy pracy z back-endem (zapleczem aplikacji), pod każdym względem jest to język typowo front-endowy. C# jest o wiele bardziej uniwersalny i dla kogoś, kto chciałby cały projekt webowy oprzeć na jednym języku, będzie jedną z lepszych opcji… tym bardziej ze wsparciem Blazora.

Jak działa Blazor? Architektura oparta na komponentach Razor

Podstawową jednostką, z której buduje się aplikację w Blazorze, jest komponent – czyli samodzielny fragment interfejsu z własnym wyglądem i logiką. Może to być pojedynczy przycisk, formularz kontaktowy, tabela z danymi albo cała podstrona, wszystko zależy od developerów. Komponenty zagnieżdża się w sobie nawzajem i składa z nich aplikację jak z klocków, a raz napisany element da się później wykorzystać w kilkunastu innych miejscach. Na marginesie, dokładnie tak samo działają React czy Vue, czyli frameworki języka JavaScript.

Same komponenty zapisujemy w plikach z rozszerzeniem .razor, w składni Razor. W praktyce wygląda to tak, że w jednym pliku mieszamy zwykły kod HTML z C#, oddzielając ten drugi znakiem @. Pierwszy odpowiada więc za strukturę interfejsu, drugi – za logikę działania. 

Kiedy stan komponentu się zmienia – bo, powiedzmy, użytkownik coś wpisał w formularzu – Blazor nie musi renderować widoku interfejsu od nowa, tylko buduje sobie w pamięci drzewo renderowania (render tree), porównuje jego nową wersję ze starą i wysyła do przeglądarki wyłącznie te kilka elementów, które faktycznie trzeba podmienić.

Pozostaje tylko jedno pytanie: gdzie jest wykonywany kod aplikacji? Blazor ma na to więcej niż jedną odpowiedź.

Modele hostowania komponentów, czyli kilka twarzy Blazora

Blazer pozwala renderować komponenty interfejsu aplikacji zarówno po stronie serwera, jak i w przeglądarce użytkownika, oferuje też model „mieszany”.

Blazor Server

W tym modelu cała aplikacja działa na serwerze (server-side rendering). Kiedy użytkownik wykona jakąś akcję, na przykład kliknie przycisk, informacja o tym jest przekazywana do serwera – ten renderuje kod danego komponentu i zwraca przeglądarce instrukcję, co należy podmienić w widoku aplikacji. 

I plusy, i minusy są oczywiste. Z jednej strony tak hostowana aplikacja powinna ładować się błyskawicznie, bo przeglądarka nie musi pobierać jej kodu źródłowego; ma też bezpośredni dostęp do bazy danych czy usług wewnętrznych na serwerze. Z drugiej, żeby interfejs aplikacji mógł być aktualizowany na bieżąco, podczas całej sesji użytkownika serwer musi utrzymywać stałe połączenie z klientem (przeglądarką), co przy większym ruchu wymaga bardzo mocnego hostingu.

Blazor WebAssembly 

Tutaj jest dokładnie odwrotnie. Serwer przesyła do przeglądarki środowisko uruchomieniowe .NET Runtime wraz z kodem aplikacji i wszystko dzieje się już po stronie użytkownika. Powstaje w ten sposób klasyczna aplikacja typu SPA (single-page application), którą można hostować jako zwykłe pliki statyczne.

Po pierwszym załadowaniu aplikacja będzie w 100% responsywna, co więcej, może nawet działać offline, przynajmniej w pewnym zakresie. Sęk w tym, że pobranie i wyrenderowanie interfejsu potrwa dużo dłużej (samo WebAssembly to ok. 10 MB plików), a żeby połączyć go z bazą danych, trzeba będzie dobudować osobne API. 

Blazor Hybrid

Z kolei Blazor Hybrid pozwala osadzić komponenty Blazora w aplikacji desktopowej, mobilnej lub PWA (progressive web app), zbudowanej np. w .NET MAUI czy w WPF. Interfejs renderuje się wtedy w specjalnym komponencie WebView, który pełni funkcję… miniaturowej, wewnętrznej przeglądarki osadzonej w aplikacji i działającej tylko na jej potrzeby. Taka aplikacja zachowuje się jak w pełni natywny program, więc może mieć dostęp do funkcji urządzenia (np. kamery albo usług lokalizacji) i jego plików.

Jak to wygląda dzisiaj?

Do 2023 roku i wersji .NET7 model hostowania trzeba było wybrać dla całej aplikacji, już na początku projektu. Ósma wersja środowiska od Microsoftu to zmieniła i teraz możemy definiować tryby renderowania osobno dla każdego komponentu. A to pozwala budować aplikacje mieszane – na przykład sklep, którego strona główna i karty produktów są generowane na serwerze, a panel użytkownika i cały checkout już na urządzeniu użytkownika.

Co Blazor daje programistom? Możliwości frameworka od Microsoftu

Jak każdy framework, Blazor oferuje cały zestaw narzędzi do pracy z kodem; pod tym względem również nie odstaje on wcale od Reacta i reszty środowiska JavaScript. Przejdźmy przez te najważniejsze:

• JavaScript interop – nawet jeśli projekt ma bazować na C#, często i tak trzeba będzie sięgnąć po JS-a. Na szczęście Blazor pozwala bez przeszkód wywoływać funkcje JavaScript z kodu C# i odwrotnie;
• routing – Blazor ma własny, wbudowany router, oparty na dyrektywie @page umieszczanej na górze komponentu. Wystarczy wskazać w niej adres URL, razem z parametrami, jeśli są potrzebne, a komponent stanie się osobną podstroną aplikacji. Nie trzeba tworzyć osobnego pliku z mapą tras, ścieżka definiujemy tam, gdzie znajduje się sam widok;
• wstrzykiwanie zależności – tak jak wspominaliśmy, framework bazuje na możliwościach platformy .NET, więc wraz z nim dostajemy m.in. wbudowany kontenter dependency injection. Obiekty rejestrujemy raz, w konfiguracji aplikacji, a potem wstrzykujemy je do dowolnego komponentu jedną linijką;
• formularze i walidacja – Blazora projektowano z myślą o aplikacjach biznesowych, więc obsługa formularzy musi być jego mocną stroną. Dostajemy tu gotowy komponent EditForm wraz z zestawem pól powiązanych bezpośrednio z modelem danych, a reguły walidacji opisujemy atrybutami na klasie modelu, tej samej, której używa back-end;
• gotowe biblioteki komponentów – wokół Blazora wyrosło też sporo bibliotek z gotowymi komponentami, od darmowych i otwartych, jak MudBlazor, Radzen czy Blazorise, po komercyjne pakiety Telerika i Syncfusion. Wybór jest co prawda mniejszy niż w ekosystemie Reacta (z którym mało co może się równać), ale nadal mamy sporo opcji;
• narzędzia deweloperskie – framework zapewnia oczywiście pełne wsparcie dla Visual Studio i Visual Studio Code; z ciekawszych funkcji, mamy na przykład tzw. hot reload, dzięki któremu możemy wprowadzać zmiany w komponentach na włączonej aplikacji i obserwować je na żywo, bez restartowania.

Jakie aplikacje internetowe można zbudować w Blazorze? 

Blazor jest też na tyle uniwersalny, że da się na nim napisać w zasadzie dowolną aplikację webową. Jednak to, czy do każdego projektu będzie najlepszą opcją, to jest już inne pytanie – na nie odpowiemy za moment. Najlepiej, co do zasady, framework Microsoftu radzi sobie z projektami:

• paneli administracyjnych i dashboardów – wszelkiego rodzaju kokpitów z tabelami, wykresami i filtrami;
• aplikacji line-of-business – systemów obsługi zamówień, obiegu dokumentów, ewidencji sprzętu, rozliczania czasu pracy i podobnych narzędzi, które muszą być zaprojektowane idealnie pod procesy w danej firmie;
• portali klienta – może to być na przykład panel, w którym klient B2B jest w stanie samemu sprawdzić status zamówienia, pobrać faktury, złożyć reklamację albo zamówić towar z własnego cennika;
• konfiguratorów produktów i kalkulatorów – wszystkiego, co wymaga przeliczania danych w locie na podstawie skomplikowanych reguł: kalkulatorów leasingowych, konfiguratorów mebli na wymiar, narzędzi do wyceny ubezpieczeń.

Co je łączy? Fakt, że większość z nich (pomijając niektóre kalkulatory i konfiguratory) będzie ukryta za ekranem logowania, niedostępna dla zwykłego użytkownika – raczej nie znajdziemy też ich w Google. I tu dochodzimy do głównej słabości Blazora.

Kiedy JavaScript ma przewagę nad Blazorem i C#? 

Jeśli aplikacja ma się pozycjonować w wyszukiwarkach: budujesz sklep, serwis contentowy lub cokolwiek, co ma zarabiać na ruchu z wyszukiwarki, Blazor prawdopodobnie nie będzie dobrą opcją. 

Tak naprawdę każdy model hostowania i renderowania kodu aplikacji, czy ten oparty na WebAssembly, czy ten przenoszący wszystko na stronę serwera, ma duże ograniczenia, jeśli chodzi o pozycjonowanie. Da się je po części obejść – na przykład prerenderując podstrony, które chcemy pozycjonować – ale JavaScript takich problemów zwyczajnie nie sprawia. I dlatego przy projektach publicznie dostępnych aplikacji JS pozostaje niezastąpiony. 

Tym bardziej, że na tle Blazora JavaScript ma też o wiele lepiej rozwinięty ekosystem bibliotek. Praktycznie na każdy problem znajdziemy tam trzy sprawdzone rozwiązania; w Blazorze często pozostaje napisanie komponentu samodzielnie albo… włączenie biblioteki JS-owej do kodu przez interop, co i tak sprowadza projekt do pracy z JavaScriptem. 

Blazor, czyli frontend bez JavaScriptu 

Gdy w 2019 roku Microsoft wprowadził pierwszą wersję Blazora, zespoły deweloperskie pracujące na co dzień w środowisku .NET Framework wreszcie otrzymały narzędzia do pracy z front-endem, które pod wieloma względami dorównują frameworkom i bibliotekom JavaScript. Nie są one idealne – mimo tego, jak bardzo elastyczny jest język C#, nadal sprawdza się on głównie w projektach firmowych aplikacji wewnętrznych, ewentualnie tych kierowanych do klientów B2B – ale tam, gdzie Blazor ma swoje mocne strony, radzi sobie bardzo dobrze.

Genialne firmy mnożą
swój potencjał z

Sprawdź nasze Case Studies

Ocena Clutch

5.0

Ocena Google

4.8

Bądź widoczny w Google i wyszukiwarkach przyszłości (ChatGPT, Gemini, Perplexity i inne)

Zostaw adres e-mail — porozmawiamy o widoczności Twojej strony w AI.

Dane przetwarzamy w celu kontaktu, zgodnie z naszą
polityką prywatności