Blazor WASM az iparban, 2022-ben (?)

.NET

Sziasztok!

Több C#-os kollegám is azon a véleményen van, hogy mennyire jó lesz, ha majd a Blazor (meg úgy általánosságban a WebAssembly) kiváltja végre a JavaScriptben való kódolást egy fullstack fejlesztő életében.
Mivel még csak dummy alkalmazásokat láttam csak, ezért roppant kíváncsi vagyok, közületek hányan fejlesztettek élesben kliensoldali Blazor frontendet, és hogy mik a tapasztalataitok például egy Angular/TypeScriptes SPA megtervezéséhez és karbantartásához képest.

  • 713 megtekintés

( uid_720 | 2022. 07. 07., cs – 21:11 )

Szerintem a Blazor ugyanúgy technikai zsákutca, mint annak idején a WebForms volt.

A szerver oldali cucc folyamatosan nyitva tart egy websocketet, és stateful, akinek sok hátránya van, nem sorolom fel.

A kliens oldalon meg már le vannak osztva a lapok.

De ez csak magánvélemény, majd kiderül, ha esetleg rosszul gondolom.

( penztar v | 2022. 07. 07., cs – 22:15 )

Azért külön kellene választani a blazor server és a blazor webassembly alaklmazásokat. Az állandó kapcsolat a blazor server appoknál van folyamatosan a szerver és a kliens között. A webassembly esetében ez a kapcsolat nem szükséges, mert a kliens oldalon történik a html renderelése. Viszont aki arra számít, hogy a blazor miatt majd elfelejtheti a javascriptet, őket el kell hogy keserítsem, mert hiába használ blazor webassemblyt továbbra is kell a javascript. Jelen pillanatban blazor oldalról nem lehet elérni a böngészők által támogatott apikat, mint  pl: geolocation,media ..etc. Ha egy nyomorult alertet akarsz feldobni a felhasználónak ahhoz is javascripten keresztül vezet az út. 

Amúgy én sem vagyok annyira biztos, hogy nem ez lesz-e a microsoft következő olyan nagy buktája, mint a silverlight vagy a xamarin.

( nagy_peter v | 2022. 07. 07., cs – 22:33 )

Én nem hiszem, hogy a PHP, JS és társai mellett bármely cég nagyobb projektbe szeretne vágni egy olyan platformra építve, amit pár év múlva simán elkaszálhatnak, miközben PHP-hot, JS-hez (TS-hez) értő fejlesztőből talál sokat, és azon sem kell aggódnia, hogy pár év múlva migrálhatja a projektet egy másik nyelv alá.

Ez inkább menekülő út azoknak, akik sok munkát fektettek a Silverlight alkalmazásuk fejlesztésébe, és nem szeretnék mindet kidobni.

Nagy Péter

Régebben pascal fejlesztőket ontottak a képzések, mégsem azt látom, hogy most mindenki abban fejlesztene. Nekem inkább úgy tűnik, hogy C#-ban megtanulják az alapokat, aztán többnyire valami más nyelvet használva elhelyezkednek. Persze temetni nem temetném, de azért az is elmond róla sokat, hogy napi szinten foglalkozok webfejlesztéssel, és most a Wikipediából kellett rákeresnem, hogy mi az a Blazor, miközben elvileg 5 éve létezik.

Nagy Péter

mégsem azt látom, hogy most mindenki abban fejlesztene

Mindenki tényleg nem, de azért kellemesen sokan már igen. A TIOBE ugyan nem reprezentatív, de iránymutatásnak jó lehet: csharp #5, php #13

most a Wikipediából kellett rákeresnem, hogy mi az a Blazor, miközben elvileg 5 éve létezik.

Ezzel én is így lennék kb bármelyik php frameworkkel 

Az jogos, hogy sokan használják a C#-ot, tulajdonképpen most éli a második reneszánszát. De valahogy azt látom, hogy rengeteg webes C# technológia bukott meg az elmúlt 10 évben. Míg desktop alkalmazásokban a mai napig elég sok helyen találkozok vele (és közte elég sok olyan programmal is, ami érezhetően jól is működik), addig a webes C# .net -ről főleg az jut eszembe, hogy lassú, és gyakran dob hibát.

