Blazor to przyszłość dla programistów C#

27 września 2020 o 20:07 Autor:

W ostatnim czasie zacząłem mocniej interesować się technologią, którą Microsoft ogłosił pierwszy raz 2 lata temu – w 2018 roku. Chodzi o framework Blazor. Teraz kiedy całość zbliża się do wersji produkcyjnej uważam, że będzie to gigantyczny game changer dla programistów pracujących z technologiami Microsoftu.

O czym my mówimy?

Samo rozwiązanie w postaci Blazora od początku było ściśle związane z technologią WebAssembly, która wprowadza możliwość uruchamiania „natywnego” czy też raczej skompilowanego do postaci binarnej kodu w przeglądarce. Więc jest to pewnego rodzaju krok w stronę wyeliminowania monopolu JavaScriptu w świecie aplikacji frontendowych.

W tym momencie wszystkie liczące się przeglądarki (poza Internet Explorerem 11…) wspierają WebAssembly. A sama technologia przygotowana jest dla języka C/C++. Tzn. dla tych języków istnieje oficjalne wsparcie.

C# dla przeglądarek?

Jeśli mówimy o Blazorze to sytuacja wygląda w ten sposób, że inżynierowie Microsoftu przygotowali specjalną wersję frameworka Mono, znaną programistom .NET pod Linuxem, która jest skompilowana właśnie do WebAssembly. I własnie z użyciem Mono uruchamiany jest nasz kod. Więc po prostu mamy środowisko .NET w przeglądarce użytkownika.

A jak to się dzieje, że ten .NET jest dostępny w przeglądarce? Czy Microsoft ma jakąś specjalną umowę z dostawcami softu lub systemów? A może coś trzeba instalować? Nic z tych rzeczy.

Działa to podobnie jak w przypadku aplikacji pisanych z użyciem np. Angulara – wszystko trzeba na początku pobrać.

I w tym momencie może Ci się zaświecić czerwona lampka – przecież .NET na komputerze jest taki ciężki! To mam otwierając stronę pobierać te kilkadziesiąt albo kilkaset megabajtów? Otóż nie. W tym momencie pierwsze wersje Mono dla WebAssembly ważą około 4MB (!). Przy przeciętnej prędkości internetu, zwłaszcza w sieciach wewnętrznych jest to tyle co nic. A już teraz Microsoft jest pewny, że jest duży potencjał na poprawę tego wyniku.

Dlaczego Blazor to przyszłość?

Każda firma dąży do minimalizacji kosztów i maksymalizacji przychodów. A Blazor jest właśnie odpowiedzią na te dążenia.

Tempo i koszty

Po pierwsze, budując aplikacje webowe zwykle w większej firmie tak czy inaczej mamy dział zajmujący się wizualną częścią aplikacji (a więc przygotowaniem designu interfejsu, a nieraz też napisaniem styli dla niego). Więc wprowadzając Blazora można wziąć ten gotowy design i dać go programistom C# żeby go wdrożyli. Bez konieczności poświęcania nawet tygodnia na naukę kompletnie nowego świata jakim są frameworki frontendowe typu Angular czy Vue. Więc jako firma możemy wziąć zespół specjalistów od C# i praktycznie od razu będą oni pisali frontendowy, dynamiczny kod bez popełniania błędów początkujących czy trafiania na nieprzewidziane problemy (kto zaczynał zagłębiać się w JavaScript ten wie ile pułapek tam czeka).

Także minimalizujemy czas potrzebny na przerzucenie programistów do pisania kolejnego elementu aplikacji. A dodatkowo nie musimy już zatrudniać typu osób stricte od frontendu. Więc tniemy koszty w tym obszarze bez utraty jakości czy tempa pracy.

Jakość od pierwszego wejrzenia

