Czy Blazor ugruntował się na rynku?

Hej, wpadł mi w ręce stary artykuł:
https://www.linkedin.com/pulse/czy-javascript-si%C4%99-ko%C5%84czy-poznaj-blazor-webassembly-artur-wi%C5%9Bniowski/?originalSubdomain=pl
O blazorze z 2019 roku... powiedzcie mi (osoby które pracują w .NET), blazor zadowomowił już się ? czy dalej jest nowościa?
Bo minęły już 4 lata... i powiem szczerze że za wiele nie słyszałem o jego wdrożeniach :( albo nikt się nie chwali.

Tak, tytuł jest Clickbait'em. JavaScript się nie kończy, skończy się natomiast moim zdaniem jego bezwzględna dominacja w świecie kodu wykonywanego w przeglądarkach po stronie klienta. Nadciąga alternatywa.

rotfl, lol. dominacja javascriptu się nie skończy w przewidywalnej przyszłości. co więcej, nawet typescript nie zawsze jest wybierany przez frontendowców:

co prawda filmik dotyczy bibliotek, a nie aplikacji końcowych, ale i tak pokazuje, że frontendowcy wolą kacze typowanie niż "zbyt trudne" typy.

na blazora był wielki hype, zwłaszcza blazora w wersji webassembly, a głównym wodzirejem tego cyrku na tym forum był @WeiXiao :) ciekawe jakie ma z blazorem doświadczenia komercyjne, o ile jakiekolwiek ma.

Tutaj znajdziesz kilka ogólnych opisów zastosowania.

Ferdynand Lipski napisał(a):

Tutaj znajdziesz kilka ogólnych opisów zastosowania.

a mi to wygląda na EFEKT końcowy - tego co osiągnięto, a chyba nie o to chodzi bo każda z tych stron mogła być równie dobrze w pehape z jsem naklepana.
Tu chodzi o to, że jak szukasz pracy i wpiszesz blazor to masz tyle ofert, że możesz w nich przebierać czy raczej jak cię zwolnią to trzeba się przebranżowić bo nie masz szans na robotę. O to czy są do tego porządne narzędzia czy trzeba w notatniku kod klepać. Czy serwer, który jest w stanie to obsłużyć jest na co setnym hostingu czy na każdym. To, że ktoś w tym jakąś stronę naklepał to NIC nie znaczy

Pracownicy chcą pracować w modnych technologiach, bo chcą mieć przydatnego skilla. Pracodawcy tworzą projekty w modnych pracownikach, żeby mieć pracowników. Myślę, że nawet jak znajdziesz C# chętnych do klepania frontu to wybiorą tradycyjnego JSa.

Taki blazor musiałby być naprawdę kilka lig wyżej od standardowego stacka, żeby ktoś się na niego przerzucił. A z tego co czytam pobieżnie to Blazor jest/był po prostu wolny.

Dobrym kontargumentem w podobnej sytuacji jest Flutter (w mobilkach), który ma jakąś tam rosnącą niszę z uwagi na:

• Google jest dobrze widziany jako dostawca takiej technologii, bo trzymają połowę rynku mobile w garści
• multiplatform, czyli to co chce każdy i to, co wielokrotnie się pojawiało i gineło. Więc potrzeba na rynku jest
• dobra wydajność
• nowe i świeże środowisko, gdzie można było sobie pozwolić na zbudowanie wszystkiego od zera vs. C#, który trzyma za sobą bagać wczesnych lat 2000. Dla niezdecydowanych devów familiarity i welcomeness to ogromny atut

slsy napisał(a):

Taki blazor musiałby być naprawdę kilka lig wyżej od standardowego stacka, żeby ktoś się na niego przerzucił. A z tego co czytam pobieżnie to Blazor jest/był po prostu wolny.

Myślę, że w blazor nigdy nie chodziło o szybkość, tylko żeby móc pisać w cywilizowanym języku.

Słabo sie ugruntował. Jakieś tam oferty na jobboardach się pojawiają dla fullstacków ASP + Blazor, ale niewiele. Zobaczymy co przyniesie w kontekście Blazora .NET 8, który zaraz będzie miał premierę. Strzelam jednak, że Blazor jak jest tak zostanie niszą dla wewnętrznych korpo apek opartych na stacku MS.

