
Must-know url hash techniques (2011) - jfaucett
http://blog.mgm-tp.com/2011/10/must-know-url-hashtechniques-for-ajax-applications/
======
StavrosK
With pushState, isn't this now irrelevant (and, as it has always been, ugly)?

~~~
jfaucett
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.

~~~
Rygu
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.

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

------
jacques_chester
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.

------
hising
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.

------
wizard_2
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.

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

