Blazor – WebAssembly na usługach Microsoftu, czyli C# trafi pod strzechy w aplikacjach SPA

Zespół .NET od zawsze marzył, aby programiści znający język C# mogli bez problemu tworzyć aplikacje webowe. Podejść było kilka i różnie z tym wychodziło. W czasach prehistorycznych (wiem, że niektórzy w tym jeszcze programują, ale tak samo gdzieś żyją jeszcze ludzie bez prądu, więc obu grupom współczuję) strony www i .NET kojarzone były z ASP.NET WebForms. Była to szybka (i dość średnio zrobiona) odpowiedź na potrzebę tworzenia aplikacji webowych, ale przez osoby nie mające pojęcia jak działa web, za to posiadające wiedzę o pisaniu aplikacji desktopowych.

Takie podwaliny nie mogły być dobrym zalążkiem do powstania WebForms, co wiemy teraz wszyscy. Aplikacje tworzone w tej technologii były bardzo ociężałe z olbrzymią ilością przesyłanych danych i pełnym odświeżaniem strony co każdy event. Pomimo tego, iż wiele firm nadal posiada projekty (utrzymaniowe) w WebForms, to praca z nimi nie należy do przyjemnych.

Microsoft chciał jeszcze po drodze ratować ten twór poprzez pomysły takie jak chociażby „ASP.NET AJAX Control Toolkit”, który miał być pomocą przy tworzeniu dynamicznych stron w oparciu o AJAX, który wówczas zyskiwał na popularności. Niestety i tutaj dały o sobie znać podwaliny, które niweczyły wszystkie dobre pomysły. AJAX do WebFormsów miał swoje przebłyski, ale oferował to kosztem przesyłania w tle całych, ciężkich stron z ViewStatem, a dodatkowo kontrolki takie jak UpdatePanel potrafiły zaciemnić kod i requesty w każdej, nawet najprostszej aplikacji.

Gdzieś po drodze pojawił się pomysł, aby aplikacje WPF przenieść niemalże w całości do przeglądarki www. Podpatrzono jak wielkim sukcesem był wówczas Flash i Microsoft postanowił wydać Silverlighta. Był tociekawy twór, który jeszcze do niedawna był niezbędny chociażby do oglądania wielu serwisów VOD. Niestety już w czasach premiery mówiono głośno o HTML5, który finalnie pogrzebał i Silverlighta i Flasha na webie. Sam Silverlight miał jeszcze epizod w mobilnym systemie Windows, ale jest to dla mnie temat bardzobolesny i prosiłbym o nierozdrapywanie ran, które dopiero co się zabliźniły.

Wspomnę tu tylko tyle, że gigant z Redmond tak się spieszył z mobilnymi nowymi okienkami, że w sumie można powiedzieć, że Windows Phone to była aplikacja Silverlight uruchomiona w sandboxie, który działał na rdzeniu starego Windows Mobile 6.x. Wiemy jak się to skończyło, nawet nowe wcielenia mobilnych okienek, bazujących już na świeżych rozwiązaniach, nie pomogą, jak rodzice odwrócą się od swoich dzieci (a tak zrobił Microsoft w momencie kiedy Windows 10 Mobile zaczął przypominać stabilny system, szkoda).

Dochodzimy już do naszych współczesnych czasów. Mamy zatem ASP.NET MVC i lekkie widoki pisane w Razorze. Znacznie lżejsze podejście w porównaniu do ociężałych WebFormsów. Rozdzielenie widoków, kontrolerów i modeli pozwoliło na tworzenie znacznie przyjemniejszych aplikacji www od strony deweloperów. Można było wreszcie zapanować nad kodem i ruch pomiędzy serwerem, a przeglądarką został w całości ujarzmiony. Klienci końcowi odczuli lekkość w kwestii szybkość i przyjemność obcowania z bytem, który był stworzony od podstaw jako framework webowy.

Największym plusem była również elastyczność tego rozwiązania. Nic nie stało na przeszkodzie, aby jednocześnie podczepić pod ASP.NET MVC frameworki typowo JavaScriptowe jak Angular czy React. W tym też celu jeszcze bardziej uszczuplono kontakt z przeglądarką i tak oto powstał ASP.NET Web API, który na błędach Web Services i WCFa dawał elastyczność. W nowych rozwiązaniach, gdzie od strony serwera wystawiane były tylko endpointy, a od strony klienckiej rządził JavaScript (lub TypeScript) wspomagany jednym z popularnych frameworków SPA. Cały ASP.NET MVC zyskał olbrzymią popularność i jest z powodzeniem używany przez biznes jako stabilna platforma do tworzenia rozwiązań opartych na technologii web.

