Blazor

1

Może dla wielu osób właśnie popełniam świętokradztwo, ale rzucam Vue na rzecz Blazor’a. Od kilku miesięcy pisałem sobie hobbystycznie program w Vue i myślę, że opanowałem go w niezłym stopniu m.in. napisałem cały interfejs do zarządzania użytkownikami w ASP.NET Core Identity czyli standardowe dodawanie i usuwanie użytkowników, zmiana hasła, przypisywanie do ról itp. Dlaczego rzucam Vue ? Zmęczyło mnie ciągłe przełączanie się z pomiędzy Vue i ASP.NET Core w którym tworzyłem API i wyszukiwanie błędów typu: czemu Json nie jest czytany jako Json. Pierwsze wrażenia jeżeli chodzi o serwerową wersję Blazor’a mam bardzo pozytywne.

2

Dlaczego piszesz Blazor'a, a nie Blazora?

Co do tematu to mnie nie przekonuje ten zachwyt Blazorem, ale za dużo styczności do tej pory nie miałem.

0
Saalin napisał(a):

Dlaczego piszesz Blazor'a, a nie Blazora?

Dlatego:
https://sjp.pwn.pl/poradnia/h[...]-w-wyrazach-obcych;11890.html

Co do tematu to mnie nie przekonuje ten zachwyt Blazorem, ale za dużo styczności do tej pory nie miałem.

Czyli na zasadzie, nie wiem, ale się wypowiem?

0
cw napisał(a):

Może dla wielu osób właśnie popełniam świętokradztwo, ale rzucam Vue na rzecz Blazor’a.

Oj tam, oj tam... ;-)

Od kilku miesięcy pisałem sobie hobbystycznie program w Vue i myślę, że opanowałem go w niezłym stopniu m.in. napisałem cały interfejs do zarządzania użytkownikami w ASP.NET Core Identity czyli standardowe dodawanie i usuwanie użytkowników, zmiana hasła, przypisywanie do ról itp. Dlaczego rzucam Vue ? Zmęczyło mnie ciągłe przełączanie się z pomiędzy Vue i ASP.NET Core w którym tworzyłem API i wyszukiwanie błędów typu: czemu Json nie jest czytany jako Json. Pierwsze wrażenia jeżeli chodzi o serwerową wersję Blazor’a mam bardzo pozytywne.

I ja miałem podobnie - jedna technologia i jeden język na front i backendzie to samo dobro.
Zwłaszcza jak się wszystko (lub w niewielkim zespole) rozwija samemu.

Nie ukrywam, że sam miałem podobne dylematy i Blazor (ale nie jako WASM a po stronie serwera, ponieważ mam specyficzne potrzeby) wpisywał się w to idealnie.
Jednakże... ekosystem frontendu na JSie jest tak potężny, że szkoda z niego rezygnować.
Tak, wiem że można używać JSa w Blazorze, ale nie jest to ani wygodne ani naturalne.

Zatem zacząłem drążyć dalej i dziś idę w stronę backendu na NodeJS (co dokładnie, to nie wiem jeszcze - pewnie NestJS) a front to Svelte.
Bo jestem blisko natywnych technologii webowych, nic mnie nie ogranicza, a zadziała praktycznie na wszystkim.

4
wloochacz napisał(a):
Saalin napisał(a):

Dlaczego piszesz Blazor'a, a nie Blazora?

Dlatego:
https://sjp.pwn.pl/poradnia/h[...]-w-wyrazach-obcych;11890.html

Podałeś linka w którym rozważane jest użycie apostrofów dla słów obcych zakończonych na -e. W takich przypadkach to -e nie jest wymawiane, więc stosujemy apostrof. W słowie "Blazor" końcowa litera jest wymawiana, więc nie stosuje się apostrofu przy odmianie "Blazora". Szczegóły: https://dobryslownik.pl/kompendium/regula/381/

Uwaga 1: błędne jest oddzielanie apostrofem każdej końcówki w wyrazach obcego pochodzenia, także gdy nie opuszcza się w wymowie żadnej głoski, np. !John’a Gray'a, !na Facebook’u, !iCloud’a itp.

1

Pierwsze wrażenie bardzo często jest pozytywne. Z resztą każdy tak jest tak zafascynowany zaczynając programowanie w ogóle. Pojawiają się wizje, w których ktoś robi genialne programy i ma tyle kasy, że opala się pod palmami. Kiedy jednak trafia się projekt pełny błędów, już nie jest tak fajnie.
Tak, że podziwiam zapał, ale kodzenie w Blazor nie jest takie fajne jak się wydaje.

1
wloochacz napisał(a):

Czyli na zasadzie, nie wiem, ale się wypowiem?

