[TwojHimars]

Jakie dajecie szanse Blazorowi na rozpowszechnienie się na rynku?

#dotnet #blazor #programowanie

[mathes]

@TwojHimars: zerowe

[TwojHimars]

@mathes: Póki co możesz nie obawiać się konkurencji i pisać szczerze. Blazor w NET8 to przełom, MAUI z resztą również

[Kinlezanc]

Czas ładowania, rozmiar i słaby marketing to są powody, przez które blazor się raczej nie przebije.

[longstar]

@TwojHimars: ten przełom był 8 lat temu i umarł, znów gówno owijają w inny papierek i marzą o tym by to samo sprzedać

[mathes]

@TwojHimars: znowu przełom? Co wydanie nowej wersji słyszę o przełomie i nikt dalej tego nie uzywa.

[Goglez]

@TwojHimars

Blazor w NET8 to przełom, MAUI z resztą również

Dlaczego?

[TwojHimars]

@mathes: @Goglez
Tryb SSR (renderowanie html-a po stronie serwera i przesyłanie wyniku), tryb Auto (nie cały projekt a pojedynczy komponent działa jako Server/WASM), MAUI Hybrid, przyspieszenie działania aplikacji, zmniejszenie ich rozmiaru

[Varin]

@TwojHimars: pisalem 2-letni projekt i nadal go rozwijam, gdzie uzylem dosc sporo Blazor Server. Mam kilka projektów własnych używając WASM. Używałem też Radzen/Mudblazor. Ogólnie nie widzę żeby to nagle zabrało wielki kawałek ciasta od Angular/React/Vue. Wygodniej mi się to pisze w porównaniu do pisania normalnie w .NET C# MVC, nie muszę używać JS czy JQuery i robić Ajax'ów do kontrolera itp.. Wolę wszystko pisać w C# bo jest jakoś tak "czyściej"

[janciopan]

Blazorowi

@TwojHimars: Dla mnie blazor ma kiepską składnie i jest to strasznie przekombinowane. Ale ja też programuję w innych językach i widziałem po prostu dużo lepsze, bardziej naturalne template engine. Może jak ktoś jest okopany tylko w .NETcie to będzie mówił że to jest dobre.

@Page "/todo"
@rendermode InteractiveServer

<PageTitle>Todo</PageTitle>

<h3>Todo</h3>

<ul>
    @foreach (var todo in todos)
    {
        <li>@Todo.Title</li>
    }
</ul>

<input placeholder="Something todo" @bind="newTodo" />
<button @onclick="AddTodo">Add todo</button>

[Kinlezanc]

@janciopan: Przecież masz możliwość separacji logiki od widoku - https://learn.microsoft.com/en-us/aspnet/core/blazor/components/?view=aspnetcore-8.0#partial-class-support

[janciopan]

@Kinlezanc: a dlaczego nie robić tego jak się robiło kiedyś czyli za pomocą ajaxa ściągasz sobie element DOMu i wstawiasz go pod określony tag. Kod jest dużo lepszy, czystrzy i mniej przekombinowany. HTMX możesz to zrobić i na oczy JSa nie zobaczysz.

https://htmx.org

a to że sobie rozbijesz jeden plik na dwa pliki to sorry ale problemu nie rozwiązuje czyli że kopiujesz złe praktyki z frontendowych frameworków tylko robisz to w

[Kinlezanc]

@janciopan: Użyj sobie takie zwracające DOM API w aplikacji mobilnej lub zrób nowy front bez dotykania backendu.

[janciopan]

@Kinlezanc: Tu już robisz fikołki. Takie narzędzia jak razor są dla backendów, którzy chcą napisać front i nie potrafią into js. Dla osoby która nie ogarnia ekostystemu dot net razor będzie czarną magią.

Druga sprawa. Możesz napisać responywną stronę która będzie dobrze działać na mobilu, a jak nie ma mowy i musi być aplikacja natywna to backend może zwracać przecież różny content type dla weba może zwracać htmla, dla reszty jsona

[Kinlezanc]

@janciopan: Możesz zwracać różny content type, ale potem zmiany na froncie będą wymagały zmian na backendzie. Dzisiaj element XYZ ma w środku <h2>, a jutro będziesz chciał mieć <h1>, będziesz przy każdej zmianie modyfikował backend? Dużo lepsza opcja to zwrócić json i niech sobie klient robi z tym co chce, jeden to wyświetli w natywnej kontrolce, drugi sobie wygeneruje z tego html itp. Blazor wasm działa niezależnie od backendu, więc nie

[janciopan]

@Kinlezanc: Jeśli to takie świetne rozwiązanie i rzeczywiście rozwiązuje jakiś ważny problem to rynek to zaadaptuje. Narazie ja tego nie widzę i rynek chyba też nie bo nie widzę by to było używane. Zobaczymy w przyszłości.

[obieq]

@TwojHimars: @Varin sam coś w tym skrobię też w MudBlazor chociaż jak widziałem to te "komercyjne" firmy w stylu DevExpress / Telerik też mają swoje komponenty. M$ zaczał to lekko pompować i w .NET 8 jest dużo lepiej, ale sporo brakuje.
Największym problemem jest chyba MAUI, które od dawna jest kupą chociaż teraz naobiecywali, ale zobaczymy.
Jakby to siadło to wychodzi fajny framework do robienia apki na Mobile + WWW +

[mch0588]

@TwojHimars: zerowe, może do korpo tabelek ale każdy normalny bierze coś z wielkiej JSowej trójcy, która ma dość dobre wsparcie. W Blazorze nie ma nawet dobrych wykresów za darmo dostępnych :(

[Saly]

@TwojHimars: żadne. Nie kojarzę nikogo, kto wybrałby Blazora bez wcześniejszego romansu z .Net. Blazor z założeń ma być szybki, ale generuje większe artefakty od jsowych kobył

[Varin]

brzydzi mnie ta składnia i brak typowania (tak wiem jest TS).

@obieq: Mnie też brzydzi. A TS - był u nas taki jeden kontraktor co go nie pilnowali i przez pol roku dodal w #!$%@? TS do naszego głownego projektu, gdzie większość tych zeczy ktore on pisal, byly juz gdzies w plikach JS/JQuery zrobione. No i w koncu kontrakt mu sie skonczyl i nie przedluzyli i teraz siedze i odkręcam ten

[Krolik]

@Varin: tylko że to nie webassembly jest powolne tylko runtime .NET jest ciężki.