Proxino (YC S11): Automated Error Reporting For Your Client-Side JavaScript

There seem to be a lot of questions in the thread regarding how this thing works, one commentator noted that you could just bind something to window.onerror (which is a valid point)

They basically seem to have their own JS asynchronous loader script that will wrap all of your scripts into its own thing. That also means you can't use a JS loader like head.js, require.js etc, but their loader serves a similar purpose. (If I'm not misunderstanding)

I have no idea why they need to do this, they might be extending JS function prototypes to log function calls etc to get a stack trace. Who knows. Way beyond myself atm.

This is just got released, but still there are a few things that strike me as odd/worrying:

- If they really need to load the JS for you, what happens to inline JS and JS that needs to be at the end of the document (for some reason or another)..

- Their JS file is +100k un gzipped.. That seems a lot if you compare to any other JS loader (typically in the 5-10 k range

- Note: 100k of JS to load in the head is a LOT of KB before the user starts downloading some HTML.

- They are actually including all of jquery within their JS file - not in global scope - which seems really wasteful, because you will probably also be doing that - there might be more libraries in there, I'm not sure.

- This taken from their docs:

> 2. We recommend that you download proxino.js and host it locally. This will ensure that your javascript always loads, even if our proxy goes down (which has never happened). Here is the basic form:

"Which has never happened" -- didn't they JUST launch? That seems a bit immature.

I mean, this is probably just their initial beta thing and I'm guessing this will be pretty decent in a year or two, but so far it's just an interesting tech demo, imo.

1) introduce added network latency (time to proxy / parse / instrument) + risk of downtime of proxy

2) adding try/catch to every function in your program will make it larger and increase download / parse time

3) try/catch blocks can cause performance hits on some JS VMs, so you're slowing down your runtime as well.

The most interesting item was kalvin's find about why they proxy your code (and what their value-add is over window.onerror):

http://blog.proxino.com/post/8388203148/catching-the-worlds-...

"At Proxino, there’s one question I receive with uncommon frequency: why the proxy? After all, we only ever (at the moment) handle exceptions for you, and so there is curiosity. Is it really necessary, my customer will ask. He considers, perhaps, that the proxy is some clever ploy, a small glimpse at our plans for world domination. A lovely thought, if only it were so. Developers in particular have a tendency to believe that what Proxino does can be done dynamically. They are mistaken.

In a general sense, what Proxino does is a form of global exception handling, a way to catch every exception that occurs within your Javascript. To their credit, our customers correctly suspect that some approximation of this can be achieved dynamically. For it certainly can. Here is a naive first pass attempt at such a global handler, no proxy required:

window.onerror = function(e){ console.log(e) }

Unfortunately, window.onerror does not work in every browser, nor on every piece of code. It will fail to catch some exceptions raised by elements of jQuery, and other similarly complex libraries. It’s a simple one-liner, and it sort of works. But quite often, sort of is not enough.

With a bit more care — and a lot more code — a clever programmer can find dynamic work arounds for most browsers and most popular libraries. However in the general case, a global exception handler constructed dynamically is something of an elusive, asymptotic state. You are simply not going to get there. And this brings me to my point. Proxino is not interested in most. We want to catch, and tell you about, everything that goes wrong in your Javascript. Enter the proxy.

When a request reaches proxy.proxino.com, we lookup your existing code, parse it into AST form, and walk down the tree inserting special try/catch blocks within each function definition, as well as around the file itself. We then serve this instrumented file to your users, and handle every exception that occurs. Naturally, we have optimized this process for speed (with caching, etc.) but this guarantees us — and more importantly, you — complete code coverage. You will know about every exception.

Dynamic approaches are incredibly convenient in some ways, but in the general case they simply don’t work. And so there is a Good reason for the proxy. Hope this helps."

1) http://mattsnider.com/languages/javascript/window-onerror-ev...

2) http://mattsnider.com/javascript/catching-all-javascript-err...

I have no idea what kind of lazy developer would pay so much money for this.