Hacker News new | past | comments | ask | show | jobs | submit login
Must-know url hash techniques (2011) (mgm-tp.com)
26 points by jfaucett on Nov 2, 2012 | hide | past | web | favorite | 9 comments

With pushState, isn't this now irrelevant (and, as it has always been, ugly)?

Well, if you do not have to support older browsers, which I think a lot of webdevs still have to do, then I guess its probably irrelevant. But the history API implementations are (of course) different across browsers/platforms, so I'd recommend taking a look at history.js, if you want cross-browser RIA with good hashchange fallbacks.

Good one, didn't know about history.js!

I think the best pushState fallback is just allowing page reloads. Hashtags are probably just annoying and confusing for the user experience. Besides, there are other very effective ways to improve page load time.

I agree; the correct fallback is to load the webpage the "traditional" way.

I've always wished this worked w/out page reload :

  window.location.pathname = new_path;
maybe it would be a total spec hack and kills everything the internet stands for but still it'd make things a lot easier.

This reminds me of the URLs generated by Oracle's Application Express (which is my main source of income at the moment).

And you wind up using cookies anyhow to cross-check (ApEx does), because real applications tend to require authorisation as well as application state.

So, to recap:

1. Uglier URLs

2. Cookies anyway.

I think the best solution for handling older browsers is to allow server rendering via loading the page the traditional way. Solving two problems: Keeping your urls looking like they should and also verify that your site is accessible for software that do not rely on JavaScript such as some search engines and other types of machines / software. I see little reason for messing up urls with hashchange, adds complexity when recreating correct state on bookmarks.

The author glosses over the fact that encoding of special characters in the hash is broken in firefox. As an application there's no way to know if you're getting the data you want or url encoded data. Base64 encoding (with replacing chars like $ which most im and email clients fail to autodetect as being part of the url) seems to be the only bet at the moment. Putting the data in the get request and ignoring it on the server also seems to work well.

Specifically, Base64Url. It's described in RFC4648 and is URL-safe.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact