views:

57

answers:

2

jQuery hashchange event

For me it looks like most mature solution right now(please correct me if I'm wrong). I really like this plugin for manipulating with browsers hashes. It simplifies js code a lot in some cases.

I really want to start use it extensively but I have a question for you.

Accordingly to the source it uses loop and check whether hash anchor was changed every 50 ms.

What about performance? Can I overuse hashchange? Can it lead to some significant slowdown in performance? If so in which cases?

+3  A: 

Checking a simple string property every 50ms is an infinitesimal cost compared to probably everything else you're running, I wouldn't be concerned about performance here. If you're changing the hash often and your callback is very, very expensive then deal with that (you callback), but the check itself is a very, very small cost.

Also keep in mind that 50ms check is only for browsers that don't have window.onhashchange built-in, for those it's a native event (and that's most modern browsers).

Nick Craver
A: 

Performance is not an issue, all modern browsers now support the onhashchange event natively and thus do not require a interval check.

-- More Info --

The jQuery History Plugin uses a 200ms test for older generation browsers which do not implement the onhashchange event natively. Without that event implemented natively, you have to workaround it's functionality by using a interval change - there just isn't any other way to my knowledge. Fortunately the latest versions of all the major browsers now support the onhashchange event natively, so this check is no longer needed.

Let's go into what what that 200ms interval check does. If they are on IE6 or 7, it will check the state of an iframe (as in those browsers a iframe is required to emulate the back and forward buttons - where for other browsers a iframe is not required). If they are using another older browser which is not IE then it can just use location.getHash() in the check (without an iframe as explained before). Both types of checks are designed to be extremely fast and as minimal as possible, bringing the necessary overhead down to next to nothing. It's all about what the browser is actually willing to let you do, and trying to do it using the least intensive code possible.

balupton