Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Good advice, but

> - users of assistive technology would be unaware of changes in context, for example when moving to a new page

> - it would fail to handle focus when moving between pages

> - the user would be unable to navigate using the back or forward buttons in their browser

> - users would be unable to recover from an error, for example if there is an interruption to their network connection

These aren’t strictly true, are they? You can achieve these things in an SPA, even if many (most?) don’t bother



You kind of get it out of the box with plain old HTML though. Once you get into SPA territory you’re reinventing a lot of wheels to get back to parity, or replacing native functionality with JS alternatives.

Consider multi-page forms: how many SPAs just store all of that in memory and then make one request at the end? Without JS, the BE would be saving the state for each step so you could come back to the form later or refresh without losing anything.


You can easily store intermediate state in sessionStorage or localStorage and prevent all the unneeded requests to the server just for moving between steps.


Yes, hence why it’s good advice.


> These aren’t strictly true, are they? You can achieve these things in an SPA, even if many (most?) don’t bother

Yes you can, but then it is way more difficult, and the fact that most don't even bother means that it is not exactly trivial to implement. Why to force that garbage when basic HTML basic web sites work just fine out of the box.


I think that section could be more clear if something like "without more effort" was added.


How could you possibly make them true, if you are told to respect even deliberately disabled features? If the user does not permit retroactively messing with their navigation history, then you are left with only one option: get the history right, at the time it is written.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: