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.
> 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.)
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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".
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.
If you wake up every day feeling like you got hit by a train and also have anxiety, depression, chronic heartburn, or exhaustion (not sleepiness, like a wired but tired) I would highly recommend looking into Upper Airway Respiratory Syndrome (UARS).
UARS was coined by Dr. Christian Guilleminault who was on the team that coined sleep apnea. Over his career he slowly widened his definition of sleep disordered breathing from choking (sleep apnea) to any nasal resistance that causes wake ups.
You be young and perfectly healthy but due to bad anatomy have micro arousals throughout the night. Becuase your young, your body fights through it (cuasing exhuastion) and will wake up up to readjust your airway. You won't remeber any of the wakeups, but many suffer from insomnia from it. The two big issues is large tongue in underdeveloped jaw that falls back and constricts your airway (you can test this with a mallamapati test) or a small nasal passage way.
I don't know enough to disprove Matt, but I don't know why anyone should listen to him. There are far smarter people who have come up with similar conclusions.
Well, I did read it, I did listen to him. Assuming he isn't lying about his anecdotal evidence, he did a very good job opening my eyes to just how fast the AI models are moving and how the disruption can and likely will hit the public before they realize it.
The author can't fork Rails because "the amount of work that goes into maintaining this ecosystem is enormous and expensive."
Rails IS FREE TO USE. If you want to improve test driven development, do the work yourself. Or start a company and dedicate 40% of your extremely well paid engineers time open source code others can use for free.
37signals and Shopify make the decisions because THEY DO THE WORK. I am happy to sit back and free load off of their contributions even if I disagree with DHH and Tobi's political opinions.
This happened to me over a decade ago. Medication was a godsend, and then I burned out. I remember sitting down to do work and not being able to start anything so I would pull up a dumb io game.
So I went off, and for the next 5 years I still couldn't focus. It got worse actually. I did a lot of caffeine. After COVID I started to work out and then suddenly for the first time ever I could focus. As long as I don't do caffeine, workout, and sleep I am sharp. I've done great work in the past couple years but I do feel cheated that Adderall stole time from me. I wonder where I would be with my career if I hadn't burned out.
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.
reply