Comment by axegon_

12 days ago

> Updates that users would not expect to see on a refresh (or a new page load)

I always hated this idea. As a user, a refresh indicates that something is happening and it's abundantly clear when something is wrong. People don't always handle errors and in all fairness they shouldn't - a developer has no way of knowing what custom stuff I have on my browser, whether I'm using any blockers or pi-holes or whatever and they should not know. Simple navigation, refreshes and server side rendering is something which worked great, the web was fast and could run on anything with a graphical output. These days a single page eats up 150+ mb while it loads. All that so the page doesn't "refresh".

8 comments

axegon_

Reply
sgt  12 days ago

It's not that smooth looking if a refresh takes 500 milliseconds. Then it flickers.

  • foobahify  12 days ago

    500ms means a slow connection, high latency or significant bloat.

    Optimising the page and using a CDN can help alot.

    It is a shame HTML doesn't have rel="swap" in links to "swap" in a new page.

  • axegon_  12 days ago

    Oh yeah a 15 second spinning circle and 250mb memory is sooooo much better than a 500ms refresh </sarcasm>

    • earthnail  12 days ago

      A 2s spinning circle may indeed be better than a 500ms flashing reload. Try it on your mom (“waaah why did it flash??”).

      I also dislike SPAs but there is business value in this slow spinner that you shouldn’t discount.

      Luckily, turbo or htmx solve this just as well. And maybe even more importantly, I can’t think of a modern browser that still flickers.

friendzis  12 days ago

> a developer has no way of knowing what custom stuff I have on my browser, whether I'm using any blockers or pi-holes or whatever

That's a feature.

> and they should not know.

Yes, a fetch failing, DOM being updated is standard web behavior, interns handle that.