Hacker News Reader

Comment by johnbender | Hacker News Reader

> PushState, for example, is not a bandaid, and for those not-so-modern browsers there are hashtags (let's be frank: 99.9% of users don't care about how beautiful or ugly their URIs are and even less about one particular character).

Keep in mind that using the history API (push|replace)State is not so much about making the URL pretty as it is about page refresh semantics.

With a hashtag the page refresh loading the correct content requires at least one more trip to the server to load the content represented by the hash and relies completely on your JavaScript not breaking.

With a url "fixed" by (push|replace)State the server can respond directly with the content speeding up the response time and removing a point of failure.

View on HN

Can the server be set up so pushed states can work with any arbitrary path, as you can do with hashtag addresses? Can you get the same level of flexibility in handling bad URLs? I'm still struggling with getting PushState working, since I implemented hash routing as a slash-delimited query rather than a reflection of any actual directory structure on the server, (I.e. domain.com/#category/group/item loads an item, with various graceful fallbacks if it's not found, such as loading the group instead, or suggesting items that do exist). If I can avoid a 404 in most cases, I think the user will be happier. I'm not sure if I can get the same level of flexibility with PushState.

The server has nothing to do, pe se, with pushState. That just manipulates the client. If on reload/next visit, you don't want the link to break (which seems like a reasonable requirement), just set up a route in whatever web server you're running that maps to the url schema you're generating in the client.

Any thoughts on avoiding generic 404s in case of typo or removed content, in the hope of returning something more useful? Can we use context info from the URL given to personalize the 404 response, or maybe route to a different resource instead for certain contexts? This all seems so simple with client-side hash routing.

[Also, would that mean that I would need to maintain a list of every single possible route in the whole site?]

You can do whatever you want. You have the URL and can return any arbitrary bytes. The way you look at the hash in JS on the client would be the same way you look at the URL on the server.

Reply on news.ycombinator.com