Nyilván JS-ben és PHP-ban is születnek borzalmas tákolmányok, és gondolom van olyan weblap, ami C#-ban készült, és egy remekműnek számít; de valahogy az az érzésem, hogy nincs olyan nagy valós igény leváltani a jelenlegi szerver-oldali technológiákat valami másra, mert a most használatosak is elég jól teljesítenek. 

De persze nem temetem, azt se gondolom, hogy ne lenne remek eszköz a Blazor; csak cégvezetőként nem mernék olyan projektbe kezdeni benne, amire még 5 év múlva is szükség lesz.

Nagy Péter

Jó, hogy nem csak én vagyok ezzel így. Fogalmam sincs, hogy mi ez a Blazor izé. WASM-ről természetesen már hallottam, de arról úgy tudom, hogy a böngészőkbe épített technológia. Az is igaz, hogy én nem vagyok webfejlesztő, JS-ben sem programozok.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( FeriX v | 2022. 07. 08., p – 01:03 )

A Blazor WASM már most is képes kiváltani a JavaScript-et. Több projekten vagyok túl és igen jól ismerem. A következő dolgokhoz használok kizárólag JavaScript-et, onscroll esemény, wysiwyg, kép vágás, css media query, és modal nyitásnál a body scroll kikapcsolására. De ezeket se én írtam, mert a nuget-en vannak csomagok, githubon meg a forrása, ami annyira kicsik, hogy ha hiba keletkezne, sima liba a javítása. Én be is építettem magamnak az összeset, kiszórva a fölösleget, így csak az van amit akarok.

Minden más viszont hatalmas előny.

Én úgy tekintek a Blazor WASM-ra mint egy natív kliensre, mint bármelyik XAML alapú MS megoldásra. Csak itt van egy hatalmas előny a Blazor javára. a UI a HTML, a design pedig CSS. Ehhez meg kapom az általam szeretett XAML bindinget.

Megkapom azt az egyszerűséget, hogy ugyan azt a model-t használom Entity Framework-höz, amit használni tudok RestAPI vagy SignalR validáláshoz szerver oldalon, és a felhasználói felületen is ugyan az van. Egy model. De lehet bonyolítani is, akinek az a kedvence.

A fent felsorolt 157 sor JavaScript-en kívül minden HTML, CSS és Razor syntax C#-al. Minden JS mentes és szuper.

Már jó ideje lehet futtatni a Blazor WASM-ban párhuzamos, sokáig futó process-eket. Én MI futtatok benne, sakk, ötödölő és malomjátékokhoz.

A Blazor Server-rel sincs semmi gond. Egy virtuális gép 1 vCPU-val és 3.5GB memóriával elfuttat 5.000 konkurens felhasználót. 4 vCPU 14GB RAM pedig 20.000-et. Ha pedig ennyi konkurens felhasználód van akkor már nagy cég vagy. Azért hogy nyitva van a kapcsolat nem kell aggódni.

Ott van még a Blazor Hybrid. Becsomagolhatod a Blazor-t MAUI-ba, így fut Linux kivételével minden platformon, és hozzáférsz a natív app adta lehetőségekhez is. De ne hagyjuk ki a Linux-ot se, mert a MAUI WinUI fut Wine-al Linux-on is, csak kicsit mókolni kell hozzá, de WPF vagy WinForms-ba csomagolva is gond nélkül fut Linuxon Wine-al. A szkeptikusoknak írom, igen fut. Nem csak kitalálom.

Ha még eszembe jut valami akkor leírom. Hirtelen ennyi.

A Blazor Server-rel sincs semmi gond. Egy virtuális gép 1 vCPU-val és 3.5GB memóriával elfuttat 5.000 konkurens felhasználót. 

