4 ms·

> I make sure that as much state as possible is saved in a URL, sometimes (though rarely) down to the scroll position. If your page is server-rendered, you get

> I make sure that as much state as possible is saved in a URL, sometimes (though rarely) down to the scroll position. If your page is server-rendered, you get saved scroll position on refresh for free. One of many ways using JS for everything can subtly break things.

divan 1y ago
Also reminder that "refresh" is just a code word for "restart (and often redownload) the whole bloody app". It's funny how in web-world people so used to "refreshing" the apps and assume that it's a normal functionality (and not failure mode).
- nextaccountic 1y ago
  The web is similar to android, and unlike desktop apps, in that restarting the whole thing is meant to not lose (much) state Actually it would be amazing if desktop applications were like this too, and we had a separate way to go back to the initial screen
  - divan 1y ago
    Restoring state is just one of the features, that can be implemented in any app if needed, with all that baggage that comes with a feature – testing, maintaining, etc. It's just if desktop app becomes so broken/unresponsive, that the only way is to restart it – we consider it a bad experience and bad software. On web "restarting the app" is a normal daily activity when something goes wrong with state/layout/fields/forms, etc.
    - nextaccountic 1y ago
      Most desktops apps are buggy enough to occasionally require restarts or even crash. I don't currently use any program that never crashed on me. On the web "restarting the app" is seamless and not imply anything wrong happened. It's like the Erlang approach to errors, but on steroids The trouble with leaving restoring state to the application do as they wish is that most of times they will get it wrong. Also most of them don't do any of this and will never do. Good defaults matter
      - divan 1y ago
        My experience has been different – and increasingly so over the past 30 years. Crashing or leaking desktop apps are a rare experience nowadays. When it happens, it’s always an "oh, really?" moment. On the web… I often can’t even write a Facebook comment without refreshing the page. Good defaults definitely matter. But not overloading an app with functionality matters as well. Matching feature sets to actual user needs also matters. The problem with state restoration is that it’s one of those features that looks simple, yet can be extremely tricky to implement correctly – the point you already made. And there’s no single solution that will fit all cases, or even 80% of them. Restoring scroll position is one thing, but restoring an unfinished video editor timeline is another. Both look deceptively simple ("I just reopened the crashed app and it opened at the exact same state"), but the internal mechanics require wildly different mechanisms and trade-offs. I do agree, however, that frameworks and SDKs should provide properly designed mechanisms for state restoration – and they often do (like the State Restoration API on iOS/macOS). But the argument that "state restoration should be default and provided by the environment" feels like post-rationalization of the existing mechanics. > It’s like the Erlang approach to errors, but on steroids The Erlang approach was intentionally designed that way. Web apps’ normalization of "restarting" is just a testament to how normal buggy software has become in the web ecosystem. Anyone who has ever tried to buy tickets online or register through a simple form on a government website knows that even for such common use cases, it’s extremely hard to create a good user experience. There are some fantastic web apps nowadays, and government-backed design systems and frameworks that sometimes match native apps’ experience – but that only proves the point. It takes an enormous amount of effort to make even simple things work reliably on the web stack. The core reason, of course, is that the "web stack" is a typesetting engine from the ’80s that was never designed for modern UI apps’ needs in the first place. Why we still use a markup language to build sophisticated UIs and think it’s fine is beyond me. I recently saw an experiment where someone played a video in Excel, using spreadsheet cells as pixels and a lot of harness code to make it work as an output device. It’s doable, but Excel was never designed for that. No matter how many layers of abstraction we put on top – or how many ExcelReact frameworks we create – the foundation is simply not right for the task. And yet people continue to justify the “defaults” of the web stack as if they were deliberate design choices rather than byproducts. Like, "it’s so good that everything is zoomable," or "I like that everything is selectable". Which sounds fine – until it doesn’t. Why on earth would I need to select half my widget tree with a 3-pixel mouse shift? And when I really do need to select something, it often doesn’t work properly because developers take it for granted and never verify or test it. Or zooming – whenever I zoom a Facebook page to write a comment, the view keeps jumping around because some amazing piece of JS crapcode decides to realign the interface on a timer (to show ads?). Nobody on Facebook’s QA team probably even tests how the comment section works when zoomed in Safari. The web app experience is simply one of the worst, due to this messy feature set people call "good defaults". And as someone who also has to write web apps from time to time, I can’t stress enough how disproportionately more effort it takes to make an app with sane, good default behavior. (P.S. There are some good things in the current state of the web stack – but they’re mostly the product of the industry’s sheer size, not the stack itself.)
