Hologram v0.7.0: Milestone release for Elixir-to-JavaScript porting initiative
107 points| bartblast | 19 days ago |hologram.page
This release is a milestone for our porting initiative. 49 contributors ported 150 Erlang functions across 19 modules, pushing client-side Erlang runtime coverage from 34% to 96% and overall Elixir standard library readiness from 74% to 87%.
This means the vast majority of Elixir standard library functions needed for full-stack web and basic local-first apps now work in the browser - string processing, collections, sets, binary operations, Unicode normalization, math, time operations, file path handling, and more.
Beyond porting, the release includes enhancements, bug fixes, and infrastructure groundwork.
Happy to answer any questions!
knubie|19 days ago
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)?
bartblast|19 days ago
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.
lawn|19 days ago
Gleam is different in that JS is a first-class target and built into Gleam's compiler, while Hologram is a standalone project.
lawn|19 days ago
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.
bartblast|19 days ago
troupo|18 days ago
[1] Being very lazy I immediately gave up of course, but did file a suggestion :) https://github.com/bartblast/hologram/issues/228
bartblast|18 days ago
ZiiS|19 days ago
bartblast|19 days ago
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.
haolez|19 days ago
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.
xlii|19 days ago
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.
bartblast|19 days ago
GCUMstlyHarmls|19 days ago
abrookewood|19 days ago
bartblast|19 days ago
worthless-trash|19 days ago
bartblast|19 days ago
victorbjorklund|19 days ago
unknown|19 days ago
[deleted]
aliljet|19 days ago