Wpis z mikrobloga

Co myślicie o .NET MAUI? Ma szanse to wypalić choćby na skale fluttera? Jak przeglądałem opinie to raczej jeszcze się nie zbyt nadaje na komercyjne projekty, ale Microsoft dość mocno w to inwestuje.
Ogólnie to Microsoft mocno inwestuje (Blazor, MAUI), tak jakby trochę chcieli wszystko moc zrobić w jednym środowisku (.NET) i za pomocą jednego języka (C#). Jakby nie patrzeć to rozwiązania backendowe i chmurowe, które się komercyjnie sprawdzają już maja.

#programowanie #dotnet #csharp
  • 11
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@Vane1905 z rok temu doszło do tego żeby wpakowali Blazora w web view który był w MAUI. Zawsze mam tak że takie rzeczy świetnie wyglądają na pierwszy rzut oka a potem im dalej w las tym więcej drzew i wychodzą różne problemy jak słaby iser experience przy dużym latency w blazor serwer czy problem z SEO w flutter web
  • Odpowiedz
@Vane1905: w listopadzie wychodzi .net 8 I mają tam trochę usprawnić blazora żeby nie trzeba było decydować czy server czy wasm.
Maui z tego co kojarzę nie ma wsparcia na Linuxie albo był tam jakiś problem przy próbie dockerowania związany z tym.
Fajnie się w tym pisze jak ktoś nienawidzi JavaScript (i jej miliona frameworkow)
  • Odpowiedz
@Vane1905: Blazor super, ale na telefonie średnio ze względu na brak sensownego zarządzania navigation stack.
MAUI lepsze niż Xamarin, ale nadal niedoinwestowany zespół i za dużo błędów.
Szlifują to MAUI, ale obiecywali bugfix release co miesiąc, a wychodzi co 3 itd. itp.
  • Odpowiedz
języki z tracing GC nie nadają się na GUI. Patrz Java na Androidzie vs Swift na iOS. Ten drugi tak nie laguje.


@Krolik: myślę, że większy problemem jest design języka Java/C# niż sam fakt istnienia tracing gc. Jakby powstał język taki jak Go do UI, gdzie nie wszystko jest obiektem to śmigałoby dużo lepiej. Z drugiej strony mobliki teoretycznie też nie powinny mieć dużego problemu z długimi pauzami, bo living
  • Odpowiedz
Co myślicie o .NET MAUI? Ma szanse to wypalić choćby na skale fluttera?


@Vane1905: microsoft po prostu próbuje zadziałać w tym temacie, bo ugryzienie kawałka tortu w postaci aplikacji mobilnych jest bardzo kuszące. Wątpię, że coś z tego wyjdzie, bo konkurencja w postaci Fluttera jest duża i za bardzo nie wiem czym microsoft chciałby przekonać developerów, którzy chcą iść w rozwiązania multiplatformowe. Zwłaszcza, że za Flutterem stoi firma, która siedzi
  • Odpowiedz
@Saly: mobilki działają na słabych prockach a do tego muszą oszczędzać baterię. Nawet jeśli ogarniesz pauzy sprzątając w tle to nadal marnujesz energię na to sprzątanie. Allocation rate w C# jest podobny jak w Javie. Mobilki mają też mniej ramu niż serwery. GC powoduje 3x-5x większe zużycie RAMu niż RC. Dlatego iPhone może mieć o połowę mniej RAMu i nadal działać lepiej.
  • Odpowiedz
Jakby powstał język taki jak Go do UI, gdzie nie wszystko jest obiektem to śmigałoby dużo lepiej


@Saly: no raczej nie. U nas jeden team napisał proxy CQL w Go i ono pożera 2,7 GB przy 10k połączeń. Z tych 2,7 GB, niemal 2 GB to narzut GC, kolejne 250 MB to narzut stosów gorutyn. Go ma bardzo podobną charakterystykę wydajnościową co Java/C# - marnuje masę pamięci na GC. Do
  • Odpowiedz
GC powoduje 3x-5x większe zużycie RAMu niż RC. Dlatego iPhone może mieć o połowę mniej RAMu i nadal działać lepiej.


@Krolik: bez przesady. Takie go by default pozwala na 2x większe zużycie (można zmniejszyć). Co do większego zużycia RAMu to zgaduje, że obiekty są tu problemem a nie samo GC. Z drugeij strony RC też swoje kosztuje: taki std::shared_ptr tez swoje kosztuje, choć z drugiej strony nie używa się go na
  • Odpowiedz
Takie go by default pozwala na 2x większe zużycie (można zmniejszyć).


@Saly - bo jest ustawione domyślnie bardzo agresywnie, tzn włącza się często. Kosztem jest palenie dużej liczby cykli na samo GC. Niestey w tracing GC masz tradeoff - odśmiecasz często i palisz dużo CPU, ale masz znośne użycie pamięci, albo oszczędzasz CPU odśmiecając rzadko, ale wtedy zużycie pamięci eksploduje. W aplikacjach mobilnych nie możesz palić sobie tak dowolnie dużo cykli CPU,
  • Odpowiedz
@Vane1905: Jako wieloletni "dotnetowiec" po razor pages stwierdziłem, że nie prędko wrócę do ichniejszych frameworków od UI. Ta sama strona medalu, te technologie to jest taka nisza, że szkoda na to czasu.
  • Odpowiedz