Kinyírja natív webes technológiáját a Google

Kinyírja natív webes technológiáját a Google
2017-05-31T07:34:40+02:00
2017-06-09T17:39:22+02:00
2022-10-19T15:20:33+02:00
  • A valóság a HTML és a CSS esetében is az, hogy azok nem véletlenül olyanok, amilyen - és hogy bármilyen keretrendszer, ami pontosan ugyanazoknak az elvárásoknak kellene, hogy megfeleljen, mint ezek a technológiák, ugyanazokkal a problémákkal is rendelkezne.


    Ez igaz, a sok öröklött kolonc miatt olyan amilyen. A CSS-t a HTML-be szintúgy bele kellett erőltetni. A HTML meg egy szánalmas kacsacsőr tag-es nyelv ami egy 50 éve kitalált mégelavultabb SGML-re épül, amit agyontákltak már mindenféle új funkcióval. Az egészet kukázni kéne egy az egyben. És új alapokra építni valamit.

    Egy widget toolkitre épülő valami messze nem lenne ennyire szerencsétlen mint ami most van. GUI-khoz csináltak már ilyeneket. A hetvenezer CSS szabály, meg paraméter röhejes.
    Mutasd a teljes hozzászólást!
  • Nem nagyon, mert gyakorlatilag senkit nem érdekelt az a sebességkülönbség, ami az úgymond natív, meg a JavaScript kódok futtatása között jelentkezett a böngészőkben.

    Saját példámon alapulva egyeseknél a már rég nem "don't be evil" Google-re bízni natív unsigned kód futtatását a saját gépeden, egy kontextben az autorizációs/autentikációs tokenjeiddel is biztos hasonló súllyal esett a latba..
    Mutasd a teljes hozzászólást!
  • Szerintem a WebAssembly viszont a flash játékok leváltására tökéletesen alkalmas.

    Szerintem a JS+jQuery, illetve az Angular meg a többi vakvágány leváltására is. :P
    Mutasd a teljes hozzászólást!
  • Ha most a teljesítményre gondolsz, a WebAssembly léte/hiánya már nem oszt, nem szoroz.

    Szerintem nyilván a teljesítmény is fontos, viszont az obfuszkáció / szellemi tulajdon védelme sem elhanyagolható.
    Mutasd a teljes hozzászólást!
  • A flash egy marha jó, korána jóval előtt járó elképzelés volt

    A probléma nem ebből eredt (ha ez egyáltalán így volt), hanem abból, hogy meg is ragadt ezen a szintén, és ezért egy idő után már nem hogy a kora előtt nem járt, hanem messze elmaradt az aktuális kortól. Ezért került lecserélésre és nyugdíjazásra.

    Gyakorlatilag ez lesz most ami flash képességeinek egy részét hozza, a JS mindig csak valami HTML-be beletrógerkedett förmedvény volt.

    Némileg cáfolja az "elméletedet", hogy a JavaScript már pusztán önértéken és a HTML-től függetlenül is jó ideje hódít, és egyre több helyen vált le egyre több másik, részben nála újabb technológiát.

    Már csak valami értelmes szabványos UI framework kéne OpenGL/Vulkan alapon és akkor kukázni lehetne a HTML/CSS ganéjságot is.

    Ezt ugyanolyan botorság gondolni, mint azt, hogy ha mindenhol Linux lenne Windows helyett, akkor minden sokkal biztonságosabb lenne (még attól eltekintve is, hogy a Linux már így sem biztonságosabb és soha nem is volt az). Mert nem lenne az, hanem éppen azoktól a problémáktól szenvedne, mint amiktől a Windows is - aminek ilyetén jellegű problémái elsődlegesen szintén pusztán pozíciójából ered.

    A valóság a HTML és a CSS esetében is az, hogy azok nem véletlenül olyanok, amilyen - és hogy bármilyen keretrendszer, ami pontosan ugyanazoknak az elvárásoknak kellene, hogy megfeleljen, mint ezek a technológiák, ugyanazokkal a problémákkal is rendelkezne.

    Nem mintha egyébként a HTML/CSS és az OpenGL/Vulkan egymást kizáró dolgok lennének, sőt, nem mintha a modern HTML/CSS implementációk és környezetek legtöbbje nem használná ki az OpenGL-t és/vagy a Vulkant, és nem építene rájuk - és ebből eredően ne lenne eleve orbitális hülyeség az egész kijelentés. Csak mondom.
    Mutasd a teljes hozzászólást!
  • A flash egy marha jó, korána jóval előtt járó elképzelés volt amit az Adobe szépen lepusztított.



    Gyakorlatilag ez lesz most ami flash képességeinek egy részét hozza, a JS mindig csak valami HTML-be beletrógerkedett förmedvény volt. Már csak valami értelmes szabványos UI framework kéne OpenGL/Vulkan alapon és akkor kukázni lehetne a HTML/CSS ganéjságot is.
    Mutasd a teljes hozzászólást!
  • Nincs semmi amitől annyira ideggörcsöt tudnék kapni mint a flash, egy hatalmas bűn az egész emberiség ellen.

    Szerintem ma már csak az találkozik Flash-es tartalommal, aki kifejezetten keresi. (Ja, az azért ugye megvan, hogy a cikk nem a Flash-ről szólt?)

    a szerencsétlen egy szálat tud kihasználni.

    Ez így nem igaz. FlashPlayer 11.4 (2012) óta vannak Workerek, 11.5 (2013) óta akár osztott memóriával is. Ez utóbbit amúgy a JS-be máig nem sikerült belealkotni. Szóval lenne ott minden, csak ez már nem számít.
    A különféle rémes Flash tartalmak elsősorban azért készülhettek el, mert nagyon (szinte túlságosan is) egyszerű volt a használata. Összekattintgatós Pistike nyilván sosem gondolkozott szálakban.
    Mutasd a teljes hozzászólást!
  • Nincs semmi amitől annyira ideggörcsöt tudnék kapni mint a flash, egy hatalmas bűn az egész emberiség ellen. Az Adobe csodálatosan megcsinálta hogy minőséget se lehessen már állítani rajta, ha meg valami hordozhatóbb eszközön akarod használni rohadt lassú mert a szerencsétlen egy szálat tud kihasználni.
    Mutasd a teljes hozzászólást!
  • Szerintem a WebAssembly viszont a flash játékok leváltására tökéletesen alkalmas.

    Ha most a teljesítményre gondolsz, a WebAssembly léte/hiánya már nem oszt, nem szoroz. Bár a FlashPlayer hamarabb JIT-elt (FP9, 10 évvel ezelőtt), a JavaScript motorok 2-3 év alatt behozták, majd végleg lehagyták. Ezután már nem a teljesítményre kellett várni, hanem a HTML5-re.
    Szóval a körítés tartotta életben a Flash-t, ideértve akár a fejlesztőeszközöket, akár a belepakolt technológiákat (tulajdonképpen minden előbb lett, mint a HTML/JS világban -vektorgrafika, gyorsított 2D/3D grafika, bináris adatok kezelése, hang, videó, többszálúság, a már említett JIT, stb.-, ráadásul a különféle browsereket sem kellett hozzá "összevárni" és/vagy polyfilleket használni).
    Mutasd a teljes hozzászólást!
  • Webes kimenete már van, JS-be tud konvertálni, másra nagyon nincs szükség a többit támogatja natívan (C++).

    Egyébként is alapvetően egy stílus kevés kivétellel nem igazán játszható teljesen eltérő platformokon. Szóval ami konzolra jó az mobilra, vagy webre nem biztos, úgyhogy ez a sok platformos fejlesztés inkább elméleti, mint gyakorlati szempont.
    Mutasd a teljes hozzászólást!
  • Annyi van, hogy a web is egy platform. És ha Pl. olyasmit szeretnél mint a jó öreg flash játékok, csak 3D-ben, és kicsit csilli-villibb megjelenéssel, akkor arra pont jó.

    Ráadásul mivel multiplatform, így az Angry Birds 3D-t eladhatod mobilra natívan, és asztalon akár böngészőben is futhat.
    Mutasd a teljes hozzászólást!
  • Igen, az interpreterek megírhatóak webassemblyben. Ez egy dolog. De ennél sokkal fontosabb, hogy a compilereknek lehet cél platform.
    Hatalmas library-k jelenhetnek meg a böngészőben, ez a nagyobbik előny.
    Mutasd a teljes hozzászólást!
  • Maga a Unity már eleve 30 féle platformon fut. Na most egy platform független réteget egy másik platformfüggetlen rétegre lefordítani olyan sok értelme nincs.
    Mutasd a teljes hozzászólást!
  • A flashben rajzolt játékok leváltására a sima js és a 2d canvas is tökéletesen alkalmas.

    Én a webassemblyben inkább ott látom a fantáziát, hogy ezzel meg lehet(ne) csinálni Pl. azt, hogy nyelvfüggetlen legyen a web. Azaz meg lehetne írni webassemblyben a javacript, typescript, python, c#, java, stb interpretereket amik betöltődnek ha kell, és onnantól kezdve ki-ki olyan nyelven írhatna webes alkalmazást amilyet szeret. Ezek az interpreterek szintén webassemblyre fordíthatnának lokálisan, így a böngészőben futó kód is sokkal gyorsabb lenne. Harmadrészt, így meg lehetne azt is csinálni, hogy a böngészőbe elve a lefordított kód megy le a forráskód helyett, amitől még gyorsabb lenne az egész.

    Kérdés, hogy megcsinálja-e ezt valaki, vagy marad minden a régiben.

    A másik amire jó lehet ez, hogy Pl. a unity3d és a többi játékkészítő platform csinálhat webassembly outputot a játéknak, ami azt jelentheti, hogy a játékok terén is erősíthet a web - persze szerintem Skyrim továbbá sem lesz, de kisebb, de igen látványos, főleg kód orientált 3D-s játékok simán lehetnek.
    Mutasd a teljes hozzászólást!
  • A legtöbb játékban már ezer éve nem előre lerenderelt pályák vannak. A gond az, hogy a modelleket, textúrákat be kell tölteni, és Pl. egy skyrim esetén, ahol egy-egy pálya egy kisebb város elég nagy adatmennyiség akkor is, ha azért egyes dolgok ismétlődnek. Ez már nem a Baldur's Gate világa ahol tényleg előre lerenderelt képekből összerakott tilemapokon gyalogoltak a kézzel rajzolt karakterek.
    Mutasd a teljes hozzászólást!
  • Szerintem a WebAssembly viszont a flash játékok leváltására tökéletesen alkalmas.

    A Hacker News-on demózta valaki a saját home projektjét, ezt:

    Funky KartsMeglepően gyorsan betölt, meg gyors meg minden. Egész meglepődtem.
    Mutasd a teljes hozzászólást!
  • Ha jól emlékszem akkor a skyrim-ban nem előre renderelt pályák vannak hanem betöltéskor csinálja ezt meg. Gondolom az lehet több idő. A stalker-ben viszont előre le kell renderelni a pályákat (anno a core 2 duo-n 2 hétig csinált a gép egy pályát) még se tölt be gyorsabban. Company of heroesben is betöltéskor renderel és krafikai beállításoktól függően nagyon nagy eltérés lehet.
    Mutasd a teljes hozzászólást!
  • Még így is várni kell úgy egy percet amíg a skyrim betölti a pályát, ami azt jelenti, hogy derekas adatmennyiségek mozognak, tekintve hogy ezt az egy percet SSD-ről töltögeti egy C++ kód - jó, közben nyilván kicsomagol és csinál még ezt-azt.
    Mutasd a teljes hozzászólást!
  • Arról azért érdemes megemlékezni, hogy a játékok nem töltik be egyszerre az összes erőforrásukat a memóriába, szóval azok akár streamelhetőek is. Mondjuk ha a cache-t is szeretnéd használni, akkor a streamelést nem érdemes szó szerint venni, de továbbra sem lesz szükséged az összes zenére meg textúrára egyazon időpontban.
    Mutasd a teljes hozzászólást!
  • Más piac. A számításigényes dolgok vagy olyan rétegigények amire nem biztos hogy a legjobb megoldás a web - Pl. Visual Studio - vagy eleve szerver oldalon számolnak. Ami nagyobb számításigényes dolog az a játék - ott viszont a játékélmény szempontjából a lokális app jobb, mivel még mindig gyorsabb betölteni a több gigabájtnyi grafikát, zenét, pályát egyszer, aztán minden induláskor mehet SSD-ről, mint minden játéknál letölteni az egészet a netről. Egy skyrimot nem biztos hogy szeretnél böngészőben játszani.
    Mutasd a teljes hozzászólást!
  • Teljesen logikus döntés.
    Mutasd a teljes hozzászólást!
  • Igazad lehet. Végül is kit érdekelne a világ legnagyobb (az Androidénál minimum 3x nagyobb) elérésű, legkisebb költségekkel működő és leggyorsabb áruforgalmat biztosító egységes piaca, a web?
    Mutasd a teljes hozzászólást!
  • Vagy inkább a web nem érdekli az olyan cégeket, akik sebesség kritikus alkalmazásokat fejlesztenek, hogy energiát feccöljenek rá, ahogy a Google Android NDK-ba feccölnek elég sokan.
    Mutasd a teljes hozzászólást!
  • Ez egy "vakvágány" volt...
    Mutasd a teljes hozzászólást!
  • Nem nagyon, mert gyakorlatilag senkit nem érdekelt az a sebességkülönbség, ami az úgymond natív, meg a JavaScript kódok futtatása között jelentkezett a böngészőkben. Annyira legalábbis biztosan nem, hogy energiát feccöljön a PNaCl port megvalósításába és külön támogatásába.
    Mutasd a teljes hozzászólást!
  • Volt valaha egyáltalán valami elterjedtebb dolog ami használta ezt a technológiá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