Hologram Works. Sponsor What Comes Next.

Hologram works. Elixir runs in the browser today - four feature releases this year, most of the standard library working client-side, a full realtime layer, JavaScript interop, and the first applications running in production.

New to Hologram? My ElixirConf EU 2025 talk is the introduction to what it is and why it exists.

What comes next is bigger than any of it. Local-first: applications that keep working offline and sync automatically when the connection returns, built into the framework instead of assembled by hand from three libraries and a lot of hope. No full-stack framework in any language ecosystem ships this. Hologram is close enough to be the first.

Whether that gets built comes down to the next few months, and to whether companies decide to put weight behind it. I'd rather say that plainly now than have it show up later as a project that quietly slowed down.

Here's where things stand, and how you or the company you work for can help.

What sponsorship built

Eight months ago I wrote that I was at a crossroads, splitting 60+ hour weeks between contract work and the framework. The community answered. Curiosum came on board as Main Sponsor, the Erlang Ecosystem Foundation funded a set of development milestones, and individual sponsors signed up on GitHub.

Four public feature releases came out of it, v0.7 through v0.10 - with v0.11 landing now.

v0.7 Elixir's standard library in the browser Elixir's stdlib calls Erlang functions underneath, so running it client-side meant porting those functions. A community initiative took client-side coverage from a fraction of the standard library to nearly all of it - 150 Erlang functions ported by 49 contributors, most of them making their first contribution to a BEAM project. The release that concluded it hit the Hacker News front page at 107 points.

v0.8 JavaScript interop Import npm packages, call Web APIs, use Web Components, and await JavaScript promises as Elixir Tasks.

A VS Code extension shipped alongside it.

v0.9 Hologram Realtime This grew well past its original scope. What began as server-triggered actions became a full realtime layer - pub/sub fan-out, think Phoenix Channels, but built fresh for Hologram and tailored end to end for developer experience.

v0.10 Events and middleware A much-expanded client-side event system and a server-side middleware layer, plus client-side error handling with full try/rescue/catch/after/else in the browser, and comprehension parity.

v0.11 Regular expressions and client error stacktraces landing now Elixir's PCRE-based regexes compiled for Hologram's client runtime, with =~ and the rest of the Regex functions, plus client-side error messages and stacktraces that match the server for easier debugging.

And beyond the releases themselves: first-class AI assistant support - llms.txt, usage_rules compatibility, and per-project agent docs, so tools like Claude Code and Cursor write idiomatic Hologram instead of falling back on LiveView patterns.

The numbers moved with the work:

⭐ 1,400+ GitHub Stars, up 40%+ since November's funding campaign

📦 3× Hex downloads since November's funding campaign, still accelerating

📬 350+ Monthly newsletter subscribers

👥 49 Contributors in the porting initiative

Ecosystem: other

The 'NextJS' of Elixir, hopefully done right."

"Hologram has been a joy to use - I default to using it unless I really need some specific capability from LiveView."

Where Hologram goes next

Local-first

Hologram is positioned to become the first full-stack framework in any ecosystem with local-first built in. Applications that are offline by default: they keep working without a connection, hold the data you choose on the client, and sync automatically when the connection returns - backed by a declarative auto-syncing data layer instead of hand-rolled plumbing.

Nobody ships this built in. Not Rails, not Next.js, not Phoenix. It normally means bolting together a sync engine, a client store and a conflict resolution strategy, then maintaining all three forever. Hologram already runs Elixir in the browser, so the hardest part of the foundation is done.

I gave the talk on this at ElixirConf EU 2026, and it's the throughline of my upcoming ElixirConf US and Goatmire talks too:

One codebase, not two

The usual full-stack app is a backend in one language, a TypeScript frontend, and a contract between them that both sides have to keep honoring. Every feature touches all three, in two languages, on top of an npm dependency tree nobody has fully audited. LiveView spares Elixir teams most of that - until the app needs real client-side logic, and the JS hooks and npm tooling creep back in at the edges.

Hologram closes that gap. One language, one codebase, no JavaScript stack to maintain.

That doesn't mean giving up the JavaScript ecosystem. When a library is worth using - charts, maps, a payment widget - Hologram's JavaScript interop imports the npm package and you call it from Elixir, with Web APIs and Web Components covered too. JavaScript becomes something you reach for when it earns its place, not a second stack your team owns.

Most of what that saves shows up outside the code. A feature stops needing a backend developer, a frontend developer and a meeting to agree on the shape of the JSON between them - one person can carry it end to end.

There's no API contract to design, version and keep in sync, and no class of bug that exists only because two sides drifted apart. One toolchain, one CI pipeline, one dependency tree to audit. Onboarding is one stack to learn, not two.

The hiring argument is not that Elixir developers are easy to find. It's that the ones you already have can own the whole feature, instead of your team being sized by how many frontend specialists you can also afford.

That matters more in 2026 than it did in 2019, because of who reads the code now. An AI agent working across a split stack has to hold the backend, the frontend and the contract between them in context at once, and it gets the seams wrong. A single Elixir codebase is small enough for an agent to reason about end to end, with far fewer places to get it wrong.

That's not theory - it's already how people build with it:

"Writing Hologram was almost disappointingly simple. I asked Codex to port our payment terminal simulator and it was done so fast I had to check it actually did it."

Less work for the teams already shipping

Hologram is in production today. The rest of the roadmap is about making that path shorter for everyone who follows: auth and forms out of the box instead of written by hand, security hardening built in, a proper testing toolkit, readable client-side stacktraces, and a standalone mode that installs in two terminal commands - run Hologram inside your Phoenix application as you do today, or on its own when you don't need the rest.