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 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).
While I like this approach as well, these URLs ending up in the browser history isn’t ideal. Autocomplete when just trying to go to the site causes some undesired state every now and then. Maybe query params offer an advantage over paths here.
I think it’s a “use the right tool for the job” thing. Putting ephemeral information like session info in URLs sucks and should only be done if you need to pass it in a get request from a non-browser program or something, and even then I think you should redirect or rewrite the url or something after the initial request. But I think actual navigational data or some sort of state if it’s in the middle of an important action is acceptable.
But if you really just want your users to be able to hit refresh and not have their state change for non-navigational stuff like field contents or whatever, unless you have a really clear use case where you need to maintain state while switching devices and don’t want to do in server-side, local storage seems like the idiomatic choice.
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
Browser autocomplete behavior is reliably incorrect and infuriating either way, so it's not a good reason to avoid the utility of having bookmarkable/sharable urls.
Yeah I use a web app regularly for work where they have implemented their own "back" button in the app. The app maintains its own state and history so the browser back button is totally broken.
The problem here is that they've implemented an application navigation feature with the same name as a browser navigation feature. As a user, you know you need to click "Back" and your brain has that wired to click the broswer back button.
Very annoying.
Having "Refresh" break things is (to me) a little more tolerable. I have the mental association of "refresh" as "start over" and so I'm less annoyed when that takes me back to some kind of front page in the app.
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
Even with JS, if it is classical synchronous JS it is much better than the modern blind push for async JS, which causes the browser to try to restore the position before the JS has actually created the content.
Also reminder that "refresh" is just a code word for "restart (and often redownload) the whole bloody app". It's funny how in web-world people so used to "refreshing" the apps and assume that it's a normal functionality (and not failure mode).
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.
> 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.
I do dislike those cases. But I also dislike being two-thirds through a video or page, thinking “I’ve got to share this with <friend>, it’s right up their alley”, then hitting my fast combination of keys to share a URL and realising the link shared my exact place, which will make the person think I’m sharing a snippet and not the whole thing, so now I need to send another message to clarify.
I like being able to have URLs reproduce a specific state, but I also want that to be a specific decision and not something I can share or save to a bookmark by mistake.
I understand the inconvenience to have to leave a keyboard-driven workflow but I think the Share button --> Copy link are common enough now that it shouldn't be an issue. I know firefox also has "Copy clean link" if you right-click on the urlbar.
I did not find an extension that does just that but it should be trivial to create one and assign a shortcut to it.
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.
> 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.
Th web has evolved a lot, as users we're seeing an incredible amount of UX behaviors which makes any single action take different semantics depending on context.
When on mobile in particular, there's many cases where going back to the page's initial state is just a PITA the regular way, and refreshing the page is the fastest and cleanest action.
Some implementations of infinite scroll won't get you to the content top in any simple way. Some sites are a PITA regarding filtering and ordering, and you're stuck with some of the choices that are inside collapsible blocks you don't even remember where they were. And there's myriads of other situation where you just want the current page in anew and blank state.
The more you keep in the url, the more resetting the UX is a chore. Sometimes just refreshing is enough, sometimes cleaning the URL is necessary, sometimes you need to go back to the top and navigate back to the page you were on. And those are situations where the user is already in frustration over some other UX issue, so needing additional efforts just to reset is a adding insult to injury IMHO.
Which, if you take the base64 encoded string, strip off the control characters, pad it out to a valid base64 string, you get
"eyJhZ2VuZGEiOnsiaWQiOm51bGwsImNlbnRlciI6Wy0xMTUuOTI1LDM2LjAwNl0sImxvY2F0aW9uIjpudWxsLCJ6b29tIjo2LjM1MzMzMzMzMzMzMzMzMzV9LCJhbmltYXRpbmciOmZhbHNlLCJiYXNlIjoic3RhbmRhcmQiLCJhcnRjYyI6ZmFsc2UsImNvdW50eSI6ZmFsc2UsImN3YSI6ZmFsc2UsInJmYyI6ZmFsc2UsInN0YXRlIjpmYWxzZSwibWVudSI6dHJ1ZSwic2hvcnRGdXNlZE9ubHkiOmZhbHNlLCJvcGFjaXR5Ijp7ImFsZXJ0cyI6MC44LCJsb2NhbCI6MC42LCJsb2NhbFN0YXRpb25zIjowLjgsIm5hdGlvbmFsIjowLjZ9fQ==", which decodes into:
I only know this because I've spent a ton of time working with the NWS data - I'm founding a company that's working on bringing live local weather news to every community that needs it - https://www.lwnn.news/
> 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.
The two use cases are in slight conflict: most of the time, when I share a URL, I don't want to share a specific scroll position (which probably doesn't even make sense, if the other guy has a different screen size.)
Obviously the URL is not all state, it doesn’t save your cursor or IME input. So there is some distinction between “important” and “unimportant” state.
First SPA I built (without frameworks) I actually wrote my own router that stored most client-side state in the URL as a hash. I remember back then having some problems with IE6 4kb limit on URL length.
It actually worked really well, but obviously I had very little state. The only things I didn't store in the hash were form state and raw visualization data (like chart data).
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!
Because a hash is by definition a one-way mapping, so then you'd have to keep a map of the reverse mapping hash -> state, which obviously gets impractical with state such as page index or search terms. Better just make two-way "compression" mapping
Url state should be descriptive not prescriptive. Either way it is important. Unfortunately my experience on several teams is that businesses never care about stuff like this but users do.
> 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.
I'm in the opposite camp - I find it extremely annoying when sites clutter up the browser history with unnecesarly granular state. E.g. hitting "back" button closes a modal instead of taking me to the previous page.
You made my day. I totally agree with you: state, state management, UX/UI.
I am extremely proud that I lately implemented exactly this: What if... you pass a link or hit reload - or back button in browser.
I have a web app that features a table with a modal preview when hitting a row - boy am I proud to have invested 1 hour in this feature.
I like your reasoning: it ain't a technical "because I can dump anything in a url", nope, it is a means to an end, the user experience.
Convenience, what ever. I have now a pattern to put in more convenience like this, which should be pretty normal.
The only think that remains and bothers me is the verbose URL - the utter mess and clutter in the browser's input field. I feel pain here and there is a conflict inside me between URL aesthetics and flatter the user by providing convenience.
I am working on a solution, because this messy URL string hurts my eyes and takes away a little bit the magic and beauty of the state transfer. This abstract mess should be taken care of, also in regard to obfuscation. It ain't cleanly to have full-text strings in the URL, with content which doesn't belong there.
But I am on it. I cannot leave the URL string out of the convenience debate, especially not on mobile. Also it can happen that strings get stripped or copy & paste accidentally cut of parts. The shorter the better and as we see, convenience is a brutally hard job to handle. Delicate at so many levels, here error handling due to wrongly formatted strings, a field few people ever entered.
My killer feature is the initial page load - it appears way more faster, since there are no skeletons waiting for their fetch request to finish. I am extremely impressed by this little feature and its impact on so many levels.
I hate sharing links that are like 2 pages long in Whatsapp. Simple as that. If I hit refresh on a page I do it for a reason and I expect to be set at the start of the page. Its no big deal to scroll to where I was. Bloated URLs are a pain to work with too. I highly prefer clean short links. Just store state in local storage and recover it if necessary. If the user has js disabled its kinda their issue state isnt persisted.
To make this work better, URL's should standardize several common semantic query parameters and fragment identifiers (like lines, etc). There is utterly no need for every website to re-invent the wheel here. It would also enable browsers to display long URL's better. It could also reduce the amount of client JS once browsers pick up the job of executing some of the client side interactions on very common fragment changes.
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. Etc. Generally, even the most internet-savvy age group, are vastly ill-equipped.
> Generally, even the most internet-savvy age group, are vastly ill-equipped.
It’s a losing battle when even the tools (web browsers hiding URLs by default, heck even Firefox on iOS does it now!) and companies (making posters with nothing more than QR codes or search terms) are what they’re up against….
And with commercial software like Outlook being so ubiquitous and absolutely HORRENDOUS with url obfuscation, formatting, “in network” contacts, and seemingly random spam filtering.
Our company does phishing tests like most, and their checklist of suspicious behavior is 1 to 1 useless. Every item on the list is either 1: something that our company actually does with its real emails or 2: useless because outlook sucks a huge wang. So I basically never open emails and report almost everything I get. I’m sure the IT department enjoys the 80% false report rate.
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.
I disagree. We write left to right, so it makes sense when the URL is essentially two parts ("external" and "internal" in regards to "place on the network", "location on the server") they are written left to right and then separated in the middle.
Plus it would make using autocomplete way harder, since I can write "news.y" and get already suggested this site, or "red" and get reddit. If you were to change that, you'd need to type _at least_ "com.yc" to maybe get HN, unless you create your own shortcuts.
Conveniently enough, my browser displays the URL omitting the protocol (assuming HTTPS) and only shows host and port in black, and path+query+fragment
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.
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.
Thank you!! There’s a tone of projects where I’ve wanted something like that. I’ve previously cobbling together something ad hoc myself but this looks way more thought out and (slightly) more standard than me making up my own thing.
> Browsers and servers impose practical limits on URL length (usually between 2,000 and 8,000 characters) but the reality is more nuanced. As this detailed Stack Overflow answer explains, limits come from a mix of browser behavior, server configurations, CDNs, and even search engine constraints. If you’re bumping against them, it’s a sign you need to rethink your approach.
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?
Each of those characters (aside from domain) could be any of 66 unique ones:
Uppercase letters: A through Z (26 characters)
Lowercase letters: a through z (26 characters)
Digits: 0 through 9 (10 characters)
Special: - . _ ~ (4 characters)
So you'd get a lot of bang for your buck if you really wanted to encode a lot of information.
Unless you have some kind of mapping to encode different states with different character blocks your possibilities are much more limited.
Like storing product ids or EAN plus the number of items.
Just hope the user isn’t on a shopping spree
When the system evolves, you need to change things. State structure also evolves and you will refactor and rework it. You'll rename things, move fields around.
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.
I think it depends on the permanence of the thing you’re keeping state for. For example for a blog post, you might want to keep it around for a long time.
But sometimes it’s less obvious how to keep state encoded in a URL or otherwise (i.e for the convenience of your users do you want refreshing a feed to return the user to a marker point in the feed that they were viewing? Or do you want to return to the latest point in the feed since users expect a refresh action to give them a fresh feed?).
Unfortunately, too many websites use tracking parameters in URLs, so when a URL is too long I tend to assume it's tracking and just remove all the extra parameters from it when saving or sending it to anyone.
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.
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.
> But HATEOAS really isn’t about storing state in URLs.
I think saying they are unrelated isn't correct either. In order for hypermedia to be the engine of application state, the continuations of your application must be reified as URLs, ie. they must be stateful. This state could be stored server-side or in the URL, it doesn't matter, as URLs are only meaningful to the server that generated and interprets them.
Jokes aside, the crux of HATEOAS is having a dumb frontend which just displays content and links from backend responses. All logic is on the server side. It is more like a terminal connection than a browser based application.
Readit News
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).
But if you really just want your users to be able to hit refresh and not have their state change for non-navigational stuff like field contents or whatever, unless you have a really clear use case where you need to maintain state while switching devices and don’t want to do in server-side, local storage seems like the idiomatic choice.
On lichess.org/analysis, each move you make adds a history item, lichess.org/analysis#1, #2, and so on.
Pretty annoying.
The problem here is that they've implemented an application navigation feature with the same name as a browser navigation feature. As a user, you know you need to click "Back" and your brain has that wired to click the broswer back button.
Very annoying.
Having "Refresh" break things is (to me) a little more tolerable. I have the mental association of "refresh" as "start over" and so I'm less annoyed when that takes me back to some kind of front page in the app.
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.
I do dislike those cases. But I also dislike being two-thirds through a video or page, thinking “I’ve got to share this with <friend>, it’s right up their alley”, then hitting my fast combination of keys to share a URL and realising the link shared my exact place, which will make the person think I’m sharing a snippet and not the whole thing, so now I need to send another message to clarify.
I like being able to have URLs reproduce a specific state, but I also want that to be a specific decision and not something I can share or save to a bookmark by mistake.
I did not find an extension that does just that but it should be trivial to create one and assign a shortcut to it.
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.
Th web has evolved a lot, as users we're seeing an incredible amount of UX behaviors which makes any single action take different semantics depending on context.
When on mobile in particular, there's many cases where going back to the page's initial state is just a PITA the regular way, and refreshing the page is the fastest and cleanest action.
Some implementations of infinite scroll won't get you to the content top in any simple way. Some sites are a PITA regarding filtering and ordering, and you're stuck with some of the choices that are inside collapsible blocks you don't even remember where they were. And there's myriads of other situation where you just want the current page in anew and blank state.
The more you keep in the url, the more resetting the UX is a chore. Sometimes just refreshing is enough, sometimes cleaning the URL is necessary, sometimes you need to go back to the top and navigate back to the page you were on. And those are situations where the user is already in frustration over some other UX issue, so needing additional efforts just to reset is a adding insult to injury IMHO.
Do you have advice on how to achieve this (for purely client-side stuff)?
- How do you represent the state? (a list of key=value pair after the hash?)
- How do you make sure it stays in sync?
-- do you parse the hash part in JS to restore some stuff on page load and when the URL changes?
- How do you manage previous / next?
- How do you manage server-side stuff that can be updated client side? (a checkbox that's by default checked and you uncheck it, for instance)
If you go there, that's the URL you get. However, if you do anything with the map, your URL changes to something like
https://radar.weather.gov/?settings=v1_eyJhZ2VuZGEiOnsiaWQiO...
Which, if you take the base64 encoded string, strip off the control characters, pad it out to a valid base64 string, you get
"eyJhZ2VuZGEiOnsiaWQiOm51bGwsImNlbnRlciI6Wy0xMTUuOTI1LDM2LjAwNl0sImxvY2F0aW9uIjpudWxsLCJ6b29tIjo2LjM1MzMzMzMzMzMzMzMzMzV9LCJhbmltYXRpbmciOmZhbHNlLCJiYXNlIjoic3RhbmRhcmQiLCJhcnRjYyI6ZmFsc2UsImNvdW50eSI6ZmFsc2UsImN3YSI6ZmFsc2UsInJmYyI6ZmFsc2UsInN0YXRlIjpmYWxzZSwibWVudSI6dHJ1ZSwic2hvcnRGdXNlZE9ubHkiOmZhbHNlLCJvcGFjaXR5Ijp7ImFsZXJ0cyI6MC44LCJsb2NhbCI6MC42LCJsb2NhbFN0YXRpb25zIjowLjgsIm5hdGlvbmFsIjowLjZ9fQ==", which decodes into:
{"agenda":{"id":null,"center":[-115.925,36.006],"location":null,"zoom":6.3533333333333335},"animating":false,"base":"standard","artcc":false,"county":false,"cwa":false,"rfc":false,"state":false,"menu":true,"shortFusedOnly":false,"opacity":{"alerts":0.8,"local":0.6,"localStations":0.8,"national":0.6}}
I only know this because I've spent a ton of time working with the NWS data - I'm founding a company that's working on bringing live local weather news to every community that needs it - https://www.lwnn.news/
The two use cases are in slight conflict: most of the time, when I share a URL, I don't want to share a specific scroll position (which probably doesn't even make sense, if the other guy has a different screen size.)
Obviously the URL is not all state, it doesn’t save your cursor or IME input. So there is some distinction between “important” and “unimportant” state.
It actually worked really well, but obviously I had very little state. The only things I didn't store in the hash were form state and raw visualization data (like chart data).
I'm in the opposite camp - I find it extremely annoying when sites clutter up the browser history with unnecesarly granular state. E.g. hitting "back" button closes a modal instead of taking me to the previous page.
You made my day. I totally agree with you: state, state management, UX/UI.
I am extremely proud that I lately implemented exactly this: What if... you pass a link or hit reload - or back button in browser.
I have a web app that features a table with a modal preview when hitting a row - boy am I proud to have invested 1 hour in this feature.
I like your reasoning: it ain't a technical "because I can dump anything in a url", nope, it is a means to an end, the user experience.
Convenience, what ever. I have now a pattern to put in more convenience like this, which should be pretty normal.
The only think that remains and bothers me is the verbose URL - the utter mess and clutter in the browser's input field. I feel pain here and there is a conflict inside me between URL aesthetics and flatter the user by providing convenience.
I am working on a solution, because this messy URL string hurts my eyes and takes away a little bit the magic and beauty of the state transfer. This abstract mess should be taken care of, also in regard to obfuscation. It ain't cleanly to have full-text strings in the URL, with content which doesn't belong there.
But I am on it. I cannot leave the URL string out of the convenience debate, especially not on mobile. Also it can happen that strings get stripped or copy & paste accidentally cut of parts. The shorter the better and as we see, convenience is a brutally hard job to handle. Delicate at so many levels, here error handling due to wrongly formatted strings, a field few people ever entered.
My killer feature is the initial page load - it appears way more faster, since there are no skeletons waiting for their fetch request to finish. I am extremely impressed by this little feature and its impact on so many levels.
Cheers!
It’s a losing battle when even the tools (web browsers hiding URLs by default, heck even Firefox on iOS does it now!) and companies (making posters with nothing more than QR codes or search terms) are what they’re up against….
Our company does phishing tests like most, and their checklist of suspicious behavior is 1 to 1 useless. Every item on the list is either 1: something that our company actually does with its real emails or 2: useless because outlook sucks a huge wang. So I basically never open emails and report almost everything I get. I’m sure the IT department enjoys the 80% false report rate.
Really we should be going to com.ycombinator.news/item?id=45789474 instead.
Plus it would make using autocomplete way harder, since I can write "news.y" and get already suggested this site, or "red" and get reddit. If you were to change that, you'd need to type _at least_ "com.yc" to maybe get HN, unless you create your own shortcuts.
Conveniently enough, my browser displays the URL omitting the protocol (assuming HTTPS) and only shows host and port in black, and path+query+fragment
Deleted Comment
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
[0]: https://github.com/persvr/rql
[1]: https://github.com/jirutka/rsql-parser
[2]: https://datatracker.ietf.org/doc/html/draft-nottingham-atomp...
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?
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.
But sometimes it’s less obvious how to keep state encoded in a URL or otherwise (i.e for the convenience of your users do you want refreshing a feed to return the user to a marker point in the feed that they were viewing? Or do you want to return to the latest point in the feed since users expect a refresh action to give them a fresh feed?).
Deleted Comment
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.
Probably because it sounds like the most poorly named breakfast cereal ever.
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.
I think saying they are unrelated isn't correct either. In order for hypermedia to be the engine of application state, the continuations of your application must be reified as URLs, ie. they must be stateful. This state could be stored server-side or in the URL, it doesn't matter, as URLs are only meaningful to the server that generated and interprets them.
I think of flight stick controllers.