WebAssembly for JVM

Jakie technologie WebAssembly specyficzne dla JVM są na rynku?
Czy gdzieś tutaj wrzucone client-side rozwiązanie scalowe, to jest formalnie właśnie WebAssembly?

Właśnie do kawy jadę prezentacje Blazora dla .NET, i to się może podobać.

Skalowalność do miliona userów, ustabilizowane API nie są moimi wymaganiami.

Scala-Native to WASM demo: https://github.com/shadaj/scala-native-wasm Scala-Native nadaje się do kompilowania do WebAssembly, bo używa LLVM pod spodem, a nie JVMa czy JSa.

http://teavm.org/

GraalVM posiada (aktualnie eksperymentalną) obsługę WebAssembly: https://www.graalvm.org/docs/reference-manual/languages/wasm/ GraalVM udostępnia Polyglot API, a więc można z poziomu WASM używać klas Javowych i vice versa. GraalVM i Polyglot API są tak skonstruowane, że jest jeden JIT do wszystkich języków i potrafi on robić np inlining między językami (np Ruby woła Javę, która woła WASM i JIT to spłaszcza do jednej metody bez wywołań funkcji/ metod/ etc).

Wideo na którym twórca Scala.js tłumaczy dlaczego nie zaimplementuje wsparcia dla WebAssembly (w obecnym jego stanie, czyli bez GC i innych bajerów) w Scala.js (ale nadal Scala-Native i TeaVM umożliwiają kompilację Scali do WASMa, przy czym TeaVM jest chyba bardziej sprawdzonym rozwiązaniem):

Trzeba też oczywiście wspomnieć o tym, że nie ma żadnego dowodu, że WebAssembly jest szybsze od JSa w kwestii obsługi GUI. Jeśli już to są dowody na tezę odwrotną: Rust skompilowany do WASMa jest wolniejszy od Vanilla.js w obsłudze HTMLowego GUI. Na https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html w "which frameworks" trzeba zaznaczyć vanilla (Vanilla.js) oraz wasm-bindgen (Rust skompilowany do WASMa). Właśnie zauważyłem, że do wyboru jest też blazor-wasm. blazor-wasm-v3.2.0-preview4.20210.8-keyed jest średnio 9x wolniejszy od vanilla.js, startuje ponad 13x dłużej i zabiera prawie 2.5x więcej pamięci. Niespecjalnie imponujące wyniki. binding.scala działa wielokrotnie szybciej chociaż zabiera trochę więcej pamięci. Implementacje można znaleźć tutaj: https://github.com/krausest/js-framework-benchmark/tree/master/frameworks/keyed

Nie należy też zapominać o https://en.wikipedia.org/wiki/Google_Web_Toolkit Co prawda nie kompiluje się do WebAssembly (gdy powstawał, to o WASMie w ogóle nie było mowy), a do JSa, ale jest sposobem na to, by pisać przeglądarkowe GUI w Javie, a nie JavaScripcie. W świecie Javy był na niego hype, tak jak teraz jest hype na Blazora w świecie C#.

Wibowit napisał(a):

Nie należy też zapominać o https://en.wikipedia.org/wiki/Google_Web_Toolkit Co prawda nie kompiluje się do WebAssembly (gdy powstawał, to o WASMie w ogóle nie było mowy), a do JSa, ale jest sposobem na to, by pisać przeglądarkowe GUI w Javie, a nie JavaScripcie. W świecie Javy był na niego hype, tak jak teraz jest hype na Blazora w świecie C#.

Myślałem, że skoro Java dawniej była w przeglądarce (jako Applet), że jest jakaś droga na skróty ;)
Oglądam, poczytałem materiały źródłowe o maszynie WebAssembly.
To rzeczywiście skomplikowane.

Są jeszcze jakieś inne środowiska z transpilerem JS, w stylu GWT - bo chyba tak trzeba by sklasyfikować ?
(wiem, ze Vaadin buduje nad GWT)

Myślałem, że skoro Java dawniej była w przeglądarce (jako Applet), że jest jakaś droga na skróty ;)

No niespecjalnie. Aplety były obsługiwane przez wtyczki, w niewielkim stopniu zintegrowane z przeglądarkami, podobnie jak Adobe Flash czy Microsoft Silverlight.

Są jeszcze jakieś inne środowiska z transpilerem JS, w stylu GWT - bo chyba tak trzeba by sklasyfikować ?

Nie siedzę w Kotlinie, ale jest Kotlin/JS i Kotlin/Native, chyba analogicznie jak w Scali.

https://kotlinlang.org/docs/reference/native-overview.html

Kotlin/Native supports the following platforms:

• (...)
• WebAssembly (wasm32)

.

(wiem, ze Vaadin buduje nad GWT)

Kiedyś Vaadin był oparty o GWT, ale od jakiegoś czasu już nie jest.

@Wibowit:

Jeśli już to są dowody na tezę odwrotną: Rust skompilowany do WASMa jest wolniejszy od Vanilla.js w obsłudze HTMLowego GUI. Na https://rawgit.com/krausest/j[...]bdriver-ts-results/table.html w "which frameworks" trzeba zaznaczyć vanilla (Vanilla.js) oraz wasm-bindgen (Rust skompilowany do WASMa). Właśnie zauważyłem, że do wyboru jest też blazor-wasm. blazor-wasm-v3.2.0-preview4.20210.8-keyed jest średnio 9x wolniejszy od vanilla.js, startuje ponad 13x dłużej i zabiera prawie 2.5x więcej pamięci. Niespecjalnie imponujące wyniki.

Niemniej jednak nie zapominajmy, że w przeciwieństwie do wasma(już nie mówiąc o blazorze), to silniki jsowe miały czas na performance tuning.

Nie zgodzę się z tezą o WASMie w ogólności. Blazor jest jeszcze świeży, więc jest pewnie za wcześnie by o nim wyrokować (ale i tak na chwilę obecną jest ociężały), ale jeśli chodzi o same WebAssembly to:

• prekursorem WASMa był asm.js, który jest z nami od roku 2013, a już w 2014 roku "Firefox with float32 optimizations can run all those benchmarks at around 1.5x slower than native, or better": https://hacks.mozilla.org/2013/12/gap-between-asm-js-and-native-performance-gets-even-narrower-with-float32-optimizations/
• WASM jest trochę szybszy od asm.js, chyba z kilkanaście procent albo nawet trochę więcej, więc już teraz jego szybkość to powiedzmy jakieś 80% natywnego kodu w średnim przypadku. Na zrównanie nie ma co liczyć, bo WASM jest osandboxowany programowo (musi np sprawdzać czy wskaźniki nie wychodzą poza zaalokowane obszary pamięci).
• Rustowy kod w wasm-bindgen jest zaledwie kilka procent wolniejszy od vanilla.js, podczas gdy Blazor WASM jest 9x wolniejszy

@Wibowit:

prekursorem WASMa był asm.js, który jest z nami od roku 2013, a już w 2014 roku "Firefox with float32 optimizations can run all those benchmarks at around 1.5x slower than native, or better": https://hacks.mozilla.org/201[...]r-with-float32-optimizations/

No spoko i co? nadal na road mapie jest dużo "corowych" rzeczy

https://webassembly.org/docs/future-features/

Rustowy kod w wasm-bindgen jest zaledwie kilka procent wolniejszy od vanilla.js, podczas gdy Blazor WASM jest 9x wolniejszy

Co daje nadzieje na to, że Blazor w przyszłości będzie porównywalnie szybki względem pure js, ale na teraz to chyba trzeba było dowieźć featuresy i stabilność, bo zapowiadali się, że w maju 2020 będzie release.