I wish there was a way to have undo/redo like when using pushState, but without polluting history. There is no separate "serializable state" API that is not tied to a URL. I could use LocalStorage, but I want to have multiple states in different tabs, persistent across reloads. Maybe storing "tab IDs" in URLs and state in LocalStorage is a good idea.

The new web standard initiative BRAID is trying to make web to be more human and machine friendly with a synchronous web of state [1],[2],[3].

"Braid’s goal is to extend HTTP from a state transfer protocol to a state sync protocol, in order to do away with custom sync protocols and make state across the web more interoperable.

Braid puts the power of operational transforms and CRDTs on the web, improving network performance and enabling natively p2p, collaboratively-editable, local-first web applications." [4]

[1] A Synchronous Web of State:

https://braid.org/meeting-107

[2] Braid: Synchronization for HTTP (88 comments):

https://news.ycombinator.com/item?id=40480016

[3] Most RESTful APIs aren't really RESTful (564 comments):

https://news.ycombinator.com/item?id=44507076

[4] Braid HTTP:

https://jzhao.xyz/thoughts/Braid-HTTP

> #/dashboard - Single-page app routing (though it’s rarely used these days)

I actually use that for my self-hosted app, because hash routing doesn't require .htaccess or other URL rewriting functionality server-side. So yes, it's not ideal, but you don't fully control the deployment environment, it's better to reduce as much as you can the requirements.

> ?theme=dark&lang=en - UI preferences

Although the article is completely on point, I disagree that theme should be stored in URL.

Imagine you’re browsing a site, and at some point you switch from light to dark theme. After some time, you press “Back”. Do you really expect to switch back to light theme, and not to go to the previous page?

I've seen a lot of “well‑behaved” sites, that are storing their state in the URL, but I've never seen one, that stores current theme.

It’s interesting that the theme is part of the state too, yet you don’t want to store it in the URL. So, this means not every part of the state should be stored in the URL? Then what's the criteria for choosing what to store, and what not to?

I use URLs for pixel art: https://www.mathsuniverse.com/pixel-art?p=GgpUODLkg-N0JchwOF...

Finishing building a framework at the moment. I'd rather say that they are state descriptors... They don't contain all the state. But they are some kind of hashkey that allow to retrieve application state. "Hypertext as the engine of application state."

I'm going to provide a dissenting opinion here. I think the URL is for location, not state. I believe that using the URL as a state container leads to unexpected and unwanted behaviour.

First, I think it's a fact that the average user does not consider a URL to be a state container. The fact that developers in this thread lament the "new school" React developers who don't use the URL as a state container is proof of this. If it follows that a React developer, no matter how inexperienced, is at least as knowledgeable if not more about URLs than the average person, if they don't even consider the URL to be a valid container for state than neither does the average person.

Putting state in the URL breaks a fundamental expectation of the user that refreshing a page resets its state. If I put a page into an unwanted state, or god forbid there is a bug that places it in an impossible state, I expect a refresh of the page to reset the state back. Putting state in the URL violates this principle.

Secondly, putting state in a URL breaks the expectation of the user for sharing locations. When I receive Youtube links from friends, half of the time the "t" parameter is set to somewhere in the video and I don't know if my friend explicitly wanted to provide a timestamp. The general user has no idea what ?t=294833289 means in a URL. It would be better to store that state somewhere else and have the user explicitly create a link a timestamp parameter if the desired outcome was to link to an explicit point in the video. As it stands now, when I send YouTube links to friends I have to remember to clear the ?=t parameter before sharing. This is not good UX.

There are other reasons why I think its a bad idea but I don't want this comment to be too long.

That doesn't mean not to use search parameters though. Consider a page for a t-shirt, with options for color and size. This is a valid use case for putting the color and size in the URL because it's a location property - the resource for a blue XL shirt is different from a red SM shirt, and that should be reflected in the URL.

That's not to say that state should never be put in the URL - in some cases it makes sense. But that's a judgement call that the developer should make by considering what behaviour the user expects, and how the link will most likely be used. For a trivial example, it's unlikely that a user wants to share their scroll position or if a dropdown is open when sharing a page. But they probably want to share the location they've navigated to on a map, as it's unlikely they're sharing a link to `maps.google.com` with others (although debatably that's not state, but rather a location property).

It's fast becoming a lost art (alongside ensuring the text can be read by the 10% of the male population that is colour blind). It's one thing to coach a junior dev on implementing it properly into a Nextjs app (or whatever is trendy at the time), but quite another to have to explain this stuff to a Product Manager. If you're going to spend copious amounts of time with a designer to make sure the site is pixel perfect visually you should also have time to get your URLs right.

Hot module replacement masks a lot of annoyances for end users. Yes its more instantaneous than reloading a page and relying on urls for all of the state and I am not advocating hard for abolishing HMR anymore, but it would be nice if we still used way more url state than currently the case. Browsers will also hibernate tabs to varying degrees, server sessions expire all the time, things are not shareable. The only thing that works as users expect is url state. One thing i absolutely hate about ios apps is how every state is lost if i just have the app in the background for a few seconds, this even applies to major apps like youtube, google maps, many email clients etc. Why do we live in this stupid world were things are not getting better, just because someone made things more convenient for developers?

PS: and i curse the day the social media brainwashed marketing freak coined the term "deep link" to mean just a normal link as its supposed to work.

The wild thing about this is that for the longest time, URLs were the mechanism for maintaining state on a page. It is only with the complete takeover of JavaScript-based web pages that we even got away from this being "just the way it is". Browsers and server-rendered pages have a number of features that folks try their best to recreate with javascript, and often recreate it rather poorly.