4 ms·

You should be using LiveView only for things that would require a server trip anyway. For client side interactions, use a client side JS library (like Alpine [1

• chrismorgan 4y ago
  The problem is that LiveView forces synchronous operation, whereas a significant fraction of things that would require a server trip anyway could actually be done asynchronously—that is, as far as the UI is concerned, they actually don’t require a server trip; not immediately, anyway, and the UI should only care about the immediate. When you control server interactions on the client side, you can do things like optimistic editing, where the UI assumes the action will succeed and then does it in the background, and then handles the exceptional case where something goes wrong, most likely by returning you to a form; or things like queuing actions up when there’s no internet connection, and performing them when you get a connection again. I want to emphasise again the importance of latency. I live in Australia. Most of the web is much slower in Australia than it is in the USA, not because of bandwidth, but because of latency. The LiveView approach is convenient, but it’s technically not a good solution for most applications. It’s excellent for things like chat systems where being bound to synchronous operation and requiring a network connection to do things isn’t an issue, but I honestly don’t think it’s the best solution (technically, again; socially it may be) for much else.