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.
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.
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/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.
50ms w operacji raz na minutęraczej nie skutkuje pytaniamiCzemu to działa tak wolno?