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.
1
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/haslo/apostrof-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/haslo/apostrof-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:
- 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.
- 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. - 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:
- 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.
- 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ć.
- 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.