Vlákno názorů k článku
Mozilla, Intel, Red Hat a Fastly formují Bytecode Alliance pro běh WebAssembly všude od oss - 1. Hadam sa dozijem obdobia, kedy sa prestanu...

1. Hadam sa dozijem obdobia, kedy sa prestanu zneuzivat webove technologie na desktope (uz tu mame neskutocne hrozny Electron).
2. Ja by som bol radsej keby dana Aliancia zatlaci na vyvoj dalsej funkcionality WebAssembly ako pristup k domu a tym zrusi monopol javascriptu na webe.
3. Sandboxyng sa nerovna bezpecnost. Casto sa stava, ze prinesie viac komplikacii pre serioznych vyvojarov ako pre tych, co by vam chceli skodit, lebo ti si najdu cestu, hoci nebude fungovat u vstekych.

"1. Hadam sa dozijem obdobia, kedy sa prestanu zneuzivat webove technologie na desktope (uz tu mame neskutocne hrozny Electron)."

nevypadá to tak, popularita elektronových aplikací roste.

"2. Ja by som bol radsej keby dana Aliancia zatlaci na vyvoj dalsej funkcionality WebAssembly ako pristup k domu a tym zrusi monopol javascriptu na webe."

v čem to bude jiné než současné transpilery?

14. 11. 2019, 09:31 editováno autorem komentáře

"nevypadá to tak, popularita elektronových aplikací roste."
Zial exponencialne rastie aj zratie RAM, velkost isntalaciek, znizuje sa responzivita programov.
Ja chapem, preco si ho niektori deveopery vyberaju, ale pre pouzivatela vyhody neprinasa.

"v čem to bude jiné než současné transpilery?"
Tranpilery stale narazaju na to, ze je pod nimi javascript, ze sa ti moze stat ze v jazyku co ani nepozna NULL ti vyhene undefines zo strasnou chybou. Ak sa nebyvime len o supersete javascriptu (ako Flow alebo typescript) tak aj na vykon.
Ked sa bavime o prenosilnosti, tak je stale problem vyvjat pre vsteky browsre, lebo kazdy implementuje ine featury a niektore dropne (v tomto je Chrome majster), takze ostatni musia dohanat co si Google vymsli. Takze mas na jednej strane roztiepenost JS enginov a transpilerov ci babelu na druhej strane mas jednoduchu VM na interpretaciu bytecodu a vsteky ostatne jazykove a runtime featury si uz riesi samotny prekladac do bytecodu.

Podla mna by to prinieslo jednoduchsiu konsolidaciu a stabilitu medzi prehliadacmi a sucasne vyvojaom slobodu.

"Tranpilery stale narazaju na to, ze je pod nimi javascript, ze sa ti moze stat ze v jazyku co ani nepozna NULL "

to je na kompileru, aby to poznal, webassembly bytekód také nemá typovou kontrolu.

14. 11. 2019, 11:00 editováno autorem komentáře

>to je na kompileru, aby to poznal, webassembly bytekód také nemá typovou kontrolu.
Ale jazyk nad nim uz ano. A kedze ely modul je pod kontrolou tohto jazyka....

> Tranpilery stale narazaju na to, ze je pod nimi javascript, ze sa ti moze stat ze v jazyku co ani nepozna NULL ti vyhene undefines zo strasnou chybou.

Javascript NULL samozřejmě "pozná".

A nevím, jaký je rozdíl mezi " undefines zo strasnou chybou" a třeba Javovou NullPointerEx­ception.

"Javascript NULL samozřejmě "pozná"."
"A nevím, jaký je rozdíl mezi " undefines zo strasnou chybou" a třeba Javovou NullPointerEx­ception."

V tom, ze javascript ma plno nepeknych vlastnosti, ktore presakuju do prekladaneho kodu (null/undefined, volanie veci co nejstvuju, runtime chyby, porovnavanie,...).

Skusal som vela prekladacov do JS, fable, Elm, TypeScript, Flow, ale pri kazdom presakuje javascript vysie a neumoznuju tak vyuzit plny potencial jazyka. K tomu nechcem mat len prekladac do nedebugovatelneho javascriptu, chcem mat plnohodnotny jazyk a slobodu jeho vyberu. Co WebAssembly umozni.

Jdes s tim pozde. V Rustu uz se treba docela slibne rozjizdi pouzivani webassembly pluginu v nativnich programech. Ta technologie neni spatna a webova je v zasade jenom podle nazvu.

Myslíte projekt Watt ( https://github.com/dtolnay/watt )? Pokud ano, tak bych tomu úplně webassembly plugin neříkal. Pokud to chápu správně, tak se to používá pouze při kompilaci a výsledná binárka WASM runtime vůbec neobsahuje.

Ne, myslim https://medium.com/wasmer/executing-webassembly-in-your-rust-application-d5cd32e8ce46