4 ms·

> Instead of managing the state of your app you’re now managing the state of your app and a connection to a remote server. Wouldn't an intermediate layer such

by shakow 6y ago

> Instead of managing the state of your app you’re now managing the state of your app and a connection to a remote server. Wouldn't an intermediate layer such as e.g. Phoenix/LiveView (https://www.phoenixframework.org/ https://www.phoenixframework.org/) solve the problem?

nickjj 6y ago
> Wouldn't an intermediate layer such as e.g. Phoenix/LiveView (https://www.phoenixframework.org/ https://www.phoenixframework.org/) solve the problem? I don't think so but if I'm wrong please correct me. For example, imagine this simple scenario: you load the comment page for this post on HackerNews HackerNews renders an HTTP response to your browser and your browser renders the page based on that HTTP payload. You can be sitting here on the page for 10 minutes reading comments and even if HackerNews randomly went down 20 times for 10 seconds each time during those 10 minutes you would never know because your browser has everything it needed to render the page when it loaded. It's a done deal. The request was made and the response was served. But now let's say you use LiveView and you made this page an actual Live View. Let's also say you load all of the comments at once to keep the example the same. Since there's a persistent websocket connection open at all times, in all 20 cases of HackerNews going down you're going to get a visual warning that the websocket connection was dropped. You also don't want to disable this visual warning because on slower devices it might take 2 seconds to load the page which is much different than an uncontrolled disconnect. IMO this user experience is pretty bad. Why should users be concerned with the server's state after it has everything it needed to handle the request it asked for (loading the comment page). If they try to post a comment and the server is down then the user should see that error at the time of them making the comment (such as a custom 502 error page if the back-end is down). The grandfather's comment of "it wasn't designed this way by accident" is spot on. The stateless web is a happy web. Sure you can sprinkle in websockets for progressive enhancements like broadcasting new content somewhere (which is awesome when done well), but websockets shouldn't be the basis for everything. HTTP has decades of very careful thought and optimizations around its protocol.
- lostcolony 6y ago
  If the connectivity state doesn't matter to the user, why would you show it?
  - TheRealPomax 6y ago
    This. No reason to say "the server's gone!" when your user's not doing anything in which that matters. Do notify them _before_ trying to execute on a task that requires the server to be up, but that's not the case that was getting described.
  - nickjj 6y ago
    > If the connectivity state doesn't matter to the user, why would you show it? It's due to Live View triggering a visual indicator that the websocket connection isn't available. It's a combination of CSS and JS. You can turn this off but if you turn it off then you have no way to show an indicator when you do care (such as transitioning between pages or submitting a form). I don't think LV at the client level can be coded in such a way that it can tell the difference between the server dropping and the user's connection dropping due to their internet being spotty.
    - lostcolony 6y ago
      So just to your last point, no one can tell the difference between "you, the client, can no longer reach this particular server" and "this server no longer is up". You might be able to tell that it's the user's connection, rather than a netsplit somewhere, with some reasonable degree of confidence (ping the ISP, ping google, etc), but that's a lot of work, still just a percentage chance of being correct, for no real benefit. To the rest...that's the point, it's just...CSS and JS. You can change it. You can show it or not, based on what the user is doing, or what view they have. Worst case, you can just hide it completely across everything, as you say, which is then no different from an SPA, except where functionality fails when you have no connectivity. Whether that leads to a better or worse user experience is dependent on the dev's handling of those failures.
- shakow 6y ago

by shakow 6y ago

nickjj 6y ago

> Wouldn't an intermediate layer such as e.g. Phoenix/LiveView (https://www.phoenixframework.org/ https://www.phoenixframework.org/) solve the problem? I don't think so but if I'm wrong please correct me. For example, imagine this simple scenario: you load the comment page for this post on HackerNews HackerNews renders an HTTP response to your browser and your browser renders the page based on that HTTP payload. You can be sitting here on the page for 10 minutes reading comments and even if HackerNews randomly went down 20 times for 10 seconds each time during those 10 minutes you would never know because your browser has everything it needed to render the page when it loaded. It's a done deal. The request was made and the response was served. But now let's say you use LiveView and you made this page an actual Live View. Let's also say you load all of the comments at once to keep the example the same. Since there's a persistent websocket connection open at all times, in all 20 cases of HackerNews going down you're going to get a visual warning that the websocket connection was dropped. You also don't want to disable this visual warning because on slower devices it might take 2 seconds to load the page which is much different than an uncontrolled disconnect. IMO this user experience is pretty bad. Why should users be concerned with the server's state after it has everything it needed to handle the request it asked for (loading the comment page). If they try to post a comment and the server is down then the user should see that error at the time of them making the comment (such as a custom 502 error page if the back-end is down). The grandfather's comment of "it wasn't designed this way by accident" is spot on. The stateless web is a happy web. Sure you can sprinkle in websockets for progressive enhancements like broadcasting new content somewhere (which is awesome when done well), but websockets shouldn't be the basis for everything. HTTP has decades of very careful thought and optimizations around its protocol.

lostcolony 6y ago
If the connectivity state doesn't matter to the user, why would you show it?
- TheRealPomax 6y ago
  This. No reason to say "the server's gone!" when your user's not doing anything in which that matters. Do notify them _before_ trying to execute on a task that requires the server to be up, but that's not the case that was getting described.
- nickjj 6y ago
  > If the connectivity state doesn't matter to the user, why would you show it? It's due to Live View triggering a visual indicator that the websocket connection isn't available. It's a combination of CSS and JS. You can turn this off but if you turn it off then you have no way to show an indicator when you do care (such as transitioning between pages or submitting a form). I don't think LV at the client level can be coded in such a way that it can tell the difference between the server dropping and the user's connection dropping due to their internet being spotty.
  - lostcolony 6y ago
    So just to your last point, no one can tell the difference between "you, the client, can no longer reach this particular server" and "this server no longer is up". You might be able to tell that it's the user's connection, rather than a netsplit somewhere, with some reasonable degree of confidence (ping the ISP, ping google, etc), but that's a lot of work, still just a percentage chance of being correct, for no real benefit. To the rest...that's the point, it's just...CSS and JS. You can change it. You can show it or not, based on what the user is doing, or what view they have. Worst case, you can just hide it completely across everything, as you say, which is then no different from an SPA, except where functionality fails when you have no connectivity. Whether that leads to a better or worse user experience is dependent on the dev's handling of those failures.
shakow 6y ago