Ugruntował się na tyle, że jest stabilny i można pisać cokolwiek. DevExpress swoje UI XAF-a przepisał na Blazor-a.
Zgadzam się z @vestige że będzie raczej niszowy przez dłuższy czas ale nie ma czego się bać. Całkiem przyjemny. Szczególnie jeśli nie potrzebuje się jakiś cudów w UI.

Czy się ugruntował? Nie wiem, ale interesujące, że Microsoft nie zrobił nowej wersji MS Teams korzystając z Blazora tylko wybrał inną technologię.

Napisałem w Blazorze już kilka komercyjnych aplikacji, i widzę jak się rozwija z wersji na wersję. Korzystałem z wersji serwerowej oraz webassembly. Nie widzę w nim ograniczeń, bo jak potrzeba, można użyć jsinterop, czy framerowków do UI takich jak MudBlazor. Z mojej perspektywy, jest świetny, chociaż mogliby poprawić hotreload, aby zmiany w kodzie na gorąco były szybsze i częściej działały bez przeładowywania całej aplikacji.

Rok 2023 to rok, gdzie wrzucili mnie do projektu Blazorowego, po wcześniejszych wielu latach z Angularem.
No nie spodobał mi się.
Dalej jest lata za takim Angularem. Najgorsze jest to, że zaczęli w nim robić programiści wpf'owi, którzy nie znają się na frontendzie, przez co wszystko jest rozpieprzone i nieustandaryzowane i nikt nit wie do końca jak to traktować. Rozbawiło mnie jak główny architekt w korpo stwierdził, że chce się zupełnie odciąć od bootstrapa, css'ów i htmla i tylko własnych komponentów używać bo "my napiszemy to lepiej", a blazorowe apki to tylko będą tylko nasze blazorowe firmowe komponenty... bardzo nie podoba mi się to podejście, bo zeru customizacji.

główny architekt w korpo stwierdził, że chce się zupełnie odciąć od bootstrapa, css'ów i htmla i tylko własnych komponentów używać bo "my napiszemy to lepiej", a blazorowe apki to tylko będą tylko nasze blazorowe firmowe komponenty.

Uciekaj. Dawno temu (czasy ASP.NET Web Forms) otrzymałem w spadku projekt napisany przy pomocy takiego frameworka korporacyjnego wymyślonego przez programistów ze Szwajcarii. Na moje nieszczęście nie tylko GUI był "ustandaryzowany" ale też backend. Czyli wszystko trzeba było pisać w ściśle określony sposób. Jak były proste case'y to nawet to działało, problemy pojawiały się przy bardziej skomplikowanych wymaganiach, których nie przewidzieli szwajcarscy architekci tego frameworka i przykładowo trzeba było hackować kontrolki renderowane po stronie serwera javascriptem dodając albo nadpisując ich zachowanie.

@wasiu Ale to akurat nie jest zły pomysł, żeby mieć własne komponenty bo właśnie wtedy masz customizacje tylko na poziomie komponentu a nie strony. Właśnie wtedy masz standaryzację. No i to jest przeniesienie html-a do komponentów a nie wyeliminowanie.
@markone_dev: Ale to jest inna sytuacja bo Blazor Cię nie ogranicza w taki sposób jak zamknięty webowy framework z gotowymi komponentami. Jak Ci czegoś brakuje w komponencie to możesz dodać swój, dziedziczyć itp.

@jacek.placek: Ja zrozumiałem że OP będzie miał właśnie taki gotowy framework aka bibliotekę komponentów graficznych w blaze'orze napisaną przez jakichś firmowych pryncypałów których będą musieli używać w swoich apkach. Jak nie o to chodzi to nic nie pisałem :P

OP zalinkował ogólny artykuł o Blazorze. Nawet jak masz gotowe komponenty 3rd party to też możesz je zastąpić, dziedziczyć, zmieniać CSSy itd. możesz mieć kilka różnych zestawów komponentów w jednym projekcie.
Zestawy komponentów to nie frameworki. Chociaż są też frameworki na Blazorze i tam wtedy faktycznie jest trochę ograniczeń ale po "każdej" klasie/komponencie możesz dziedziczyć. Zależy jak głęboko chcesz zejść.
Ja mam np. własny TextEdit z edycją inline bazujący na SfTextBox od Syncfusion. Normalnie jest readonly a po kliknięciu jest edytowalny z ikonkami zapisu/anulowania. Preparowane Gridy ze spreparowanym widokiem i nadpisaniem jakichś akcji itp.

Zestawy mają też różne podejścia. Komponenty DevEXpress mają dużo własnych properties dla ostylowania komponentów a Sycfusion jedzie na klasach css.

