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 
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 
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
I never have flattened Jose or Chris for Elixir or Phoenix, just to be clear how high I put the bar 
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 !
As the package is not published yet, you will find the documentation in the code, take a look at the README
@josevalim @chrismccord and others, please be careful as quite a few people would like to flatten you! 
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! 
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: GitHub - jpincas/go-tea: Build server rendered apps in Go that function like a SPA without the need for JS · GitHub (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…