Never Look Back - The Real-Time Revolution with LiveView

Chapter 5: The Real-Time Revolution with LiveView

If Ecto and Plug were the features that sold me on Phoenix’s architecture, LiveView was the feature that blew my mind and made it impossible to go back.

Phoenix LiveView is a library that allows you to build rich, real-time user experiences with server-rendered HTML. Let that sink in. You get the interactive, responsive feel of a single-page application (SPA) built with React or Vue, but you write almost no JavaScript.

1. How It Works

   When a user first requests a LiveView page, the server renders the full HTML, just like a traditional request. It then establishes a persistent WebSocket connection between the client and the server. From that point on, every interaction—a button click, a form submission, a key press—sends a tiny message over the WebSocket to a dedicated LiveView process on the server.

   The LiveView process handles the event, updates its state, and re-renders its template. But it doesn’t send the whole HTML page back. It intelligently diffs the new HTML with the old HTML and sends only the minimal changes needed to update the page. The client-side JavaScript, which is completely transparent to you, receives this tiny diff and surgically updates the DOM.

   The result is an incredibly fast and responsive user experience. The state lives on the server, in an Elixir process, which means you have access to the full power of the BEAM.

2. The End of the SPA Divide

   For years, the dominant paradigm for building interactive web apps was to create a REST or GraphQL API on the backend and a completely separate JavaScript SPA on the frontend. This has always been a source of immense complexity.

   1. You need two codebases, often in two different languages.
   2. You need to manage state on both the client and the server and keep them in sync.
   3. You have to deal with authentication, routing, and validation in two separate places.
   4. You double your hiring complexity and create a division in your team (frontend vs. backend).

   LiveView collapses this divide. Your rendering logic, your event handling, and your state all live in one place, on the server, written in Elixir. You can build a feature like auto-suggest search, which used to require significant JavaScript, in just a few lines of Elixir code.

   # In your LiveView
   def handle_event("search", %{"query" => query}, socket) do
     # The state is updated, LiveView re-renders,
     # and the diff is sent to the client.
     {:noreply, assign(socket, results: search_database(query))}
   end
   
   # In your template
   <input type="text" phx-change="search" phx-debounce="300" />
   
   <ul>
     <%= for result <- @results do %>
       <li><%= result.name %></li>
     <% end %>
   </ul>
   

   That’s it. A real-time search box. No API endpoints, no JSON serialization, no client-side state management. It feels like cheating in a way that even Rails scaffolding never did. Rails has Hotwire and Turbo, which are steps in a similar direction, but they don’t have the stateful server-side process that makes LiveView so powerful and seamless.

Read prev: Phoenix - The Framework That Respects You | Read next: Performance, Scalability, and Peace of Mind