No tak, mam styczność tylko z dwiema aplikacjami w Blazorze, które są tylko do użytku wewnętrznego w firmie. To chyba i tak więcej, niż ludzie, którzy będą się tu wypowiadać.

0
Saalin napisał(a):
wloochacz napisał(a):

Czyli na zasadzie, nie wiem, ale się wypowiem?

No tak, mam styczność tylko z dwiema aplikacjami w Blazorze, które są tylko do użytku wewnętrznego w firmie.

A skoro tak, to napisz może coś więcej dlaczego Cię nie przekonuje?
Taka opinia od praktyka (zakładam, że styczność = rozwój tych aplikacji), z pewnością będzie z korzyścią dla wszystkich.

To chyba i tak więcej, niż ludzie, którzy będą się tu wypowiadać.

Pewnie masz rację :)

1
wloochacz napisał(a):

A skoro tak, to napisz może coś więcej dlaczego Cię nie przekonuje?
Taka opinia od praktyka (zakładam, że styczność = rozwój tych aplikacji), z pewnością będzie z korzyścią dla wszystkich.

Tak, styczność = rozwój, ale to małe narzędzia w tym momencie. Dlaczego mnie nie przekonuje:

  1. Blazor Server wymaga aktywnego połączenia z serwerem. Trudno to w ogóle porównywać z frameworkami działającymi tylko po stronie przeglądarki.
  2. Trudno narzekać na to, że można mieć wspólny codebase dla frontu i backendu, ale według mnie w praktyce oznacza jeszcze większe wymieszanie odpowiedzialności i teraz encja z bazy może być pchana jeszcze dalej niż do kontrolera, bo wprost do samego komponentu Blazora. Można się nawet nie pierdzielić w tańcu i wstrzyknąć cały DbContext.
  3. Pomimo tego, że lubię C# i .NET nie mam zaufania do nowych zabawek Microsoftu - już wystarczy mi System.Text.Json.

Ogólne wrażenie nie jest złe, ale jeśli gdzieś widziałbym Blazora to właśnie małe aplikacje, które w razie czego będzie można zakopać szybko. Zgodzę się za to w pełni, że piszę się w tym bardzo miło, nawet z JavaScriptowym interopem.

0
Saalin napisał(a):
wloochacz napisał(a):

A skoro tak, to napisz może coś więcej dlaczego Cię nie przekonuje?
Taka opinia od praktyka (zakładam, że styczność = rozwój tych aplikacji), z pewnością będzie z korzyścią dla wszystkich.

Tak, styczność = rozwój, ale to małe narzędzia w tym momencie. Dlaczego mnie nie przekonuje:

  1. Blazor Server wymaga aktywnego połączenia z serwerem. Trudno to w ogóle porównywać z frameworkami działającymi tylko po stronie przeglądarki.

Dlatego masz również inny model hostowania aplikacji, czyli Blazor po stronie przeglądarki jako WASM.
I praktycznie jest to ten sam codebase, a konwersja jest stosunkowo mało skomplikowana.

Trudno mówić że to wada (skoro można mieć albo po stronie serwera albo po stronie przeglądarki), to jest po prostu taki model działania.
I jeśli chcesz mieć po stronie serwera, to tak to działa.
Ale bez przesady, że to nie działa - przecież nie jest tak, że w momencie zaniku połączenia z serwerem aplikacja umiera i pomaga tylko jej restart/przeładowanie.
Nie, jak odzyska połączenie to dalej działa sobie normalnie.

  1. Trudno narzekać na to, że można mieć wspólny codebase dla frontu i backendu, ale według mnie w praktyce oznacza jeszcze większe wymieszanie odpowiedzialności i teraz encja z bazy może być pchana jeszcze dalej niż do kontrolera, bo wprost do samego komponentu Blazora. Można się nawet nie pierdzielić w tańcu i wstrzyknąć cały DbContext.

Prawda, ale czy to wada?
To że ktoś tak zrobi wcale nie oznacza, że tak należy robić.

  1. Pomimo tego, że lubię C# i .NET nie mam zaufania do nowych zabawek Microsoftu - już wystarczy mi System.Text.Json.

OK, ale to subiektywna opinia, która na dodatek nie opiera się na faktach :)

Ogólne wrażenie nie jest złe, ale jeśli gdzieś widziałbym Blazora to właśnie małe aplikacje, które w razie czego będzie można zakopać szybko. Zgodzę się za to w pełni, że piszę się w tym bardzo miło, nawet z JavaScriptowym interopem.

Chyba nikt tego wyraźnie nie powiedział w MS, ale mi się wydaje że Blazor to jest właśnie zabawka do takich aplikacji LoB (aplikacje używane bardziej jako wewnętrzne rozwiązania w firmie, a niedostępne w "szerokim" Internecie).
Taki zamiennik do LightSwich a może i dla PowerApps.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0