Yeah, “all” is a hyperbole I guess. There’s always going to be a lot of transient or session-related state for any interactive app. Things like the state of form fields in a bulk edit workflow should be preserved so the user doesn’t lose work if they accidentally close the page, but not in the URL. Using the URL for something like that could even present a security/compliance risk since URL params show up in network logs.

I think my frustration with SPAs wrt URL state comes from the fact that a lot of things that could be easily stored in URL state are often not simply because of the patterns that SPA frameworks encourage. The common example is a pagination param like page=2 being sent to the BE apis to load the page data on the “next page” button click, but not exposing that to the browser URL. If the user leaves the page, they have no way to get back to whichever page they were on without clicking through different pages or maybe using the jump-to-page input (if it’s implemented on that page). This is especially bad if the app isn’t set up to handle client-side routing and load components based on the URL path because then the user gets redirected to the homepage, so they have to click all the way through the app to get back to the view they were on, then page through it. This gets worse when we start adding other basics like sorting and filtering to the view.

Personally, I think the ability to link directly to a particular view of data on a website is one of the superpowers of the web. We lost a lot of things when we moved from primarily native desktop UIs to browser-based UIs (easily implemented undo/redo for example), but the web does make some interaction patterns easier out of the box, and tunneling directly to a specific view with specific state at any arbitrary point in the application is one of the things the web can do easily that native apps need special consideration from the engineer to support.

Cheers!

That’s a good article and touches on something which bothers me deeply - the complete disregard for semantic markup. I mean, do it for the visually impaired people who might use assistive technology. You don’t have to use aria-* attributes, proper semantic markup goes a long way. When I see a button that does navigation or if/else in template which renders an anchor or a button, I get goosebumps. There are many other cases, I’m sure everyone has encountered at least one.

But this isn’t the same thing.

You can replicate the “click entire row” behaviour while still respecting accessibility. Check out the free tailwind course: Build UIs that don't suck - Tailwind CSS

In this case, the solution is to put some position classes on the table row and then making an <a> element that overlaps the entire row.