Nyíl forrású, platformfüggetlen formában tér vissza a Silverlight

A Blazor szerintem k... jó lesz.
A komponens gyártók már rá is pattantak pedig még nincs is kész csak a server side renderingje. A client side májusban jön.
Itt van pl. a devexpress demója:
Native Blazor Components powered by DevExpress

Mondjuk az, hogy a MS belerakja a .NET frameworkbe egy elég jó garancia szvsz.

Mondjuk a flash-nál kevés lassabb és erőforrásigényesebb dolog létezett.

Naja, lattam, kiprobaltam Apple fejleszto letemre ezt a Blazor cuccot, valami Pizza shop demot, nagyon tetszett!
Ertem amit mondasz, de ... hogy ez rendesen mukodjon majd, ugyertem lecserelje a JS-t, az kell majd, hogy nagyobb cegek vezetoi legyenek meggyozve arrol, hogy hosszan tamogatott dologrol van szo ami sokkal sokkal produktivabb mint a jelenlegi megoldasok .... ha minket fejlesztoket gyozkodnek azzal nem sokra mennek ... ha az adott ceg nem lat penzt abban amivel kene foglalkoznia akkor mast fog valasztani.

Ja, köszi, így már értem, hogy mit nem értek;)
Mondjuk az utolsó örömteli fejlemény az swf kinyírása volt: az jogos volt, hiszan vannak lassabb és erőforrásigényesebb eszközök a HTML5-óta, legfeljebb nulláról kell újraírni a programokat.

Mivel ezek alapvetően webes cuccok, az ActiveX megszűnése óta a natív kód és a win32 annyira nagyon nem játszik ezen a téren, hacsak valaki ráérő ember nagyon neki nem hasal és portolja a wine-t webassemblyre

Off: nagyon gáz, ha én ebből egy szót sem értek? Illetve annyit értek, hogy egyre újabb és szebb csodatermékek születnek, mind jobb egymásnál és főleg a natív kódnál meg a  Win32 direkt használatánál.

Ha a .NET framework közvetlenül webasm-re tud fordítani, és nem egy webasm-ben írt interpreter értelmezi a .NET-es bytekódot, akkor a cucc gyorsabb lehet mint a javascript. De szerintem ennek a silverlightos cuccnak most sem a CLR sebessége a gondja, hanem hogy egy xaml-t kell megjeleníteni a böngészőben, márpedig gyors xaml megjelenítőt írni nem triviális. Ebből a szempontból a Blazort jóval életképesebb ötletnek tartom, ott csak a javascript/random javascript frameworköt cseréljük le C#/.NET kombóra, ráadásul az egész hivatalosan támogatott is.

nem kell megtanulnom, mert már tudom
és még sok más ember van így vele.

a többit meg lc leírta

Nem, mert .NET framework egy van, js framework viszont van minden bokorban. Plusz, így tudsz megosztani kódot a kliens és a szerver között, ami néha nagyon jól tud jönni.

Cserebe a XAML C# kombot kell megtanulnod es a frameworkjeit...nem tokmindegy?

ez a nativ sebesség eléggé relatív fogalom.
Az i9-em gyorsabb mint az i5-öm, de attól még az is egy qrvajó gép.
Egész pontosan ott veszem észre, amikor 16 magon renderel a Modo. Meg az Unreal Engine érezhetően gyorsabban buildeli a shadereket és a c++ kódokat. Amúgy máshol nem érzem.

Valszeg Te is kb ennyit fogsz észrevenni a legvégén.

cserébe nem kell a teljes JS CSS HTML ökoszisztémát egy tonna frameworkkel megtanulnom, hanem olyan valamibe csöppenek bele, amit többnyire ismerek.

Amugy mi az ertelme?
Ugy ertem ott a JS ... nem szeretem, de ez most lenyegtelen.
Akar nativhoz kozeli sebesseggel is tud futni, es nem ma talaltak ki, vannak hozza eszkozok.
Minek csinal barki egy Web ASM-re epitett plusz layert, ami lassit majd a nativ sebessegen ugyanugy.
Mi a turo az egesz ertelme, elmagyaraznatok?

hm, oké

nem azt mondom, hogy kapkodó idegbeteg....

majd meglátjuk

AMD Ryzen7, 16GB RAM, Geoforce GTX 1060, természtesen SSD bár itt mindegy, win10 insider. Mind firefox, mind chrome alatt tetűlassú.

nem tudom milyen gépen nézted, nekem a laptopomon se csiga lassú, pedig az nem gamer
ha ez 10x gyorsabb lesz az már siker.
Csak ne halljon el

mint minden minden ilyen terméknél, itt is várni kell 1 évet a megjelenés után, hogy életképes marad-e.