Po drugie, ograniczamy błędy. Co by nie mówić to statyczne, silne typowanie pozwala wykryć naprawdę sporo błędów już w trakcie kompilacji. A jak jeszcze do tego dodamy fakt, że nasz frontend operuje na dokładnie tych samych klasach co backend to kolejny „punkt zapalny” nam odpada. Poza tym skoro już wzięliśmy tych programistów C# z poprzedniego punktu to znają oni frameworki do testów jednostkowych dla języka C#. I spokojnie mogą ich użyć również dla frontendu. A wiadomo, że znane środowisko to pewniejsze środowisko i mniej błędów wynikających z bycia początkujacym. Do tego mając ten sam język i strukturę projektu dużo łatwiej jest stosować te same dobre praktyki co w backendzie.

Więc po raz kolejny – nie trzeba zatrudniać kolejnego zespołu z zupełnie innym zestawem umiejętności albo poświęcać środki na nauczenie się zupełnie czegoś nowego przez obecny zespół, który dzięki temu od razu robi kod wg swoich najlepszych praktyk. A to oznacza kolejne oszczędności.

Jeden by wszystkimi rządzić

Po trzecie w końcu, Blazor tak jak C# i ASP.NET Core to technologia Microsoftu. Więc stosując go firma ma wsparcie 100% stosu technologicznego u jednego dużego dostawcy. Więc nie musi np. podpisywać umów z supportem wielu firm.

Poza tym programowanie w Blazorze oznacza praktycznie zawsze korzystanie z tego samego Visual Studio, z którego korzystają już i tak programiści backendowi. Więc można zminimalizować liczbę narzędzi jakimi zarządza dział IT i jakie ewentualnie trzeba zakupić (chociaż akurat dla Angulara czy Vue świetny jest Visual Studio Code, który jest w 100% darmowy).

Więc mamy kolejny punkt, który potencjalnie daje oszczędności w firmie. A jednocześnie nadal pozwala tworzyć dynamiczne aplikacje, których z samym ASP.NETem nie zrobimy nie posiłkując się do tej pory JavaScriptem.

Dodatkowo same komponenty napisane w Blazorze bardzo łatwo można współdzielić w firmie poprzez paczki NuGeta. A z doświadczenia wiem, że większe firmy, które opierają aplikacje o technologię .NET prędzej czy później i tak „produkują” wszelkiego typu paczki z gotowymi bibliotekami wewnętrznymi. I nasze elementy frontendu mogą być po prostu kolejną biblioteką, którą instaluje się w projekcie tak jak wszystkie inne.

Czy to dla Nas jedyna droga?

W porządku, przedstawiłem zalety używania Blazora z perspektywy firmy. I sprowadzają się one do jednego wyrazu – oszczędności. Czy to czasu czy też pieniędzy. A zwykle jednego i drugiego.

Ale co z Nami – programistami?

Czy w takim razie będziemy zmuszeni do przejścia na Blazora? Albo z drugiej strony czy w takim razie nie musimy w ogóle już poznawać innych technologii frontendowych nawet jak jesteśmy albo planujemy być full-stackami?

Absolutnie nie!

Po pierwsze – o ile Blazor moim zdaniem świetnie sobie poradzi w przypadku wewnętrznych aplikacji dla firmy działających w oparciu o platformę .NET to jednak nie tylko taki soft powstaje. Są też aplikacje dla użytkowników zewnętrznych. I w tym przypadku mimo wszystko Blazor ze swoją wagą przy pierwszym uruchomieniu i mimo wszystko mniejszym wsparciem w przeglądarkach niekoniecznie będzie dobrym wyborem. Chociaż pewnie wraz z kolejnymi wersjami i zmianami na rynku przeglądarkowym będzie się to zmieniać. Poza tym Blazor ServerSide rozwiązuje problem kompatybilności bo renderuje widok po stronie serwera.

