Blazor od zera: Rozdział 1 — Czym jest Blazor?

· 6 min czytania
Blazor .NET Web Development Series
Available in: Polski · English · Español · Français · Deutsch · Português · 한국어 · 日本語 · Русский · 中文 · العربية · हिन्दी · Türkçe · Bahasa Indonesia · Nederlands

Witaj w Rozdziale 1 serii Blazor od zera. Jeśli nie czytałeś posta wprowadzającego, w którym wyjaśniłem, o czym jest ta seria i do kogo jest skierowana, zacznij od niego — jest krótki.

W tym rozdziale odpowiemy na fundamentalne pytanie: czym jest Blazor? Brzmi prosto, ale odpowiedź ma kilka warstw — szczególnie dlatego, że przez lata „Blazor“ zyskał nieco różne znaczenia. Pod koniec tego posta będziesz wiedzieć, czym jest Blazor, jak wpisuje się w ekosystem .NET, jakie istnieją modele renderowania i dlaczego możesz — lub nie — wybrać go zamiast frameworku JavaScript.

Krótka historia

Blazor zaczął jako eksperymentalny projekt Steve’a Sandersona w Microsoft około 2017 roku. Pomysł był prowokacyjny: uruchomić C# w przeglądarce za pomocą WebAssembly, całkowicie eliminując potrzebę JavaScript. Był to dowód koncepcji, a nazwa była celowym połączeniem Blazer i Razor — silnika szablonów, na którym Blazor miał ostatecznie zostać zbudowany.

Eksperyment wywołał wystarczająco dużo entuzjazmu, żeby Microsoft potraktował go poważnie. Blazor trafił do użytkowników jako część ASP.NET Core 3.0 we wrześniu 2019 roku — najpierw jako Blazor Server: model uruchamiający kod C# na serwerze i używający połączenia SignalR w czasie rzeczywistym do wysyłania aktualizacji interfejsu do przeglądarki. Blazor WebAssembly dołączył w maju 2020 roku jako część ASP.NET Core 3.1, przynosząc frameworkowi prawdziwe wykonanie po stronie klienta.

.NET 6 i 7 dopracowały doświadczenie programistów. Następnie .NET 8, wydany w listopadzie 2023 roku, fundamentalnie przeprojektował model renderowania z tym, co Microsoft nazwał full-stack web UI. Statyczne renderowanie po stronie serwera, streaming rendering, interaktywny serwer, interaktywny WebAssembly i nowy tryb Auto — wszystko pod jednym dachem w jednym projekcie. .NET 9 budował na tym fundamencie i wyrównał chropowate krawędzie.

Tak wygląda sytuacja dziś.

Czym Blazor naprawdę jest

W swojej istocie Blazor to oparty na komponentach framework UI dla .NET. Budujesz interfejs z komponentów — samodzielnych jednostek C# i znaczników HTML, które mogą przechowywać stan, reagować na zdarzenia i składać się w większe struktury. Jeśli pracowałeś z React lub Vue, ten model mentalny wyda ci się znajomy. Kluczowa różnica polega na tym, że zamiast JavaScript piszesz C#.

Komponenty Blazor zapisuje się w plikach .razor. Plik .razor łączy znaczniki HTML z kodem C# przy użyciu składni Razor, którą możesz znać z widoków ASP.NET MVC. Oto jak wygląda prosty komponent:

@page "/counter"

<h1>Licznik</h1>
<p>Bieżąca wartość: @currentCount</p>
<button @onclick="IncrementCount">Kliknij mnie</button>

@code {
    private int currentCount = 0;

    private void IncrementCount()
    {
        currentCount++;
    }
}

Żadnego JavaScript w zasięgu wzroku. Dyrektywa @onclick wiąże kliknięcie przycisku z metodą C#. Wyrażenie @currentCount renderuje bieżącą wartość. Gdy stan się zmienia, Blazor ustala, co zaktualizować w DOM.

To jest sedno. Wszystko inne — routing, wstrzykiwanie zależności, formularze, wywołania HTTP — jest zbudowane na tym modelu komponentów.

Modele renderowania

Tu kryje się wiele zamieszania, więc bądźmy precyzyjni. Dzisiaj „Blazor“ odnosi się do rodziny trybów renderowania, nie do jednego modelu wdrożenia. Zrozumienie różnicy jest ważne, bo wpływa na wydajność, wymagania infrastrukturalne i to, co komponenty mogą, a czego nie mogą robić.

Statyczny SSR

Najprostszy tryb. Twoje komponenty Razor renderują się na serwerze do HTML, który jest wysyłany do przeglądarki. Brak trwałego połączenia, bez WebAssembly i domyślnie bez interaktywności po stronie klienta. To właściwie to, co robi Razor Pages, ale z użyciem modelu komponentów.

Używaj do stron z dużą ilością treści, landing pages, wszystkiego, co nie wymaga interaktywności w czasie rzeczywistym.

Interaktywny serwer

Kod komponentu działa na serwerze. Między przeglądarką a serwerem nawiązywane jest połączenie WebSocket przez SignalR. Gdy klikasz przycisk lub wpisujesz coś w pole, zdarzenie wędruje przez WebSocket do serwera, twój C# się wykonuje, obliczana jest różnica i aktualizacje DOM wracają do przeglądarki.

Zalety: Pełny dostęp do zasobów serwera (bazy danych, system plików, sekrety). Szybkie pierwsze ładowanie. Małe rozmiary pobierania. Działa w przeglądarkach bez obsługi WebAssembly.

