What is Phoenix LiveView
The Sizzle Reel
Before we get into the details of how it works, let's geek out about some of the official demos!
Here's a snake game, rendering at a playable framerate:
Here’s a basic user signup form, with some data validations running on the server:
For more experimental demos, check out the results of the recently wrapped up Phoenix Phrenzy competition. There are some really impressive apps and they’re all open source!
But how does it work?
The LiveView programming model will feel very familiar to anyone who has worked with React or similar frontend frameworks, but with the rock-solid reliability that Elixir brings to the table. LiveViews are programmed declaratively: the programmer specifies the state of the program and how it can change and then LiveView figures out how to update the rendered page to match the new state. This is a huge improvement from having to imperatively tell the browser each step needed to change what it's displaying, and it’s great that LiveView has adopted this model.
When you write a LiveView template, you include some pieces of dynamic data within your static markup. This is no different than a templating language in any other server-side language; if you’ve written Twig in PHP, ERB in Ruby, or Jinja2 in Python, you understand the basic concept. Where LiveView templates work differently is when that data changes. Let's walk through a toy example to illustrate how this works at a high level.
This page has only two pieces of dynamic content: the comment stream and a count of upvotes.
Now, let’s press the upvote button, change some of that data, and see what happens 3. Without going into implementation details, we bind an event to the button and then write a handler function (in Elixir) that responds appropriately. When the button is pressed, the event is sent over the socket connection.
Only the changed content is sent back to the client! Since our comment stream hasn’t changed, we don’t send any new comments. This makes the data sent over the wire very slim. This enables LiveView to provide highly performant experiences by default.
How does this compare to...?
There are three main approaches to building a web app.
- Full Page Reloads
This is the classic old style of web app. Users click a link or other piece of interaction on the screen, and a request is sent to the server which responds with a complete new page representing the new state after the interaction resolves. The server renders the HTML and sends it over to a dumb client that does little more than present it to a user.
This works great for many kinds of applications, particularly content sites that skew closer to the original vision of the web as a document delivery platform. It falls down when we want the user to be able to interact in real-time with the application.
- Single Page Apps
- JS Sprinkles
When would I use LiveView?
All that said, LiveView is still early stage software that is not quite ready for prime time. In my week of hacking around, I found that file uploads over a LiveView socket was not yet supported, but there was a talk demonstrating a proof of concept at this year's ElixirConf. Phoenix maintainer Chris McCord said that he is no rush to hit a 1.0 release, preferring to slowly build on the core LiveView that exists now. I am excited to follow along and contribute!
- We are not providing a downvote button, you monsters. ⤴️
- While they all have their differences, for the purposes of this discussion they are all solving the same problem. ⤴️