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:

1. Are you building a fat client app (for that’s the only kind of web app LiveView is not made for)?
2. Are you building an app that’s meant to scale without rewriting it each time it gains another order of magnitude more users (b/c with LiveView you won’t have to)?
3. Are you planning to hand most of your SaaS income over to Amazon (for with LiveView you won’t need to)?

My 2c

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.

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.

It could, of course. But as you already noted, there are gotchas. Some things are sensitive so you encrypt them. Some things won’t work if you reconnect to another node (NIF resources). With all that, I don’t think it should be part of LiveView itself and you instead roll your own if necessary (or build a library).

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.