Reduce total html payload size with liveview

[bartblast]

@spicychickensauce

Well in liveview I can maintain state on the server per connection via the assigns. And then update those via pupsub.

Nothing prevents you from using standard Elixir primitives like GenServers, Agents, or any state management libraries to keep state alive on the server-side and communicate with it through Hologram’s command pattern. You have the full power of Elixir/OTP at your disposal for server-side state management – Hologram doesn’t restrict that at all.

@spicychickensauce

I didn’t find a similar mechanism from the docs in Hologram, as it seems like it wants to move all state to the client.

You should want to move as much state as possible to the client, especially for interactions (UI state, form data, selections, etc.). This gives you:

1. Resilience: No state loss during deployments, crashes, or disconnections

2. Performance: Instant interactions without round-trips (exactly what you wanted in this thread!)

3. Scalability: No per-connection state on the server

That said, you can still use GenServers, Agents, or any Elixir primitives for server-side state when truly needed (auth, permissions, shared state). The key is choosing the right place for each piece of state.

@spicychickensauce

So it’s not clear to me how I can push state changes from the server to the clients. Use case might be chat rooms or similar.

Hologram will have dedicated primitives for real-time state synchronization. For now, you can implement a basic pull mechanism using put_action with a delay to periodically fetch updates from the server. This will become much cleaner once Hologram’s local-first data store is released – it will automatically sync with your server-side database.

Worth noting: for use cases like chat rooms, you actually want something more robust than PubSub alone. PubSub can drop messages if a client is temporarily disconnected. A persistent, consistent data store that syncs to the server-side database is the right solution for these scenarios, and that’s exactly what Hologram’s local-first approach will provide.

@spicychickensauce

If Hologram wouldn’t try to be a replacement for Phoenix, but just an enhancement for client side logic I would be more interested.

You don’t have to move away from Phoenix! Currently, Hologram runs as a library within Phoenix applications, serving as an enhancement for the frontend layer only. Standalone mode is coming soon as an additional option, but you’ll always be able to use Hologram on top of Phoenix if that’s your preference.

See my post here for details on both modes: How should Hologram position itself in relation to Phoenix?