Looking forward - eventually - to trying out the wasm option, which might eventually help speed up my interactive climate-scenario model which already runs with scala.js. Although speed is not currently the limiting factor, a wasm option might expand the potential scope - for example to increase regional resolution. However I presume to do this I’d have to refactor the code a lot, to keep all the gui and io in js while pushing the intensive calculations to wasm, and create data interfaces between these (at a rather low level if i understand correctly?), which could get tricky as it’s tightly coupled, code evolved over 24 years …
Puzzled why wasm is promoted for “backend”, which already has other compilation targets (jvm, native), seems to me this is a bigger opportunity to do complex calculations in the browser.To follow up my previous comment - recently I did try compiling my interactive climate scenario model (written in scala) as wasm, and hey presto it just works, didn’t have to change one line of code (except in build.mill). You can have a look:
My interactive climate model (SWIM) run with wasmBut first enable ‘experimental webassembly’ in your browser e.g. in Chrome chrome://flags/#enable-experimental-webassembly-features, in Vivaldi vivaldi://flags and enable “experimental webassembly”, in Firefox (recent) - it just works, only Safari doesn’t seem to be ready yet.
You can check with devtools, it’s mostly wasm, with a little js (beware devtools really slow it down).
To compare same scala code running as normal js, just remove the ?wasm in the url.
Initial setup won’t be faster with wasm as it’s mainly data loading, but model re-run should be a little faster, although I suspect writing to console and rotating cogs etc. slow it down. Ideally I’d keep gui stuff as js, and model calculation as wasm, but we can’t currently influence this division. What’s remarkable it’s that it’s so easy and reliable ‘out-of-the-box’, for such complex calculations (in this case including all future projections and generation of many svg plots).That’s frankly mind blowing. About as much as parallel-collections gaining support for scala-native in the recent days, with the PR not even touching a single line of code (only through build configuration). The scala ecosystem is way under-appreciated :-)
Indeed so. I also intend (eventually) to try running my model with scala-native - a purpose could be to ‘pipe’ runs connected with other climate model / tools (mostly written in python nowadays) for probabilistic analyses over thousands of scenarios (as I used to do with my old java JCM from which SWIM descends). So both native and wasm offer ways to connect with other languages (without any jvm). But for such complex systems modeling it’s great to rely on the intelligence of scala compiler (and metals, as typing) - basically if it compiles it usually runs correctly, the graphical image with all the plots is my main ‘test’.
