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.