Najnowsze dziecko ludzi od ASP.NET to ASP.NET Core. Całkowicie przepisana od zera technologia, która czerpie najlepsze rozwiązania z ASP.NET MVC, a jednocześnie umożliwia tworzenie aplikacji web, które postawić można nie tylko na Windowsie, ale i na MacOS czy Linuxie. Tutaj postarano się oto, aby komponenty był lekkie, szybkie i wydajne, a jednocześnie bardzo rozszerzalne. Dzięki, odcięciu się całkowicie od przeszłości można było stworzyć framework, który obecnie jest przykładem na świetnie zaprojektowane środowisko do tworzeni aplikacji web.

Tak oto przechodzimy do najnowszego dziecka z Redmond.

.NET Core 3.0 przedstawi kolejne wcielenie nieziszczonego snu twórców ASP.NET, aby wprowadzić C# bezpośrednio do przeglądarki. WebForms dawał złudzenie działania w przeglądarce od strony programistów, Silverlight robił to aż za dosłownie i wchodził „z butami” do przeglądarki www. Blazor ma być czymś nowym, co może wreszcie pozwoli w pełni zaistnieć językowi C# po stronie przeglądarki.

Blazor to framework, który pozwala na budowanie stron SPA przy użyciu języka C#. Dzieje się tak dzięki WebAssembly, które umożliwia użycie .NET po stronie przeglądarki. Skompilowany program jest uruchamiany po stronie klienta niemalże z natywną prędkością. Microsoft obecnie używa Mono do obsługi .NET w WebAssembly. Warto pamiętać, że .NET 5 będzie miał jeszcze ściślejszą integrację z Mono, a to m.in. dzięki temu, iż Mono od dłuższego czasu wspiera WebAssembly i całkiem nieźle sobie z nim radzi. Co ważne, obecnie wszystkie przeglądarki na rynku obsługują WebAssembly, nawet wersje mobilne, zatem nie będzie problemu z odpalaniem strony od strony klienckiej (chyba, że ktoś nadal działa na Internet Explorerze).

Blazor umożliwi pisanie w C# po stronie przeglądarki z natywną prędkością z pominięciem JavaScriptu czy TypeScriptu. W tym momencie można mówić o dwóch typach aplikacji bazujących na Blazorze. Pierwsza to aplikacja pisania po stronie serwera, gdzie komunikacja odbywa się za pomocą SignalR. Mamy wówczas klasyczny przykład strony klienckiej odwołującej się do serwera poprzez zapytania. Drugi zaś typ aplikacji to strona, która bazuje na WebAssembly i wykonuje cały kod po stronie przeglądarki. To właśnie ten ostatni rodzaj wykorzystania Blazora jest najbardziej nowatorski w świecie .NET. Pozwala on na tworzenie widoków w Razorze, które będą utrzymywane po stronie klienckiej (w przeglądarce) wraz z całym kodem napisanym w C#.

W tym momencie, aby przetestować działanie Blazora należy pobrać .NET Core 3.0 SDK w wersji Preview, a także Visual Studio 2019 również w wersji podglądowej. Dodatkowo przyda się również wtyczka do VS, która posiada szablony z projektami do Blazora. Wyposażeni w te narzędzia można testować nowytwór od Microsoftu.

Szablon Blazora (w wersji klienckiej) ukrywa się w gałęzi ASP.NET Core Web Application:

W tym momencie można już przetestować jak Blazor działać będzie w naszej przeglądarce. Sam kod jest bardzo znajomy dla osób, które tworzyły choć trochę strony w Razorze. Widzimy połączenie html ze wstawkami typowo C#. Można korzystać w tym momencie z C# i JavaScriptu, jedno niewyklucza drugiego.

Po kompilacji kod będzie całkowicie przesłany do przeglądarki w postaci pliku dll. Można zaobserwować to podglądając jakie dane pobierane są przy załadowaniu strony:

Widzimy tu sporo plików dll, w tym nasz skompilowany projekt, a także środowisko uruchomieniowe .NET w postaci Mono pod WebAssembly. Nic nie stoi zatem na przeszkodzie, aby debugować  kod C# bezpośrednio w przeglądarce. Warto to jeszcze raz podkreślić, że C# będzie uruchamiany z wykorzystaniemWebAssembly, zatem nie ma tu mowy o żadnym JavaScripcie. Z drugiej strony Blazor nie stara się wyprzeć JavaScriptu. Oba te języki mogą wspólnie działać i się uzupełniać.

