3 ms·

Phoenix creator here. Stimulus Reflex and most LiveView-like solutions do not perform diffing that LiveView does, so you are receiving the entire page/template

Phoenix creator here. Stimulus Reflex and most LiveView-like solutions do not perform diffing that LiveView does, so you are receiving the entire page/template for every change which adds to the overhead. You are correct that purely client-side interactions should be instant, and we promote keeping purely client-side interactions client-side. For any interaction that must otherwise make a trip to the server – saving a form, posting a message, fetching new results, etc, an SPA will not be any better. In fact, it will usually be slower because LiveView payloads are going to be better optimized than the best hand written JSON you could write for your SPA client/server contract. Likewise, we use the established websocket connection so there is no HTTP handshake, header parsing, authentication, etc for every interaction so LiveView can provide a better UX when round-trips are involved than SPAs. For client-side interactions, we have a number of UI features built-in that provide user feedback while awaiting an acknowledgment and tools like Alpine.js are fantastic when you have purely client-side interactions to perform like opening navs and controlled input formatting. I wrote about UX considerations with LiveView here that addresses these points: https://dockyard.com/blog/2020/12/21/optimizing-user-experience-with-liveview https://dockyard.com/blog/2020/12/21/optimizing-user-experie...

bluewalt 5y ago
Thanks for the explanations. This makes perfect sense that having an open WebSocket connection drastically speed up the exchanges between client and server. However, I guess there is still a UX difference with SPAs when you go to a new page. Going to another page with a SPA is instantaneous, and user just waits for server-side data to be loaded, with data with spinners in between. But with Liveview, the client would need to wait for the server to render the whole new page, before displaying anything new (exactly like a standard MVC framework). And this specific behaviour can create a "laggy feeling" IMO. This will never be as fast as a SPA in this case. I think this can be disturbing, especially for websites used as mobile apps. In that case, users expect navigating between app pages without waiting at all, even if they are used to to wait for specific data to be loaded in that same page. Please correct me if I'm wrong, but to me, it seems Liveview is perfectly suited for intensive data exchange on an open page (for example, the bitcoin example used in this video seems perfect), but not suited for apps with an intensive navigation between different pages, because that pages will require a round trip to the server to be rendered. Still, I'm jealous there is no Liveview equivalent in Python, so that I would stop requiring the whole SPA toolchain as soon as I need some updates in my project.

bluewalt 5y ago

Thanks for the explanations. This makes perfect sense that having an open WebSocket connection drastically speed up the exchanges between client and server. However, I guess there is still a UX difference with SPAs when you go to a new page. Going to another page with a SPA is instantaneous, and user just waits for server-side data to be loaded, with data with spinners in between. But with Liveview, the client would need to wait for the server to render the whole new page, before displaying anything new (exactly like a standard MVC framework). And this specific behaviour can create a "laggy feeling" IMO. This will never be as fast as a SPA in this case. I think this can be disturbing, especially for websites used as mobile apps. In that case, users expect navigating between app pages without waiting at all, even if they are used to to wait for specific data to be loaded in that same page. Please correct me if I'm wrong, but to me, it seems Liveview is perfectly suited for intensive data exchange on an open page (for example, the bitcoin example used in this video seems perfect), but not suited for apps with an intensive navigation between different pages, because that pages will require a round trip to the server to be rendered. Still, I'm jealous there is no Liveview equivalent in Python, so that I would stop requiring the whole SPA toolchain as soon as I need some updates in my project.