Live data from Hacker News

URLs are state containers

alfy.blog

61–70 of 218 posts

Re: URLs are state containers

#61
post #8

I agree, and this reminds me: I really wish there was better URL (and DNS) literacy amongst the mainstream 'digitally literate'. It would help reduce risk of phishing attacks, allow people to observe and control state meaningful to their experience (e.g. knowing what the '?t=_' does in youtube), trimming of personal info like tracking params (e.g. utm_) before sharing, understanding https/padlock doesn't mean trusted…

[deleted]

Re: URLs are state containers

#63
post #59

Earlier quoted context omitted.

JS does have features for editing the history, but it's a trade-off of not polluting the history too much while still letting the user navigate back and forth

I'm glad to see that prismjs site mentioned by the blog is doing the right thing - when it updates the URL, it replaces the current history item.

Does that handle back button correctly? Nothing more annoying that sites/apps that overwrites the history incorrectly, so when you press the back button it goes to the entry before you entered the website/app, rather than back into what you were doing in the website/app.

Both approaches (appending/rewriting) have their uses, the tricky part is using the right thing for the right action, fuck up either and the experience is abysmal.

Re: URLs are state containers

#65
Hanselman famously said “URLs are UI” and he’s absolutely right

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.

Re: URLs are state containers

#67
post #24

When I get my way reviewing a codebase, I make sure that as much state as possible is saved in a URL, sometimes (though rarely) down to the scroll position. 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…

I can understand "shareable" state (scroll position), but _as much as possible_ seems like overkill. Why not just use localStorage?

> Why not just use localStorage?

So that I can operate two windows/tabs of the same site in parallel without them stealing each other’s scroll position. In addition, the second window/tab may have originated from duplicating the first one.

Re: URLs are state containers

#68
post #51
post #24

When I get my way reviewing a codebase, I make sure that as much state as possible is saved in a URL, sometimes (though rarely) down to the scroll position. 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…

I completely agree. In fact, I believe URL design should be part of UX design, and although I've worked with 30+ UX designers, I've never once received guidance on URLs.

As a UX designer that always gives guidance on URL design/strategy, I’ll say it’s not always well received. I’ve run into more than a few engineering or PM teams who feel that’s not w/in scope of design.

Re: URLs are state containers

#69
post #66
post #2

Not quite. As the L in URL says, it is the locator or address of the state. The S in REST implies the same, indicating states as the content, not path to it.

State is just your location in state space.

An address book is not "state space". The country, land and things are the state.

Re: URLs are state containers

#70
>Scott Hanselman famously said “URLs are UI”

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.

Post reply on HN