Zalety i wady Blazora po roku w projektach. Czy wykorzystałbym go jeszcze raz?

Na Blazora natrafiłem w roku 2020, gdy model hostingowy WebAssembly był jeszcze oznaczany jako gotowy do wykorzystywania na produkcji w niedalekiej przyszłości. Zaciekawiony jego możliwościami napisałem kilka własnych projektów, aby przetestować jak on działa oraz czym tak właściwie jest. Udało mi się nawet na bazie moich doświadczeń przedstawić Blazora mojej lokalnej społeczności w ramach prezentacji. Po pewnym czasie przy okazji realizacji projektów komercyjnych padł pomysł, aby wykorzystać Blazora zamiast standardowych frameworków oraz bibliotek JavaScript. Okazało się to bardzo dobrym pomysłem, realizowane projekty sprawdzają się równie dobrze jak te pisane w JavaScripcie. Dodatkowo za takim podejściem przemawiał fakt posiadania sporej bazy kodu, którą można było wykorzystać.

Od pierwszej wersji Blazora wydanej w marcu 2018 mijają powoli 3 lata, a na dodatek zbliża się koniec roku, czyli naturalny okres podsumowań. To wszystko skłania do podzielenia się moimi spostrzeżeniami na temat Blazora. Na początek temat zalet i wad z perspektywy napisanych projektów.

tl;dr

Dla wszystkich tych, którzy chcą szybko przeskanować wady i zalety Blazora oto zestawienie

Zalety
  • Duże wsparcie od strony community,
  • Zaangażowanie Microsoftu w propagowanie technologii,
  • Możliwość wykorzystania kodu z projektów backendowych,
  • Nowa technologia, która nie musi jeszcze wspierać zbyt wielu wersji wstecz, aby zachować kompatybilność,
  • Przenoszenie umiejętności developerów .NET,
  • Wykorzystanie istniejących bibliotek .NET,
  • Dobre i powszechnie znane IDE – Visual Studio oraz Visual Studio Code,
  • Skrypty cli ułatwiające budowanie aplikacji w CI,
  • Wbudowane komponenty i funkcjonalności wspierają szybkie i łatwiejsze tworzenie aplikacji,
  • W przyszłości możliwość wykorzystania również w projektach Desktopowych i mobilnych,
  • Wsparcie firm zajmujących się przygotowywaniem toolboxów.

Wady
  • Wydajność aplikacji może stanowić problem przy bardziej zaawansowanych projektach,
  • Czas ładowania aplikacji będzie dłuższy od odpowiedników w JavaScripcie,
  • Wielkość pobieranych danych może być odczuwalnym problemem,
  • Rozpoznawalność znacznie mniejsza niż frameworków JavaScriptowych przez co trudniej znaleźć developera z doświadczeniem,
  • Brak wsparcia w pisaniu projektów w innych językach niż C#,
  • W przypadku WebAssembly uzależnienie od parametrów urządzenia na którym jest uruchamiane.

Zachęcam jednak do zapoznania się z moją argumentacją zalet i wad, szczególnie w przypadku, gdy nie do końca zgadzasz się z danym punktem. W takim wypadku mam nadzieję, że rozwinięcie tematu rozwieje wątpliwości.

Zalety

Community

Mimo, że Blazor nie ma takiej rozpoznawalności, a jego społeczność nie jest tak duża jak frameworków JavaScriptowych to jest bardzo zaangażowana. Na stackoverflow do tej pory powstało 11 tyś. pytań, kod źródłowy Blazora jest dostępny na githubie jako część ASP.NeT Core i ma obecnie 26.7 tyś gwiazdek, na jego kolejne wersje mają wpływ developerzy pracujący w swoich projektach. Do tego ciągle powstają kolejne artykuły o projektach pisanych w Blazorze.

Strony z których ja często korzystam to

Do tego wiele nowych postów jest umieszczanych na agregatorach dla .NET Developerów i newsletterach.

Microsoft również jest mocno zaangażowany w rozwój Blazora. Nie tylko nadzoruje prace nad nim, lecz dostarcza wielu pomocnych materiałów. Na docs.microsoft.com można znaleźć dokumentacje Blazora oraz opis integracji backendem w ASP.NET Core, do tego Microsoft na swoich konferencjach poświęca sporo czasu na Blazora, to samo dotyczy kanałów na YouTube, takich jak dotNET oraz Microsoft Developer.

