Sharing a BEAM There, Done That episode with Bart Blast, creator of Hologram, covering the technical architecture of what’s probably the most ambitious BEAM-to-browser project in the ecosystem.
The core claim: the same Elixir code should run identically on the server and in the browser, with full runtime parity rather than treating the two targets as different.
The implementation: Hologram pulls the expanded AST from compiled BEAM files, normalizes it, lowers to an intermediate representation designed to bridge Elixir semantics to JavaScript, then encodes to a JS runtime. Values are boxed - Elixir integer 42 becomes {type: “integer”, value: 42n} - to preserve type identity across the boundary. Pattern matching runs as a real engine, not a translation. OTP guarantees are reconstructed in JS.
The contrast with Luster (Gleam’s equivalent): Gleam treats the two targets as different - it doesn’t replicate BEAM processes in the browser, has a minimal prelude, and lets the JS target be genuinely different. Hologram is building full parity. Heavier runtime, but the payoff is identical semantics on both sides.
From an Erlang perspective the interesting question is whether full runtime parity is the right goal or whether a lighter “semantics-compatible but not identical” approach is more pragmatic. The episode doesn’t resolve this but Bart makes a clear case for the full parity path.
Bart is also candid that it’s still a young framework - the comparison isn’t “Hologram vs. Live View for production today” but “what does the architecture look like when the maturity gap closes.”
