We can't find the internet
Attempting to reconnect
Something went wrong!
Attempting to reconnect
Analysis Summary
Worth Noting
Positive elements
- This video provides a very clear, high-level architectural comparison between traditional AJAX/WebSockets and the LiveView model.
Be Aware
Cautionary elements
- The video frames the use of JavaScript as a burden to be avoided, which is a common marketing trope in the Elixir ecosystem to drive adoption.
Influence Dimensions
How are these scored?About this analysis
Knowing about these techniques makes them visible, not powerless. The ones that work best on you are the ones that match beliefs you already hold.
This analysis is a tool for your own thinking — what you do with it is up to you.
Related content covering similar topics.
Build a Twitch Clone in Elixir
Peter Ullrich
The BEAM-Rust Sandwich - Julian Köpke | Code BEAM Europe 2025
Code Sync
Mastering WebSockets With Go - An in-depth tutorial
ProgrammingPercy
Build a Twitch Clone in Elixir
Peter Ullrich
One to Rule them All Aaron Bedra
Zhang Jian
Transcript
- [Mike] So what is LiveView? What problems does it solve and what can you do with it? To answer that, say we have a conventional Phoenix application, and on this page, there's an interactive element. It sends an HTTP request to a controller action, which changes some state on the server, renders a view template, and a new page of HTML is sent back as the response. Then the entire page is reloaded, even though only part of the page changed. And that's far from ideal. Only the affected parts of the page should update. That would feel more, you know, interactive. - [Nicole] The traditional approach is to write JavaScript on the front end, perhaps using a framework such as React, Vue, or your current favorite. And instead of sending a regular get request, the JavaScript sends an asynchronous JavaScript or AJAX request to the server. The request is routed to a controller action, which handles the request and sends JSON as the response. And then the JavaScript dynamically updates the DOM to reflect the changes. - To avoid the overhead of the HTTP request-response cycle, there's another approach. Set up a Phoenix channel server process and have the client and server communicate over a persistent web socket connection. The JavaScript then pushes user events down the WebSocket, the channel process handles those events and pushes JSON back to the client. And, again, the JavaScript then dynamically updates the DOM. So, in both scenarios, all the HTML rendering happens on the client side. - And although the page now feels more interactive, we've introduced a lot of complexity. For starters, we have the mental overhead of building and maintaining a multi-language system, JavaScript on the front end and Elixir on the back end. - We also have to muck around with WebSockets and the details of channel-based communication. On top of that, we have the challenge of keeping state in sync across the client and server. - And all of this discontinuity just slows us down. What if we could get fast dynamic page updates with server-rendered HTML and no custom JavaScript? - That's where LiveView comes in. It's a library included in every Phoenix app that unifies everything and gives us a simple yet powerful programming model. Here's how it works. A LiveView is initially rendered as a static HTML page via a request-response cycle. Then a persistent WebSocket connection is automatically opened between the browser and a stateful LiveView process running on the server. User events are then pushed down the WebSocket to that process, which causes the LiveView state to change. - And rather than re-rendering the entire page, LiveView only re-renders the parts of the page that are affected. Those HTML diffs are then sent back, and LiveView includes JavaScript that efficiently patches the DOM. So as the LiveView process receives user events, changes state, and re-renders, everything is automatically kept in sync without having to write any JavaScript or manage WebSockets. - In doing so, LiveView frees us up to focus on the interactive dynamic features of our app, such as quickly sorting and paginating pizza orders, filtering boat rentals, adding items to a shopping cart, and quickly navigating between pages. - But the benefit of using LiveView is more than just server-rendered HTML over WebSockets. LiveViews run in a Phoenix server, which can scale to handle millions of WebSocket connections, and it has built-in presence tracking so it knows who's connected, and a built-in PubSub system for broadcasting real-time updates to LiveViews. And all this rests on a rock-solid foundation of Elixir, OTP, and the Erlang VM. - So you have an unrivaled stack for building massively scalable, multi-user, interactive, real-time distributed web apps faster and with less code. - Which means we can do such things as track who's currently watching a video, monitor who's checked in or out, and see what's on everyone's desk. - We'll build all these projects in this course and a lot more in an incremental step-by-step fashion. Plus, there's a whole bunch of exercises so you can practice what you learn along the way by building something different. So let's go build some LiveViews.
Video description
🤔 Curious about Phoenix LiveView? - What is it? - What problems does it solve? - What can you do with it? Here's our take in a 4-minute video for busy, curious developers. It's also the first video in our Phoenix LiveView course available at: https://pragmaticstudio.com/phoenix-liveview And if you're new to Elixir, we have a popular course on that, too: https://pragmaticstudio.com/courses/elixir Thanks for watching and we'd be delighted to have you in the Studio!