Phoenix LiveView is now... live!

This is an entirely valid point of view.

That said, if you measure the value of Live View at least in part by how much basic interactivity you can get without writing Javascript, it would be nice to be able to access parts of the DOM that aren’t tied to assigns. Drab does this, it is very pleasant and has worked fine for me even if it is not optimally efficient.

That said, it feels to me like Live View only allowing DOM updates via modified assigns is a conscious design choice, and as I try to get familiar with it by rewriting a Drab-powered application in Live View, I see how introducing this constraint has advantages, too.

Drab also provides a map of the attributes of the DOM element to the event handler, (the sender map) as opposed to just one attribute (e.g. phx-value). You can work around that in Live View, but unlike the absence of direct DOM manipulation discussed above, I don’t yet see any advantage to this limitation; it’s just kind of a pain (at least from my vantage point of having become accustomed to having it with Drab).


In master we have already changed phx-value to be a map, so we can allow extra data to be given but it is not yet clear how this extra data will be retrieved/computed. Maybe a custom function that is evaluated with the DOM element? But it is unlikely we would send anything extra out of the box.


Sorry, I must be missing something really obvious but I can’t find any examples that point the way to re-usable components.

For example, if I have a page/view with:
<%= live_render(@socket, DemoWeb.ImageLive) %>
<%= live_render(@socket, DemoWeb.ImageLive) %>

… each DemoWeb.ImageLive is mounted with the same, no client events appear to be generated by the second DemoWeb.ImageLive and so the second DemoWeb.ImageLive “doesn’t work”.

What’s the recommended strategy for using multiple identical liveViews/re-usable components alongside one another please? Thanks …

1 Like

This was a bug with child id generation, and is fixed :slight_smile:


The responsiveness of you guys is ridiculously amazing! Thank you!


3 posts were split to a new topic: Phoenix LiveView and Pjax

A post was split to a new topic: What’s the possibility of creating a “drop-in component” (React-like) using LiveView?

Just a quick note to say that now this thread is getting quite long, if you have a question about LiveView please post it in a dedicated thread :smiley:

Chances are that many others may have a similar query and so by having dedicated threads they will be more likely to be picked up by search engines… which means they will be more easily found, hopefully lightening the load for Chris, José and the rest of the Phoenix team, thanks :023:


2 posts were split to a new topic: Will LiveView work with iOS or Android?

Desktop apps is one area that I think LV have a lot of potential.

The past couple of months, I’ve been looking for a way to give one of my elixir apps a GUI (JavaFx, wxWidgets, Electron, etc), but all of them had major drawbacks that kept me from committing. With the introduction of LiveView, I just made that exact same app as a dependency for a phoenix liveview front-end and ran things straight from the browser. Work that would have otherwise taken me weeks, done in a day.

Great job here m8s


A post was merged into an existing topic: LiveView demos thread!

I never have flattened Jose or Chris for Elixir or Phoenix, just to be clear how high I put the bar :wink:

But LiveView might as well (and should IMHO) revolutionize the web.

So let me say something I probably should have said a long time ago:

Jose, Chris and all the others working on Elixir, Phoenix, Ecto, LiveView etc.

You are my heroes and I am, like many, many others, in your debt !


where is phoenix live view documents?

you mean the code?

Hello, no I mean like this

As the package is not published yet, you will find the documentation in the code, take a look at the README :wink:

1 Like

@josevalim @chrismccord and others, please be careful as quite a few people would like to flatten you! :thinking::face_with_monocle:

But yeah, thanks for all your work and optimizations which allow liveview to be useable (maybe most thanks should go to the people who made the BEAM and light processes possible). It only lacks a way for forms to have a fallback when JS is off for me to happily flatten you as well! :partying_face:


oh good one People.flatten flatter of course!!!

1 Like

Golang/Elm user here (although very interested in Elixir) - just wanting to add my 2 cents.

