top | item 46984674

(no title)

knubie | 18 days ago

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)?

discuss

order

bartblast|18 days ago

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.

dnautics|18 days ago

you could have a lighter runtime by implementing a bytecode interpreter in wasm.

lawn|18 days ago

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.