Thank you! The Elixir -> JS compiler is currently coupled with the framework - it's a custom thing, not a separate dependency.
Re the Gleam comparison: I don't know Gleam's implementation in detail so someone correct me if I'm wrong, but as I understand it - Gleam compiles to fairly readable JS with a minimal prelude, and deliberately treats the two targets as having different concurrency semantics. It doesn't try to replicate BEAM processes or OTP in JavaScript, instead using JS's native promise-based async. The upside is zero runtime overhead and clean JS interop.
Hologram takes the opposite approach - we're iteratively reimplementing the Erlang runtime in the browser, with the goal of having full semantic parity eventually. The tradeoff is a heavier runtime, but the benefit is that the same Elixir code can run on both server and client with consistent behavior.
To clarify - Hologram's runtime is heavier than Gleam's, but that doesn't mean it's heavy. The compiler does tree-shaking, bundling only the code your app actually uses, so you're not shipping the entire reimplemented runtime to the browser.
As for the WASM bytecode interpreter idea - you'd run into the same problems I described in my earlier comment. Even a minimal interpreter compiled to WASM tends to land in the multi-MB range once you include enough of the runtime to be useful. You still can't touch the DOM from WASM, so every UI update crosses the JS bridge with serialization overhead. You lose the ability to surgically call native browser APIs (like built-in Unicode support) instead of bundling your own. And you lose readable output, which matters for debugging.
Gleam is written in Rust but compiles to Erlang (BEAM) or JavaScript - I mentioned the JS compilation in my previous comment. The WASM point was a response to your bytecode interpreter suggestion, not about Gleam.
Re the Gleam comparison: I don't know Gleam's implementation in detail so someone correct me if I'm wrong, but as I understand it - Gleam compiles to fairly readable JS with a minimal prelude, and deliberately treats the two targets as having different concurrency semantics. It doesn't try to replicate BEAM processes or OTP in JavaScript, instead using JS's native promise-based async. The upside is zero runtime overhead and clean JS interop.
Hologram takes the opposite approach - we're iteratively reimplementing the Erlang runtime in the browser, with the goal of having full semantic parity eventually. The tradeoff is a heavier runtime, but the benefit is that the same Elixir code can run on both server and client with consistent behavior.