This looks really cool. Congratulations on the milestone.
Does the elixir->js compiler exist as a separate project, or is it built into the framework? Is it based on an existing transpiler? How does it compare / contrast to something like gleam (which, AFAIU also let's you transpile elixir to JS)?
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.
Hologram is an amazing project and I'm really excited for it's future.
I worked on a project last year based on Hologram but ran into some minor issues, and other real-life stuff got into the way. I'm looking forward to picking it up again soon as I have some energy to spare.
Really appreciate it! Would love for you to give it another go - a lot has improved since then. If you run into any issues or have ideas for how things could be better, don't hesitate to reach out. Happy to help!
I keep keeping an eye on your amazing project. Though I've only touched it very superficially [1], I'm very keen to see where it goes (and want to use it finally one of these day)
Two big reasons: bundle size - few hundred KB uncompressed vs multiple MB already compressed with WASM. And the DOM lives in the JS world - WASM can't touch it directly and has to cross the JS bridge with serialization overhead every time.
On top of that, since the browser platform has different characteristics, you can surgically drop down to native JS functions instead of compiling and bundling everything. For example, things like Unicode code point databases are already built into the browser - no need to ship them in your bundle when you can just call into the native APIs. The compiled output is also readable which helps with debugging.
For web apps generally JS is the better target IMO - you want the smallest possible bundle and the app reacting as quickly as possible on load.
Slightly off-topic, but are there teams using Erlang instead of Elixir for application development?
I'm planning on getting into this ecosystem and I'm considering if it's worth it also becoming an expert on Erlang beyond understanding OTP's internals.
For serious apps it's impossible to escape reading Erlang or Erlang documentation. Many functions and libraries simply aren't available for Elixir or are partial (see `opentelemetry_*` family as an example). Deep debugging is almost exclusively done with Erlang functions.
I'd even say that the more serious/critical application becomes the more weight shifts toward Erlang. Personally I'd go with Erlang-first, but only because I've accumulated thousands paper cuts from Elixir.
For starters Elixir has much more palatable syntax, though.
> For serious apps it's impossible to escape reading Erlang or Erlang documentation
Erlang documentation yes, but I VERY RARELY look at Erlang code. The only times I've really done it have been fiddling with an ODBC driver issue, which isn't really supported anymore by OTP, a crash dump maybe twice, and writing a dialyzer wrapper. I've been building elixir systems for over 10 years, and use OTP heavily,
But beyond syntax, how does the tooling compare? It seems that Mix is very convenient and feels like similar tools in other languages. I'd imagine that Erlang doesn't have an equivalent.
Overall Elixir tooling has more modern feel to it, but often it wraps around Erlang tools but.
Keeping mind that Erlang exists much longer than Elixir tooling for Erlang is more robust and mature. BUT its tooling revolves around advanced features e.g. hot updates. For webdev Elixir's tooling is capable enough.
It depends on what you're doing. I've been in Elixir web dev for about 7 years and never really needed to write or understand Erlang, outside of my work on Hologram. That said, Erlang is always there under the surface - it "leaks" into Elixir in places if you look at the stdlib, and understanding it gives you a better mental model of the whole platform. I'd say you don't need it on a daily basis for most Elixir work, but the runtime and OTP are incredible pieces of engineering, and getting to know Erlang better will only make you stronger in this ecosystem.
Just wanted to echo that my experience is almost identical (production elixir/phoenix for 10 years), and also very rarely touch erlang. But it does leak in every now and then.
And it'll feel less intimidating once you code in elixir, but I still find it more cryptic and less approachable the 3-4 times I've had to splunk into erlang to debug something in the last decade.
So with that in mind, you can just learn Elixir, use Erlang where you need it for some libraries. Elixir is IMO much nicer to learn, write and use. I think it is worth learning a bit about the underlying systems but I've never felt like I should have put in 10
erlang-only projects before writing larger elixir stuff.
Just to emphasize this as someone that's worked in Elixir professionally for a decade now.
It really is that easy. The interoperability between Erlang and Elixir is fantastic and the communities get along well. There has been a long time push from many of the thought leaders that BEAM (the VM that Erlang and Elixir run on) should be a community regardless of language. That way we can share resources.
When I first learned Elixir I spent all my time in Elixir. Erlang has a lot of nice libraries though, so it wasn't uncommon back when I started to reach for one.
It was a pretty gentle learning curve, you can write Elixir with no knowledge of Erlang at all. You can consume Erlang libraries from Elixir with no knowledge of Erlang at all. Then if you are like me, you are curious about how something works and you go read some library code and it's a bit odd but you can mostly get the gist of it. Then over time reading Erlang is easy enough, the prolog inspired syntax is the hardest hurdle to get over, but then you realize how much Erlang and Elixir have in common.
Is the main benefit that someone who is familiar with Elixir can code the front-end in the same language? Or is the intention to have the front-end JavaScript act as a node in a cluster with the server?
Both! Right now the focus is on enabling rich UIs with pure Elixir running in the browser. But eventually Hologram could be able to act as an Erlang node in the cluster as well.
Not currently, but expanding to Erlang is definitely possible down the road. I've actually been considering adding an Erlang compiler since some Erlang functions that the Elixir standard library depends on could be compiled automatically instead of being ported by hand.
This looks really cool. Congratulations on the milestone.
Does the elixir->js compiler exist as a separate project, or is it built into the framework? Is it based on an existing transpiler? How does it compare / contrast to something like gleam (which, AFAIU also let's you transpile elixir to JS)?
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.
you could have a lighter runtime by implementing a bytecode interpreter in wasm.
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 doesn't run a bytecode interpreter in wasm! i think it compiles straight to rust? which is why there are some leaky as hell abstractions.
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.
I may be wrong but I believe the elixir->js compiler is currently built into the framework but it could potentially be separated in the future.
Gleam is different in that JS is a first-class target and built into Gleam's compiler, while Hologram is a standalone project.
Hologram is an amazing project and I'm really excited for it's future.
I worked on a project last year based on Hologram but ran into some minor issues, and other real-life stuff got into the way. I'm looking forward to picking it up again soon as I have some energy to spare.
Really appreciate it! Would love for you to give it another go - a lot has improved since then. If you run into any issues or have ideas for how things could be better, don't hesitate to reach out. Happy to help!
I keep keeping an eye on your amazing project. Though I've only touched it very superficially [1], I'm very keen to see where it goes (and want to use it finally one of these day)
[1] Being very lazy I immediately gave up of course, but did file a suggestion :) https://github.com/bartblast/hologram/issues/228
Oh yeah, I remember! We'll get there :) Hope you'll give Hologram another spin sometime soon!
I definitely will!
As a novice who enjoyed an AoC in Elixir but has never used it in battle; what is the quick answer to why JavaScript not WASM?
Two big reasons: bundle size - few hundred KB uncompressed vs multiple MB already compressed with WASM. And the DOM lives in the JS world - WASM can't touch it directly and has to cross the JS bridge with serialization overhead every time.
On top of that, since the browser platform has different characteristics, you can surgically drop down to native JS functions instead of compiling and bundling everything. For example, things like Unicode code point databases are already built into the browser - no need to ship them in your bundle when you can just call into the native APIs. The compiled output is also readable which helps with debugging.
For web apps generally JS is the better target IMO - you want the smallest possible bundle and the app reacting as quickly as possible on load.
[dead]
Slightly off-topic, but are there teams using Erlang instead of Elixir for application development?
I'm planning on getting into this ecosystem and I'm considering if it's worth it also becoming an expert on Erlang beyond understanding OTP's internals.
For serious apps it's impossible to escape reading Erlang or Erlang documentation. Many functions and libraries simply aren't available for Elixir or are partial (see `opentelemetry_*` family as an example). Deep debugging is almost exclusively done with Erlang functions.
I'd even say that the more serious/critical application becomes the more weight shifts toward Erlang. Personally I'd go with Erlang-first, but only because I've accumulated thousands paper cuts from Elixir.
For starters Elixir has much more palatable syntax, though.
> For serious apps it's impossible to escape reading Erlang or Erlang documentation
Erlang documentation yes, but I VERY RARELY look at Erlang code. The only times I've really done it have been fiddling with an ODBC driver issue, which isn't really supported anymore by OTP, a crash dump maybe twice, and writing a dialyzer wrapper. I've been building elixir systems for over 10 years, and use OTP heavily,
But beyond syntax, how does the tooling compare? It seems that Mix is very convenient and feels like similar tools in other languages. I'd imagine that Erlang doesn't have an equivalent.
Overall Elixir tooling has more modern feel to it, but often it wraps around Erlang tools but.
Keeping mind that Erlang exists much longer than Elixir tooling for Erlang is more robust and mature. BUT its tooling revolves around advanced features e.g. hot updates. For webdev Elixir's tooling is capable enough.
It depends on what you're doing. I've been in Elixir web dev for about 7 years and never really needed to write or understand Erlang, outside of my work on Hologram. That said, Erlang is always there under the surface - it "leaks" into Elixir in places if you look at the stdlib, and understanding it gives you a better mental model of the whole platform. I'd say you don't need it on a daily basis for most Elixir work, but the runtime and OTP are incredible pieces of engineering, and getting to know Erlang better will only make you stronger in this ecosystem.
Just wanted to echo that my experience is almost identical (production elixir/phoenix for 10 years), and also very rarely touch erlang. But it does leak in every now and then.
And it'll feel less intimidating once you code in elixir, but I still find it more cryptic and less approachable the 3-4 times I've had to splunk into erlang to debug something in the last decade.
It's very easy to call Erlang from Elixir,
So with that in mind, you can just learn Elixir, use Erlang where you need it for some libraries. Elixir is IMO much nicer to learn, write and use. I think it is worth learning a bit about the underlying systems but I've never felt like I should have put in 10 erlang-only projects before writing larger elixir stuff.Just to emphasize this as someone that's worked in Elixir professionally for a decade now.
It really is that easy. The interoperability between Erlang and Elixir is fantastic and the communities get along well. There has been a long time push from many of the thought leaders that BEAM (the VM that Erlang and Elixir run on) should be a community regardless of language. That way we can share resources.
When I first learned Elixir I spent all my time in Elixir. Erlang has a lot of nice libraries though, so it wasn't uncommon back when I started to reach for one.
It was a pretty gentle learning curve, you can write Elixir with no knowledge of Erlang at all. You can consume Erlang libraries from Elixir with no knowledge of Erlang at all. Then if you are like me, you are curious about how something works and you go read some library code and it's a bit odd but you can mostly get the gist of it. Then over time reading Erlang is easy enough, the prolog inspired syntax is the hardest hurdle to get over, but then you realize how much Erlang and Elixir have in common.
Is the main benefit that someone who is familiar with Elixir can code the front-end in the same language? Or is the intention to have the front-end JavaScript act as a node in a cluster with the server?
Both! Right now the focus is on enabling rich UIs with pure Elixir running in the browser. But eventually Hologram could be able to act as an Erlang node in the cluster as well.
Can I use this for erlang instead of elixir?
Not currently, but expanding to Erlang is definitely possible down the road. I've actually been considering adding an Erlang compiler since some Erlang functions that the Elixir standard library depends on could be compiled automatically instead of being ported by hand.
Sweet
Am I just a cynic, or do any of the LLMs deserve love too?