4 ms·

You can put much more stuff in the url fragment (location.hash). Like megabytes. No host can stop you, even vercel, as it stays on the client. As a bonus, yo

You can put much more stuff in the url fragment (location.hash). Like megabytes. No host can stop you, even vercel, as it stays on the client. As a bonus, you can keep all your logic in one place. I'm not a fan of anything that has the word "rehydration" in it. Server is good at some stuff. Client is good at other stuff. Trying to blur the boundary seems like an engineering exercise in search of an application.

no_wizard 3y ago
location hashes are an under-used feature of the web. I completely agree with this. It would seem however, that most applications that would benefit from this, the routing in use relies entirely on the web history API to determine what happens, but none simultaneously support both the web history API and hash fragments, which would really be the best of both worlds when used properly. That said, there are many instances where you need server data and you don't want to get it post-render (thus avoiding the now dreaded spinners on first load), you don't have many options
- recursive 3y ago
  I don't think there's anything about the standard history APIs that causes conflicts between history and url hash use. I don't really know how widely used client routers work, but this really sounds like a trivial fix. I'm probably missing something.
  - no_wizard 3y ago
    there isn't, as far I know, its simply that most client routers require you to make a choice: either use hash routing, or use history API. They don't have any built-in conveinences for using both together (namely, around things like getting URL parameters) React Router, Vue Router etc. None of them have any consideration for using them together, they either don't support it at all or make you choose.
    - mhio 3y ago
      I don't follow, Why would hash based routing not use the history API? I'm aware of the choice between path based routing, and hash based routing, which has some server side implications. The History API manages entries in the client history, which I always thought a hash based router would still need to use. Maybe because a hash based router can work single page on the client without having to fake real resource paths? edit: I'm only familiar with the vue side, but vue-router relies on the same code for both, I can only see minimal differences for the `#`, not much for the history management. https://github.com/vuejs/router/blob/110c86929ac92e2428d8d4958b6c6374754bc0df/packages/router/src/history/hash.ts#L45 https://github.com/vuejs/router/blob/110c86929ac92e2428d8d49...
      - no_wizard 3y ago
        It’s more about the convenience features and melding of the two methods not so much that the underlying API prevents them from working together. Vue router doesn’t have a mixed mode for instance
gustavus 3y ago
I could be wrong but I thought there was a limit of like 4kb for a URL before you start running into issues. I don't remember if it applies to the hash but I remember one of my clients ran into that issue at one point trying to store their OIDC JWTs in the url fragment.
- recursive 3y ago
  Experimentally, it seems to be at least 50kb, although I can't find a spec. https://jsfiddle.net/Jz3ZA/ https://jsfiddle.net/Jz3ZA/

no_wizard 3y ago

location hashes are an under-used feature of the web. I completely agree with this. It would seem however, that most applications that would benefit from this, the routing in use relies entirely on the web history API to determine what happens, but none simultaneously support both the web history API and hash fragments, which would really be the best of both worlds when used properly. That said, there are many instances where you need server data and you don't want to get it post-render (thus avoiding the now dreaded spinners on first load), you don't have many options

recursive 3y ago
I don't think there's anything about the standard history APIs that causes conflicts between history and url hash use. I don't really know how widely used client routers work, but this really sounds like a trivial fix. I'm probably missing something.
- no_wizard 3y ago
  there isn't, as far I know, its simply that most client routers require you to make a choice: either use hash routing, or use history API. They don't have any built-in conveinences for using both together (namely, around things like getting URL parameters) React Router, Vue Router etc. None of them have any consideration for using them together, they either don't support it at all or make you choose.
  - mhio 3y ago
    I don't follow, Why would hash based routing not use the history API? I'm aware of the choice between path based routing, and hash based routing, which has some server side implications. The History API manages entries in the client history, which I always thought a hash based router would still need to use. Maybe because a hash based router can work single page on the client without having to fake real resource paths? edit: I'm only familiar with the vue side, but vue-router relies on the same code for both, I can only see minimal differences for the `#`, not much for the history management. https://github.com/vuejs/router/blob/110c86929ac92e2428d8d4958b6c6374754bc0df/packages/router/src/history/hash.ts#L45 https://github.com/vuejs/router/blob/110c86929ac92e2428d8d49...
    - no_wizard 3y ago
      It’s more about the convenience features and melding of the two methods not so much that the underlying API prevents them from working together. Vue router doesn’t have a mixed mode for instance

gustavus 3y ago

I could be wrong but I thought there was a limit of like 4kb for a URL before you start running into issues. I don't remember if it applies to the hash but I remember one of my clients ran into that issue at one point trying to store their OIDC JWTs in the url fragment.

recursive 3y ago
Experimentally, it seems to be at least 50kb, although I can't find a spec. https://jsfiddle.net/Jz3ZA/ https://jsfiddle.net/Jz3ZA/