Jak to działa? No cóż, jest to na ten moment wersja rozwojowa i to dość mocno czuć. Oprócz pobranych testowych wersji narzędzi, sam Blazor jest mocno niestabilny. W czasie pisania tego artykułu najnowsza wersja preview 6 Blazora miała bug, który nie pozwalał na debugowanie po stronie przeglądarki. Również ilość przesyłanych danych jest na ten moment spora, gdyż w niemalże pustej aplikacji strona zaciąga z serwera ponad 2.5 MB danych. To dużo.

Napiszmy jednak coś, więcej z użyciem zewnętrznych danych pobieranych z WebAssembly (od strony klienckiej). W tym celu wykorzystamy testowe API zwracające zdjęcia (https://jsonplaceholder.typicode.com/photos/).

Strona jest dość prosta, ale posiada kilka ciekawych elementów, które warto omówić. Cały kod wygląda następująco:

Na samym dole widzimy deklarację klasy Photo, która zawiera dane pojedynczego zdjęcia z API. Tuż nad deklaracją klasy Photo i właściwością photos (listy zdjęć) widźmy metodę OnInitAsync, która odpalana jest po wyrenderowaniu strony. Umieściłem w niej pobieranie danych wprost z API i rzutowanie bezpośrednio na listę Photo. Z racji tego, iż API zwraca sporą listę (i nie można jej ograniczyć poprzez API), po zaciągnięciu danych wybieram tylko pierwszych 10.

W kodzie powyżej znajduje się również if, który sprawdza czy zdjęcia już załadowały się czy jeszcze nie. W momencie załadowania uruchamiana jest pętla, która tworzy wiersze w tabeli. Warto zauważyć, że podobnie jak ma to miejsce chociażby w Angularze, zmienne są monitorowane automatycznie. Dzięki temu podstawienie danych pod zmienną photos, spowoduje wykonanie warunku z else. Co ciekawe, w kodzie html używając C# nie musimy sprawdzać nullowalności (w danym przykładzie elementu null w liście nie wyrzuci wyjątku).

Strona z danymi zwracanymi z API wyglądać będzie tak:[img=code4]Podsumowanie, czyli co z tym BlazoremBlazor jest ciągle w wersji rozwojowej i jeszcze daleka droga do tego, aby móc mówić o stabilności i zacząć go szerzej testować. Microsoft chce również wydać finalnego Blazora razem z .NET Core 3, czyli na jesień 2019, ale nie wydaje mi się, aby gigant z Redmond zdążył z wypuszczeniem stabilnego wydania w tym terminie. Nawet jeśli ta sztuka się uda, to zapewne Blazor jeszcze co najmniej do wersji .NET 5 będzie tylko ciekawostką, aczkolwiek warto już teraz poznać ten projekt.

Sam Blazor jest kreowany również jako framework, w którym mogą odnaleźć się osoby piszące do tej pory w WebFormsach (które nie trafią już do .NET 5). Porównanie jest z deka osobliwe, ale pokazuje kierunek rozwoju projektu, czyli szansy na wdrożenie języka C# jeszcze bardziej w technologie web, podobnie jak chciano zrobić to z nieszczęśliwymi WebFormsami.

Powodzenie Blazora ciężko jest przewidzieć. Często mówi się, że pozwoli on backendowcom szybciej wejść w świat web, a także łatwiej będzie tworzyć jednolite zespoły pod kątem technologii, gdyż po stronie klienckiej i serwerowej działać będzie mógł ten sam C#. Czas pokaże czy tak się stanie. Idea wydaje się słuszna, ale dużo będzie tu zależeć od szczegółów jak szybkość, prostota działania, rozmiar bibliotek i dostosowanie drobnych szczegółów implementacyjnych Blazora do własnych potrzeb.

Na ten moment jest za wcześnie, aby cokolwiek oceniać, ale jest to dość odważne posunięcie Microsoftu. Obok ASP.Net Core, który zdążył wyrosnąć z bolączek wieku dziecięcego, Blazor kreuje się jako ciekawostka, która może za rok będzie mogła być użyta na produkcji w niewielkim projekcie. Sam podchodzę do tej nowinki z rezerwą, gdyż co jak co, ale technologie frontendowe, zmieniają się bardzo często, a Blazor wcale nie musi być wyjątkiem. Z drugiej strony pisanie w nim jest bardzo przyjemne i domyślam się, że może być ciekawą alternatywą w frameworkach SPA. Warto śledzić ten projekt i bez wątpienia w najbliższych miesiącach będzie się on dynamicznie zmieniał i kształtował, a dopracowaną wersję zapewne poznamy w przyszłym roku. Mam nadzieję, że będzie na co czekać.