Dzięki tak dużemu zaangażowaniu community oraz udziałowi developerów przy jego tworzeniu wejście w świat aplikacji frontendowych z wykorzystaniem Blazora jest proste i intuicyjne. Artykuły i wsparcie powstają nie tylko w przypadku prostych aplikacji i podstaw, lecz również przy bardziej zaawansowanych problemach. Na githubie istnieje nawet repozytorium ze zbiorem najbardziej wartościowych projektów. Te wszystkie elementy wspierają wejście nowych developerów do Blazora, a nawet tworzenie całych projektów komercyjnych z jego wykorzystaniem.

Wsparcie i migracje bibliotek JavaScriptowych

Kontynuując temat community jego zaangażowanie jest również zauważalne przy migrowaniu bibliotek JavaScriptowych do Blazora. Istniejące biblioteki napisane w JavaScripcie przerabiane są na takie, które korzystają z komponentów Blazorowych.

Przykładami wartymi docenienia są

Powstają nawet biblioteki, które wykorzystują wyłącznie Blazora, takie jak MudBlazor.

Blazor ma także wsparcie firm zajmujących się tworzeniem toolboxów z komponentami dla projektów w różnych technologiach. Mam tu na myśli DevExpress, SyncFusion czy Telerik. Wykorzystanie tych komponentów bez względu na to czy zdecydujemy się na wersje płatne czy darmowe przyśpieszy pisanie aplikacji, a my możemy skupić się na dostarczaniu nowych funkcjonalności zamiast na szczegółach implementacyjnych.

Wykorzystanie kodu

Pora na zaletę, które prawdopodobnie zdecydowała o tym, że projekty w ogóle decydują się na wykorzystanie Blazora, czyli wykorzystywanie kodu. Jeżeli mamy istniejący projekt z backendem napisanym w C# to całkiem prawdopodobne, że podobne bądź nawet identyczne modele znajdą się na frontendzie. Dosyć częstymi przypadkami wykorzystywania kodu wielokrotnie są walidacje czy serwisy do obliczeń.

Trwają prace nad wersjami desktopowymi oraz mobilnymi Blazora, więc projekty w których istnieje potrzeba utworzenia jednocześnie aplikacji mobilnej oraz webowej mogą zaoszczędzić czas na wykorzystaniu tego samego kodu z Blazorem.

Blazor pozwala na prostsze wejście do frontendu developerom, którzy do tej pory pisali aplikacje backendowe, a w przyszłości całkiem możliwe, że tworząc komponenty w Blazorze będziemy mogli je przenieść bez większego wysiłku nawet do aplikacji desktopowych i mobilnych. Dzięki pisaniu całej aplikacji w C# możliwe jest wykorzystanie doświadczenia i dobrych praktyk nabytych z projektów .NETowych.

Visual Studio jako IDE do pisania kodu

Wraz z Blazorem dostajemy nie tylko możliwość pisania aplikacji całkowicie w C# ale również jedno z najlepszych IDE dla developerów. Mam tu na myśli Visual Studio, które dodatkowo od wersji 2022 wraz z .NET 6 dostało wsparcie dla Hot Reload. Poza tym mamy intellisense z automatycznym uzupełnianiem kodu, wersje 64-bitową oraz template do tworzenia nowych projektów Blazorowych.

Jeżeli wolisz lżejsze IDE to istnieje również Visual Studio Code. Jest domyślnie okrojone z wielu funkcjonalności, które w razie potrzeby można doinstalować. W przypadku setupowania CI bądź tworzenia skryptów możliwe jest wykorzystanie dotnet-cli, czyli linii poleceń do tworzenia i budowania projektu.

Całość łączy się w zestaw narzędzi znacząco zwiększających produktywność i pozwalających developerom wykorzystać maksymalnie ich potencjał poprzez zredukowanie powtarzalnych czynności.

Produktywność

Na koniec zostawiłem temat dotyczący moich własnych doświadczeń w pisaniu aplikacji w Blazorze. W projektach, które realizowałem nie wystąpiły większe problemy przy ich tworzeniu. Dodawanie nowych funkcjonalności było tak samo płynne jak w frameworkach JavaScriptowych, a przy wykorzystaniu kodu wielokrotnie było to miejscami nawet sprawniejsze. Mogłem również przenieść doświadczenie z C# na projekty napisane w Blazorze. Sam framework zapewnia wsparcie przy tworzeniu formularzy, routingu czy obsłudze wyjątków, więc wszystkie niezbędne rzeczy mamy dostępne od razu po uruchomieniu projektu.

