HN Reader

I genuinely don't understand why people don't get more upset over hitting refresh on a webpage and ending up in a significantly different place. It's mind-boggling and actually insulting as a user. Or grabbing a URL and sending to another person, only to find out it doesn't make sense.

Developing like this on small teams also tends, in my experience, to lead to better UX, because it makes you much more aware of how much state you're cramming into a view. I'll admit it makes development slower, but I'll take the hit most days.

I've seen some people in this thread comment on how having state in a URL is risky because it then becomes a sort of public API that limits you. While I agree this might be a problem in some scenarios, I think there are many others where that is not the case, as copied URLs tend to be short-lived (bookmarks and "browser history" are an exception), mostly used for refreshing a page (which will later be closed) or for sharing . In the remaining cases, you can always plug in some code to migrate from the old URL to the new URL when loading, which will actually solve the issue if you got there via browser history (won't fix for bookmarks though).

That said, I agree with the point and expose as much as possible in the URL, in the same way that I expose as much as possible as command line arguments in command line utilities.

But there are costs and trade offs with that sort of accommodation. I understand that folks can make different design decisions intentionally, rather than from ignorance/inexperience.

https://github.com/Nanonid/rison

Super old but still a very functional library for saving state as JSON in the URL, but without all the usual JSON clutter. I first saw it used in Elastic's Kibana. I used it on a fancy internal React dashboard project around 2016, and it worked like a charm.

Sample: http://example.com/service?query=q:'*',start:10,count:10

So what is the reality? The linked StackOverflow answer claims that, as of 2023, it is "under 2000 characters". How much state can you fit into under 2000 characters without resorting to tricks for reducing the number of characters for different parameters? And what would a rethought approach look like?

Though I guess this won't happen if it's obvious at first glance what the parameters do and that they're all just plaintext, not b64 or whatever.

URL is considered a permanent string. You can break it, but that's a bad thing.

So keeping state in the URL will constrain you from evolving your system. That's bad thing.

I think, that it's more appropriate to treat URL like a protocol. You can encode some state parameters to it and you can decode URL into a state on page load. You probably could even version it, if necessary.

For very simple pages, storing entire state in the URL might work.

Probably because it sounds like the most poorly named breakfast cereal ever.

Maybe a solution is some kind of browser widget that displays query params in a user-friendly way that hides the ugliness, sort of like an object explorer interface.

Youre doing two things:

1) youre moving state into an arbitrary untrusted easy to modify location.

2) youre allowing users to “deep link” into a page that is deep inside some funnel that may or may not be valid, or even exist at some future point in time, forget skipping the messages/whatever further up.

You probably dont want to do either of those two things.

I actually implemented a comment system where users just pick any arbitrary URL on the domain, ie, http://exampledomain.com/, and append /@say/ to the URL along with their comment so the URL is the UI. An example comment would be typed in the URL bar like,

http://exampledomain.com/somefolder/somepage.html/@say/Hey! Cool somepage. - Me

And then my perl script tailing the webserver log file sees the line and and adds the comment "Hey! Cool somepage. - Me" to the .html file on disk for comments.

    // /some/path?name=Francisco
    const [name, setName] = useQuery("name");
    console.log(name);  // Francisco
    setName('whatever');

    export default function SearchForm() {
      const [place, setPlace] = useQuery("place");
      const [max, setMax] = useQuery("max");

      return (
        <form>
          <header>
            <h1>Search Trips</h1>
            <p>Start planning your holidays on a budget</p>
          </header>
          <TextInput
            label="Location:"
            name="place"
            placeholder="Paris"
            onChange={setPlace}
            value={place}
          />
          <NumberInput
            label="Max Price ($):"
            name="max"
            placeholder="0"
            onChange={setMax}
            value={max}
          />
        </form>
      );
    }

[2] https://codesandbox.io/p/sandbox/festive-murdock-1ctv6

I think the fundamental issue here is that semantics matter and URLs in isolation don't make strong enough guarantees about them.

I'm all for elegant URL design but they're just one part of the puzzle.

Few years back, I built a proof-of-concept of a PDF data extraction utility, with the following characteristic - the "recipe" for extracting data from forms (think HIPAA etc) can be developed independently of confidential PDFs, signed by the server, and embedded in the URL on the client-side.

