Komolyan gondolja a WebAssembly-s .NET-et a Microsoft

Komolyan gondolja a WebAssembly-s .NET-et a Microsoft
2019-04-29T12:18:21+02:00
2019-10-02T21:42:36+02:00
2022-10-18T05:55:32+02:00
  • Tegyél bele valami komolyabb DOM manipulációt és kommunikálni fog. Nem tudom, hogy működik pontosan belülről, de az biztos, hogy a mostani verzió ami stabil az szerver oldali.
    Mutasd a teljes hozzászólást!
  • Én nem ezt tapasztalom, amit használok .net standard 2.0-át, egy dll, xamarin formsban, és asp net core-hoz, ugyan úgy fut blazorral.
    Mutasd a teljes hozzászólást!
  • Az a szerver oldali változat amiről írsz, az az új Visual Stúdióval beépített templét projekttel böngészőben fut. Nem kommunikál a counter példa a szerverrel hogy növelje az értéket és c#.

    Belejavítok, a c# http kliens kommunikál a szerverrel, ez se javascript.
    Mutasd a teljes hozzászólást!
  • Igen, jövő év májusára ígérik a kliens oldali verziót. Én is ezt találtam. Annyi, hogy elvileg a kettő kompatibilis lesz azaz bármikor átbillentheted a szerver oldali kódod kliens oldalivá.
    Közben meg fejleszthetnek a tradicionális .net komponens gyártók. A Devexpress, a Telerik és a Syncfusion is csinált már egy-egy készletet. Nyilván az igazi rajtra ami jövő év májusa, ha minden jól megy, már mindenki készen akar lenni.
    Mutasd a teljes hozzászólást!
  • a Core3-ban még csak szerver oldali blazor van

    Preview formában most is benne van a BlazorWasm.

    Nem láttam hivatalos menetrendet, de egy YT videó szerint 2020 májusban élesedik majd a kliens oldali változat. A szerveresen meg lehet addig fejleszteni, pl. létrehozni a komponenseket, amiből össze lehet rakni a weblapot.

    dotnet new blazorwasm -o WebApplication1 vs. dotnet new blazorserver -o WebApplication1
    innen
    Mutasd a teljes hozzászólást!
    Csatolt állomány
  • Még ha esélyes jelölt is lesz akkor is ott van egy hatalmas közösség és kódbázis. Ha meg is történne akkor is évtizedek. Lásd Perl amit sokkal de sokkal kevesebben használtak és már 10 éve is halott volt mégis még sok helyen ott figyel :)
    Ugyanígy a Java se halt ki pedig elég jó alternatíva a .net core.
    Mutasd a teljes hozzászólást!
  • Igen, igazad van. Megnéztem ami jelenleg van az server side rendering. Ezért is kérdeztem, hogy ilyen kérdéseket tegyenek fel mások :)
    Kérdés, hogy ha kijön a client side az vajon csak annyi lesz-e, hogy egy flaget átállítasz.
    Mutasd a teljes hozzászólást!
  • Esélytelen.
    Mutasd a teljes hozzászólást!
  • Hali!

    kijelenthető-e hogy pár év múlva kihal a javascript?

    Igen, kijelenthető. Pl. én is kijelentem: pár év múlva kihal a Javascript. Hogy ez bekövetkezik-e? Majd kiderül. 

    Mutasd a teljes hozzászólást!
  • kijelenthető-e hogy pár év múlva kihal a javascript?
    Mutasd a teljes hozzászólást!
  • Amennyire én tudom, a Core3-ban még csak szerver oldali blazor van. Annak meg több a baja mint az előnye.
    Mutasd a teljes hozzászólást!
  • Új projektet indítanék és nagyon gondolkodom rajta. Alapvetően ha 1.5 év múlva lenne teljesen kész a Devexpress a saját könyvtárával még elfogadható lenne. A mostani már nem rossz alap.

    Viszont ez a sebesség érdekes. Vajon a browserek azok amik még nincsenek kioptimalizálva a Blazor futtatásra vagy maga a runtime a lassú, vagy mindkettő :)
    Mutasd a teljes hozzászólást!
  • Ha a Devexpress, Telerik és Syncfusion is komolyan veszi, akkor komoly bázisra számítanak.

    Én most ezt próbálgattam, de nem zökkenőmentes még:

    Demos, Examples of Syncfusion Blazor Components - Preview

    Mindenesetre ez érdekes adat (sebesség):

    https://wijmoblazor.firebaseapp.com/benchmark

    Ettől függetlenül annyival elegánsabb, letisztultabb, biztonságosabb, egyszerűbb és ráadásnak lehetőséget biztosít C/S egységben fejlesztésre, a korábbi C# kódok használatára, hogy passzolom a JS-et :)
    Mutasd a teljes hozzászólást!
  • Kinek mi a véleménye erről most így, hogy megjelent a végleges verzió.
    A komponens gyártók közül a Devexpress meg a Telerik már rá is mozdult és csináltak valami kezdetleges csomagot is belőle.
    Native Blazor Components powered by DevExpress
    Mutasd a teljes hozzászólást!
  • Köszönöm, ez hasznos tipp volt. Sajnálatos módon a doksi nem nagyon hangsúlyozza ezt ki, és még a mellékelt példában is hibásan szerepel az ISO 8601-es dátum (Z nélkül).

    Ma sem keltünk fel hiába. 

    Szerk.: bár működik, de érdekes módon arra azért figyelmeztet, hogy így ne használjuk

    Note: parsing of date strings with the Date constructor (and Date.parse, they are equivalent) is strongly discouraged due to browser differences and inconsistencies.

    Szóval visszakanyarodtunk az eredeti problémához. Csak ES9 óta van standard Date parser, így ha az ember megbízható dátumfeldolgozást szeretne, inkább írja meg maga.
    Mutasd a teljes hozzászólást!
  • Hiányzik a végéről a Z betű, ezért lokális (tulajdonképpen ad-hoc) és nem UTC (ISO 8601 - Wikipedia )
    "2019-03-11T14:02:06.24" helyett "2019-03-11T14:02:06.24Z", és máris jön a hiányolt kimenet.
    Mutasd a teljes hozzászólást!
  • Bejön, de

    1. pont az elvi problémára kívántam rámutatni JS-ügyben, hogy még ilyen alapvető dolgokban sincs egységes, "gyári" támogatás, mint a dátumkezelés (.NET alatt ez a kezdetektől, lassan 20 éve egységesen van kezelve, JS alatt meg egy standard Date.parse() is implementáció-függő, bár ahogy nézem, ES9-ben sikerült végre specifikálni, így már csak pár év, és lehet is rá támaszkodni),

    2. ebben az esetben kicsit ágyúval veréb lett volna, hiszen csak egy egyszerű, értékadó konverzióra volt szükségem, minden extra nélkül, amit a momentjs tud.
    Mutasd a teljes hozzászólást!
  • ..és mi legyen a hatalmas mennyiségű C# forrást felhalmozókkal?

    Kétségtelen, esetükben lehet jobb megoldás, de a többség már elkezdett valami komoly felületi FW-öt használni, pl AngularJS és könnyebben is kapnak a piacon ahhoz értő programozót. Tehát alapvetően igazad van, de ez szerintem nem elég nagy tétel a kritikus tömeg eléréséhez. Meglátjuk, 1-2 év és világos lesz mennyi embert keresnek blazor tapasztalattal a piacon.
    Mutasd a teljes hozzászólást!
  • moment.js miért nem jön be neked dátum kezelésre?
    Mutasd a teljes hozzászólást!


  • Hát pont ez a gond.

    Itt egy minta JSON, az idő UTC-ben van:

    { "userCreated": "2019-03-11T14:02:06.24" }

    Az általad javasolt konverzió (Google Chrome 74-ben):

    const jsonUtcDate = "2019-03-11T14:02:06.24"; console.warn(jsonUtcDate); // 2019-03-11T14:02:06.24 const myDate = new Date(jsonUtcDate); console.warn(myDate); // Mon Mar 11 2019 14:02:06 GMT+0100 (Central European Standard Time)
    Elvárt eredmény: Mon Mar 11 2019 15:02:06 GMT+0100 (Central European Standard Time)

    Nyugodtan lehet Google-t is használni, nem triviális megoldást találtam csak.
    Mutasd a teljes hozzászólást!
  • ...és mi legyen a hatalmas mennyiségű C# forrást felhalmozókkal?
    Nem egyszerűbb nekik Blazor-ban indítani egy webes alkalmazást a tucatnyi nem webes dotnet alapú alkalmazásukhoz?

    A véleményed a standalone weblapokra jó... de egy C#-ban írt vállalatirányítási rendszer webes frontendjénél a JS erőlködés megbukik. 

    Mennyiségben és pénzben is jelentős tömeg a dotnet és ha ezt ki lehet használni a kliens oldalon (egy újabb frontend a többi mellé!!! nem az "egyetlen a web" koncepcióban), akkor megéri.
    Mutasd a teljes hozzászólást!
  • Persze hogy nem arra való. A amire a Silverlight való volt, az ugyanaz volt mint a Flash. És a koncepció is együtt halt vele. Onnantól kezdve csak a html5 és a javascript volt. Persze a MS elkezdhetett volna egy Silverlight to html5/js projectet, de mire elkészülnek vele, addigra a kihűl a Föld.
    Mutasd a teljes hozzászólást!
  • JSON-ban érkező UTC idő natív, helyi időzónájú Date objektummá alakítása - valaki Google nélkül?

    new Date(valami). Ahol a valami mondjuk egy Unix timestamp vagy egy ISO akármilyen dátumstring, amit a toJSON is gyárt. Amúgy a Date belül nem függ időzónától, azt csak a get/set/toString metódusai nézik.
    Mutasd a teljes hozzászólást!
  • így pár év múlva már valóban lesz értelme a nyelvek népszerűségét vizsgálni a népszerű topicokban. :)

    LIKE :)
    Mutasd a teljes hozzászólást!
  • Az aggályaid jogosak: a Microsoft híres arról, hogy ugyan nagyon átgondolt, hosszútávú megoldásokat hoz ki, de megkésve, lemaradva a piacról (Windows Phone remek példa). Ugyanakkor arra is van több példa, hogy türelemmel, sok év veszteségét benyelve végül elterjesztik a technológiát (ld. Xbox - személy szerint vártam a bukását, nem értettem, mit akarnak ezzel a PlayStation 2 után).

    A Silverlight ugyanakkor egy másik vezetés, másik stratégia mentén született, évekkel a NodeJS és az ES6 előtt. Ballmer az Apple mostani hozzáállásához hasonlóan zárt ökoszisztémában gondolkodott: használj mindenütt Microsoft terméket, ahol csak lehet (ld. mint Flash alternatíva), minél jobban magukhoz kötve a felhasználókat. Windows kell a Silverlighthoz? Micsoda pech, akkor azt is venni kell.

    Utána jött a fizetős szoftverbolt a Windows 8-cal és az Apple-höz hasonlóan rájöttek, hogy a boltkínálatukat szűkíti egy böngészős platform, ami ennyire tág alkalmazási lehetőségeket kínál, így megszabadultak tőle.

    Nadella teljesen más stratégiát követ, és onnantól, hogy a Blazor a .NET Core része, még alacsony elterjedtség esetén sem valószínű, hogy csak úgy kidobják. Ha nagyon nem teljesít majd jól, akkor valószínűleg egyszerűen csak támogatott marad, kizárólag hibajavításokkal, érdemi fejlesztések nélkül. Ahogy a FAQ írja: az alapjai is teljesen mások, a nyílt webre készül, cross-platform eszközként.

    A JS szerintem az ES6 óta tekinthető használható nyelvnek, mindössze 4 éve, és máig alapvető dolgok hiányoznak, túlbonyolítottak ill. inkonzisztensek, pl. egy JSON-ban érkező UTC idő natív, helyi időzónájú Date objektummá alakítása - valaki Google nélkül? Egy tipikus feladat, standard metódus nélkül.

    Ráadásul ha nézegetted a Blazort, láthatod, hogy nemcsak arról van szó, hogy azonos nyelvet és eszköztárat használ szerver és kliens oldalon. Látszik, hogy a készítői tanulmányozták a konkurens framework-öket és próbálták mindenből a jó ötleteket összeszedni. Bármennyire is sokat fejlődött a JS környezet és TypeScript-tel kombinálva már valóban használható és karbantartható megoldásokat lehet készíteni, azért még mindig ég és föld egy Angular/React fejlesztői élmény egy C#/Razor pároshoz képest, ez pedig értékké válik (válhat) majd a produktivitásban.

    Részemről a teljesítménytől félek a legjobban: biztos kelleni fog némi idő, amíg kiforr. Viszont javarészt máshol bizonyított, ismert technológiát használ, így C# fejlesztőként nincs túl sok kockázat benne (kicsi a tanulási görbe). Döntéshozóként - épüljön-e erre a kliensem - izgalmasabb a kérdés, ez igaz.

    Én egyébként arra számítok, hogy ez csak a kezdet: a WebAssembly terjedésével egyre több külsős nyelvet (értsd: nem JS) lehet majd webes kliensoldali fejlesztésre használni, így egyre többen használják majd a sajátjukat hasonlóan (pl. Java), így pár év múlva már valóban lesz értelme a nyelvek népszerűségét vizsgálni a népszerű topicokban. :)
    Mutasd a teljes hozzászólást!
  • Nem véletlenül vagyok tamáskodó a Blazor-al kapcsolatban! Pontosan tudom, hogy a Microsoft miért hozta ki, de tartok tőle, hogy ez ismét egy olyan elkésett vergődés lesz, mint a Windows Phone volt. 

    Az a helyzet, hogy a fejlesztők érthető elvárása, hogy a kliens és szerver oldalon ugyanaz a programnyelv dolgozzon Web-es fejlesztések esetén. Számos komponens újrahasznosítható - pl validáció, DTO-k -, illetve javul a REST interfész minősége is a két oldal kompatibilitása miatt. Ebbe a világba nőtt bele az ES6 (és utódai majd), valamint a NodeJS. A Microsoftnak erre kezdetben a Silverlight volt megoldása, de az - mindegy milyen indokok miatt - megbukott. És most be akar törni a C#-al mindkét oldalra, amikor már ott egészen jól használható JavaScript framework-ök vannak,  sőt ha kell TypeScript-ben is lehet dolgozni. Hát innen nézve nem tűnik úgy, hogy sikerülni fog. És ez nem szól a JavaScript minőségéről, a típusosságról, a C# és .NET minőségéről és teljesítményéről. Egyszerűen csak praktikus szempontokról. Ráadásul annyian dolgoznak már JavaScript-ben, hogy nem biztos, hogy átvágynak bármi másra. Nem hiszem, hogy megvan a kritikus tömeg.
    Mutasd a teljes hozzászólást!
  • Meddig tart megismerni 1-2 nap, netán 1 hét?

    Az attól függ mit akarsz csinálni.
    Kirakni egy gridet egy textbox-al pár perc.
    Egy datagird már icipict több.
    Komplex controlokat írni (amelyek nem eszik szanaszét az összes erőforrást) meg azért jónéhány hónap.

    Hidd el elég sok embert oktattam. Valakinek ez atomfizika volt. Az egész UI meg az MVVM meg a binding meg minden.
    Nem azért mert hüje volt, hanem egyszerűen csak mert.
    Mutasd a teljes hozzászólást!
  • Mindenki saját maga dönti el, hogy mit vállal be. :)
    Mindazonáltal picit fura, hogy az MS a .Net-hez nem nagyon akar AI támogatást adni.

    A többi frameworknek meg vagy nincs c# wrappere vagy "valaki" önszántából fejleszti.
    Abban se vagyok biztos, hogy azok production ready cuccok, vagy nem
    Meg amúgy is, a problémáinkra a CNTK volt a legalkalmasabb

    na még utoljára írd be a gugliba: Over 80% Microsoft internal DL workload runs CNTK

    de mint írtam, nincs gond.
    1. mert ez még legalább 2 évig kitart mire a következő generációs GPU-k divatba jönnek. tehát idő mint a tenger valami mást keresni. Már ha kell. 
    2. simán lehet, hogy a community viszi tovább.

    szerintem ezt túlragoztuk :)
    Mutasd a teljes hozzászólást!
  • Ha visszaolvasol, az volt a kifogás, hogy itt az új technológia, a Blazor, csak nehogy hiába tanuljuk meg, mint a Silverlightot.

    Miközben.
    Mutasd a teljes hozzászólást!
  • Igazából nem izgat ez a "meghalt a silverlight" topic, csak állandóan azt látom, hogy mindenki a túlélő xaml-t hozza fel (wpf, xamarin, uwp). A probléma, hogy egyik sem arra való, mint amire a silverlightot kitalálták, továbbá, a xaml meg, mint "dekleratív nyelv" hát nem egy rocketsience, hogy überkirály tudást birtokol az illető, ha ismeri :D
    Meddig tart megismerni 1-2 nap, netán 1 hét?
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd