Cool. Thanks for the code.
What's the advantage of doing it this way as suppose to using an ajax call?
What's the advantage of doing it this way as suppose to using an ajax call?
Con: You can't manipulate the Request (GET only, can't touch headers), and you can't even see the Response -- when you vote on HN it just increments the number it already had instead of getting the new number in the response from the server.
If there's another advantage, I'm probably missing it (the image switchout shouldn't require a server-side call, since we already have the up/down icons loaded in the browser)
Maybe it's faster to do a "img get"? Or that you can't terminate it half way as suppose to an ajax? Better browser compatibility?
I haven't test it yet. I just hope someone who has can educate me.
There are other advantages and disadvantages to image beacons depending on how you use them.
In the case of a search engine using them to track clicks, a major advantage is that the performance cost (to the user) of an image beacon is much lower than the performance cost of using redirect-based tracking. The tradeoff is that beacons are less reliable than redirect tracking, since users may not have JS enabled.
Also, with click beaconing, there's a race between the beacon request and the navigation event; you fire the beacon when the user clicks, but there's no guarantee that the request will finish before the browser switches navigation contexts, unloads the current page, and cancels all pending requests. An image beacon is more likely to succeed in this case than an Ajax request, since there's more overhead associated with Ajax requests.
All the major search engines use image beacons for tracking to some extent, but Google and Bing use them more than Yahoo! currently does.