Wady: Każda interakcja użytkownika wymaga podróży do serwera i z powrotem, co dodaje opóźnienie. Zasoby serwera skalują się z liczbą aktywnych połączeń. Aplikacja degraduje się po zerwaniu połączenia.

Używaj do aplikacji biznesowych, narzędzi wewnętrznych, aplikacji, gdzie dostęp do danych po stronie serwera jest ważniejszy niż możliwość pracy offline.

Interaktywny WebAssembly

Środowisko uruchomieniowe .NET jest pobierane do przeglądarki, a twoja aplikacja działa całkowicie po stronie klienta. Po pierwszym pobraniu aplikacja działa w pełni offline, a każda interakcja jest natychmiastowa — bez podróży do serwera dla logiki interfejsu.

Zalety: Prawdziwe wykonanie po stronie klienta. Działa offline. Zmniejszone obciążenie serwera po załadowaniu aplikacji.

Wady: Większy rozmiar pierwszego pobrania (środowisko .NET + aplikacja). Wolniejsze pierwsze ładowanie. Potrzebujesz API, by uzyskać dostęp do danych po stronie serwera.

Używaj do aplikacji działających offline, narzędzi wymagających natychmiastowej reaktywności, scenariuszy, w których UI nie wymaga przetwarzania po stronie serwera.

Tryb Auto

Wprowadzony w .NET 8. Aplikacja startuje w trybie interaktywnego serwera (szybkie pierwsze ładowanie, bez czekania na pobranie WebAssembly). Gdy pliki WebAssembly zostaną pobrane w tle, kolejne wizyty automatycznie przełączają się na tryb WebAssembly.

Daje ci to szybkie pierwsze ładowanie trybu serwera i ostatecznie pełne wykonanie po stronie klienta WebAssembly. To najbardziej złożony model do ogarnięcia, ale praktyczne ustawienie domyślne dla wielu aplikacji.

Mieszanie trybów w tej samej aplikacji

W .NET 8 i późniejszych nie jesteś ograniczony do jednego trybu renderowania dla całej aplikacji. Marketingowa landing page może być statycznym SSR; uwierzytelniony pulpit nawigacyjny może być interaktywnym serwerem; widget wizualizacji danych może być interaktywnym WebAssembly. Framework zarządza przejściami.

W tej serii zaczniemy od interaktywnego serwera, bo najłatwiej go uruchomić i ma najbardziej bezpośredni model mentalny. Będziemy odkrywać inne tryby w miarę postępów.

Jak Blazor wypada w porównaniu z frameworkami JavaScript

Jeśli budowałeś z React, Angular lub Vue, to prawdopodobnie to porównanie cię interesuje.

Podobieństwa są prawdziwe. Model komponentów Blazor jest celowo podobny do React. Masz props (Parametry w Blazor), stan lokalny (pola w bloku @code), hooki cyklu życia i ten sam wzorzec komunikacji: dane w dół, zdarzenia w górę. Jeśli znasz React, poczujesz się jak w domu w ciągu kilku godzin.

Kluczowa różnica to język. W Blazor piszesz C#. Twoja logika biznesowa, reguły walidacji i modele danych mogą być współdzielone między frontendem Blazor a backendem ASP.NET Core. Koniec z duplikowaniem klasy User w TypeScript, gdy masz ją już w C#.

Luka ekosystemów jest realna, ale się zmniejsza. Ekosystem npm jest ogromny. Ekosystem NuGet dla komponentów UI jest mniejszy, choć znacznie urósł. Jeśli potrzebujesz konkretnej biblioteki wykresów lub widżetu drag-and-drop, JavaScript wciąż ma więcej opcji. Ale dla większości aplikacji biznesowych to, co jest dostępne w świecie .NET, jest więcej niż wystarczające.

Interoperacyjność z JavaScript istnieje, gdy jej potrzebujesz. Blazor pozwala wywoływać JavaScript z C# i C# z JavaScript. Dla API przeglądarki bez wrapperów .NET, lub gdy chcesz użyć istniejącej biblioteki JS, interop jest dostępny. Dodaje warstwę, ale nie jest bolesny.

Szczera odpowiedź: Jeśli twój zespół to wyłącznie programiści JavaScript budujący publiczny produkt, w którym SEO, wydajność i ekosystem npm są krytyczne, zostań przy JavaScript. Jeśli twój zespół to programiści .NET, jeśli budujesz aplikacje wewnętrzne lub biznesowe, lub jeśli współdzielenie kodu między frontendem a backendem jest dla ciebie ważne, Blazor jest przekonującym wyborem.

Co jest potrzebne, żeby podążać za serią

Do dalszej części serii będziesz potrzebować:

  • .NET 9 SDK — pobierz z dot.net
  • IDE — Visual Studio 2022 (edycja Community jest darmowa), VS Code z rozszerzeniem C# Dev Kit lub JetBrains Rider
  • Podstawowa znajomość C# — klasy, właściwości, interfejsy, async/await

To wszystko. Żadnego Node, npm ani webpacka.

Co dalej

W Rozdziale 2 stworzymy twoją pierwszą aplikację Blazor, przejdziemy przez strukturę projektu i upewnimy się, że możesz ją uruchomić lokalnie. Na koniec będziesz mieć działającą aplikację i jasny obraz tego, co robi każdy plik.

Do zobaczenia tam.