endless1234 1y ago
Still leaves the problem of not being able to simply send the current URL to someone else and know they'll see the same thing. Of course anchors can solve this, but not automatically
- pests 1y ago
  Chrome (at least?) solves this via Text Fragments[0] which are a pure client side thing and requires no server or site support. This URI for example: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/a#:~:text=downgrade:-,The%20Referer,be%20sent,-to%20origins https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... Links to an instance of "The Referer" narrowed down via a start prefix ("downgrade:") and end suffix ("to origins"). These are used across Google I believe so many have probably seen them. [0] https://developer.mozilla.org/en-US/docs/Web/URI/Reference/Fragment/Text_fragments https://developer.mozilla.org/en-US/docs/Web/URI/Reference/F...
- MrJohz 1y ago
  You probably don't want that most of the time, though. The time I'm most likely to send someone an article is once I've got to the end of it, but I don't want them to jump to the end of the article, I want them to start at the beginning again. There are situations where you want to link to a specific part of a page, and for that anchors and text anchors work well. But in my experience it isn't the default behaviour that I want for most pages.
- IanCal 1y ago
  Scroll position doesn’t do this because it’s not portable between devices.
o11c 1y ago
Even with JS, if it is classical synchronous JS it is much better than the modern blind push for async JS, which causes the browser to try to restore the position before the JS has actually created the content.
- nextaccountic 1y ago
  isn't there a way to instruct the browser to restore the position only after certain async thing?
  - kuekacang 1y ago
    I think the hack is to store html height/width locally and restore it as early as possible so the content will then load under the scrolled view
fithisux 1y ago
True

divan 1y ago

Also reminder that "refresh" is just a code word for "restart (and often redownload) the whole bloody app". It's funny how in web-world people so used to "refreshing" the apps and assume that it's a normal functionality (and not failure mode).