Amíg újra nem kell indítani, mondjuk egy kernel update, vagy egy újabb verzió deployolása miatt (mármint az alkalmazásból), akkor ugye aki éppen használja, az megszívta. A stateful cuccon a rolling update sem segít.

Szerintem a szerver oldali Blazor egy teljesen értelmetlen megoldás, de a kliens oldali végülis eléldegélhat pár évig, mint a Silverlight, vagy a WinRT, vagy a WinJS, vagy a Metro-style, vagy a WebForms.

Én is örülnék, ha végre lecserélhetnénk a JS-t/TS-t, de az a csodálatos nap nem mi életünkben fog eljönni.

Mindenesetre megvárom, míg a Microsoft is elkezdi használni productionben.

Ha a szerver nem érhető el mert újraindul, vagy csak egy service indul újra akkor mindegy, hogy state az ful vagy less, a böngésző így is úgy is hibát fog jelezni. Az emberekbe pedig beleivódott a föntről lefelé pöccintés vagy bármilyen újra töltés, nem esnek pánikba. Kap egy új state-et és akkor mi van? A wifi is megszakadhat, a mobil hálózat is kimaradhat, a szolgáltató routere is lehet problémás, majd kap új state-et. Nincs ezzel baj.

Ha pedig olyan fontos az állandó kapcsolat, amit egy szolgáltatáshoz kell, megvannak a lehetőségek hogy frissítsd a kerneled újraindítás nélkül, vagy kicseréld a dll-eket az AppDomain-ben menet közben.

Nincs gáz a szerver oldali Blazor-ral.

( Aadaam v | 2022. 07. 08., p – 10:39 )

Én ezt már meghallgattam a .NET-esektől 2009-ben… akkor az EPAMnak effektív 2 részlege volt, a Java meg a .NET… én meg JS-sel akartam foglalkozni tisztán.

A .NET-esek meg voltak győződve, hogy ez egy fad, és felfejlődik a silverlight, az asp, a xaml, a ria, stb, és a js eltűnik a süllyesztőben.

Én elmentem senior frontend developernek máshova, és hát azóta az EPAM-nál is léteznek senior frontend developerek, de kellett pár év.

Nyomjad fullba a JS-t / TS-t, több esélyed lesz.

penztar kifejtette.

https://hup.hu/comment/2805299#comment-2805299

kiváltáshoz nincsenek meg az azonos képességek. Persze mókolni(middleware,illesztő stb-t írni) lehet de akkor nem kiváltottad.

**

tapasztalatom csak egy pilot kapcsán van, de elengedtük.

( FeriX v | 2022. 07. 08., p – 19:05 )

A kérdésedhez hozzáfűznék pár dolgot, mert látom, hogy azok, akik azt írják, hogy nem, vagy ezt ki is egészítik néhány szóval, inkább arról szól, hogy egyrészt eltántorítson bármilyen indokkal is, másrészt pedig a Blazor Web API hiányosságait emlegetik.

A Blazor jelen állapotában nem, nem váltja ki a JavaScriptet. De nem is fogja. Ez pedig azért van, mert a böngésző Web API hívásokhoz csak a JavaScripten keresztül vezet az út. Még az indításához is JavaScript kell.

Bármilyen framework-öt is szeretnél használni, ugyan azok a problémák. Miért nincs Geolocation API támogatás, basszus, nézzük mit adnak ingyen, vagy kalkuláljuk ki mennyi a fejlesztési idő, ha sok adnak-e pénzért olcsóbban. De ha nem Web API akkor más, szükség van wysiwyg szerkesztőre, azt se fejleszti le senki, használ egyet. De biztos van, aki lefejleszti, mert itt kapnék a fejemre, ha ezt a mondatot kihagynám. Ezért van az, hogy bizonyos esetekben hozzá kell nyúlni harmadik féltől származó JavaScripthez, mint bármelyik framework-ben.

Amint túl vagy a speciális eseteken, eljön az, ami egy C# programozónak elmondhatatlanul jó érzés. Innentől kezdve érdekes a Blazor.

