Hey folks!
Would it be possible, in theory, for Roc to be compiled to JS through a platform?
I can imagine that platforms can only access their API's, right? So the compiled Roc itself would still be in another format (binary?) so a platform by itself would never be able to do it?
I'm 100% sure this has been asked before but I couldn't find it... thanks! :grinning_face_with_smiling_eyes:
Interesting question! Are you aware that we already compile to WebAssembly? That's a much more practical target for Roc, since a lot of the compiler is focused on things that make sense for binary output formats that operate on bytes in memory.
In JS it's a bit unnatural to express things like that... Although I suppose it must be possible using a Uint8Array
. But you'd end up recreating a slower implementation of WebAssembly!
In the examples
folder in the repo, one of the examples displays the words "hello world" on a web page using WebAssembly.
hey @Brian Carroll ! thanks for the reply!
I'm aware of WASM support but I was wondering how practical would be for other runtime representations - even if slower! currently WASM is slower in theory but since DOM manipulation still needs JS you end up slowing things down if you need a lot of interop, right? and you end up with larger bundles.
I'm aware it has been stated before that Roc doesn't aim at replacing web languages like Elm but I wonder if that is a non-goal or if it's not even a possibility if someone tried to do it. Makes sense?
Yes that's right, you need JS/Wasm interop stuff to manipulate the DOM. I built a C backend for the Elm compiler to target Wasm and that was the main issue with it.
From that experience I concluded that if you try to convert complex Wasm structures to complex JS structures, it will be slow.
I think it can be fast if you design the whole system around that Wasm/JS boundary and minimise the JS. All you really need in JS is a small number of DOM API functions and a TextDecoder
.
You don't want an overly general system that can convert any Wasm structure to any JS structure, like wasm-bindgen
tries to do. That's always going to be slow. You want something that a virtual DOM and nothing else, and is excellent at that one thing.
So to your actual question on whether it's possible... Well in theory you can translate any set of bytes to any other set of bytes. You could build a new Roc compiler!
uhnn interesting! and with that in mind you can definitely make it a platform, right?
sorry for the ignorance but is the wasm bundling size these days still a "problem"? or is it something that has been getting better over time?
Could you fit it into the current one without major surgery everywhere in a reasonable amount of time and effort? I'm not sure, I'd have to think about it a bit more!
I don't understand the connection with platforms, can you elaborate?
What would the platform do?
The compiler is the thing that translates Roc code to some other code format like x86 instructions or Wasm instructions or JS. The platform doesn't do that
If you're used to Elm then think of the platform as "the Elm runtime".
In fact the elm runtime has a Platform module that is very similar to what we call a platform in Roc.
I'm just wondering about eventually using Roc fullstack for building the same things I currently use Elm for. I guess the platform could take a view abstraction and do whatever with it - but the runtime itself would continue to be WASM, right? (using the current wasm compiler)
for the bundle size to be more optimized (not use wasm) I would need to properly work on a compiler and not a platform afaik
What gave you the idea that Wasm bundles are always larger than JS bundles?
I don't see any reason for that, maybe I'm missing something
yeah! this is my assumed ignorance - this is 100% based on criticisms I have been hearing over time but not based on actual experience. (elm bundle sizes begin at sub-20kb as an example)
It would be hard to get solid evidence for that, you'd need to compare the same app in each target somehow.
I might be able to find some numbers actually, but they're on a machine I can't access this week.
You might be hearing about very inefficient Wasm implementations with lots of big dependencies that aren't really necessary. Because rust and c libraries normally run on desktop where bundle size is irrelevant.
got it! but this is interesting - indeed there is nothing preventing wasm from anything. I had more blockers in mind for some reason.
things completely unrelated like GHCJS might have been mixed in my mind for some reason.
If we do a web platform for Roc it would be completely dedicated and optimized for this, with no dependencies
Or very few
I have fairly clear ideas on how I would do it
and the roc runtime/compiled code wouldn't be large by itself by default, right?
No I don't think so
@Brian Carroll awesome! got me excited to experiment :) thank you
Great! I'm interested in this, so keep me informed and I'll be happy to chat about ideas if you like.
Last updated: Jul 05 2025 at 12:14 UTC