It’s one of the problems I’ve thought about. You might be interested in this post: https://forum.elixirforum.com/t/phoenixundeadview-lets-discuss-optimization-possibilities-for-something-like-phoenix-liveview/
tmbb
bjunc
Regarding performance, I think it might be nice to do some benchmarks to see where the limit actually is. In the JS community, there have been countless attempts to compare React vs Vue vs Angular in every which way. One that I remember somewhat vividly was React Fiber rendering a Sierpinski triangle: GitHub - claudiopro/react-fiber-vs-stack-demo: ⚡️ React Fiber vs Stack Demo · GitHub
On my machine, React Fiber hovers around 60fps (Chrome performance tab, record); where Stack hovers around 2fps. Any chance we could create this in LiveView and see how it compares?
0
tmbb
LiveView is vaporware as of now… My musings about minimizing data transfer are merely theoretical and should not be taken as advice on how to efficiently diff HTML on the client
0
chrismccord
Creator of Phoenix
The 60fps was to showoff the performance of the approach, not to promote using LiveView for sending an html page every 16ms 
. Performance wise, we’re planning to perform diffing on the server to only send the bits that have changed.
11
OvermindDL1
Some things that pre-date this in one form of another, Nitrogen on erlang and Wt framework on C++. nitrogen let you define a page and then react to it similar to Drab’s low level interfaces, not as ‘live’. Wt for C++ on the other hand has been around for a LONG time, it basically gives you a kind of normal desktop GUI API (QT’ish) for working with the web, been around since 2005, and it is very much like liveview in functionailty (it was SO nice to work in!).
Nitrogen, due to it’s more low-level style, only did explicit updates. Wt was full observer-oriented, super-efficient. Drab.Live is mostly observer style though with some slightly heavy pre-generation (still less than a VDom).
It is in my stuff! ^.^
Unpoly and Drab both make it pretty easy to do though.
I’m curious, how is that new state transformed to the client? Is it a template replacement on the client, a VDOM merge, direct observer interactions (most efficient of these listed but requires compiled-in metadata about the template on the server, which is entirely doable in Elixir), or something else?
What does it gain over Drab.Live as well?
Do note, I’ve not seen the video, I often can’t watch videos. ^.^;
Isn’t the entirety of Drab already? 
Eh, I actually see it as the very old way of doing this. Going back 20 years all web pages were server driven, even with sessions and live polling and COMET and all. It’s just coming back around at this point. Even Wt was birthed as the epitome of that whole server-owned idea (it’s built and managed by a business, it’s only incidentally open-source, and it didn’t even used to be FOSS back when I used it).
3
chrismccord
Creator of Phoenix
It would really help if you watched the video as I believe most of your questions will be covered. We use morphdom to apply the DOM patch, without the need for vdom on the client. wrt to drab, there’s some really great work there, and I think we have similar visions, but with different approaches. Note: I’m only familiar with Drab from tangentially following the forum posts, but from what I’ve seen Drab focuses on “remote controlling” the page from the server, where its primitives revolve around poking parts of the page for update, peeking parts of the page for values, and using client-like primitives for setting DOM node props/attrs. With LiveView, we take the react model and place it on the server, where we focus on stateful processes that upon updating their state, transform that state into HTML, which then is used to update the UI. So our approach is more about focusing the UI and stateful views, where the update step pushes the diff down, versus a more direct coupling to server controlling the client DOM/page.
I see this point, but I also find it funny we have folks who both see this as yet another new way to do server apps, and also the way we always did them from the start. Both have valid points, but it’s interesting watching the different hot-takes 
7
kelvinst
Well, I particularly disagree with this point for some reasons:
- I would not call opposite direction, @chrismccord explained very well that his attempt was to solve the same problem, which is the poor UX when you have too many page refreshes. So the direction is the same, it’s just a different path, and it’s totally valid to try out different solutions for the same problem.
- Just because big companies are pushing it to a certain way does not mean that’s the best solution.
- Just because it’s not “disruptive”, doesn’t mean it’s not good. I see what you mean: the concept is really close to turbolinks, but over websockets. Well, turbolinks was good enough for a long time, but then, some people started to complain about UX with that and try out new solutions, which is good! Very good! But if you try out a new solution, and it’s not better in some senses, the wisest thing to do is going back and maybe try something else closer to how it was.
I see it as the way we always did them from the start, but a little bit simpler, faster and reactive. I already love the way we were doing it from the start, and if you really made it better, I’m really excited to try it out! Thank you!!!
2
codyclay88
AstonJ
The funny thing is some industries are actually exploring or heading that way - with dumb(er) clients and intelligent backends. Where? Perhaps where you’d least expect it… gaming
3
riga
I can’t imagine how this approach would be any more fragmenting than the existing standard for rich clients – where you already have the initial server render, the client side code, and some API. LiveView just looks like a simple embedding a view within a view (which we already do in Phoenix), except the embedded view can by dynamically updated.
Clearly it doesn’t do anything technically that couldn’t be done in 2009, but to have all the tedious and error-prone plumbing taken away seems like a huge win to me. Big props to Chris and the Phoenix team for making this happen.
0