[h0l0cube]

> Phoenix is bad in environments with bad wi-fi

I think people conflate LiveView with Phoenix. I think the former is a little over-hyped, has a high learning curve, has an impedance mismatch with usual web developer tooling and libraries, as well as the latency issues you describe. In the app I'm building I've used it for only part of the functionality. The rest is a plain old SPA and a few templated SSR pages. My other experience lies mainly with Django/C#, but I'd say Phoenix is highly ergonomic for making boring websites, has sensible abstractions for database mapping and date/time, and has integrations with every service I've encountered. I do, however, look forward to making some pure LiveView projects in the future as I gain more experience with it, and it does make sense for realtime collaborative tools where always online is a soft-requirement.

[freedomben]

This is what I came to say as well. Phoenix is not LiveView and LiveView is not Phoenix!

And even when LiveView is used, there's no reason whatsoever that you can't still use whatever JS client-side thing you want for things when you need it. There are increasingly more built-in JS functions available that run client-side, and Alpine.js in particular fits neatly into Phoenix and lets you do a ton of stuff. I always add Alpine and use it for menus and other stuff. If the action doesn't need data from the server, I do it client-side in Alpine.

IMHO way too many people think of LiveView as a total replacement for javascript that is all or nothing, but that's a bad approach.

[h0l0cube]

Agreed. I think the OPs criticism of LiveView is also a bit overblown. You have blocking latency issues in CRUD apps too, and in general UI changes pair with data updates, and as you say, where they don't you can still do client-side UI updates.