Worth noting that LiveView Native was discontinued - the core library is archived on GitHub. The project maintainer shared the reasons publicly.
Just to clarify - Hologram is a separate project to LiveView with a different architecture - it compiles Elixir to JavaScript and runs on the client, so it’s not related to LiveView Native. That said, mobile support is on the Hologram roadmap as well, and Local-First would definitely be important for that use case.
From a user and dogfooding perspective, the ideal app I’d want to build would indeed be local-first in the sense of online-optional. A PWA that runs offline by default without limitations, but can connect to an official sync server or a self-hosted one for backups and sharing data between devices or users. Even better if in addition to the browser version, I was able to install a desktop or mobile version that writes to an SQLite database on the local file system. So in the end, it would be a three-way sync between browser storage, online server, and local file system. If the data is trapped in IndexedDB, I don’t really own the data as a user.
I think that Hologram as it stands today already does a world-class job separating client-side and server-side concerns. Extending that principle into managing offline data is how I would approach this problem.
Let me explain the DX I wish for with some code examples. (Caveat: I will include Ash-like snippets in my examples, but that’s primarily because I work in Ash every day. I am much more comfortable expressing myself in it)
Imagine a simple Hologram page. Right now, opening and closing a ticket works this way:
defmodule MyApp.TicketListPage do
use Hologram.Page
# ... route, layout, init, template omitted for brevity ...
def action(:open_ticket, _params, component) do
subject = component.state.new_subject
component
|> put_state(:new_subject, "")
|> put_command(:create_ticket, %{subject: subject})
end
def action(:close_ticket, params, component) do
component
|> put_command(:update_ticket, %{id: params.id, status: :closed})
end
def command(:create_ticket, params, server) do
case do_open_ticket(params.subject) do
{:ok, ticket} -> put_action(server, :ticket_created, %{ticket: ticket})
{:error, _} -> put_action(server, :create_failed, %{})
end
end
def command(:update_ticket, params, server) do
case do_close_ticket(params.id) do
{:ok, ticket} -> put_action(server, :ticket_updated, %{ticket: ticket})
{:error, _} -> put_action(server, :update_failed, %{})
end
end
defp do_open_ticket(subject) do
# Does something... Starts an Oban job, calls an external API, sends an email, etc
MyApp.Support.Ticket.open(subject)
...
end
defp do_close_ticket(id) do
# Also does some very important server-side things
MyApp.Support.Ticket.close(id)
...
end
end
With a ticket resource that looks like this:
defmodule MyApp.Support.Ticket do
use Ash.Resource,
domain: MyApp.Support,
data_layer: AshPostgres.DataLayer,
authorizers: [Ash.Policy.Authorizer]
postgres do
table "tickets"
repo MyApp.Repo
end
attributes do
uuid_primary_key :id
attribute :subject, :string, allow_nil?: false, public?: true
attribute :status, :atom do
constraints one_of: [:open, :closed]
default :open
allow_nil? false
end
end
relationships do
belongs_to :representative, MyApp.Support.Representative
end
policies do
policy action_type(:read) do
authorize_if expr(representative_id == ^actor(:id))
end
policy action_type(:create) do
authorize_if always()
end
policy action(:close) do
authorize_if expr(representative_id == ^actor(:id))
end
end
actions do
defaults [:read]
create :open do
accept [:subject]
end
update :close do
accept []
argument :id, :uuid, allow_nil?: false
validate attribute_does_not_equal(:status, :closed) do
message "Ticket is already closed"
end
change set_attribute(:status, :closed)
end
end
code_interface do
define :open, args: [:subject]
define :close, args: [:id]
end
end
In my dream DX, upgrading what we have today to a local first app will only need these changes:
Configure an extension provided by Hologram:
defmodule MyApp.Support.Ticket do
use Ash.Resource,
domain: MyApp.Support,
data_layer: AshPostgres.DataLayer,
authorizers: [Ash.Policy.Authorizer],
extensions: [Hologram.Extension.IndexedDb] # add the local datastore you want to use
# ... everything else stays the same ...
indexed_db do
store "tickets"
scope :authorized # sync everything the actor is authorized to read
resolution_strategy :last_write_wins # can be the simple strategy for a start. future versions can even allow anonymous functions for custom strategies
end
end
On the page, actions now write to the local store first and then dispatch commands:
defmodule MyApp.TicketListPage do
use Hologram.Page
# ... route, layout, template omitted for brevity ...
def init(_params, component, _server) do
# Reads come from the local store -- no server round-trip, no spinner.
tickets = MyApp.Support.Ticket.read!()
put_state(component, %{tickets: tickets, new_subject: ""})
end
def action(:open_ticket, _params, component) do
subject = component.state.new_subject
# 1. Write to local store immediately (optimistic update)
{:ok, ticket} = MyApp.Support.Ticket.open(subject)
tickets = MyApp.Support.Ticket.read!()
component
|> put_state(%{tickets: tickets, new_subject: ""})
|> put_command(:create_ticket, %{subject: subject})
# 2. Command syncs to server in the background
end
def action(:close_ticket, params, component) do
# Write to local store immediately
{:ok, _ticket} = MyApp.Support.Ticket.close(params.id)
tickets = MyApp.Support.Ticket.read!()
component
|> put_state(:tickets, tickets)
|> put_command(:update_ticket, %{id: params.id})
end
# Commands stay exactly the same -- they still do the important
# server-side work (Oban jobs, external APIs, etc.)
def command(:create_ticket, params, server) do
case do_open_ticket(params.subject) do
{:ok, ticket} -> put_action(server, :ticket_created, %{ticket: ticket})
{:error, _} -> put_action(server, :create_failed, %{})
end
end
def command(:update_ticket, params, server) do
case do_close_ticket(params.id) do
{:ok, ticket} -> put_action(server, :ticket_updated, %{ticket: ticket})
{:error, _} -> put_action(server, :update_failed, %{})
end
end
defp do_open_ticket(subject) do
MyApp.Support.Ticket.open(subject)
...
end
defp do_close_ticket(id) do
MyApp.Support.Ticket.close(id)
...
end
end
This approach is beautiful to me because it’s declarative and explicit, and it preserves the mental model that the developer already works with (client-side concerns happen in actions and server-side concerns in commands, no magic). Calling MyApp.Support.Ticket.open in both the action and the command might initially seem redundant. But to me, it is explicit. It’s not redundant.
In addition, this approach suddenly unlocks several new possibilities! Local-first, local-only, local-never (server-only), @woylie‘s vision of 3-way-sync, or any other permutation of interest, all by configuring resource extensions and choosing where to call a write function:
The wiring to achieve this is non-trivial. Perhaps Hologram has a command queue already for handling commands when disconnected, but that’s a key piece. When a command dispatch fails, it queues locally and retries with backoff. On reconnection, queued commands replay through the same server-side business logic (@jam’s proposal). Also simplifies the retry logic.
So, in summary, mapping back to @bartblast’s original questions:
Configure an extension on the resource. Authorization rules determine what syncs. Actions and commands control write locality. Define the model once, declare where it lives, write normal Elixir.
Declared on the resource via the extension’s DSL (resolution_strategy :last_write_wins). Queued commands replay through business logic for natural conflict detection. Future versions can support per-field strategies and custom resolver functions.
Transparent. Actions work against the local store regardless of connectivity. Commands queue when unreachable and replay on reconnection.
The biggest inspiration is Ash’s data-layer agnosticism – same resource definition, multiple storage backends. @jam referenced Meteor’s “it just works” DX as the bar. I think the action/command model gets us there.
Really excited about this discussion!
I guess HTTP retries are more predictable durable - don’t get filtered by firewalls, the mobile networking issues @derek-zhou mentioned? Just curious about this design choice (I have a somewhat relevant project in this area coming up).
The big picture for me - what I would personally want/love out of hologram - is zero/low latency interactivity on the client for clicks/touches, graceful handling of temporary network disruptions (seconds/minutes not days), guaranteed order from a single node/client, near real-time updates on the client, and an option to choose a concurrent write resolution strategy for multiple nodes/clients.
Some strategies I might want:
I’d say 1 would be my first pick if I had to choose.
Just an implementation detail but with the http retry I suppose we also have to account for single node message ordering? Maybe a genserver buffer + sort based on a client-provided lamport or HLC - then merge multiple nodes…somehow? Interesting problems!
Also, hologram looks awesome! 
FWIW I do personally believe that using a declarative data backend like Ash is how this should actually be accomplished. Being able to rely on a data-layer agnostic storage layer that is introspectable and extensible is how I’ve personally always been planning on doing this.
With Ash you can ask a resource “can your data layer do X type of thing”, meaning that hologram can react to differently-capable data layers to make strategic choices, i.e if the data layer can transact, then you can batch operations. Your extension could add additional attributes to the resource even. Sky is the limit.
You didn’t hallucinate! Hologram did use WebSockets for commands and page fetching in earlier versions. I moved away from that in v0.5.0 - mainly because cookies and sessions can only be set via HTTP, and the workaround (a CRDT-based cookie store syncing across nodes) was way too complex. Plus other practical issues like corporate firewalls blocking WebSockets and so on.
The key realization was that Hologram doesn’t need WebSockets the way LiveView does. Since the code runs in the browser, the server only gets hit for page fetching and commands - not for every user interaction. HTTP persistent connections work great for that.
Interesting examples, thanks! Sync status and version history are definitely on my radar.
That aligns well with where Hologram is heading - cross-platform from a single codebase (browser, desktop, mobile), with the local-first layer working the same across all of them. Multi-device sync should work out of the box. Good point about data ownership and not being trapped in IndexedDB - I’m currently leaning toward OPFS rather than IndexedDB for the storage layer, though I still need to do proper benchmarking before committing to that. I’ll take the data ownership aspect into account too.
Thanks for that incredibly thorough reply, the code examples really help ground the discussion!
I liked the local-only, local-first, server-only, three-way sync breakdown. I’m thinking along similar lines - and ideally this could be granular enough to configure per-model or even per-field if needed.
I’d push back a little on calling Ticket.open in both the action and the command. The whole goal of a local-first approach is to remove that kind of plumbing - the developer writes to the local store once, and the framework handles syncing to the server declaratively in the background. So the ideal DX would be closer to:
def action(:open_ticket, _params, component) do
subject = component.state.new_subject
{:ok, _ticket} = Ticket.open(subject)
# Done. Framework syncs to server, handles conflicts, retries.
put_state(component, :new_subject, nil)
end
No put_command, no server callback for the write itself. The framework knows Ticket is a synced model, so it writes locally and queues the sync automatically. The command queue you mentioned (retries, backoff, maybe replay on reconnection?, etc.) is a key piece - but it should be entirely opaque to the developer. They just write, and the framework takes care of the rest.
That still leaves inherently server-side effects - sending emails, calling external APIs, starting Oban jobs. Today those live in commands, but we could potentially push this further with some kind of declarative workflow mechanism tied to the model itself - server-side effects that trigger automatically when a synced write lands on the server. That way the page code stays focused purely on intent and state, no manual command wiring at all. But that’s a separate discussion.
Regarding the integration angle - I think the right approach is for Hologram to provide its own sync protocol and conflict resolution hooks as native primitives (think “Hologram sync protocol”, “Hologram conflict resolution hooks”). This would make Hologram’s local-first layer extendable, so any library or custom solution can plug into it.
Really appreciate the enthusiasm and depth here 
Thanks for the kind words and the great breakdown!
On the HTTP choice - I touched on this a bit in my reply above, but to expand on your specific question: you’re right that HTTP is more predictable and durable as a transport. That was definitely part of the reasoning. The bigger driver though was that WebSockets forced me into distributed state for cookies and sessions - I had a CRDT-based cookie store syncing across nodes, and while it worked, it was a debugging nightmare. Cookies and sessions just work naturally with request-response. And then the practical stuff adds up - firewalls, no HTTP caching, mobile reconnection being flakier with persistent sockets, and each WebSocket holding a persistent process and connection state per client which eats more memory. The key insight was that Hologram doesn’t need WebSockets the way LiveView does - since the code runs in the browser, the server only gets hit for page fetching and commands, not every interaction. HTTP persistent connections are plenty for that, and it maps nicely onto offline queuing for local-first too.
On your wishlist - good news on the zero-latency interactivity front - Hologram already gives you that! Since the code runs directly in the browser, clicks and touches are handled on the client in step with the browser’s event loop - no server round-trip needed.
Near real-time updates on the client is definitely on the list too - that’s where the sync layer comes in.
As for offline resilience - the seconds/minutes case is definitely the most common scenario. Ideally I’d love for it to work offline indefinitely on the existing schema - that way we don’t have to make compromises. Not sure yet if that’s fully achievable, but it’s worth aiming high and seeing where the constraints actually bite.
On conflict strategies - First One Wins is clean and covers most cases, I agree. Throw Both Away feels more niche - curious if you have a specific use case in mind for that one? But the priority-based example is what really caught my eye - in-store terminal beating a shopping cart is a great real-world scenario. That’s essentially a “trust hierarchy” where some clients are more authoritative than others. I could see this being a declarative per-resource policy rather than a global setting.
Actually, quick follow-up on that: when the in-store terminal wins over the shopping cart, what should happen on the cart client? Silent override, a notification, something else? Curious what you’d want as a developer there.
On ordering - good call on this. Single-client ordering is something you get for free with WebSockets, but with HTTP separate requests can arrive out of order, so it needs to be handled explicitly. Cross-client ordering adds another layer on top of that. Both are on my radar - haven’t settled on the exact approach yet, there are a few directions I’m exploring.
Great timing with your upcoming project btw - would love to hear more about it as the design evolves!