A Blazor egy 12 éves kiforrott technológiára támaszkodik, a Razor-ra. A Razor syntax az alapja. Minden a ComponentBase-ből származik, még a legelső App.razor fájl is a projektben. Ez pedig a lehetőségek tárházát hozza el Neked, mert nincs mégy egy olyan framework mint a dotnet és az asp dotnet, ami egy kézben van és olyan funkcionalitást adna, amivel szinte mindent meg lehet csinálni.

Polgárpukkasztás be, ugyan ez más nyelveken nagyszámú fejlesztő kismillió termékét húzza be maga alá a működéshez. Amit én nem szeretek, de ez nem azt jelenti, hogy itt a kedves olvasó ne imádná.

( kisg v | 2022. 07. 09., szo – 09:06 )

Ugyan te konkrétan a Blazort kérdezted, de amit írok, az minden WASM alapú megoldásra igaz.

A WASM futtatókörnyezet jelenleg egy nagyon egyszerű számítógépet emulál: van egy darab RAM terület, amit használhatsz + alacsony szintű utasítások. Ez egyszerre jó és rossz. Jó, mert gyakorlatilag bármilyen nyelvhez lehet csinálni fordítót ami WASM-re fordít + relatíve könnyebb hatékony implementációt csinálni hozzá. Rossz, mert ha olyan nyelvet akarsz WASM fölé rakni, ami pl. GC-t használ, akkor a teljes GC infrastruktúrát vinned kell magaddal. Ez jelentősen növelni fogja a kódméretet, amit le kell tölteni a böngészőbe.

Ez nem csak a .NET / Blazorra igaz, hanem pl. Pythonra is (pyodide), vagy bármi másra.

A másik kérdés, hogy hogyan futtatsz magas szintű nyelvet WASM felett. JIT fordítás a jelenlegi implementációk mellett nem támogatott (nem tudsz úgy WASM-ban WASM kódot generálni, hogy utána azt le is futtasd). Ez biztonsági szempontból egyébként szerintem jó.

Viszont ez azt jelenti, hogy két opciód van: interpreter vagy AOT fordítás. A Blazor mindkettőt támogatja. Az interpreter előnye, hogy kisebb a letöltendő kódméret: a runtime-on (pongyolán: GC + MSIL interpreter) kívül az appban használt .NET DLL-eket kell letölteni a böngészőbe. Az MS dokumentáció szerint az AOT üzemmódnál átlagos esetben kb. 2x nagyobb az app mérete, cserébe gyorsabban tud futni.

Persze minden hasonló rendszer a buildelésnél próbál okos lenni, és kidobálni pl. a runtime-ból / libekből a nem használt dolgokat, a Blazor is csinálja ezt.

Aztán a következő kérdés a DOM hozzáférés. Sokáig a WASM-nál egy nagyon buta inferfészen keresztül volt ez lehetséges, pl. nem lehetett DOM node-ra közvetlenül referenciát eltárolni a WASM oldalon, hanem JS-ben kell egy DOM node -> WASM handle mapet implementálni. Szerencsére most már a reference type támogatás elérhető WASM-ban, de ettől még értelemszerűen ki kell hívni WASM-ból, ha a DOM-ot el akarjuk érni, aminek van költsége.

Ezektől függetlenül a WASM sok mindenre jó megoldás, de tisztában kell lenni azzal, hogy hogyan működik, és mik a korlátai.

A kérdés nem az, hogy általánosságban jó-e a Blazor, hanem a konkrét feladatra jó-e. Olyan webapp fejlesztésre, ahol nem gond, hogy első betöltéskor nagyobb mennyiségű kódot kell letölteni (mondjuk egy ügyviteli app vagy valamilyen admin felület), és egyébként C#/.NET stacket használ a csapat, simán jó.

Egy olyan appnál, ahol ha 1s alatt tölt be az app (weboldal) már mérhetően elkattintanak a felhasználók, nem biztos, hogy ezt választanám.

A humán oldalt nézve: ha a csapat most nem C#/.NET stacket használ, nem biztos, hogy a Blazor miatt elkezdenék átállni rá.