I developed something very, very similar to this in Go last year. I modelled it after The Elm Architecture (hence the name ‘go-tea’) but it does essentially the same thing: renders HTML, establishes a websocket connection, then pushes ‘messages’ from the client to the server. The server holds a state object for the session which it updates and then sends the rerendered HTML back to the client. As with LiveView, the client uses Morphdom to make minimal incremental changes to the DOM. Repo is here: (hasn’t been touched for a while).

I had a few cool examples, similar to some of the stuff @chrismccord demoed in his keynote: forms, navigation, shared list editing across connected ciients, basic components, even a little card flipping game.

I came to a similar conclusion: that this architecture was easy to reason about, performant enough and could scale quite well, so our team took the plunge and used it on a project we were working on at the time which needed an internal admin panel with fairly interactive UI.

I was actually amazed at the results. I built the admin panel in about 2 days instead of maybe 2 weeks. The code was clean and honestly, the app was indistinguishable from a SPA except perhaps to an expert eye.

The only real issue we had was with debouncing text input in a text editor. We were live rendering a preview of parsed markdown next to where the user typed the content. As an aside - that was another compelling argument for this architecture. We were able to use the exact same template to render the preview in the admin panel as was used for the user-facing portion of the site (also server rendered in Go). Anyway, when the user typed too fast, the server state could get out of sync with the browser state causing some strange regressions while typing. We experimented with a few different debouncing techniques and parameters but never really settled on anything we liked.

Eventually that project was abandoned in favour of Wordpress (don’t get me started on that…) but the idea of building sites/apps in this way has stuck with me ever since but I’ve always been hesitant to go all in on it for a couple of reasons:

Firstly, there’s always been that “can this really scale” niggling doubt. It’s such a departure from the norm that I think it’s natural to be slightly cautious in this respect.

Secondly, and this is definitely subjective - for me, at least, Golang was not a ‘nice’ fit for building apps in this way. Don’t get me wrong, the raw power of Golang, the speed and concurrency features makes it an ideal candidate for doing this - probably one of only a handful of languages in which you’d even attempt to do such a thing. I just found that expressing the app/UI logic felt clumsy. I longed for the functional elegance of Elm. I don’t know if it’s just because I’m used to Elm now, but it feels very natural to write UI logic as pipelines of transformations. You have a list of this thing, map it to this other thing, filter out these ones, then render. That seems to me the to represent 80% of the code you end up writing - that and case switches. This was just horribly verbose to write in Go.

So stumbling across LiveView was a real joy for me. I can attest that this way of architecting apps is totally awesome and works better than you probably imagine at first. Personally, I’m ready to go all in. 90% of the sites/apps I build will never need the power/overhead of Elm, so it’s a great fit for me - obviously YMMV depending on what you build.

Now I’ve got to learn Elixir as fast as possible. Off to research resources…


I first heard about Phoenix LiveView in more detail during ElixirConf.EU in @chrismccord’s talk there. Before that, I had heard about it a little bit, but was (a) skeptical about its intended performance, and (b) far too busy with other projects these last two months to look at it in any detail.

But not only did my jaw drop to the floor during Chris’ talk, also did I realize that it was a godsend to use during hackathons where you want to quickly build something simple, without wanting to worry about the ‘frontend <-> backend communication layer’.

So, last weekend, during the Odyssey Blockchain Hackathon in Groningen, we set out to build a simple PoC ‘mobile-like’ web interface to make people’s energy usage more sustainable by gamifying it.

While we did run into a couple of bugs (it seems that currently nested if/else statements or case-statements in LiveView templates sometimes cause weird behaviour; I’ll investigate further before opening a issue request), the speed improvement gained from not having to worry about the JS boilerplate meant that within ~30 hours, the designer/slicer and I (the single developer on the six-person team) were able to flesh out the complete interactive interface.

Absolutely stunning. :heart:

We will probably release some screen footage and the source code soon, but first let me catch some sleep – I’ve been going on for 56 hours with very little of it. :sweat_smile: