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.

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ć.