When compiling a program, how large is the generated binary file? Is it small enough that it would be reasonable to make websites with it? Assuming that it's possible to target WASM in the future.
it should be, it's a bit like Rust or C (and nothing like e.g. haskell, which has to bring along its whole runtime system)
in terms of code size it's not as good as the current elm -> wasm project (cc @Brian Carroll ) because we fully monomorphize while that wasm conversion generates something that is still more dynamic in nature
but cool things are already happening with wasm in zig/c/rust so yea it should be feasible
That's true, my generated Wasm is pretty much untyped so only one copy of List.map for example, and that's good for size. (There are other things bloating up the code size at the moment but that will all get removed eventually!)
also it might require being careful on the platform side - e.g. there are various special things you have to do to get hello world in Rust wasm down to 2.4k:
https://kripken.github.io/blog/binaryen/2018/04/18/rust-emscripten.html
Interesting! Yeah the complicated parts of the Wasm platform for me have been about the interface with JS. You need to encode and decode your data structures, you need to write a Wasm stack frame from JS when you call a function, you have different memory managers on each side with cross-references between them (which makes lifetimes complicated), etc. There's some overhead for all of that.
is that inherent or just the current state of the wasm stack/browser integration?
It's inherently hard but it's possible, and there are proposals in the works. But I first checked the status 3 years ago and it is still in stage 1 today. There's an explainer doc here and the list of proposal statuses is here
It would allow Wasm to refer to values owned by the platform, and the platform would handle the memory management. I think the hard part is that the web standards are not defined in terms of integers and floats, but higher level types like DOMString and Regex and Promise and a hundred other things with implementation-defined memory layout.
Cool, sounds like support is a ways off due to both Roc and WASM being in development. Still, I think it would be fantastic if one day I could write code that could be used on the backend as well as web apps, desktop apps, and mobile apps, without needing resort to Electron and Node or something low level like QT.
yea share the vision, lots of work that needs to be done to make that ergonomic, but it all should be possible in theory
I actually let go of write once, run anywhere as a goal. Every manifestation seems to be hacky and never respect the platform well enough. It’d be interesting to see if roc can break that. But I imagine it’d still be a separate roc platform for each (mobile, web platform, desktop native graphics) and then for app devs they just use roc
For web, I’m also increasingly less excited about wasm with each year that passes. But on the roc side of things a platform for the web could emit javascript and wasm based off functions and types the app dev uses that the platform needs to consume. Instead of roc itself compiling to wasm
what makes you less excited for wasm on the web? just the hype dying down or are there technical reasons?
seems to be only hype so far
i know for a fact that it's used a bunch outside the web
then I search for rust web frameworks and find 5 competing frameworks all inspired by Elm architecture
my theory: the wasm tooling is built by non-web people
And I end up thinking “ok here we go again, frontend framework wars the rust version”
i know for a fact that it's used a bunch outside the web
nice, any cool examples?
Also don’t get me wrong. I’m not saying roc shouldn’t compile to wasm
but I do think a separate Lang just for web and wasm (or a roc platform), with NextJS features sprinkled on top is what the world needs
it's NDA'd but the vague idea is that you can just send a bunch of code to a remote device and execute it there and be sure that it's safe
because of the sandboxing
slick
and that's really nice if you have a lot of machines in the field and want to make a software update
seems like a killer feature for IoT stuff
wasmtime or something to execute I imagine
yea, so you need a somewhat capable machine for this
but most machines are in that category these days
if you can run a botnet on it, then it can run this probably
so fridges ect :smile:
lmao that reminds me of that famous mirai hack
consumer IOT is very bad...
b2b though is pretty interesting
interesting
well that gives me a more positive outlook
well the tooling is the hard part here for the web
plus you have to compensate for bigger binary size
give me direct DOM access!
well, yes
lol I think there’s a proposal but as it was said above that’s tricky
not sure why that is taking so long, seems pretty fundamental
I think Brain said it well.
I think the hard part is that the web standards are not defined in terms of integers and floats, but higher level types like DOMString and Regex and Promise and a hundred other things with implementation-defined memory layout.
UI is in a strange state of affairs and it doesn’t help that Apple and Android don’t play nice. At least they have react inspired ways of building now with SwiftUI and Jetpack Compose
Lucas Rosa said:
I actually let go of write once, run anywhere as a goal. Every manifestation seems to be hacky and never respect the platform well enough. It’d be interesting to see if roc can break that. But I imagine it’d still be a separate roc platform for each (mobile, web platform, desktop native graphics) and then for app devs they just use roc
To be clear, I'm interested in being able to reuse some code (but not all). You're right that it is a bad idea to try reusing all code between different devices, but usually there is a chunk of code (shared datastructures, validation, helper functions, etc) that want to be able to use on frontend apps and on the backend.
nice totally makes sense
In terms of roc, I imagine there’s a fair bit of helper functions and shared code that can be intentionally platform agnostic. That way no matter how many base platforms you need for various apps as part of your stack, you could still get one of the best code re-use experiences there is out there
In a way I think I might be trying to say that maybe roc can be better than wasm for code re-use. Would a world with great roc success even care as much about wasm? Obviously still probably yes but I wanted to be dramatic lol
As an example. Maybe I have some app. It has an API, a web frontend, a desktop app, and a CLI interface. Those 4 things could all be a different platform. Maybe the API is a platform for building graphql backends on top of postgres. Maybe the web frontend platform does some fancy ssr and client rendering by emitting JS/wasm at run time. Maybe the desktop app is a UI platform built using native graphics or even just an SDL wrapper. And then the CLI platform handles capturing commands with a nice dsl. All the data types representing your domain and common transformations of these could be stuffed in a platform agnostic shared package to be used across every platform you need.
Last updated: Jul 06 2025 at 12:14 UTC