Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

URLs are state containers

alfy.blog

Post reply on HN
Print view View original

161–170 of 218 posts

Re: URLs are state containers

#161

Post by stonecharioteer »

jorl17 wrote: 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…

Would this hijack the back button though? Genuinely curious if modifying the URL adds to the location history.

Re: URLs are state containers

#162

Post by pbreit »

jorl17 wrote: 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 would never structure my URLs for performance reasons. 100% for usability.

Re: URLs are state containers

#163

Post by thewisenerd »

i see the complaints around URL length limits and i raise you..

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.

Re: URLs are state containers

#164

Post by MrJohz »

endless1234 wrote: post #115
apitman wrote: post #110

Earlier quoted context omitted.

> I make sure that as much state as possible is saved in a URL, sometimes (though rarely) down to the scroll position. If your page is server-rendered, you get saved scroll position on refresh for free. One of many ways using JS for everything can subtly break things.

Still leaves the problem of not being able to simply send the current URL to someone else and know they'll see the same thing. Of course anchors can solve this, but not automatically

You probably don't want that most of the time, though. The time I'm most likely to send someone an article is once I've got to the end of it, but I don't want them to jump to the end of the article, I want them to start at the beginning again.

There are situations where you want to link to a specific part of a page, and for that anchors and text anchors work well. But in my experience it isn't the default behaviour that I want for most pages.

Re: URLs are state containers

#165

Post by CarlitosHighway »

gortok wrote: post #155

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.

Yes and the comments in this thread don’t give me much hope that we will ever progress from the SPA mess to the idea that „simple is best“. Developers love to overengineer.

Re: URLs are state containers

#167

Post by balllpug1 »

I disagree in the public URL, as either GPG --quick-generate in coining a counterpoint as a feature of anti-DDOS protocols.

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

Re: URLs are state containers

#168

Post by noctune »

padolsey wrote: 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…

It doesn't help that URLs are badly designed. It's a mix of left- and rightmost significant notation, so the most significant part is in the middle of the URL and hard to spot for someone non-technical.

Really we should be going to com.ycombinator.news/item?id=45789474 instead.

Re: URLs are state containers

#169

Post by IanCal »

endless1234 wrote: post #115
apitman wrote: post #110

Earlier quoted context omitted.

> I make sure that as much state as possible is saved in a URL, sometimes (though rarely) down to the scroll position. If your page is server-rendered, you get saved scroll position on refresh for free. One of many ways using JS for everything can subtly break things.

Still leaves the problem of not being able to simply send the current URL to someone else and know they'll see the same thing. Of course anchors can solve this, but not automatically

Scroll position doesn’t do this because it’s not portable between devices.

Re: URLs are state containers

#170

Post by jongjong »

I loke to keep state in the URL. It's nive when you can bookmark any section in an app and it brings you back to the exact same place, all the menus exactly the same. Also it's amazing for debugging. Any bug, I tell the user to send me the URL. I reproduce the issue instantly, fixed in 5 minutes. I wrote some very complex frontends without any tests thanks to this approach... Also it's great during development; when I make a change anywhere in the app, I just refreshed the page... I never have to click through menus to get back to the part of the code I want to test. Really brings down my iteration time... Also I use Vanilla JavaScript Web Components so I don't have to wait for transpiler or bundler. Then I use Claude Code. It's crazy how fast I can code these days when it's my own project.
Post reply on HN