Wprowadzenie
Od kilku lat następuje coraz większa specjalizacja w tworzeniu aplikacji webowych. Jeszcze jakiś czas temu, tworząc projekt w ASP.NET MVC, większość rzeczy robiliśmy po stronie serwera, dodając pojedyncze dynamiczne elementy w jQuery po stronie przeglądarki. Teraz po stronie serwera tworzymy głównie API, które następnie jest wykorzystywane przez aplikację działającą w przeglądarce, tworzącą interfejs użytkownika.
Takie podejście powoduje, że świat frontendu znacznie różni się od świata backendu. Na ogół używamy innych narzędzi, innych technologii, innych bibliotek. Następnie potrzebujemy czegoś w stylu Swaggera, który umożliwi nam połączenie tych dwóch światów, aby nie tracić zbyt dużo czasu na ręcznych zmianach w definicji i użyciu API.
Koniec końców takie podejście powoduje, że pojedyncze osoby mają problem w ogarnięciu technologicznym całego projektu i już nawet do małych aplikacji potrzebujemy większego zespołu, który ogarnie poszczególne elementy układanki.
Na szczęście stoimy u progu zmian, które mogą spowodować, że ten obraz chociaż trochę się zmieni i nie będziemy skazani na tworzenie frontendu w znienawidzonym przez większość JavaScripcie*.
* Tak, wiem, że mamy jeszcze TypeScript, który dla takiego backendowca jak ja jest znacznie przyjemniejszy niż JavaScript.
WebAssembly
Powodem całego zamieszania jest WebAssembly (Wasm). Jest to język programowania, który umożliwia nam skompilowanie różnych języków programowania (np. C++, Java, C#) do formatu binarnego i wykonywanie go po stronie przeglądarki w szybkości zbliżonej do natywnej.
Jest to otwarty internetowy standard, wspierany przez większość przeglądarek. Jak podaje caniuse.com (https://caniuse.com/#feat=wasm) na dzień pisania tego artykułu (czyli 15 marca 2019) 81,41% przeglądarek wspiera WebAssembly. Są to głównie wiodące przeglądarki takie jak: Chrome, Chrome for Android, Firefox, Edge, Safari, iOS Safari. Więc, jak widać, nie musimy się martwić, że ten standard nie jest wspierany i tylko nieliczni będą mogli korzystać z aplikacji stworzonej w WebAssembly.
Co ważne, WebAssembly nie ma zastąpić używania JavaScript, a raczej go uzupełnić. Szczególnie w sytuacjach takich jak gry czy multimedia, gdzie JavaScript radził sobie średnio.
Możemy tworzyć rozwiązania, w których aplikacja działająca w ramach WebAssembly (np. Blazor) będzie korzystać z bibliotek JavaScript i odwrotnie. Dzięki temu jesteśmy w stanie wykorzystać to wszystko, czego używamy podczas tworzenia aplikacji w JavaScript.
Dzięki WebAssembly będziemy mogli również przenieść technologie wykorzystywane do tej pory po stronie backendowej do tworzenia frontendu, tak jak to jest w przypadku .NET i C# w Blazorze.
Blazor
Blazor (https://blazor.net/) jest jednym z frameworków, który powstał na bazie WebAssembly. Dzięki niemu możemy stworzyć aplikację SPA w .NET, C# oraz Razor, która następnie wykona się po stronie przeglądarki. Microsoft skompilował specjalną wersję .NET Framework (bazującą na Mono) do WebAssembly, która umożliwia nam wykonywanie kodu .NET w przeglądarce.
Najlepiej widać to w liście żądań przesyłanych do serwera z przeglądarki:
Jednym z pierwszych plików, które pobiera przeglądarka, jest mono.wasm. Jest to właśnie skompilowane Mono do WebAssembly, które będzie wykonywało kod aplikacji. Kolejne pobierane pliki to już zwykle biblioteki .NET . Demo1.dll to skompilowany kod testowej aplikacji.
W tym momencie Blazor jest eksperymentalnym frameworkiem, który dynamicznie się rozwija. Zawiera już sporo funkcjonalności, ale jeszcze sporo pracy przed twórcami. Blazor może działać w dwóch trybach: klienckim oraz serwerowym. W pierwszym działa całkowicie po stronie przeglądarki. Natomiast w drugim zdarzenia z przeglądarki są przesyłane za pomocą SignalR do serwera, który wykonuje kod aplikacji i przesyła z powrotem wygenerowany HTML do przeglądarki. Ten drugi model działania nazywa się Razor Components i ma być jednym z elementów .NET Core 3.0.
W najbliższych tygodniach planuję opisywać różne funkcjonalności Blazora, więc dzisiaj skupimy się tylko na podstawach.
Budowa aplikacji
Po zainstalowaniu rozszerzenia do Visual Studio dla Blazor (https://marketplace.visualstudio.com/items?itemName=aspnet.blazor) w liście dostępnych szablonów pojawią się dwa nowe. Poniżej znajduje się zrzut z ekranu tworzenia nowego projektu ASP.NET Core Web Application, w którym widać nowe szablony. Zrzut ekranu pocahodzi z Visual Studio 2019 Preview:
Pierwszy szablon (Blazor) tworzy tylko projekt aplikacji, która będzie działać w przeglądarce. Natomiast drugi szablon (Blazor ASP.NET Core hosted) tworzy solution składające się z trzech projektów: aplikacji Blazor, Web Api w ASP.NET Core oraz projektu Shared do współdzielenia klas DTO między frontendem oraz backendem. Ostatni projekt znacznie ułatwia pracę, ponieważ zmiany w nim (np. dodanie nowej właściwości do jakiegoś obiektu) są automatycznie dostępne po obu stronach. W klasycznym podejściu niestety jest to dużo bardziej czasochłonne.
Sam projekt aplikacji Blazor składa się z kilku elementów:
Poza znajomymi elementami z ASP.NET Core widzimy również dwa foldery (Pages oraz Shared) z komponentami Blazora. W Shared znajdują się komponenty współdzielone przez strony, takie jak menu. Dodatkowo znajduje się tam plik MainLayout.cshtml, który określa ogólny wygląda aplikacji. Podobnie jak _Layout.cshtml w ASP.NET MVC.
W katalogu Pages znajdują się widoki poszczególnych stron, do których użytkownik może nawigować.
Strony w Blazor
Na tę chwilę pojedyncza strona znajduje się w pliku cshtml. Znajduje się w nim kod HTML oraz C#. Z czasem ma to zostać rozbite na dwa oddzielne pliki, podobnie jak to jest na przykład w Angularze. Przykładowy widok wygląda tak:
@page "/counter" | |
<h1>Counter</h1> | |
<p>Current count: @currentCount</p> | |
<button class="btn btn-primary" onclick="@IncrementCount">Click me</button> | |
@functions { | |
int currentCount = 0; | |
void IncrementCount() | |
{ | |
currentCount++; | |
} | |
} |
W pierwszej linii znajduje się dyrektywa page, w której określamy adres, pod którym dostępny jest dana strona. Niżej znajduje się HTML strony.
Na samym końcu znajduje się natomiast blok functions, w którym umiejscowiony jest kod C# widoku. W powyższym przykładzie znajduje się pole currentCount oraz metoda IncrementCount, która zwiększa o jeden wartość pola. Oba elementy są użyte w kodzie HTML. Wartość pola wyświetla się w paragrafie, natomiast metoda jest zbindowana z zdarzeniem click przycisku i wykonuje się po jego naciśnięciu.
Najfajniejsze w tym wszystkim jest to, że ten kod wykona się po stronie przeglądarki, dzięki czemu my, programiści .NET, nie musimy się uczyć nowych technologii, aby tworzyć frontend. Prawda, że fajnie?
Przykład
Na githubie znajduje się prosta aplikacja stworzona w Blazorze. Do jej uruchomienia potrzebne są elementy opisane na stronie https://docs.microsoft.com/pl-pl/aspnet/core/client-side/spa/blazor/get-started?view=aspnetcore-3.0&tabs=visual-studio.
Prezentacja podczas WDI
Zainteresował Cię Blazor? Jeśli tak, to serdecznie zapraszam Cię na moją prezentację o nim, która odbędzie się 26 marca o 10:20 w auli 328 podczas Warszawskich Dni Informatyki (https://warszawskiedniinformatyki.pl/). Jeśli nie możesz się zjawić, to nic straconego. W najbliższym czasie na blogu pojawi się więcej wpisów o Blazorze.
Podsumowanie
Gdy pierwszy raz zobaczyłem, czym jest Blazor, to na początku nie mogłem uwierzyć, że za jakiś czas będzie można tworzyć frontend w C#, używając tych samych narzędzi oraz składni, które mamy w ASP.NET MVC. Gorąco kibicuję Blazorowi i mam nadzieję, że szybko wyjdzie z fazy eksperymentalnej. Już to widzę, jak Blazor ułatwi tworzenie aplikacji. Nie mogę się tego doczekać.
A jakie są Twoje przemyślenia na temat Blazora? Też Ci się podoba?
Zainteresowany Blazorem? Jak tak to zapraszam na stronę prezentacji Front-end in C#? Yes – Blazor, gdzie znajdziesz więcej materiałów.
Nareszcie ktoś o tym napisał! Panie Danielu teraz nie ma Pan już wyjścia. Kurs! Nie widzę inaczej. Będę pierwszym recenzentem
Dzięki za komentarz!
Na tą chwiłą myślę, że jeszcze za wsześnie na kurs, ale jak tylko będzie wersja stabilna to wtedy coś przygotuje