> phoenix live view is effectively built around the assumption that the server process never dies and never restarts.
Not exactly, it's built to hold state in memory by default but doesn't assume how you want to handle deploys or server restarts. There's a built in restore mechanism for forms and it's trivial to shuffle state off to either the client/redis/your db[1]. You'd have the same problem if you were storing all your state in memory for any web application regardless of your library choice. Or you conversely have the problem that refreshing the page trashes client state.
So there are two thinks here, you don't have to use live_view to use elixir or phoenix, and if you do you just need to actually think about how you're solving problems. The state can get trashed anywhere for any number of reasons. Tossing on the client and forgetting about it just moves the problem.
> You'd have the same problem if you were storing all your state in memory for any web application regardless of your library choice.
But that's the thing - traditional server-side web applications don't do this. The the stateless request/response cycle of traditional server-rendered apps is a _huge_ advantage from a system design standpoint. State is bad. State is hard to manage correctly over time. Elixir makes it possible to manage this in-memory state relationship better than other languages, but it's still difficult to do at scale regardless.
LiveView turns stateless web applications into stateful web applications, and this is a problem most folks aren't considering when they see developer experience improvements the LiveView project claims. This is _the_ specific tradeoff that LiveView makes, and I wish folks wouldn't handwave it away as if it were trivial to manage. It's not. It's a fundamentally different client/server architecture.
Source/disclaimer: I work at a large company with a large LiveView deployment, we have spent a ton of time and money on it, and it's a pain in the ass. I still love Elixir, I just think LiveView is oversold.
I guess my quibble is that I’ve talked to Jose and Chris about this and I don’t think they’re overselling it. The caveats are in the docs and they expect you to understand the tools.
And realistically there are cases where I’d use another tool.
the way live-view is sold is some kind of alternative to writing javascript. if you have a very rich client side application then you can easily end up with a bunch of state which would be in the clients memory but now is in the servers memory. but if its in the servers memory the data ends up being much more fragile because any failure of the client or the server means the live view state is lost. whereas if the data was just in client memory then it would only be lost if there is a problem in the browser. ideally people would write applications that are tolerant to both faults. but i think in practice live-view practitioners just ignore the problem and then you are left in a worse situation.
i realize there is still a dataloss problem when there is state on the client but there is a lot of simple stuff that causes problems if you are effectively reloading the page if the server disappears due to a redeploy or a crash.
for example i'm reading an email in my message client. i've scrolled half-way down the email. but now the server crashes i reconnect to live view and my scroll position when reading the email is reset.
when i look at live view i feel like its written by people that have never deployed something in production. of course this is not really true but i feel like it would be better if live-view people were more honest about the tradeoffs. its a very complicated situation and having some bad outcomes might be worth the increase in developer productivity but i feel like live-view people just ignore the bad outcomes.
also, take a cloud deployment. websockets seem to be an inherent problem in cloud deployments especially AWS. as far as i know AWS does not expose some event to a instance that is part of a load balancer that it is about to die. ideally if you have a websocket instance with a client and you realize you are scheduled to be reaped you would message the client that it needs to reconnect. then the client would reconnect to a server that would not be reaped and everything would be dandy. but AWS doesn't seem to have this functionality (or its not easy to implement!) but more importantly live view does not expose any kind of hooks so you can have 'safe' server redeployment out of the box.
I'm not sure who from the core group of developers is overselling it in the way you're claiming. Yeah, I wouldn't try to build figma or gmail with liveview, but I'd be fine building an app for a bank for example. Tools exist in a mesh of other tools and problem spaces where they may or may not be appropriate.
Not exactly, it's built to hold state in memory by default but doesn't assume how you want to handle deploys or server restarts. There's a built in restore mechanism for forms and it's trivial to shuffle state off to either the client/redis/your db[1]. You'd have the same problem if you were storing all your state in memory for any web application regardless of your library choice. Or you conversely have the problem that refreshing the page trashes client state.
So there are two thinks here, you don't have to use live_view to use elixir or phoenix, and if you do you just need to actually think about how you're solving problems. The state can get trashed anywhere for any number of reasons. Tossing on the client and forgetting about it just moves the problem.
[1] https://hexdocs.pm/phoenix_live_view/deployments.html