Phoenix LiveView Info

We’ve put together this wiki for Phoenix LiveView - please feel free to add any info you feel is worth including.

What is Phoenix LiveView?

As described by @darinwilson “Phoenix LiveView allows developers to add dynamic, client-side interactions to web pages, using code that runs in Elixir on the server”. This mean you could kiss goodbye to front end frameworks like React and the JS-hell that so many of us have been finding ourselves in these past few years! As you might imagine, the community is very excited about this!

For a more in-depth explanation, check out Darin’s excellent blog post on the topic.

Official URL:
Original announcement: Chris McCord’s ElixirConf 2018 Keynote

Threads of interest:

Screencasts & Talks:

Podcasts of interest:

When can you get your hands on it?

Chris has said “soon after Phoenix 1.4 comes out” (and 1.4 is due out soon!). Edit: Now! Here:

Has there been anything like it previously? Has the idea been tried and tested at all?

We’ve put both of these questions together because the answer is yes and yes! There is a similar library in the Phoenix world called Drab, which has proven to be very popular in the community. LiveView tackles the same sort of problem but from a different angle - so if Drab is anything to go by, LiveView is going to be a huge hit :003:

There is also another similar library that was announced at ElixirConf 2018, called Texas.

There’s now another new library, called Morphling… and… another called Whistle :smiley:

Where can I get more details?

Chris McCord’s keynote is currently the best place to get details, followed by the blog posts on the topic as well as Chris and José’s comments in the numerous threads that have cropped up here on the forum.


  • Blog post and another demo:


the pragprog phx 1.4 book published date is 10th of November. 8 days

I’d guess its all going to drop together; book, phx 1.4, live view

personally, I’ve been tracking phx head for maybe 6 months, so LiveView is the NEXT BIG THING

kind of revolutionary actually, Websockets is an entirely new paradigm from http


Live view is not going to drop in a few days. Chris clearly said in his elixir conf talk, that once the book and phoenix 1.4 is out he can start further research into live view. By now it’s probably just a small prove of concept implementation far from a publishable state.


I think he’s just excited that it means LiveView is what may be coming next… he’s not the only one:


1 Like

oh, I thought LiveView was going to be released at the same time…

If you want to try out a similar concept to LiveView, maybe consider trying out Drab?


I’m not 100% sure now, but I think Chris’s exact words were “soon after Phoenix 1.4 comes out” :smiley:

I only listened to the vid 1 1/2 times, either way, its a big change

I don’t see LiveView in the book at all, except for

“Unfortunately, when the confluence of the development of a major new feature like LiveView coincides with ElixirConf and Phoenix 1.4…”

so, I figure its not going to be a full release of LiveView, or if it is, its the start of a journey

the http + ws journey has just begun


I’ve looked into Drab and Texas and get the idea

more interested in the new standard implementation from the founders

Chris has tweeted a short LiveView demo:


That looks amazing - lightening fast!! Can’t wait to try it :003:

am keen to understand how this effects the rest of the ecosystem

how one might migrate a CRUD app ?

I saw someone asking about LiveQuery, I wonder how it will effect JSON api also

lots of questions

I am so thankful I never bought into the Javascript Frontend JSON API koolaid

dhs convinced me a couple of years ago with his screeds

chris_mccord has really shifted the paradigm

1 Like

This is cool indeed, but what I really want to see controlled inputs and how @chrismccord plans (and if) to implement it. Like, when you type, events are being sent to server, server does something with the text and sends update back.

Good use case is for example input that converts entered text to lowercase, or an input that formats phone number.

Longer text inputs (text areas) with a lot of text in it is going to be another problem. Also, pasting text, entering / deleting text in the middle of input etc. is going to be hard without some smart diff algorithm.

I did some experiments with server-side updates, and form inputs were the thing that seemed to be the hardest to handle.


I’m wondering how interop with JS could work with LiveView… I have a bunch of React components and currently am happily using react-phoenix to render them.

A lot of use cases will work great in pure Elixir with LiveView but frequently I will need to client-side render a React component (that’s already loaded in JS scope on the page) with props in the middle of a LiveView component/module. Not sure how that would/could work with the DOM diffing strategy but it would be totally awesome. I think Chris mentioned in a podcast (or video, not sure) he was thinking about this.


As long as the javascript components follow the webcomponents spec then I wouldn’t see much issue unless the DOM swaps things out or mutates a property when it meant for an attribute or vice-versa or so (Drab handles this really well).


typo: dhh
Stimulus and Rails
server side html with sprinkles of Javascript

@chrismccord has posted this on the DockYard blog

Has lots of useful info and cool examples - can’t wait to check it out :slight_smile:


Something I’ve been missing is information of whether or not history alteration will be a first class citizen.
To be able to truly replace react we’ll need to be able to construct rich urls that can be updated by the liveviewing.

Any idea if this is coming? @chrismccord?

Exciting stuff!!!

What’s Next?

We’re close to an initial release, and we can’t wait to see the kinds of applications the community builds with LiveView. Our next step is building testing tools similar to Phoenix.ChannelTest, which will allow testing live views and client interaction purely in Elixir without a browser. We will also be shipping LiveView generators that will allow bootstrapping CRUD UIs like the existing phx.gen.html generator, but fully real-time out-of-the-box. Stay tuned!



Push state is definitely something I will explore once other areas settle, but I think standard URL navigation should still be the default. We supports redirects today, so I imagine there will be a transition primitive that would use pushstate, but not a goal for our initial release.