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…

For an “image editor”, yes, absolutely would use more bandwidth than a client app, but that example is more to showoff the minimal diffs we apply on both client and server. The autocomplete search example is a much better real-world comparison when discussing bandwidth:

https://i.imgur.com/WWAHTR3.gif

In this case, the LiveView diffs match the best, most optimized server JSON you could write by hand, and you get that for free with zero effort. For some use cases we will use more bandwidth , like real-time form validations, but there are others where we can match, or potentially beat, a SPA bandwidth wise.

To add to what Chris said, there is also a feature to add debouncing/throttling in the cases you don’t want to immediately send changes all the time to the server.