6 ms·

There's no need for client side prediction or optimistic UI on (most) Live View projects. It's all done on the server.

meheleventyone 5y ago
Latency is the reason. Even in a turn based game it still feels really bad to make a move and have to wait for it to make its way through the round trip before seeing the result. In a game with strict ordering like Tic Tac Toe there is little reason not to show the chosen move immediately.
- 1_player 5y ago
  Sure, that's why I meant most use cases. I mean, 100 ms between a click and a cross appearing on screen is not great user experience, but it's not even the worst. If you're writing a game, a little client side prediction is a good idea. But if you have a form with instant validation, or any old regular UI, that is not necessary at all. The only built in optimistic UI functionality on Live View is disabling a button when you press it and wait for the server to respond, to avoid double submissions.
  - meheleventyone 5y ago
    > But if you have a form with instant validation, or any old regular UI, that is not necessary at all. Arguably because you're trusting the client and essentially the built or built-in behavior is therefore optimistic by default. Then hopefully validating on submission server-side.
- keymone 5y ago
  From the tech talks I vaguely recall, LiveView folks seem to disregard latency, which is where the entire model falls apart for me because the moment you need more control on the client over what to do when the server is not responding - you’re entirely out of luck. Though maybe I’m wrong and there has been some new developments to address this, I wasn’t following too closely.
  - sfusato 5y ago
    On the contrary, LiveView documentation acknowledges this and suggests to handle such scenarios using client side tools: There are also use cases which are a bad fit for LiveView: Animations - animations, menus, and general UI events that do not need the server in the first place are a bad fit for LiveView. Those can be achieved without LiveView in multiple ways, such as with CSS and CSS transitions, using LiveView hooks, or even integrating with UI toolkits designed for this purpose, such as Bootstrap, Alpine.JS, and similar. https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html#module-use-cases https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html#m...
    - keymone 5y ago
      Sorry, that’s not acknowledging that latency can become an issue, that’s acknowledging that using server-side rendering for things that don’t require a server isn’t the best of ideas (shocker, I know).
      - hnedeotes 5y ago
        What exactly are you thinking in terms of latency becoming an issue under LiveView but not on normal requests? Do you mean when websites just need a full refresh because they lost their requests on some callback and no-one implemented recovery across the 5 levels of callbacks or something more specific?
        arjan_sch 5y ago
        Well with Liveview you go "full server state" for everything that you would normally just use plain JS for. For instance, toggling a checkbox or collapsing a div. Having latency on such lowlevel interactions might make the UI feel sluggish as a whole.
        hnedeotes 5y ago
        Yeah certainly, but I'm not sure people are using it that way? Most examples are to show cool stuff you can do, they're not production vetted. Like most JS examples out there don't really mean that people should be publishing live credentials with their bundles. I imagine in most cases one would leave everything that is not behind a logged in status as normal routes/pages (signin, landing, contacts, etc). Or if not that those would be things requiring a socket/real-time interface anyway. For the interactions, I don't think you even need to use alpine.js. Plain setup on DOMContentLoad, CSS Dropdowns/collapsibles that are replaced on JS load, proxying LiveView DOM/Morphdom events (if needed) so other components (even vue,react, etc) can listen to them, and CSS animations. import { setup_live } from "./phx/setup_live.js"; import { setup_dropdowns } from "./interactivity/dropdowns.js"; import { setup_collapsibles } from "./interactivity/collapsibles.js"; import { setup_links } from "./interactivity/links.js"; import { setup_inputs } from "./interactivity/inputs.js"; function setup() { setup_live(); setup_links(); setup_dropdowns(); setup_collapsibles(); setup_inputs(); } document.addEventListener("DOMContentLoaded", setup); I went as far as having `onclick` handles and global window functions. Complete heresy. Yes, it's not 100% JS free, but it's pretty much low overhead. Then LiveView is mostly for your admin dashboards and logged in users views, where it makes it pretty easy to do real-time feedback type of interactions/views and spa like navigation. Since you have proper auth and identification on the user, you can just log them off, rate-limit, block an account, and close their socket if needed.