The client can work entirely offline (save the HTML to disk, airgap if you want!) off the "recipe" contained in the URL itself, process the data in WASM, all client-side. It can be trivially audited that the server does not receive any confidential information, but the software is still "web-based", "browser-based" and plays nice with the online IDE - on dummy data.

Found a working demo link - nothing gets sent to the server.

https://pdfrobots.com/robot/beta/#qNkfQYfYQOTZXShZ5J0Rw5IBgB...

"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

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.

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?

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.

In a previous experiment, I created a simple webpage which renders media stored in the URL. This way, it's able to store and render images, audio, and even simple webpages and games. URLs can get quite long, so can store quite a bit of data.

https://mkaandorp.github.io/hdd-of-babel/

[0] https://nuqs.dev/

This is because many sites cram the URL full of tracking IDs, and people like to browse without that.

So if you are embedding state in your URL, you probably want to be sure that your application does something sane if the browser strips all of that out.

Why?

I get it if we're talking about a size that flirts with browser limitations. But other than that I see absolutely no problem with this. In fact it makes me think the author is actually underrating the use-case of URL's as state containers.

A challenge for this is that the URL is the most visible part of an HTTP request but there are many other submerged parts that are not available as UI yet are significant to the http response composition.

Additionally, aside from very basic protocol, domain, and path, the URL is a very not human friendly UI for composing the state.

Depending on which mechanism you use to construct your state URLs they will see them as different pages, so you may end up with a lot of extra traffic and/or odd SEO side effects. For SEO at least there are clear directives you can set that help.

Not saying you shouldn't do this - just things to consider.

https://rssrdr.com/?rss=raw.githubusercontent.com/Roald87/Ha...

This is a small hobby project, I am not in IT.

I design my SSR apps so that as much state as possible lives in the server. I find the session cookie to be far more critical than the URL. I could build most of my apps to be URL agnostic if I really wanted to. The current state of the client (as the server sees it) can determine its logical location in the space of resources. The URL can be more of an optional thing for when we do need to pin down a specific resource for future reference.

Another advantage of not urlizing everything is that you can implement very complex features without a torturous taxonomy. "/workflow/18" is about as detailed as I'd like to get in the URL scheme of a complex back office banking product.

Sure, in the prismjs.com case, I have one of those comments in my code too. But I expect it to break one day.

If a site is a content generator and essentially idempotent for a given set of parameters, and you think the developer has a long-term commitment to the URL parameters, then it's a reasonable strategy (and they should probably formalise it).

Perhaps you implement an explicit "save to URL" in that case.

But generally speaking, we eliminated complex variable state from URLs for good reasons to do with state leakage: logged-in or identifying state ending up in search results and forwarded emails, leaking out in referrer logs and all that stuff.

It would be wiser to assume that the complete list of possible ways that user- or session-identifying state in a URL could leak has not yet been written, and to use volatile non-URL-based state until you are sure you're talking about something non-volatile.

Search keywords: obviously. Seach result filters? yeah. Sort direction: probably. Tags? ehh, as soon as you see [] in a URL it's probably bad code: think carefully about how you represent tags. Presentation customisation? No. A backlink? no.

It's also wiser to assume people want to hack on URLs and cut bits out, to reduce them to the bit they actually want to share.

So you should keep truly persistent, identifying aspects in the path, and at least try not to merge trivial/ephemeral state into the path when it can be left in the query string.

Key is to generate capitol, which is being either a URL or playing hand in ball.

storing the entire state in the hash component of the URL

http://example.com/foo#abc

since this is entirely client-side, you can pretty much bypass all of the limits.

one place i've seen this used is the azure portal.. (payload | gzip | b64) take of that what you will.

https://scrobburl.com/ https://github.com/Jcparkyn/scrobburl

But what bugs me about it is that this isn’t even that novel or intelligent of a realization. If you’ve used a web browser you’ve seen the url change. Connecting that with putting values in the url shouldn’t be such a huge leap. This was for a simple search page.

How do I stop this sort of brain dead unrealized thinking?

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

No database. No cookies. No localStorage

Themes chosen. Languages selected. Plugins enabled.

Which have the pattern of rhetoric but no substance. Clearly the author put significant effort it so why get an LLM to add noise?