Hacker News Reader

Comment by petcat | Hacker News Reader

> I wanted to make a back button use browser APIs to go back if the coming from the inbox, just link to the inbox otherwise to preserve scrolling. I had to wire the actions from the html to call the function that goes back, then in my controller determine the previous page and send the JS enabled back button or the hard link.

This is why I hate react spas. They're always trying to find some stupid way to break my browsers back button and navigation buttons.

I will always prefer htmx/server rendering with native everything (except the occasional form boosting.)

View on HN

They are actually speaking to trying to make an in-app back button use the history stack so that it _doesn’t_ “break” your browser’s back button.

The problem with just calling history.back() with no fallback is it will bounce users out of your app (back to Google or wherever they came from) and PMs won’t like that…

`history.back()` shouldn't even exist, it's almost never correct to use it instead of a logical back button that works on the logical navigation structure e.g. going up a level, or to the previous page, etc.

For example, if you are on Page 5, then pressing "back" inside the app should always take you to Page 4. `history.back()` could take you to any page, it's unpredictable.

It’s really common that you can arrive on a view from different places.

For example on instagram you might click through to a post from the explore page or from someone sending it to you via DM. In either case pressing the back button rendered in the app, or swiping back, will take you back to where you came from. It feels natural and seamless. Although I guess there are other ways to skin that cat than history.back()

But I agree with you when there’s a clear hierarchy. Like on a job ad a “back” button should just be a normal link to the index of job openings.

Disagreed. In everyday speech "going back" means going to where you came from. If I'm at a friend's place at 123 Main Street and I tell him I'm going back, what I'm saying is I'm heading back to my home, not to 122 Main Street. The web should work similarly.

And the idea of logical navigation is flawed because most websites don't have a well defined logical structure, nor is it feasible to have one. What is the previous page of a Wikipedia article, or an HN submission, or an Amazon listing, or a search result of cheapest direct flights between New York and Cancun? With how the back button currently works, at least there is consistency in what to expect when clicking it. Under your suggestion, there is no way a user knows what the back button does on each website unless he clicks on it first and find out himself.

I'm not talking about the back button. I'm talking about history.back() API. If you have a "back" button that is inside the page's viewport, it should work based on the page's logical model. So you go back from Page 5 to Page 4, regardless of where you were before. Only back buttons outside the viewport should work based on browser history. The history is part of the browser it's not part of the page.

That's not a react thing, it happened before React was even a thing. It's just self-centered website programmer design.

This has been a non issue when using proper routing libraries that push history entries on the stack properly and render routes from the top of the component tree down.

You hate BAD react SPAs that break the fundamentals of how the web works. Good ones take care to not do that.

React fundamentally doesn't cause this issue either. You can use a different framework than react or even vanilla JS and still produce the same bugs.

Sure, but the internet is majority bad SPAs vs good ones. Rarely am I delighted by a SPA, but suffer through how poorly it works in bad network conditions, usable back buttons, or otherwise respecting the user.

> You hate BAD react SPAs that break the fundamentals of how the web works.

But that’s all of them? If Github, Reddit, LinkedIn and Facebook and others are unable to build SPAs that don’t constantly break the fundamentals while also choking the browser, maybe it is a tech problem.

If the APIs are too hard to use properly that no site can use it right, then it's a browser issue.

It’s not that. The sort of issues all of the above have caused are fundamental, eg not using anchor tags for navigation. It’s not in any way easier to use a button or div with an onclick handler. It’s also not easier to serve megabytes of JS to render 5kb of comments.

It’s an absolutely not true that react is especially bad for this behavior.

I think that lots of more traditional websites have very poor back button designs, especially around editing and form submissions. Remember clicking back and the browser prompting for form resubmission? Very poor design since you have no clue how the server will even handle form submissions. Or getting stuck deep in an application, hard to get back to the root. Or, consider encoding current page data that you’re editing into the URL, and back buttons don’t return to root and just strip query params. Often a very frustrating experience.

Often, “go back to what I was doing before” is what I actually want, not “go strictly to the previous state in the URL bar.”

Sure, plenty of people mess that up too, but the reality is that controlling the navigation stack can help you build more useful designs.

Reply on news.ycombinator.com