Po drugie – nie każda firma może sobie pozwolić na przejście na Blazora. Bo może ma już zespół programistów, który świetnie sobie radzi z frontendem. I do tego mają już uzbieraną masę komponentów czy praktyk, które szkoda wyrzucać do kosza i wprowadzać zupełnie nowe. Więc ta wiedza na temat JavaScriptu nadal będzie nam potrzebna. Chociażby po to żeby być cennym programistą również w trochę starszych projektach albo w firmach gdzie nie można sobie pozwolić na przejście na Blazora.

Jak żyć?

Dobre pytanie. Ale wg mnie teraz jest świetny moment żeby wchodzić w to i utonąć po uszy. Bo temat jest świeży i zaraz pewnie zaczną się pojawiać pierwsze oferty pracy wymagające Blazora. Więc będziemy mieli przewagę na starcie.

I możesz powiedzieć, że cały czas mówię tutaj o byciu full-stackiem. A przecież Ty piszesz tylko backend i nie brudzisz rąk frontendem. Świetnie – bo Blazor jest właśnie tym co daje Ci najlepszy kompromis. Możesz poszerzyć zakres umiejętności bez dotykania JavaScriptu, którym pewnie od zawsze gardzisz. Więc jako backendowiec nie musisz wchodzić do zupełnie innego świata. Teraz możesz poszerzyć swoje kompetencje i wejść w nowy obszar cały czas używając tych technologii, które i tak znasz. Czy to nie jest piękne?

Sam zacząłem mocniej zgłębiać to co Microsoft daje. Dokumentuję budowanie projektu z użyciem Blazora w filmach na Youtubie. Tutaj znajdziesz playlistę.

Poza tym założyłem grupę na Facebooku gdzie mam zamiar zbudować społeczność Blazora w Polsce. Także możesz być pierwszy wśród specjalistów! Dołącz do niej. Mam nadzieję, że w niedługim czasie zbudujemy mocną ekipę specjalistów tej, jakby nie patrzeć, świeżej technologii.

4 komentarze

  • Gdn pisze:

    Jakiś czas temu MŚ usilnie promował technologię Silverlight, która była odpowiedzią na Flasha i HTML, gdzie pisało się kod po stronie klienta w c# i XAML. I zdaje się, że SL był szybszy niż webassembly, wsparcie w VS miał też doskonałe.
    A po jakimś czasie MŚ zrezygnował z tej technologii, teraz SL nie wspiera żadna nowa przeglądarka, nawet microsoftowy Edge.
    Ja wolę standardowe frameworki webowe, np. Angular.

    • Marek Zając pisze:

      Tylko, że Silverlight tak jak Flash, żeby był wspierany na jakiejś platformie wymagał wtyczki do przeglądarki przygotowanej przez jednego producenta. Tutaj Microsoft korzysta z otwartego standardu, którego implementacja nie jest po jego stronie. Więc użytkownik nic nie musi instalować dodatkowo żeby korzystać z takiej aplikacji.
      Więc wsparcie lub jego brak jest na takim samym poziomie jak np. Angulara, który na starszych przeglądarkach też tak po prostu nie ruszy, i zależy od dostawców przeglądarek.
      To jest ta ogromna zmiana, która wg mnie będzie kluczowa. Bo już nie ma sytuacji, że przestaną wydawać wtyczkę. Jedynie mogą przestac to wspierać w nowym Visual Studio i SDK ale istniejące strony, w przeciwieństwie do Flasha i Silverlighta, nadal bedą działać i będzie je można rozwijać w starszych narzędziach.

  • Katarzyna pisze:

    Jest to możliwa przyszłość dla programistów, którzy będą mogli tworzyć frontend w C# zamiast w znienawidzonym JavaScripcie. I to wszystko bez instalowania wtyczek i innych dodatków, oparte na standardach.

  • Aneta pisze:

    W tym momencie Blazor może funkcjonować w dwóch trybach, Client-Side gdzie wszystko wykonuje się po stronie przeglądarki oraz Server-Side – gdzie kod wykonuje się po stronie serwera.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *