If I need to ship a new product in a week, Phoenix LiveView is my go-to framework.
Elixir LiveView is incredible, and an alluring choice for software leaders looking to develop applications super fast. However, in recent experience, I’ve seen teams hit some pitfalls.
The trick is to understand what Elixir LiveView excels at, and what it doesn’t.
TL;DR: LiveView is perfect for internal tools and simple apps. Skip it for complex UIs, offline-first apps, or if your team doesn’t know Elixir well.
A LiveView developer here (from its earliest days)..
Is your team familiar with Elixir?
As opposed to what? JS or Python? The languages every human gets born with knowing full well, so outside of the two learning any other language is like a burdensome extra skill yet to get acquired?
IMO out of all the cons you list there, the only one holding water is the continuous connection requirement, and even that one is only partially true b/c LiveView does handle a loss of connection gracefully when idle, the only catch being you can’t really change the server-side state if the connection is down, but that’s true for every web app.
What you don’t mention in your post is that LiveView has the BEAM VM underneath meaning you can achieve things with processes WITHIN your app you can only dream of in any other framework. That’s not to mention the savings on, say, Amazon services that you otherwise MUST pay for because your Lego-component friendly framework of choice runs in a single server-side thread, has no in-memory DB of its own nor does support horizontal scaling while it’s vertical scaling is non-existent.
The more appropriate questions you could’ve asked in your post are the following:
My 2c
Thank you for writing this article, definately thought provoking. In the past I have read similar analyses of liveview’s limitations regarding client side interactions. What I always find puzzling is that when there is critique on liveview for having to write a few js/ts functions through a hook, the solution for not having to do this is bringing in a full js framework complete with npm hell and lots more js to write than if you would be creating a hook.
I wouldn’t really refer to terminating the process and destroying all of the state within it as handling it “gracefully”. It would be fair to say that LiveView could handle it gracefully, but it doesn’t.
I do think for certain use-cases having a thin client with state directly next to the BEAM/database is advantageous. However, it’s not like this is black and white; you could have a client-rendered app that interacts with a BEAM backend and still get all of Elixir’s benefits on the server.
I think this premise is a bit absurd in general, but also I would point out that a thin client approach is more expensive on the server side than a thick client because you have to do more work on the server.
But really I am just restating the previous point: you can use Elixir without LiveView and get those same benefits.
Have you tried pulling the ethernet cable out and then plugging it back in? Unless LiveView was trying to push or render during that period the process(es) would not restart. You wouldn’t even notice it happened.
Of course, I wasn’t arguing about fat client (“client-rendered”) apps. One of my points was in fact that that’s the only case LiveView is not made for. And yes, any app that keeps sufficient state on the client to function in a stand-alone mode and only query/mutate server state on explicit demand is in essence a fat client app.
It depends on the particular requirements. If the app doesn’t require frequent queries/mutations, then sure, but that’s again the fat client type of app that’s not perfectly suited for LiveView.
On the other hand, if the app is chatty, and you have a REST API, you can stay assured the amount of data transferred over the wire on average (not accounting for full page http refresh) will be far less if its LiveView server-rendered than if it’s “client-side” rendered. It’s easy to understand why’s that, and we have also proven it to ourselves in practice.
Btw, I only hope we’re not having this conversation solely because of the LiveView process restarting when it detects it’s out of sync.
Like, it’s all datagrams underneath. I understand that TCP can survive a little blip. But if you lose the connection you lose the process, right? I would love to be wrong about this but I don’t think I am. My understanding is that there is no reconnection behavior at all and you simply get a new process.
And that is a much more reasonable and nuanced position than “LiveView is magic that will reduce your AWS bill”.
I do like LiveView, but I am not a fan of meaningless hype. Clearly you are knowledgeable and capable of carrying on a nuanced discussion of the topic, so why not do that instead? This is literally the Elixir Forum; there is no need to evangelize here.
True. In it’s current form/version when it detects it’s out of sync, there’s no going back. But, again, it’s not the end of the world because..
One needs to evaluate what it is that actually happens (to the app itself) in each of the cases (a LiveView app vs a fat client app) when connection is lost, and more importantly how it affects the user.
For the fat client app, it’s simple (assuming it’s client-side framework doesn’t flip over too in which case it’s gonna be far worse than if a LiveView restarts). But let’s assume it doesn’t crash. The fat client app stays in it’s semi-usable mode until the connection is back on.
As for the LiveView app we have the process restart, but what really bothers people is the loss of client-side state after having reloaded the page. The perceived pain can be substantially alleviated by keeping track of the important client-side data points on the server. For instance in our app we track what was clicked last and where in the stream it was so we can reposition on page reload but not just on page reload triggered by a lost connection, but also in a scenario when the user navigates elsewhere within the app and the navigation itself restarts the LiveView so when the user decides to go back by pressing the browser’s back button they not only get returned to the correct page, but also to the correct location in the stream (if there is one) and even within a nested stream of the stream and so on. In practice, the pattern/mechanism used for this pretty much undoes most of the negatives of a LiveView restart.
So, if it’s all about LiveView restarting on a lost connection, in the end it doesn’t get all too much different for the end user since we save that what’s dear to them.
Agreed.
© Copyright Elixir Forum | Terms | Privacy & Cookies
