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

81–90 of 218 posts

Re: URLs are state containers

#81

Post by threetonesun »

poncho_romero wrote: post #40
bgilroy26 wrote: post #37

Earlier quoted context omitted.

To save the url length, why not hash all possible states and have the value of the variable in the query string refer to that?

This is a viable solution, but as the article mentions, you lose intent and readability (e.g. seeing a query parameter for “product=laptop” vs. “state=XBE4eHgU”). And in general, it’s unlikely you’ll run into issues with URL length. Two to eight thousand characters is a lot!

I remember bouncing into this limit once in a project because we wanted to make a deeply customized interface shareable without a backend, and while on the site itself we didn't hit a URL limit, when someone shared it via some email clients it added it's own tracking redirect onto the URL which caused it to hit the limit and break.

Re: URLs are state containers

#82

Post by game_the0ry »

simonhamp wrote: post #62

React kid discovers the web

Holding the snark aside for second, I think there is some harsh truth here.

Url query params are not popular in the front end developer world for some reason, probably bc the fundamentals of web dev are often skipped in favor of learning leetcode and all the react hooks. Same could be sade for SQL and CSS.

I also don't think its a good look that the author is a CTO and is just discovering how useful url query params are. that being said, its a pretty good and well-written blog post.

Re: URLs are state containers

#83

Post by ahmadalfy »

sixhobbits wrote: post #20

More good content with a bunch of GPT noise added, obvious from patterns like 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?

Hello, I am the author of the article and I can explain a few things.

First of all thank you for your words about the content.

I get why you might feel that way. English isn’t my first language, so I sometimes use GPT to help me polish phrasing or find a smoother rhythm for certain lines.

But the ideas, structure, and all the writing direction are mine. I don’t ask it to write articles for me. It just help me express things more clearly. I treat it more like an editor than a writer.

Re: URLs are state containers

#86

Post by chaboud »

If the URL is your state container, it also becomes a leakage mechanism of internals that, at the very least, turns into a versioning requirement (so an old bookmark won’t break things). That also means that there’s some degree of implicit assumption with browsers and multi-browser passing. At some point, things might not hold up (Authentication workflows, for example).

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.

Re: URLs are state containers

#88

Post by MyOutfitIsVague »

caseysoftware wrote: post #12

HATEOAS never gets the love it deserves until you call it something else.. Probably because it sounds like the most poorly named breakfast cereal ever.

From a human user perspective, HATEOAS is effectively just the web. You follow links to get where you want, and forms let you send data where you want, all traversed from some root entrypoint.

From a machine client perspective, it's a different story. JSON-LD is more-or-less HATEOAS, and it works fine for ActivityPub. It's good when you want to talk to an endpoint that you know what data you want to get from it, but don't necessarily need to know the exact shape or URLs.

When you control both the server and client, HATEOAS extra pain for little to no benefit, especially when it's implemented poorly (ie. when the client still needs to know the exact shape of every endpoint anyway, and HATEOAS really just makes URLs opaque), and it interacts very badly when you need to parse the URL anyway, to pull parts from it or add query parameters.

Re: URLs are state containers

#89

Post by macNchz »

embedding-shape wrote: post #63
orphea wrote: post #59

Earlier quoted context omitted.

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 experie…

It’s definitely possible to make a really stellar experience, but that winds up being the exception. The URL and history state are sort of “invisible” elements of the user experience but require thoughtful care and attention to what the user expects/wants at each step, a level of attention which is already a rarity in web development even in the most visible parts of a page…so frequently the history/back button stuff just totally sucks.

Re: URLs are state containers

#90

Post by jarofgreen »

Also to consider: bot traffic and SEO.

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.

Post reply on HN