4 ms·
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
by ricketycricket 6y ago
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.
- morelisp 6y ago> 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.
- nickjj 6y ago> 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.