4 ms·

Nothing loaded from the web should be able to fiddle with any browser behavior, yet here we are.

optionalsquid 6mo ago
It should be opt-in per website, per feature, because IMO it can be quite useful in some cases. Like clicking back on a slide-show bringing you to the overview page, instead of only going back one slide
- arcfour 6mo ago
  Opt in features are a great way to increase user frustration and confusion. See the whole new geolocation API they had to make for browsers since people would perma-deny it reflexively and then complain that geolocation features weren't working.
  - optionalsquid 6mo ago
    That's a good point, though I'm not familiar with the (changes to the) geolocation API you mention. Do you have any recommendations for reading up on that development?
    - arcfour 6mo ago
      Sure, I should have said geolocation element, since the original API still exists and is used: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/geolocation https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
- lxgr 6mo ago
  > clicking back on a slide-show bringing you to the overview page That behavior is expected in exactly one case (assuming slides, not the whole presentation, are modeled as a page each): If I navigated to that specific slide from the overview. In any other scenario, this behavior amounts to breaking my back button, and I'll probably never visit the site again if I have that choice.
least 6mo ago
The History API is pretty useful. It creates a lot of UX improvement opportunities when you're not polluting the stack with unnecessary state changes. It's also a great way to store state so that a user may bookmark or link something directly. It's straight up necessary for SPAs to behave how they should behave, where navigating back takes you back to the previous page. This feels like a reasonable counter-measure.
- hnlmorg 6mo ago
  Yeah but all of this is a symptom of a broader problem rather than reasons why the history API is useful. SPAs, for example, require so many hacks to work correctly that I often wonder to myself if they’re not really just a colossal mistake that the industry is too blinded to accept.
  - boomskats 6mo ago
    Could you provide some examples of the hacks you're referring to?
    - TeMPOraL 6mo ago
      State management, URL fragment management, reimplementing basic controls... One that I hate the most is that they first reimplement tabular display with a soup of divs, then because this is slow as a dog, they implement virtualized display, which means they now need to reimplement scrolling, and because this obviously breaks CTRL+F, they end up piling endless hacks to fix that - assuming they bother at all. The result is a page that struggles to display 100 rows of data. Contrast that with regular HTML, where you can shove 10 000 rows into a table, fully styled, without noticeable performance drop. A "classical" webpage can show couple megabytes worth of data and still be faster and more responsive than typical SPA.
      - boomskats 6mo ago
        Sounds like you're referring to some specific examples of poorly implemented apps rather than the concept of SPAs as a whole. For your example, the point of that div soup is that enables behaviours like row/column drag&drop reordering, inline data editing, realtime data syncing and streaming updates, etc. - there is no way to implement that kind of user experience with just html tables. There's also huge benefit to being able to depend on clientside state. Especially if you want your apps to scale while keeping infra costs minimal. I get the frustrations you're talking about, but almost all of them are side effects of solutions to very real UX problems that couldn't be solved in any other way. And to be clear, I'm not saying that people building SPAs when all they needed was a page showing 10,000 rows of static data isn't a problem. It's just a people problem, not an SPA problem.

It should be opt-in per website, per feature, because IMO it can be quite useful in some cases. Like clicking back on a slide-show bringing you to the overview page, instead of only going back one slide

arcfour 6mo ago
Opt in features are a great way to increase user frustration and confusion. See the whole new geolocation API they had to make for browsers since people would perma-deny it reflexively and then complain that geolocation features weren't working.
- optionalsquid 6mo ago
  That's a good point, though I'm not familiar with the (changes to the) geolocation API you mention. Do you have any recommendations for reading up on that development?
  - arcfour 6mo ago
    Sure, I should have said geolocation element, since the original API still exists and is used: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/geolocation https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
lxgr 6mo ago
> clicking back on a slide-show bringing you to the overview page That behavior is expected in exactly one case (assuming slides, not the whole presentation, are modeled as a page each): If I navigated to that specific slide from the overview. In any other scenario, this behavior amounts to breaking my back button, and I'll probably never visit the site again if I have that choice.

least 6mo ago

The History API is pretty useful. It creates a lot of UX improvement opportunities when you're not polluting the stack with unnecessary state changes. It's also a great way to store state so that a user may bookmark or link something directly. It's straight up necessary for SPAs to behave how they should behave, where navigating back takes you back to the previous page. This feels like a reasonable counter-measure.

hnlmorg 6mo ago
Yeah but all of this is a symptom of a broader problem rather than reasons why the history API is useful. SPAs, for example, require so many hacks to work correctly that I often wonder to myself if they’re not really just a colossal mistake that the industry is too blinded to accept.
- boomskats 6mo ago
  Could you provide some examples of the hacks you're referring to?
  - TeMPOraL 6mo ago
    State management, URL fragment management, reimplementing basic controls... One that I hate the most is that they first reimplement tabular display with a soup of divs, then because this is slow as a dog, they implement virtualized display, which means they now need to reimplement scrolling, and because this obviously breaks CTRL+F, they end up piling endless hacks to fix that - assuming they bother at all. The result is a page that struggles to display 100 rows of data. Contrast that with regular HTML, where you can shove 10 000 rows into a table, fully styled, without noticeable performance drop. A "classical" webpage can show couple megabytes worth of data and still be faster and more responsive than typical SPA.
    - boomskats 6mo ago
      Sounds like you're referring to some specific examples of poorly implemented apps rather than the concept of SPAs as a whole. For your example, the point of that div soup is that enables behaviours like row/column drag&drop reordering, inline data editing, realtime data syncing and streaming updates, etc. - there is no way to implement that kind of user experience with just html tables. There's also huge benefit to being able to depend on clientside state. Especially if you want your apps to scale while keeping infra costs minimal. I get the frustrations you're talking about, but almost all of them are side effects of solutions to very real UX problems that couldn't be solved in any other way. And to be clear, I'm not saying that people building SPAs when all they needed was a page showing 10,000 rows of static data isn't a problem. It's just a people problem, not an SPA problem.