bartblast

Author here. Hologram is a web framework where the browser-side code is Elixir too. v0.11.1 couldn't build a sponsor's 9,000-module app. It ran out of memory. I went looking for the one big bug and there wasn't one, just about two dozen places where the compiler did work it didn't need to, like encoding the same function to JS once for every page that used it. Shoot me any questions.

Local-first is simmering! :)

There's Jido Assembly that uses Hologram under the hood: https://github.com/agentjido/jido_assembly

Hologram author here. It's the opposite, really - the whole thing is built on web technologies. The compiler builds an IR from your Elixir code, analyzes the call graph, and spits out per-page JavaScript bundles. In the browser it's regular JavaScript patching the real DOM, and transport is plain HTTP (POST + Server-Sent Events) - no canvas rendering, no WASM. It uses Web APIs directly, and the goal is to make the whole Web API surface available from Elixir. The only thing being swapped out is the authoring language, same as with TypeScript or Elm.

There's no easy out-of-the-box way yet. But you can do it today with JS interop as a workaround. For small files: read the file and send the bytes directly in a Hologram command payload. For big files: fetch-POST the file to your own Phoenix endpoint, or directly to S3 with a presigned URL (no extra endpoint needed, since presigning can happen in a regular Hologram command or in the page's initial state), then pass the returned reference to a command for processing.

A proper Hologram-way file upload is planned as part of a high-level forms abstraction, which comes after Local-First support lands.

Mobile's part of the plan - one Elixir codebase across web, mobile and desktop, with local-first as the groundwork. Covered in the post and roadmap (https://hologram.page/docs/roadmap).

Creator here. Quick context: Hologram lets you build interactive web apps in pure Elixir by compiling to JavaScript on the client side.

This release brings JavaScript interoperability - the most requested feature since the project's inception. Hologram's premise is that you shouldn't need to write JavaScript, but cutting yourself off from 3 million npm packages and hundreds of browser APIs isn't realistic. v0.8.0 bridges that gap: call JS functions, use npm packages, interact with Web APIs, instantiate classes, and work with Web Components - all from Elixir, with zero client-side latency.

AMA!

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.

Oh yeah, I remember! We'll get there :) Hope you'll give Hologram another spin sometime soon!

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.

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.

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.

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.

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!

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.

Creator here. Hologram compiles Elixir to JavaScript to run in the browser, enabling full-stack development in pure Elixir - and soon, Local-First applications.

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!

Hologram's journey just took a significant leap forward: Curiosum is coming on board as the Main Sponsor, and I'm joining their team to work on Hologram full-time.

Hologram compiles Elixir to JavaScript to run in the browser, enabling full-stack development in pure Elixir - and soon, Local-First applications.

I'm deeply grateful to Curiosum's founders for believing in this vision and going all in.

Read more about what this partnership means for Hologram: https://hologram.page/blog/hologram-partners-with-curiosum

Great news for Hologram: the Erlang Ecosystem Foundation has awarded a stipend to support key development milestones!

I’m deeply grateful to the EEF for their support of the project vision.

Read more about what this means for Hologram and learn about the EEF’s mission: https://hologram.page/blog/hologram-awarded-eef-stipend

(Hologram compiles Elixir to JavaScript to run in the browser, enabling full-stack development in pure Elixir - and soon, Local-First applications.)

Hi Elixir friends,

I'm Bart Blast, creator of Hologram. I wanted to share an update that's been on my mind lately. For those unfamiliar, Hologram is a full-stack Elixir web framework that automatically transpiles Elixir to JavaScript, bringing the language to the browser, see: https://hologram.page

After nearly 3 years of full-time work on Hologram, I've reached a crossroads. I believed deeply enough in this vision to dedicate years of my life to it - and that belief has been validated. We're seeing real-world production use, endorsements from community leaders, and genuine excitement from the ecosystem. But to keep this momentum going, I need to find a sustainable path forward.

Right now, I'm working 60+ hour weeks trying to balance contract work with Hologram development. It's not sustainable, and frankly, neither the codebase nor the community deserves a maintainer who's stretched this thin.

I've put together a post that explains where we are, where we're going, and how you can help if Hologram's vision resonates with you: https://hologram.page/blog/seeking-sustainable-sponsorship

Even if sponsorship isn't an option for you right now, sharing the post or talking about Hologram in your networks helps more than you know.

Thank you for reading. Let's build the future of Elixir web development together!

- Bart

(Disclosure: I'm building Hologram)

You might find Hologram interesting for this use case - it transpiles Elixir to JavaScript so your UI runs client-side. No persistent connection needed, so no reconnection delays or error messages. Still write in Elixir, still communicate with the server when needed.

It's early stage with some rough edges, but there are already Hologram apps in production: https://hologram.page

Appreciate the suggestion! Yeah, I've picked up on that - technical posts definitely do better here. The dang's comment is a great reference. I've got some good material brewing, but right now I need to prioritize building over blogging. Will definitely share some technical deep dives once things are further along!

Yes, I'm Hologram's creator. Previous newsletter editions will be published online eventually – for now they're only sent to subscribers.

In the meantime, here are the best places to follow development and join discussions:

- Hologram forum: https://elixirforum.com/hologram

- Hologram Slack: https://elixir-lang.slack.com/channels/hologram

- Monthly newsletter: https://hologram.page/newsletter

- My X account: https://x.com/Bart_Blast

- My Bluesky account: https://bsky.app/profile/bartblast.com

I'm also planning to set up a Discord channel soon.