Böngészőkben is futhatnak majd a .NET alkalmazások

Böngészőkben is futhatnak majd a .NET alkalmazások
2017-08-11T07:22:43+02:00
2017-08-15T19:27:27+02:00
2022-10-19T11:10:34+02:00
  • Mikor lesz GC?
    A C# --> WebAsm kompiler megalkotja.
    A forrás (jórészt) már megvan, a kompiler készül. :)
    Mutasd a teljes hozzászólást!
  • A dotnet core-nak például akkora GC class-t írtak, hogy a GitHub már nem is támogatja

    A kód tele van opcionális részekkel, szóval amit a valóságban le kell fordítani, az jóval rövidebb. És 1 mega formázott forráskódból mekkora lefordított kód lesz? 1-200 kilobyte? Tömörítve mondjuk a harmada?
    Szerintem belefér, az én csőrömet pár megányi JavaScript framework akkor már jobban böki.

    Amúgy "igazi" GC nélkül, pimf kis referenciaszámlálással nagyon messzire el lehet jutni, sok projektnek az is elég lenne.
    Mutasd a teljes hozzászólást!
  • Ez szép és jó, de én csak azon gondolkodtam, hogy vajon mikor is lesz GC. Csak nem arra reagált (mint ahogy te sem.)



    Hanem valami képzelt téveszmére.
    Mutasd a teljes hozzászólást!
  • gc.cpp 36783 sor.

    Tény, hogy nem nyerő kódszervezés (36783 sor egy osztályban), különösen mivel a C# ismeri a partial class-okat is. 

    De ugye ez a webes világon túl nem számít komoly méretnek?
    Mutasd a teljes hozzászólást!
  • Talán nem ártana, ha nem 'okoskodásnak' tekinted a másik gondolatát.

    Két irányba mennek (ahogy olvastuk), ahogy a nem virtuális processzorokon is ez van.

    Az egyik irány egy VM megalkotása WebAssembly-ben megirva, ami közvetlenül futtatja a byte-kódokat.
    A másik irány az ami folyamatban van pl. a Xamarin vonalon is, a natív kóddá fordított C# forrás és ekkor persze a GC funkcionalitás belinkelve a programba libraryból.
    Mutasd a teljes hozzászólást!
  • Minek kell okoskodni? Ha nincs megírva akkor nincs. GC nélkül meg nincs pl. C#
    Mutasd a teljes hozzászólást!
  • A dotnet core-nak például akkora GC class-t írtak, hogy a GitHub már nem is támogatja 


    dotnet/coreclr
    Mutasd a teljes hozzászólást!
  • ? Garbage collection · Issue #1079 · WebAssembly/design

    (Azt azért ugye tudod, hogy az x86-os processzorok sem támogatják a GC-t, mégis van rájuk .NET?
    A GC nem varázslatból készül, szükség esetén meg is lehet írni.)
    Mutasd a teljes hozzászólást!
  • Tudtommal a webassemlbyből hiányzik a garbage collection. Amire a .net-nek igen csak szüksége van.
    Arról van hír hogy mikor implementálnak GC-t a webassemblybe?
    Mutasd a teljes hozzászólást!
  • "a JS a web assembly nyelvévé vált"

    Igen egy évtizede. De mivel nem jól csinálja a dolgát kitalálták a WebASM-et, ami még mindig nem a tökély, de már az a kompromisszum a JS és egy újonnan kifejleszett bytekód között, ami már előrébb lökheti a technologiát.

    De a JS megmarad. Úgy tűnik örökre. Csak visszakerül a helyére: script nyelv kis weblapokba szúrt kódoknak.
    Mutasd a teljes hozzászólást!
  • Teljesen egyetértek. Scott Hanselman már jó ideje hangoztatja, hogy "a JS a web assembly nyelvévé vált", és szerintem igaza van.

    JavaScript is Assembly Language for the Web: Sematic Markup is Dead! Clean vs. Machine-coded HTML -
    Mutasd a teljes hozzászólást!
  • Miféle káoszra gondolsz?

    Ennél jobb összefoglalót még nem láttam: How it feels to learn JavaScript in 2016

    Ez a .NET stack-kel összehasonlítva szvsz egy káosz.

    Félreértés ne essék, a kliens oldalt magam is JS-ben írom (React/Angular), és nagyon tetszik a végeredmény (a közel natív program futtatására emlékeztető teljesítmény bármely böngészőben), de a fejlesztési élmény mindig úgy 15 évvel ezelőtti állapotokra emlékeztet.

    ES6 óta már sokkal jobb a helyzet: már kezd valódi projectre hasonlítani egy kliens oldali web app, nemcsak egy spagetti-scripthalmazra, kár, hogy pont a JS egyes állítólagos előnyei feláldozásával értük ezt el (lassú, fordított kód; rengeteg boilerplate copy/paste rész - hol vagyunk már attól az előnytől, hogy nem kell kiírni a típust - stb.).

    Ha mindez kiegészül azzal, hogy a WebAssembly jóvoltából gyakorlatilag a JS csak egy egységes futtatóplatform lesz, amin immár tetszőleges technológiákkal gyártott kódot lehet futtatni, hát az egy megvalósult álom lenne. És ez a hír pont ezt vetíti előre.
    Mutasd a teljes hozzászólást!
  • Eddig úgy szólt a fáma itt prog.hu-n hogy a JS a leggyorsabb. (Gyorsabb mint az assembly, vagy GPU-ra protolt implementacio

    Te valamit nagyon félreérthettél eddig.

    Most akkor mi van? Mégis csak van amitol a JS lassabb? :O

    Ezt is félreértetted.
    Mutasd a teljes hozzászólást!
  • Végre. Innen kellett volna indulnia a .Net torténetnek 17 éve.

    Tizen éve pluginok voltak. Mint a FlashPlayer meg a Java... meg persze a Silverlight.

    "ami a korábbiaknál hatékonyabban teszi lehetővé kódok futtatását a webes szoftverekben"

    Eddig úgy szólt a fáma itt prog.hu-n hogy a JS a leggyorsabb. 

    A hatékonyság nem kizárólag a sebességről szól, egy webassembly bináris reprezentáció mérete a töredéke egy azonos működést leíró forráskódú reprezentációénak. Más nyelvből keresztfordított JavaScript kódnak (pl. Emscriptennel) tipikusan se füle se farka, szóval a nézegetésével nem nyersz semmit, viszont cserébe jó nagy.
    Mutasd a teljes hozzászólást!
  • Végre. Innen kellett volna indulnia a .Net torténetnek 17 éve.

    "ami a korábbiaknál hatékonyabban teszi lehetővé kódok futtatását a webes szoftverekben"

    Eddig úgy szólt a fáma itt prog.hu-n hogy a JS a leggyorsabb. (Gyorsabb mint az assembly, vagy GPU-ra protolt implementacio egy 10 PetaFlops-os GPU grid-en) Most akkor mi van? Mégis csak van amitol a JS lassabb? :O
    Mutasd a teljes hozzászólást!
  • "mert majd pattog a piros képernyő, hogy az az alkalmazás alá van-e írva valami digitális kulccsal meg miahócipő"
    ma már egy valamire adó desktop program fejlesztője is megveszi a code signing certificate-et. Anélkül a windows rengeteg akadályt gördít az install elé. Én személy szerint fel se rakok olyan szoftvert ami nincs aláírva.
    Mutasd a teljes hozzászólást!
  • Azt hogyan? Le kell tölteni, el kell indítani. Ugyan azt csinálja a böngésző is.

    Csak, hogy a böngésző mindezt automatikusan csinálja, míg a natív alkalmazásnál minden lépést neked, felhasználónak kell csinálnod vagy legalábbis tovább lendítened. Ez időben és fáradtságban is rengeteg (sokszoros) különbség - pláne az általad említett kis programok esetében (amik kódjának letöltése amúgy a másodperc törtrészéig tart).

    Ha letöltesz egy bin progit, és pld chrome-od van, látod alul a pici fület, kattintasz rá, azonnal elindul.

    Nem. Egyrészt mert egy rakás warningot kell átnyomnod, mire egyáltalán futtathatsz bármilyen, frissen letöltött natív alkalmazást. Másrészt mert a valamire való natív programokat nem "bin progi"-kban, hanem telepítőkkel szokták kiadni (mert hogy általában nem egyetlen monolitikus futtatható állományból állnak, hanem több tucat vagy több száz dinamikusan linkeltből/megosztottból), amiknél licencszerződés, célkönyvtár kiválasztás, stb. van. Harmadrészt azért, mert Windows-on kívül még a keretrendszert is ugyanígy le kell tölteni (sőt, Windows-on is lehet, hogy le kell tölteni, ha régebbi van csak fent, mint az igényelt), a keretrendszer telepítőjét el kell indítani, fel kell telepíteni, stb. - amire még inkább igazak a fenti megállapítások.

    De ha olyan egyszerű is lenne minden, mint ahogy mondod, akkor is igaz lenne, hogy egyrészt ha csak pár kattintással és pár másodperccel is, de körülményesebb a natív program letöltése. Másrészt akkor is igaz lenne, hogy ettől függetlenül a böngészőben futó változat semmivel sem kellene, hogy lassabb legyen a natív kiadásnál - mert hogy a közhiedelemmel ellentétben semmi sincs, ami ezt technikailag szükségszerűé tenné.

    Szóval amiatt aggódni, hogy majd pont a böngészőben lesz körülményesebb és lassabb egy-egy program letöltése és futtatása, nyilvánvalóan technikai szempontból teljesen értelmetlen.

    A hátrány meg majd ott lesz, amikor kitalálják, hogy milyen progit indíthatsz el böngészőben, és milyet nem, mert majd pattog a piros képernyő, hogy az az alkalmazás alá van-e írva valami digitális kulccsal meg miahócipő.

    Miért találnák ki ezt? És ugyanezt miért ne találhatnák ki natív programok esetében is? Olyan dologról beszélsz, aminek egyrészt kevés a realitása, másrészt aminek semmi köze a böngészős környezetben működéshez. Ha valaminél, ott pont sokkal kevésbé valószínű, hogy ilyesmit bevezessenek, hiszen a böngésző egy eleve sandboxolt és a gazdarendszerről többé-kevésbé leválasztott környezet, ahol ebből eredően sokkal kevésbé fontos az eredet ellenőrzése - mert hogy a programok, ha nem eredeti/megbízható forrásból származnak, akkor is kisebb károkozó potenciállal rendelkeznek előbbi okból kifolyólag.

    Amihez böngésző kell, az mindig is kekecebb környezet lesz, mint az, amihez nem kell.

    Megint nem. A "kekecség" amiről beszélsz, a biztonsággal függ össze, nem azzal, hogy böngészőben vagy nem böngészőben működik valami. A böngésző ebből a szempontból egyébként pont kevésbé kekec (mert ti. eleve egy védett, limitált környezet - lásd fent), ahol meg a böngésző is kekec, ott szükség is van a kekecségre, és ugyanolyan vagy még nagyobb kekecség (lásd pl. UAC, biztonsági zónák, társított alkalmazástípusok jóváhagyása, stb.) várható el natív környezetben is azonos biztonsági szint eléréséhez.
    Mutasd a teljes hozzászólást!
  • értsd: előbb tudja ugyanazt az eredményt szolgáltatni


    Azt hogyan? Le kell tölteni, el kell indítani. Ugyan azt csinálja a böngésző is. Ha letöltesz egy bin progit, és pld chrome-od van, látod alul a pici fület, kattintasz rá, azonnal elindul. Hol lenne a sebesség különbség?

    A hátrány meg majd ott lesz, amikor kitalálják, hogy milyen progit indíthatsz el böngészőben, és milyet nem, mert majd pattog a piros képernyő, hogy az az alkalmazás alá van-e írva valami digitális kulccsal meg miahócipő. Amihez böngésző kell, az mindig is kekecebb környezet lesz, mint az, amihez nem kell.
    Mutasd a teljes hozzászólást!
  • Várjatok jól értem? .NET-ből , WebAssembly-n keresztül végül JS-be forduló kód..

    Nem érted jól. A fordító és a böngészőben futó .NET VM is WebAssembly kódot generálnak, ami "közvetlenül", JS-be fordítás nélkül fut a böngészőben.

    És akkor még a Falsh volt a lassú?

    Egy WA (sőt, akár egy JS-ben) lévő .NET kód simán lehet effektív ugyanolyan gyors, mint amilyen eredetileg volt .NET alatt. Nincs semmi, ami miatt szükségszerűen lassabbnak kellene lennie.

    Ráadásul ha hozzászámítjuk, hogy a böngészős futtatásához nem kell kézzel letölteni és telepíteni a programot, sőt, (pl. Linux alatt) a .NET környezetet/runtime-ot sem, akkor meg effektív még gyorsabb lehet egy ilyen megoldás (értsd: előbb tudja ugyanazt az eredményt szolgáltatni a felhasználó számára, előbb lehet a munkát elkezdeni vele, stb), mint a klasszikus, natív párja.
    Mutasd a teljes hozzászólást!
  • Várjatok jól értem? .NET-ből , WebAssembly-n keresztül végül JS-be forduló kód.. JS-be írt Webassembly parseren keresztül átforduló .NET kód? ??? 
    És akkor még a Falsh volt a lassú?    
    Mutasd a teljes hozzászólást!
  • Részemről csak a Blazor nevű projectről hallottam idáig, ami tényleg érdekesnek tűnik. Angolul tudóknak ajánlom, hogy nézzék meg a Blazor atyjának, Steve Sandersonnak az oslói NDC-n mondott beszédét.
    Másrészt viszont szerintem ennek az egésznek nem sok értelme van. Lehet próbálkozni különböző kísérleti projectekkel, de ezt a versenyt toronymagasan megnyerte a JS.
    Mutasd a teljes hozzászólást!
  • Na a végén még a .NET egész kellemes környezet lesz.

    @Kukipapa

    Részemről megváltóként várom a WebAssembly-t, az talán végre rendezett alapokat ad ennek a káosznak, amit ma webes frontend fejlesztésnek hívunk.

    Miféle káoszra gondolsz? Nem hinném, hogy átveszi, én remélem hogy nem. A HTML5 és a CSS3 nagyon jó dolgok, én örültem neki, hogy végre egész sok helyre eljutott, mert így végre van egy mainstream vonal a UI fejlesztésekhez.
    Mutasd a teljes hozzászólást!
  • Kukipapa hozzászólása 2017.01.09. 13:58:

    Részemről megváltóként várom a WebAssembly-t, az talán végre rendezett alapokat ad ennek a káosznak, amit ma webes frontend fejlesztésnek hívunk.

    Sting válasza Kukipapa (13:58) részére 2017.01.09. 14:20:

    A WebAssembly semmit nem fog változtatni azon, amiken panaszkodtál. Sőt, maga is megtestesítője annak a folyamatos, a változó lehetőségek és igények által indukált fejlődésnek, ami számos másik platformról hiányzik.
    Mutasd a teljes hozzászólást!
  • 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