I like React. And I have seriously tried the HTMX/Hotwire camp.

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. My logic was spread out over 3 files!

With React I can have js in a component determine if the previous page was inbox, and based on that value show the back button JSX or the link. ALL IN ONE FILE. One conceptually entity for me to model vs 3 that do other things and this functionally is hammered in.

Is it slower? Definitely. But it makes me happy. Miserable in a corporate React slopbase? Blame your coworkers, it would definitely be worse without it.

▲

petcat 8 hours ago | parent | next [-]

> 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.)

▲

kcrwfrd_ 4 hours ago | parent | next [-]

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…

▲

zarzavat 3 hours ago | parent [-]

`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.

	▲	pibaker 2 hours ago \| parent \| next [-]
		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.
	▲	kcrwfrd_ 3 hours ago \| parent \| prev [-]
		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.

▲

jeroenhd 4 hours ago | parent | prev | next [-]

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

▲

imperio59 8 hours ago | parent | prev | next [-]

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.

▲

Zanfa 7 hours ago | parent | next [-]

> 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.

▲

charcircuit 7 hours ago | parent [-]

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

	▲	Zanfa 6 hours ago \| parent [-]
		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.

▲

3eb7988a1663 7 hours ago | parent | prev [-]

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.

▲

anon7000 3 hours ago | parent | prev [-]

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.

▲

yxhuvud 35 minutes ago | parent | prev | next [-]

Isn't the best way to solve the back button question to not be so damned complicated and just make certain that only things which you want to go back to ends up in the history? The whole framing of the problem just screams "structure your thing better and it won't be a problem to solve".

▲

evolve-maz 7 hours ago | parent | prev | next [-]

My advice would be to only use HTMX for data state related operations. For something like an intelligent back button, unless it depends on resource state do not use the backend to calculate it.

The recommended htmx way would be to hook up an onclick button to inline js or if you dislike that, a function called goBackOrInbox. It can then be something like:

function goBackOrInbox() { if (document.referrer) { const path = new URL(document.referrer).pathname; if (path.startsWith('/inbox')) { history.back(); return; } } window.location.href = '/inbox'; }

And if you use that pattern a lot then you can parameterise the function with whatever the route should be.

▲

altbdoor 8 hours ago | parent | prev [-]

I know there will probably be some complications here and there, but this could be done with Web Components too, right?

	▲	kcrwfrd_ 3 hours ago \| parent \| next [-]
		Yes you could, or even just a vanilla DOM event handler on a button click. The problem is that you cannot introspect the browser’s history with the history API. So you have to hack your way around that if you want the “go back in history if possible, otherwise navigate to fallback url” behavior. Which I guess is easier if you’re in a react SPA. Or if you’re fully a MPA and can just check document.referrer There’s a brand new Navigation API that does let you introspect history entries from the same origin, which perfectly addresses the issue. I wrote a polyfill in order to take advantage of the navigation API for this exact problem: https://github.com/kcrwfrd/navigation-ponyfill
	▲	jimbob45 6 hours ago \| parent \| prev [-]
		Came to ask this myself. Oddly enough, I think they’ve kind of slipped under everyone’s radar.