Comment by hnlmorg
3 days 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.
As a user, I really don't care about the supposed purity or correctness of a website's tech stack. When I click "back" I want to go back to what I think the previous page was.
As a user, I don’t really care about the building materials used in construction. But that doesn’t mean builders should cut corners.
A building collapse and a poorly built website UI are completely different in terms of actual risk.
1 reply →
Could you provide some examples of the hacks you're referring to?
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.
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.
6 replies →
If you don't manage the history properly in your SPA, pressing the back button could take the user out of the app entirely.
If you don't let web developers manage history/state like this, we'd be going back to the inefficient world of, "every forward/back movement loads a whole page." (With lots of unnecessary round trip messages between the client and server while the user waits for everything to load).
Basically, the ability to manage history is a user-centric feature. It makes the experience better for them.
> If you don't manage the history properly in your SPA, pressing the back button could take the user out of the app entirely.
Yes. And that should be the default behavior: browser buttons should take you through the browser's history. If you keep a in-app state and want the user to navigate through it, you should provide in-app buttons.
Nobody complains that the browser's close button quits the browser instead of the app it's showing, or that the computer's power button shuts down the whole OS and not only the program in the foreground.
Users must be educated. If they have learned that left means "back" and right means "forward", that a star (sometimes a heart) means "remember this for me", and that an underlined checkmark means "download", then understanding the concept of encapsulation shouldn't be too much for them.
2 replies →