Top
Best
New

Posted by thm 2 days ago

URLs are state containers(alfy.blog)
486 points | 210 commentspage 3
nubinetwork 1 day ago|
URLs are user supplied. You can't trust user data in 95% of cases. Storing stuff belongs in a database or a cookie.
jillesvangurp 1 day ago|
That's true for any content or request coming from the user. If it's not signed by a trusted party, you should not trust it and instead validate whatever you receive. It doesn't matter whether a client side database, a cookie, a file, or indeed the url was used.

Urls are kind of convenient for a lot of things like form parameters, #link into an app or page, etc. That's state. Adding a bit more state via json in a parameter or whatever is about as old as the web is. Mostly, url length restrictions are still a bit of a problem but you need really long urls these days to hit those with most browsers. But aside from that, it's just another way to store stuff between requests.

aatd86 1 day ago||
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."
jakegmaths 2 days ago||
I use URLs for pixel art: https://www.mathsuniverse.com/pixel-art?p=GgpUODLkg-N0JchwOF...
andy_ppp 1 day ago||
I think the set of rules around when to put things in the URL and when not to are incredibly complex and require serious thought. I don't want the whole history polluted with loads of entries either so when the replace the current history item and when to push a new one also requires a lot of discussion.
gortok 1 day ago||
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.
CarlitosHighway 1 day ago|
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.
llIIllIIllIIl 1 day ago||
That’s the reason i stay away and keep my customers away from SPAs. Good ole html forms do the trick for 99.95% use cases.
almosthere 1 day ago||
Remember when URLs became unstable wacky identifiers 10 years ago. Thankfully that trend died.
coolgoose 1 day ago||
This and the lack of proper a hrefs is the biggest pet peeve of mine with a lot of spa's
jFriedensreich 1 day ago||
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.

mk12345 2 days ago|
I really like this approach, and think it should be used more!

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/

More comments...