nextaccountic 1y ago
The web is similar to android, and unlike desktop apps, in that restarting the whole thing is meant to not lose (much) state Actually it would be amazing if desktop applications were like this too, and we had a separate way to go back to the initial screen
- divan 1y ago
  Restoring state is just one of the features, that can be implemented in any app if needed, with all that baggage that comes with a feature – testing, maintaining, etc. It's just if desktop app becomes so broken/unresponsive, that the only way is to restart it – we consider it a bad experience and bad software. On web "restarting the app" is a normal daily activity when something goes wrong with state/layout/fields/forms, etc.
  - nextaccountic 1y ago
    Most desktops apps are buggy enough to occasionally require restarts or even crash. I don't currently use any program that never crashed on me. On the web "restarting the app" is seamless and not imply anything wrong happened. It's like the Erlang approach to errors, but on steroids The trouble with leaving restoring state to the application do as they wish is that most of times they will get it wrong. Also most of them don't do any of this and will never do. Good defaults matter
    - divan 1y ago
      My experience has been different – and increasingly so over the past 30 years. Crashing or leaking desktop apps are a rare experience nowadays. When it happens, it’s always an "oh, really?" moment. On the web… I often can’t even write a Facebook comment without refreshing the page. Good defaults definitely matter. But not overloading an app with functionality matters as well. Matching feature sets to actual user needs also matters. The problem with state restoration is that it’s one of those features that looks simple, yet can be extremely tricky to implement correctly – the point you already made. And there’s no single solution that will fit all cases, or even 80% of them. Restoring scroll position is one thing, but restoring an unfinished video editor timeline is another. Both look deceptively simple ("I just reopened the crashed app and it opened at the exact same state"), but the internal mechanics require wildly different mechanisms and trade-offs. I do agree, however, that frameworks and SDKs should provide properly designed mechanisms for state restoration – and they often do (like the State Restoration API on iOS/macOS). But the argument that "state restoration should be default and provided by the environment" feels like post-rationalization of the existing mechanics. > It’s like the Erlang approach to errors, but on steroids The Erlang approach was intentionally designed that way. Web apps’ normalization of "restarting" is just a testament to how normal buggy software has become in the web ecosystem. Anyone who has ever tried to buy tickets online or register through a simple form on a government website knows that even for such common use cases, it’s extremely hard to create a good user experience. There are some fantastic web apps nowadays, and government-backed design systems and frameworks that sometimes match native apps’ experience – but that only proves the point. It takes an enormous amount of effort to make even simple things work reliably on the web stack. The core reason, of course, is that the "web stack" is a typesetting engine from the ’80s that was never designed for modern UI apps’ needs in the first place. Why we still use a markup language to build sophisticated UIs and think it’s fine is beyond me. I recently saw an experiment where someone played a video in Excel, using spreadsheet cells as pixels and a lot of harness code to make it work as an output device. It’s doable, but Excel was never designed for that. No matter how many layers of abstraction we put on top – or how many ExcelReact frameworks we create – the foundation is simply not right for the task. And yet people continue to justify the “defaults” of the web stack as if they were deliberate design choices rather than byproducts. Like, "it’s so good that everything is zoomable," or "I like that everything is selectable". Which sounds fine – until it doesn’t. Why on earth would I need to select half my widget tree with a 3-pixel mouse shift? And when I really do need to select something, it often doesn’t work properly because developers take it for granted and never verify or test it. Or zooming – whenever I zoom a Facebook page to write a comment, the view keeps jumping around because some amazing piece of JS crapcode decides to realign the interface on a timer (to show ads?). Nobody on Facebook’s QA team probably even tests how the comment section works when zoomed in Safari. The web app experience is simply one of the worst, due to this messy feature set people call "good defaults". And as someone who also has to write web apps from time to time, I can’t stress enough how disproportionately more effort it takes to make an app with sane, good default behavior. (P.S. There are some good things in the current state of the web stack – but they’re mostly the product of the industry’s sheer size, not the stack itself.)

endless1234 1y ago

Still leaves the problem of not being able to simply send the current URL to someone else and know they'll see the same thing. Of course anchors can solve this, but not automatically

pests 1y ago
Chrome (at least?) solves this via Text Fragments[0] which are a pure client side thing and requires no server or site support. This URI for example: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/a#:~:text=downgrade:-,The%20Referer,be%20sent,-to%20origins https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... Links to an instance of "The Referer" narrowed down via a start prefix ("downgrade:") and end suffix ("to origins"). These are used across Google I believe so many have probably seen them. [0] https://developer.mozilla.org/en-US/docs/Web/URI/Reference/Fragment/Text_fragments https://developer.mozilla.org/en-US/docs/Web/URI/Reference/F...
MrJohz 1y ago
You probably don't want that most of the time, though. The time I'm most likely to send someone an article is once I've got to the end of it, but I don't want them to jump to the end of the article, I want them to start at the beginning again. There are situations where you want to link to a specific part of a page, and for that anchors and text anchors work well. But in my experience it isn't the default behaviour that I want for most pages.
IanCal 1y ago
Scroll position doesn’t do this because it’s not portable between devices.

o11c 1y ago

Even with JS, if it is classical synchronous JS it is much better than the modern blind push for async JS, which causes the browser to try to restore the position before the JS has actually created the content.

nextaccountic 1y ago
isn't there a way to instruct the browser to restore the position only after certain async thing?
- kuekacang 1y ago
  I think the hack is to store html height/width locally and restore it as early as possible so the content will then load under the scrolled view

fithisux 1y ago

True