How LiveView Took on a Life of Its Own

Summary

Phoenix LiveView began as an attempt to build dynamic server-rendered applications without writing JavaScript, using the server for interactions such as realtime reservation updates. Its initial design used stateful Phoenix Channels, a WebSocket connection, client event bindings, and full template re-renders sent back as HTML, a model that worked but produced redundant server work and large payloads. Adding Phoenix PubSub let LiveViews subscribe to reservation events and update all connected browsers through ordinary Elixir callbacks, without client changes. The implementation then evolved around diffing dynamic values, shared static template references, and cached live component templates, reducing transferred data and avoiding growing client bundles. The post concludes that this programming model sidesteps HTTP for dynamic features, with compact payloads and less client-side code.

Takeaways

1. 1

   The initial LiveView implementation sent the entire re-rendered template to the client after interactions, replacing the relevant page content through a WebSocket response.

2. 2

   Phoenix PubSub lets LiveViews subscribe to reservation events and update connected browsers through Elixir handle_info callbacks without adding client-side code.

3. 3

   LiveView diffs dynamic values and reuses shared or cached static templates, so clients receive only needed data and do not require a growing JavaScript bundle.