Wybór frameworka jest zawsze złożony i powinien być podejmowany na podstawie doświadczeń oraz umiejętności zespołu, istniejącej bazy kodu czy dopasowania potrzeb projektu do możliwości frameworka, lecz myślę, że w moim wypadku nie miałbym większego problemu z zasugerowaniem wykorzystania Blazora w projektach komercyjnych.

Aby mieć pełny obraz tego czym jest Blazor pora na opisanie jego mniej korzystnych stron, które wyszły podczas pisania w nim aplikacji.

Wady

Mała rozpoznawalność wśród developerów

Mimo, że community rozwija się bardzo szybko to Blazor nie jest na tyle znany co frameworki JavaScriptowe jak Angular czy React. Niestety jeszcze mu do tego sporo brakuje i ze względu na to, że Blazora można używać wyłącznie w połączeniu z C# to jego szanse na przebicie się do świadomości większej ilości developerów nie są zbyt duże.

Dla projektu oznacza to, że znalezienie doświadczonego developera w pisaniu aplikacji w Blazorze może być nie lada wyzwaniem. W tym wypadku trzeba postawić na .NET Developerów z umiejętnościami pisania kodu zarówno backendowego jak i frontendowego oraz dać im czas na migracje do Blazora.

Performance aplikacji

Rozpoczynając projekty w Blazorze trzeba mieć z tyłu głowy, że co jakiś czas należy sprawdzić jak aplikacja radzi sobie na słabszych urządzeniach. W zależności od modelu hostowania problem z wydajnością może pojawić się w różnych miejscach. Aplikacje Blazorowe cechują się dosyć przeciętną wydajnością i to co w ich odpowiednikach JavaScriptowych nie powodowałoby najmniejszych problemów w tym wypadku może wymagać refaktoryzacji na rozwiązanie bardziej optymalne bądź przeniesienia złożonych obliczeń na część backendową lub cachowanie wyników.

Należy również pamiętać, że w przypadku aplikacji Blazor WebAssembly część frontendowa wykonywana jest po stronie klienta, jeżeli nie mamy pewności co do tego na jakim urządzeniu będzie uruchamiana aplikacja to może stanowić to potencjalną przeszkodę i w tym wypadku warto rozważyć aplikacje Blazor Server.

Kolejnym problemem z wydajnością w Blazorze jest czas załadowania aplikacji, na początku przesyłany jest runtime .NET, więc najprostsza aplikacja napisana w Blazorze zajmuje około 2 MB, te bardziej skomplikowane mogą zajmować nawet 50 MB. W przypadku projektów w których czas uruchomienia oraz ilość przesyłanych danych ma znaczenie warto przemyśleć inne frameworki.

Wiele z opisywanych tu problemów zostało już znacząco poprawionych wraz z .NET 6, który dla Blazora przygotował AOT czy App Trimming. Możliwe, że gdy to czytasz to ten temat nie stanowi już problemu, więc warto sprawdzić najnowsze informacje na temat wydajności Blazora, bo jest to jeden z głównych obszarów nad którym obecnie pracuje zespół rozwijający Blazora.

Podsumowując ostatni rok w projektach z Blazorem upłynął mi w budowaniu aplikacji bez większych problemów i przeszkód. Jak na dosyć nową technologię w której spodziewałem się, że jeszcze istnieją pewne problemy do rozwiązania to Blazor zaskoczył mnie tym jak dobrze jest przemyślany i większość czasu spędziłem nad implementowaniem funkcjonalności zamiast szukać rozwiązania problemu, który jest specyficzny dla tego frameworka.

Mimo wszystko nie spodziewałbym się, że zyska na tyle uznania, aby był stawiany na równie z Angularem czy Reactem. Jest to bardziej dopełnienie ekosystemu Microsoftu, aby .NET Developer miał narzędzia do budowania wszystkich typów aplikacji od webowych po desktopowe czy mobilne. Myślę, że Blazor najlepiej sprawdzi się w wewnętrznych projektach firm czy urządzeniach IoT, które potrzebują interfejsu do interakcji.

Jeżeli Ty także w swoich projektach używasz Blazora to proszę podziel się swoimi spostrzeżeniami, chętnie posłucham opinii innych!

Jeżeli uznasz ten post za przydatny to proszę udostępnij go innym. Zapraszam również do mojego newslettera na którym regularnie udostępniam przedpremierowo artykuły, materiały wideo i wiele więcej.

Share via
Copy link
Powered by Social Snap