Is WASM a backend worth having?

[cmdv]

Just wondered on people’s thoughts of having a WASM backend?
What would be advantages/disadvantages?

[garyb]

Advantages: Are there any? Honest question, I don’t know… performance maybe, assuming the compiler does a good job?

Disadvantages: It’s an entire research project in which a PS runtime would need to be written with GC, etc. FFI/interactions with normal JS would need to be figured out again I assume. Only supported by more modern browsers, rather than any ES5 browser like it currently is (actually I think the compiler generated code is fine for ES3 even).

“Compiler doing a good job” is a big if too. We could do much better in JS yet even.

[paf31]

There is a path to WASM already: pure11 -> emscripten

[cmdv]

@garyb thanks that’s what I was after, clearly more disadvantages
The other thing I can think of is WASM is still in it’s infancy and I’ve not seen many adopt it. When it was announced the PR made it sound like the next big thing for browsers

@paf31

pure11 -> emscripten

that’s a good point, I wouldn’t like to set up the tooling chain for that one though!! Also it would be a diversion from the core project if the maintainer didn’t keep up with PS updates.

[garyb]

Actually I missed one sort-of advantage: it’d be fun to work on most likely

[cmdv]

Well that was my initial thinking but you’ve put me off haha

[andyarvanitis]

Actually, the wasm toolchain setup is pretty easy now. I hadn’t tried it in a while (maybe a year?), but did just now:

1. Set up platform’s standard C++ toolchain (easy on most systems) – mine is macOS
2. Set up wasm tools as documented here: https://webassembly.org/getting-started/developers-guide/
3. Using latest version of purescript-native, build your app by running make using this command (options obtained from example in wasm doc above):
   make CXX=emcc LDFLAGS="-s WASM=1" BIN=main.html -j8
4. Run using standard wasm way:
   $ emrun --no_browser --port 8080 .