Reverse-engineering the script they want you to include and how they transform the code you pass through their proxy service reveals the following:

- It sends a good deal of information it can find out about the browser and where in the uncompressed code the error occured (it does this by you feeding it the original js file, unmodified, to their proxy service).

- Before minifying and compressing your scripts, it wraps every function it can find in a try/catch, and wraps the entire script's contents in a try/catch as well.

- As such, I don't believe it can correctly catch syntax errors.

I've done something similar that sends error logs to a Sentry error handler in my Django-based websites. It's definitely handy to be able to catch and fix javascript errors as they happen live, before clients even report or notice something is wrong. Quite a handy tool to have in addition to automated testing (with something like Qunit) and Selenium.

I've just installed Taazr on our machines, and it's already helped. I got an email alert when a user hit a function where we expected an object to always be defined but it was not (undefined is not an object). I was able to fix the problem right away because of Taazr. JSLint will catch syntax errors, but Taazr will catch everything else.

If this is true, it's hard to see how it counts as optimization. Try/catch is very expensive in all js environments.

I think the supposition is that the syntax errors are worked out of the JavaScript by the time you deploy it to customers. This is most likely intended to catch runtime errors from unanticipated conditions.

A `try/catch` is most expensive when used in a deep function called many times. Wrapping the typical "click" handler isn't going to cause performance issues. The biggest issue is that browsers have inconsistent support for stack and line info in a `try/catch` block.

Another options would be to use `window.onerror`. I've deployed apps that use the latter to report Javascript errors via the query string on an `<img>` element and it's been very useful.

This would have been a lot more interesting if I could just punch in the url to my scripts and it spits out an optimized version with notes.

I'm kind of hesitant to make my site depend entirely on some shiney new site.

It seems a little pricey to me. 10,000 page views (for $30) isn't all that much. It's not convenient enough (for me) to justify $99 per month for the next tier of 100K page views.

It would require more thought, but maybe they could consider number of exceptions reported as part of pricing, in addition to page views.

They should just roll this into a CloudFlare plugin so you don't have to modify your site or depend on their servers.

I would be much more interested if this were the case.