How We Got to LiveView

Summary

Chris McCord recounts how Phoenix and LiveView emerged from attempts to make real-time features as simple as Rails CRUD development. He first built sync.rb, which used WebSockets to re-render server-side templates and push HTML updates without requiring programmers to write JavaScript, but Ruby’s concurrency model and EventMachine proved unreliable for the task. He then turned to Elixir and the Erlang VM, whose lightweight message-passing processes and fault tolerance supported Phoenix Channels and a reported load test of 2 million concurrent WebSocket connections on one server. LiveView unifies client and server state in a stateful process that synchronizes only necessary HTML changes. The account also describes binary uploads, WebSocket-based navigation via live_redirect and live_patch, and HEEx, an HTML-aware Elixir template syntax with compile-time validation.

Takeaways

1. 1

   sync.rb re-rendered server-side templates and pushed HTML over WebSockets, allowing dynamic behavior without application-specific JavaScript, but EventMachine threads could silently die and required repeated health checks and restarts.

2. 2

   Phoenix Channels are bidirectional and transport-agnostic, commonly use WebSockets, retain state for a connection, and can relay events across a server fleet.

3. 3

   HEEx extends Elixir EEx with HTML-aware tag syntax and compile-time validation; LiveView uploads and navigation use the existing WebSocket connection.