MARGO

Aktualności

Blazor – okiem sceptyka

Autor: Paweł Gorczyński Senior Software Engineer

19/06/2019

U większości programistów mojego pokolenia* na hasło “.NET w przeglądarce” zaczyna grać w głowie stary kawałek Maryli Rodowicz – „Ale to już było”. Oczywiście mam na myśli technologię Silverlight.

 

Dla tych, co nie pamiętają – dawno, dawno temu w czasach, kiedy przeglądarki naprawdę niewiele umiały, firmy IT kombinowały na różne sposoby, by zapełnić lukę funkcjonalną i umożliwić tzw. Rich User Experience na stronach WWW. Pierwszy i najbardziej rozpowszechniony był oczywiście Adobe Flash. Microsoft dołączył w 2007 roku wypuszczając Silverlighta, czyli okrojoną maszynę wirtualną .NETu dystrybuowaną jako plugin do przeglądarki (ostatnia wersja waży ~13 MB). Językiem definicji widoków był znany z WPFa XAML (również w wersji okrojonej) i wiele osób (w tym ja) zjadło zęby próbując mieć jeden codebase działający zarówno w przeglądarce jak i jako aplikacja okienkowa.

Blazor - okiem sceptyka

Rys. 1. Hello Silverlight

 

Rewolucja, jaką przyniósł standard HTML 5 i stowarzyszone technologie takie jak Canvas czy WebGL, jak i rozpowszechnienie się urządzeń mobilnych, spowodowały, że Silverlight umarł śmiercią naturalną (support przewidziany jest mniej więcej do 2021 roku).

 

Po co zatem wchodzić dwa razy do tej samej rzeki i czy tym razem będzie inaczej? I w czym Blazor ma być lepszy od Silverlighta?

 

HTML SPA

W założeniu, Blazor ma być frameworkiem służącym do tworzenia aplikacji typu SPA przy użyciu zwykłego HTMLa wzbogaconego o składnię @Razora. A zatem, w przeciwieństwie do SL, nie ma potrzeby uczenia nikogo całego XMLowego dialektu, a wygląd aplikacji definiują powszechnie szanowane i uwielbiane CSSy :). Sam Razor natomiast jest na tyle prosty i nieinwazyjny, że każdy webdesigner szybko się w nim odnajdzie. A zatem zdecydowanie na plus.

 

blazor

Rys. 2. Hello Blazor

 

W obecnej wersji Blazor dostarcza dość standardowy zestaw feature’ów znany z innych frameworków SPA, takich jak routing, komponenty, dependency injection i interop z Javascriptem.

 

Wasm

Dużo ciekawiej robi się, kiedy zajrzymy za kulisy. W przeciwieństwie do Silverlighta, który używa okrojonej wersji .NET Runtime do uruchamiania w przeglądarce kodu CIL, Blazor wykorzystuje mono-wasm, czyli swoistego translatora tłumaczącego CIL na Wasm już po stronie klienta.

 

Czym zatem jest rzeczony Wasm?

 

WebAssembly, bo tak brzmi pełna nazwa standardu, jest rodzajem pośredniego kodu binarnego uruchamianego w przeglądarce (i działającego z natywną prędkością), niezależnego od oryginalnego języka, w którym została napisana aplikacja (istnieją kompilatory do większości współczesnych języków programowania). Wasm jest już całkiem szeroko wspierany, a zatem z kompatybilnością nie powinno być problemów. Nie są też potrzebne żadne dodatkowe wtyczki.

 

Jakie są wady tego rozwiązania?

 

Na pewno odpada możliwość natywnego CLRowego debugowania (na pocieszenie pozostaje fakt, że Chrome ma wsparcie dla debugowania Wasma z poziomu przeglądarki).

Drugi istotny problem to konieczność pobrania wraz z wszystkimi używanymi assembly’ami (asamblażami? – przemilczę microsoftowy “skład”) w postaci binarnej, a to waży niemało.

 

Pewną ciekawostką jest Server Side Hosting model, w którym kod .NETa wykonywany jest po stronie serwera, natomiast wszystkie eventy przesyłane są na serwer przez SignalR. Rozumiem, że jest to próba ograniczenia narzutu na transfer danych, ale oczywiste wady tego rozwiązania, jak konieczność używania łącza o bardzo niskim opóźnieniu bardzo ograniczają jego potencjalne wykorzystanie praktyczne. Nie wspominając już o tym, że to samo można osiągnąć już w isniejącym ASP.NET i Blazor nie jest tu do niczego potrzebny.

 

Moim zdaniem

Aktualnie Blazor jest frameworkiem eksperymentalnym. Czy ma szanse na szerszą adaptację? Patrząc, jak silna jest konkurencja (Angular, React, …) w segmencie, w którym się sytuuję – śmiem wątpić. Przedziwna żywotność Javascriptu, który nie dość, że nie chce zginąć, to jeszcze zdobywa nowe przyczółki, również nie przemawia na korzyść Blazora.

 

Dostrzegam jednak jedno miejsce, gdzie Blazor mógłby zdobyć potencjalnie przewagę – mianowicie obliczenia wielowątkowe. Sam Wasm posiada ekperymentalne wsparcie dla wielowątkowości, niestety póki co mono-wasm pozostaje wąskim gardłem i nawet po włączeniu wsparcia dla threadów wasmowych w Chromie, próba stworzenia nowego wątku kończy się smutnym komunikatem:

 

WASM: WASM doesn’t support threading

components.webassembly.js:1 Uncaught (in promise) Error: System.ExecutionEngineException: Couldn’t create thread.

 

*Jako punkt odniesienia w tym artykule przyjąłem datę 9 grudnia 2011 czyli dzień premiery Silverlight 5 – ostatniej wypuszczonej dużej wersji.

 


Autor: Paweł Gorczyński Senior Software Engineer