|
|
|
|
|
by nickjj
2541 days ago
|
|
> LiveView cannot avoid latency. When I've experimented it's great for something running on my local network; less good when it's in a datacentre in another country. It's laggy. If you built a traditional SPA, aren't you still making loads of calls to your server? I don't see how LiveView would be more laggy than that. In both cases you're making network calls from the user's machine, to your server, getting a response from the server and then rendering output on the client when it's received. Of course you can cheat and do optimistic rendering on the client (like outputting what you wrote instantly in some DOM element instead of waiting for a response and validating it after the fact) but I believe that enhancement could be done with both techs. The only place where LiveView falls short is a true offline / fully client side app, but those are such a rare breed and way out of the norm for a typical web app. In 20 years of web dev as a freelancer, I've been asked 0 times to build an offline / client side JS app. |
|
For data loading, yes. But here's a few random thoughts:
* I can pre-emptively load data in a SPA (think: 3 screens-worth of a datagrid) and keep fetching in advance, so the user rarely feels the lag.
* Much of my investigation has been around adaptive forms, wizards, validation and keeping logic in a single place. Having to define models and logic once, rather than client-side and server-side would save so much time.
My testing suggested that client-side validation still gave better results, because it was instant. Moving forward & back through a wizard was better if client-side rather than each screen rendered server-side.
I experimented early May so am a little hazy on details (and can't find which PIM I put my notes in, sigh) and look forward to seeing other people's experiments. Particularly when not run on their local machine.