Are there any real risks to continuous polling?

It's sort of been 'against my religion' to poll a condition using a timeOut or similar techniqu开发者_如何学运维e. I'd so much rather handle an event than continuously search for evidence that an event occurred.

But, due to spotty support for the onHashChange event, it was suggested I use a plugin that polls the window.location property every 50ms.

Are there any real risks to doing this (eg processing expense)? Or am I just superstitious?

When I asked a similar qestion recently, people suggested a poll frequency of once per second: What is a good setTimeout interval for polling in a IE?

We use a setInterval of 120ms to check the hash key.
Although it is a one page web app that relies heavily on javascript, the polling doesn't hit the performance at all.

I didn't try IE6 and IE7 but everything is fine on IE8 and other today's common browsers.

The 120ms value came by some qualitative testing.
I played by steps of 20 while using the back/forward buttons.
I couldn't feel the difference for values lower than 120. While I could feel a growing lag for values over 120.

But this probably depends on your app, the polling time should have a value relative to the overall response time of the app.

Since it is a common practice to poll the window.location property, I believe there is no real risk involved. When I needed to implement it, I found out that such polling is used in Google's gmail and "translate".

The biggest problem here is that your window.location checking code will be executing 20 times every second, which seems like overkill.

You may want to test it on IE to see what kind of slowdown it has there, as IE is going to be the biggest problem with anything JS related.