Tuesday, September 23rd, 2008

BrowserHawk Lives!

Category: JavaScript

Many years ago I stumbled across the original BrowserHawk. Back then, it was primarily a way to feed information about a client’s web browser to a server-side web framework. I was impressed at the time with its ability to detect display resolution, color depth, and a variety of other data not available via HTTP headers.

Richard Litofsky wrote in to tell us that BrowserHawk lives on in a new form: BrowserHawk To-Go. It sounds interesting, though not as revolutionary today as it was to me back when embraced complete ignorance of client-side browser programming:

BHTG is a complete rewrite of our classic BrowserHawk product and is
specifically designed for cross browser, JavaScript-centric programming.

By including our BHTG JS library developers can add our robust browser
sniffer that detects over 100 different properties including browser
type/version/platform, connection type and speed, latency, installed
plug-ins, blocked popups, Java settings, and more. This data can be logged
and/or used to dynamically control page behavior.

BHTG also can add an automated browser troubleshooting and self-help page to
a web site, again just by including the JS library. It also can, with one
line, monitor the *actual* page load times experienced by each user to a
site. And it reports any JavaScript errors users encounter on the site, with
customizable match rules.

BrowserHawk To-Go is a commercial product; they’re going for a Software-as-a-Service model where their servers host the script (à la Omniture, etc.).

Posted by Ben Galbraith at 7:30 am

3.8 rating from 43 votes


Comments feed TrackBack URI


My company moved away from BrowserHawk because of the prohibitive licensing. It was around $1000 per server. I simply wrote from scratch all the parts we needed and dropped BH like a bad habit.

Comment by commadelimited — September 23, 2008

If you really need some of these features, just include a teensy Flash movie that allows itself to communicate with JavaScript and grab the values from your SWF that you can’t easily get from JavaScript.

Actually, you could do most of this with a teensy SWF that reports back to JavaScript, and for the SWF detection just use or modify one of the standard detection scripts like SWFObj or the stock Adobe detection.

To log this nonsense, just write a simple CGI that appends whatever data structure you create (enterprise bonus for JSON) into a file that is processed at some interval by a CRON (or equivalent) script and pushed into a database.

Why would anyone pay for this crap?

Comment by MichaelThompson — September 23, 2008

I think you’re over simplifying this Michael.

Yes, of course it’s possible to write this sort of stuff yourself. But what you’re paying for is someone to handle all the little quirks of the detection scripts and constantly required updates for you. It doesn’t even seem that pricey. About $7.00/mo for ~30,000 pages (assuming some are cached).

Whilst I personally wouldn’t pay for something like this I think writing it off as crap is a little harsh.

It’s worth noting that your site is currently returning a “Site Temporarily Unavailable” message with a “error id: “bad_httpd_conf” error.

Sometimes it’s just more reliable to offload the work to others, huh?

Comment by russh — September 23, 2008


Comment by AlexHernandez — September 23, 2008

$1,000 is nothing. I work at a company that isn’t even big and doesn’t think twice about writing $5,000 cheques for consultants

It would cost far more then $1,000 to get an external coder in to write something with half the capacity of browserhawk. I mean seriously good luck writing a latency detector along with everything else in < 20 hours.

Comment by stevesnz — September 23, 2008

Leave a comment

You must be logged in to post a comment.