W ASP.NET Web Forms też możesz sobie dziedziczyć i na bazie istniejących tworzyć swoje, ale szybko pojawi się problem z kompatybilnością bo jak zaczynasz sobie robić customizacje takich komponentów a korpo pryncypały zdecydują się zrobić update frameworka/komponentu(ów) to kończy się to drutowaniem i naprawianiem swoich customizacji przez tracisz masę czasu i energii i zamiast dostarczać wartość biznesową musisz użerać się z korporacyjnym frameworkiem. Nie muszę mówić że robiąc takie customizacje traci się gwarancję i support korpo pryncypałów.

Ale to ryzyko jest zawsze jak korzystasz z zewnętrznego kodu.
Czy poprawek po nowej wersji jest mnóstwo to zależy. Jak sobie każdy zewnętrzny komponent opakujesz we własne (kompozycją, bez dziedziczenia) to, ewentualnie, poprawiasz w jednym miejscu. Możesz bez dużych problemów podnienić "bazowe" komponenty na inne itp. Wszystko zależy od jakości tych komponentów.W biznesowej aplikacji to używam ze 20 różnych komponentów.
Ja używam DevExpress-a od ponad 10 lat i normlane jest to, ze po aktualizacji coś jest obsolete i trzeba zmienić, poprawić itp. ale jakoś nigdy nie było dramatu.

Ale to ryzyko jest zawsze jak korzystasz z zewnętrznego kodu.

Zewnętrzny kod np używane biblioteki możesz sobie owinąć dodatkową warstwą abstrakcji i z niej korzystać, przez co w przyszłości teoretycznie łatwiej będzie ci zmienić implementację czy zewnętrzną bibliotekę. Z GUI już tak łatwo nie jest że zrobisz se interfejs ILogger i w zależności od mody będziesz sobie przełączał pomiędzy Serilogiem, NLogiem czy Log4Netem.

Ja używam DevExpress-a od ponad 10 lat i normlane jest to, ze po aktualizacji coś jest obsolete i trzeba zmienić, poprawić itp. ale jakoś nigdy nie było dramatu.

Porównujesz teraz komercyjny produkt za którym stoi masa ludzi planująca i analizująca każdą zmianę do wewnętrznego korpo frameworku pisanego przez grupkę zapalonych korpo pryncypałów w celu wyrobienia sobie visibility i awansu na wyższe stanowiska w myśl sentencji A po mnie choćby potop :P

Akurat z komponentami UI Blazora jest dość prosto. Chyba tylko API komponentu Cię ogranicza ale to zawsze tak jest.
Jedynym jakims ograniczeniem Blazora jest współpraca z JS jeslo ktos naprawde potzrebuje. Trzeba trochę kodu doklepac.
Co się reszty to zgoda. Ja w swojej niszy nie używam żadnych większych frameworkow bo nigdy nie wiadomo co w przyszłości będzie.

Bardzo lubię Blazora i ucieszyłem się, gdy wreszcie mogłem tworzyć front w "cywilizowanym" języku :) Niestety, Blazor nie ma jeszcze swojej pozycji. Niestety firmy wciąż wybierają JavaScript (w jakiejkolwiek postaci). Być może za kilka lat... Może z 10 i Blazor albo stanie się pełnoprawną metodą do robienia frontów w aplikacjach komercyjnych, albo upadnie.
Osobiście mam nadzieję, że przetrwa i będzie można w nim klepać fronty :)

Juhas napisał(a):

Bardzo lubię Blazora i ucieszyłem się, gdy wreszcie mogłem tworzyć front w "cywilizowanym" języku :) Niestety, Blazor nie ma jeszcze swojej pozycji. Niestety firmy wciąż wybierają JavaScript (w jakiejkolwiek postaci). Być może za kilka lat... Może z 10 i Blazor albo stanie się pełnoprawną metodą do robienia frontów w aplikacjach komercyjnych, albo upadnie.
Osobiście mam nadzieję, że przetrwa i będzie można w nim klepać fronty :)

Wszystko kiedyś było nowe ;)

Blazor(server side) + MudBlazor i to się nadaje tylko do apek do wewnętrznego użytku w firmach Bardzo przyjemne ale jakoś się nie wybiło. Wszędzie ten next js

Angular > Blazor > React

Svelte wydaje się być fajnym frameworkiem, tak samo Astro może wiele zmienić.
Z Vue nie miałem okazji pracować.