Comment by nickjj | Hacker News Reader

Comment by nickjj | Hacker News Reader

Parent Full thread

> Wouldn't an intermediate layer such as e.g. Phoenix/LiveView (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.

The sensible response to that scenario would be: Why did you make HN a Live View? I don't think anyone is suggesting that you make anything a Live View that is more appropriate as plain HTML. If you wouldn't use React, you shouldn't use Live View.

I understand you needed an example, but a better comparison would be a heavy SPA with real-time interactivity. In that case, if your server is down your API calls will fail and you're going to have to handle the failure and let the user know something went wrong any way. If anything, Live View's built-in buffer and retry can actually provide a better user experience because the UI will automatically "catch up" when the client reconnects.

> 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.

Live View loads the entire initial page over HTTP, then mounts the Live View. Your slow device won't see any difference if the visual warning is disabled or not.

> If you wouldn't use React, you shouldn't use Live View.

I have bad news for you about how often most web developers are using React.

> The sensible response to that scenario would be: Why did you make HN a Live View? I don't think anyone is suggesting that you make anything a Live View that is more appropriate as plain HTML.

It's because the creator of Live View himself said he's not going to be using "dead views" anymore for sites that don't need offline capabilities or are clear cases where LV would fall apart. He's advocating for everyone to use LV instead of regular views even to serve HTML for most sites.

I can see the appeal too, Turbolinks did a great thing a few years ago by improving page load speeds by turning regular HTTP requests into ajax calls behind the scenes and then swapping the <body> of the page, all without having to write a single line of code beyond importing the JS library and without having to change anything on the back-end.

With LV's live_redirect you can get a similar effect. It's a much different implementation (way more changes are needed on the back-end) but the end result is similar'ish.

And if you had a site that benefits from speedy page transitions (aka pretty much every site) and you happen to have a few cases where using LV makes sense such as wanting to do real time validations or show a stream of something then it would make sense to want to go all-in and use LV to serve every page so that you don't need to bring in both Turbolinks and LV as dependencies and still benefit by having fast page transitions across your site.

If the connectivity state doesn't matter to the user, why would you show it?

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.

> 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.

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.

> 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.

You can restrict the visual warning to the first load only, it would be pretty distracting otherwise.

> You can restrict the visual warning to the first load only, it would be pretty distracting otherwise.

How would this work in practice while still showing it when you want it to be shown?

If your server is done 20 times in 10 min, replace your incompetent eng, ops, service provider.

A feature that protects from ridiculously unlikely problem is no feature. It is over engineering

> If your server is done 20 times in 10 min, replace your incompetent eng, ops, service provider.

You could have incompetent engineers or you could have bad internet. The user could be on a train that is going in and out of tunnels. Or the user could be in a house using WiFi and the microwave could be causing interference.

"Replace the user". ;)

Reply on news.ycombinator.com