---
title: "How We Got to LiveView"
description: "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."
---

# How We Got to LiveView

[Fly.io](https://yomu.fyi/company/fly-io) · Sep 22, 2021

**Type:** Explainer

## 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.

## Context

Real-time features such as chat and activity feeds moved Rails development away from its productive abstractions into JavaScript, HTTP glue, and concurrency patterns that were difficult to make reliable. The work sought a simpler way to synchronize application updates between servers and browsers.

## Approach / What changed

The work moved from sync.rb on Ruby and EventMachine to Phoenix on Elixir and the Erlang VM. Phoenix Channels use lightweight, message-passing processes and WebSockets for stateful, bidirectional communication, while LiveView keeps application state in a server process and synchronizes rendered HTML changes with the browser. Later additions include uploads, WebSocket navigation, and HEEx templates.

## Takeaways

- 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.
- Phoenix Channels are bidirectional and transport-agnostic, commonly use WebSockets, retain state for a connection, and can relay events across a server fleet.
- HEEx extends Elixir EEx with HTML-aware tag syntax and compile-time validation; LiveView uploads and navigation use the existing WebSocket connection.

**Tags:** [Elixir](https://yomu.fyi/topic/elixir), [Phoenix](https://yomu.fyi/topic/phoenix), [Phoenix LiveView](https://yomu.fyi/topic/phoenix-liveview), [WebSockets](https://yomu.fyi/topic/websockets)

- Source: [Fly.io](https://fly.io/blog/how-we-got-to-liveview)
- Source URL: https://fly.io/blog/how-we-got-to-liveview
- Ingested by Yomu: 2026-09-03T01:24:55.772Z

[Read original post](https://fly.io/blog/how-we-got-to-liveview)