hckrnws

GHC’s WASM backend is already really useful! I also used it to port one of my own programs to the browser [0], albeit not using the DOM as this person did. Documentation is still sparse, but it’s a very similar process to creating a shared foreign library. (At the very least, I tried to document what I could.)

[0] https://github.com/bradrn/brassica

Looks cool, I'm not much into webassembly... but I see just fews lines of Haskell code produced a gzipped wasm of 448K. How does this compares to other languages?

Remember that this includes the runtime. It'll hopefully shrink a bit once the wasm gc is stabilised

It's already in Phase 4, so close: https://github.com/WebAssembly/proposals#phase-4---standardi...

The RTS is a bit more than the GC though.

Does it really need a GC or is JavaScript engine's GC such a bad fit for Haskell?

I think it depends on how much of the GHC RTS semantics you wish to preserve.

I said a bit, not go away entirely

The uncompressed wasm binary for a simple fluid simulation in julia is 5k (or 2.7k compressed):

https://alexander-barth.github.io/FluidSimDemo-WebAssembly/

But here the wasm code does only the number crunching. The visualization (and memory allocation) is all done in javascript.

haskell and raylib work together in WebAssembly too!

https://github.com/Anut-py/ghc-web-test

It think you might not need to go via CString to get to the browser, given that the browser side doesn't care about NUL termination either. I think you could use Data.ByteString.Internal to grab the ForeignPtr/length out of the BS constructor directly.

Finally! Nice!!

I tried getting it going on my stream a couple times but failed to get the shim going!

Can’t wait to dive into this!

Well done!

Does this unlock something re: postgrest? I'm way out of my depth; the level of detail I can bring is the factoid 'postgrest runs on haskell'

Maybe, but probably not. Postgrest still needs to talk to Postgres over the Postgres wire protocol, which isn't possible with wasm in the browser because there is no raw socket API. However, I'm sure there are some cool hacks you could do like running postgres-wasm "locally" (also within the browser) and having postgres talk to it. You'd still need to modify Postgrest to change how it speaks to Postgres, though.

This is also assuming you're running the WebAssembly in the browser. If you're running it in something like WASI, you might have access to a raw socket API and then maybe it's a different story.

Maybe: if you have a postgres (no "t") service provider and you can't install postgrest on it, then you can now possibly run it in the browser. Though, it adds the problem of how do you connect one with the other. Even if there existed a workaround to make this connection, it might just not be worth it.

It is nice to live in the future "when browsers do not include JS any more".

I do not want to steal your greatness when you port basic JS APIs to Haskell WASM.

Or that of WASI work, when we no longer need to use raw JS API.