Latency is the reason. Even in a turn based game it still feels really bad to make a move and have to wait for it to make its way through the round trip before seeing the result. In a game with strict ordering like Tic Tac Toe there is little reason not to show the chosen move immediately.

1_player 5y ago
Sure, that's why I meant most use cases. I mean, 100 ms between a click and a cross appearing on screen is not great user experience, but it's not even the worst. If you're writing a game, a little client side prediction is a good idea. But if you have a form with instant validation, or any old regular UI, that is not necessary at all. The only built in optimistic UI functionality on Live View is disabling a button when you press it and wait for the server to respond, to avoid double submissions.
- meheleventyone 5y ago
  > But if you have a form with instant validation, or any old regular UI, that is not necessary at all. Arguably because you're trusting the client and essentially the built or built-in behavior is therefore optimistic by default. Then hopefully validating on submission server-side.
keymone 5y ago
From the tech talks I vaguely recall, LiveView folks seem to disregard latency, which is where the entire model falls apart for me because the moment you need more control on the client over what to do when the server is not responding - you’re entirely out of luck. Though maybe I’m wrong and there has been some new developments to address this, I wasn’t following too closely.
- sfusato 5y ago
  On the contrary, LiveView documentation acknowledges this and suggests to handle such scenarios using client side tools: There are also use cases which are a bad fit for LiveView: Animations - animations, menus, and general UI events that do not need the server in the first place are a bad fit for LiveView. Those can be achieved without LiveView in multiple ways, such as with CSS and CSS transitions, using LiveView hooks, or even integrating with UI toolkits designed for this purpose, such as Bootstrap, Alpine.JS, and similar. https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html#module-use-cases https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html#m...
  - keymone 5y ago
    Sorry, that’s not acknowledging that latency can become an issue, that’s acknowledging that using server-side rendering for things that don’t require a server isn’t the best of ideas (shocker, I know).
    - hnedeotes 5y ago
      What exactly are you thinking in terms of latency becoming an issue under LiveView but not on normal requests? Do you mean when websites just need a full refresh because they lost their requests on some callback and no-one implemented recovery across the 5 levels of callbacks or something more specific?
      - arjan_sch 5y ago
        Well with Liveview you go "full server state" for everything that you would normally just use plain JS for. For instance, toggling a checkbox or collapsing a div. Having latency on such lowlevel interactions might make the UI feel sluggish as a whole.
        hnedeotes 5y ago
        Yeah certainly, but I'm not sure people are using it that way? Most examples are to show cool stuff you can do, they're not production vetted. Like most JS examples out there don't really mean that people should be publishing live credentials with their bundles. I imagine in most cases one would leave everything that is not behind a logged in status as normal routes/pages (signin, landing, contacts, etc). Or if not that those would be things requiring a socket/real-time interface anyway. For the interactions, I don't think you even need to use alpine.js. Plain setup on DOMContentLoad, CSS Dropdowns/collapsibles that are replaced on JS load, proxying LiveView DOM/Morphdom events (if needed) so other components (even vue,react, etc) can listen to them, and CSS animations. import { setup_live } from "./phx/setup_live.js"; import { setup_dropdowns } from "./interactivity/dropdowns.js"; import { setup_collapsibles } from "./interactivity/collapsibles.js"; import { setup_links } from "./interactivity/links.js"; import { setup_inputs } from "./interactivity/inputs.js"; function setup() { setup_live(); setup_links(); setup_dropdowns(); setup_collapsibles(); setup_inputs(); } document.addEventListener("DOMContentLoaded", setup); I went as far as having `onclick` handles and global window functions. Complete heresy. Yes, it's not 100% JS free, but it's pretty much low overhead. Then LiveView is mostly for your admin dashboards and logged in users views, where it makes it pretty easy to do real-time feedback type of interactions/views and spa like navigation. Since you have proper auth and identification on the user, you can just log them off, rate-limit, block an account, and close their socket if needed.