Én mondjuk túl sokat egyikkel sem játszottam, de a silverlightos megoldás nekem veszett lassúnak tűnik, bár elvben 30x gyorsabb lesz, de ezt hiszem ha látom. Jelenleg egy bikaerős gamer PC-n is veszettül lassú, ez szerintem 30x gyorsabban sem fog labdába rúgni egy régebbi telefonon.

Érdekes lenne egy lista Silverlight Webassembly vs Blazor Webassembly pro-kontra érvekkel.

mondjuk ezzel egyet tudok érteni (eltekintve a WF még így is felesleges szidásától).
Tipikus szép koncepció, de a megvalósítással vannak gondok cucc volt.
Ha az lett volna ami akart lenni, nagyon jó lett volna.
De szerintem én most használom a DotVVM-et (utánanéztem és van benne pl.: Static Command Service, ami annyit tesz hogy amennyiben olyan a feladat, ahol ha nincs szükség a ViewModel-re (=ViewState) akkor azt nem küldöd el, csak az argumentumokat a feladathoz (tehát egy nyavajás fájl törléséhez nem kell a teljes oldalt oda-vissza megfuttatnod))
Nekem jónak tűnik.
(Csak hogy tisztázzuk: nincs semmi közöm a fejlesztőkhöz és nem is akarom reklámozni a DotVVM-et, ez csakis a saját véleményem)

kipróbáltam. 
ehető a cucc :)

Ja, meg ha in-processz tárolod a state-et, akkor csak a sticky load balancing fog működni, ha state szerverben vagy SQL-ben, akkor meg olvasztod a jégsapkákat egy olyan dolog miatt, amit kliens oldalon is meg tudnál csinálni.

A WebForms szerintem is egy rakás sz'r volt, a teljesen értelmetlen és logikátlan page lifecycle eventektől a customizálhatatlan formokig (mert ki akarna magyar ünnepnapokat látni a calendar-ban).

És sajnos azt, hogy valamit mire használunk, nem mi döntjük el, hanem az öt generációval előttünk alkotó fejlesztőcsapat és a rettenetesen okos biznisz.

Egyszer kaptam egy állásajánlatot, amint megemlítették interjún, hogy van WebForms, már meg is született a döntés.

de azt mondják nemsokára jóval gyorsabb lesz

Azért a sebesség terén küzd bizonyos kihívásokkal.

A rendszerunk szempontjabol ez total lenyegtelen. Meg gondolom ezt csak 1x teszi meg lehetoseg szerint.

Bizakodo vagyok. A showcase elsore mar tetszetos

Már nem tudtam szerkeszteni, ide leírom:

az implementációval voltak problémák (pl.: a ViewState amit te is említettél),
de ha ezeket kijavítanánk (mert kijavíthatók, például hogy csak a változást küldje át),
akkor egy praktikus eszköz lenne.

A problémát amiket említettél, azokat némi munkával (tekintve hogy .NET Core-ra úgyis újra kéne írni) ki lehet javítani.



Szerkesztés: megtaláltam amit szerettem volna, DotVVM, többek között a ViewState macera is hiányzik belőle: https://www.dotvvm.com/Ami nem ingyenes az csak ilyen extra Bootstrap-könytár meg VS-kiterjesztés, de maga a keretrendszer ingyenes és nyílt forrású ( olyasmi üzleti modell mint amivel a Qt is operál)

Dettó. Az is kérdés persze, hogy mekkora webassemblyt tölt ez le az end-user gépére.

Most abbahagyom mielőtt elkezdődik a vallásháború mint a VB.NET-es topicban.
Én személy szerint szerettem, nekem logikus vol BIZONYOS FELADATOKRA, mert szerintem
ezzel is az volt a baj mint a JS-sel, hogy az emberek olyan dolgokra kezdték el használni, amire nem
való, aztán hőbörögnek hogy nem volt rá jó. Egyébként egy extra WebSocket az AJAX és postback helyett, pár apró fejlesztés, nyílt forráskód és a mai sok interaktív elemet igénylő webALKALMAZÁSHOZ (nem sima honlaphoz!!) tökéletes lenne.

És, mint tudjuk, nem kötelező használni, csak mert létezik.

Neeee! A webforms volt a microsoft egyik leghülyébb ötlete. Az, amire kitalálták, már hogy te a formodon vizuálisan szerkesztesz meg dolgokat, soha egyetlen másodpercig nem működött a helló világnál komplexebb formokon, unit tesztelni semennyire nem lehetett, ráadásul elég könnyen össze lehetett hozni akkora viewstate-et mint egy ház, ami minden mozdulatnál ide-oda kóválygott a kliens és a szerver között. Hirtelen nemigen jut eszembe olyan dolog, ami miatt azt mondanám hogy ilyet szeretnék.

Thx.  

Epp a blazoron kezdtem agyalni de akkor ezt bevarom.

Valami hasonlót szeretnék még WebForms-hoz is