Hologram: Building Local-First Apps in Pure Elixir (ElixirConf US 2026)

bartblast

Creator of Hologram

This is the follow-up to my ElixirConf EU talk in Malaga, which was mostly about the local-first problem and where sync engines stand on it today. Over the summer I built Hologram’s local-first data layer, and this time I got to show it working. It isn’t released yet, it’s still on a branch.

It starts with a demo, a trip planner open in two browser windows. I switch the wifi off in one of them, add a couple of stops, switch it back on, and the other window catches up.

After that I go through how it works. The compiler already walks each page’s call graph to decide what code to ship, so it also picks up every query the page can run, and that decides what the page syncs. You declare permissions in the entity file, and the same rules run in the browser and again on the server.

Offline writes wait in IndexedDB and go up in order on reconnect. If the server refuses one, it reverts locally and the reason comes back with it. And when two people edit the same row, the merge happens per column, no CRDTs involved.

Code for the demo app: https://github.com/bartblast/hologram_offgrid

Target audience: Intermediate to Expert

Topics covered: hologram local-first #sync-engines #crdts realtime

Speaker: @bartblast

The rest of the ElixirConf US 2026 talks are available with a video pass: https://ti.to/elixirconf/2026/with/qva5vpgkamc

8 comments

/hologram #talks #elixirconf #elixirconf-us #elixirconf2026

9 1161 8

2026-09-16 16:20:46 UTC

Showing Posts 1 to 8

Show Best Posts
Show All (oldest first)
Show All (newest first)

jam

Well done Bart! Local first hologram is amazing. Looking forward to the official release.

Post #1

bartblast

Creator of Hologram

Soon!

Post #2

arconautishche

Looks very interesting! I was surprised though how Hologram seems to take over everything, including the application and model layers. Quite an uphill battle to try replacing things like Ash, and even Ecto .

I kind of get why Hologram needs to take over that part for the local-first story. But this is going to be controversial. Can only hope for honest and nuanced discussions.

Good luck with the release and ongoing development anyway!

Post #3

jam

Fwiw, I appreciate Bart’s first principles thinking and approach to radically simplify the stack.

It’s important to note that you can use Ash or Ecto with Hologram, you just wouldn’t get its local first capability. I wonder if maybe an ash_hologram bridge could be developed in the future to take advantage of local first but imo that should be developed and owned by Ash enthusiasts and not a Hologram focus.

Post #4

arconautishche

I appreciate Bart’s first principles thinking and approach to radically simplify the stack

Completely agree!

you can use Ash or Ecto with Hologram, you just wouldn’t get its local first capability

Good point, a good combo is possible. Local-first is not a must-have for many use cases, and Hologram already has enough benefits on its own.

Would be interesting to see what something like ash_hologram could look like . Potentially a generator/translator from Ash resources to Hologram definitions, and/or a dedicated data layer.

Post #5

bartblast

Creator of Hologram

It only takes over if you want it to, and that’s something I care about a lot. Hologram runs inside a Phoenix app today and that’s staying, as the embedded mode. Use Hologram just for the frontend there and call your Ecto repo or Ash domain from commands like you normally would. As @jam said, the only things missing then are auto-sync and offline.

Standalone mode is coming too, where Hologram is the whole stack. That’s the version I’m personally after, something closer to Rails, Laravel or Django, which all ship their own data layer as well. One repo, one language, sync built in, and simple enough to pull in people who’ve never touched Elixir. Eventually not just the web either, but mobile, desktop and serverless too. Both standalone mode and local-first have been on the roadmap for a while if you want the bigger picture: https://hologram.page/docs/roadmap

Problem is, I couldn’t build that on Ecto or Ash, and that’s not me saying anything’s wrong with them. They were built for different problems than the one I’m chasing. The compiler has to read every query and permission rule and be able to ship them to the browser. Queries also have to be limited on purpose, nothing that drops down to SQL strings, because that’s what lets Hologram work out each page’s sync window, the rows it needs, before anything runs. Later the same limits are what make incremental view maintenance on the client possible, so a result updates in place when a row changes instead of the whole query rerunning. And migrations need to work as lenses, so someone who hasn’t refreshed since the last deploy still gets data their version of the app understands.

It’s still regular Postgres underneath btw. Better interop with Phoenix, Ecto and Ash is planned as well, so you can stick with whatever stack you already like.

Post #6

arconautishche

I couldn’t build that on Ecto or Ash

Totally understandable, the kind of client-server sync & integration you’ve shown during your talk is impressive and probably requires starting at the root of the problem.

I like the idea of “Standalone mode”, the whole stack, batteries included, targeted at non-Elixir devs. Could become a very good thing on its own. And Hologram itself, within Phoenix, integrated with existing Ecto/Ash/whatever, still is pretty cool.

Post #7

bartblast

Creator of Hologram

Yep, that’s the plan once v1.0 is out. Get people from outside Elixir to try it. The whole point of Hologram is making app development radically simpler, and as I said in the talk, that happens to suit agents really well. One language, one repo, no client/server split to keep in their head. Put that on top of the BEAM and what Elixir can do at compile time, macros included, and I think it’s kind of an unfair advantage over other ecosystems

Post #8

— All posts loaded —