
Proxino (YC S11): Automated Error Reporting For Your Client-Side JavaScript - schlichtm
http://techcrunch.com/2011/08/22/yc-funded-proxino-automated-error-reporting-for-your-client-side-javascript/
======
arnorhs
Seems to be an interesting product, but..

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.

------
pcarmichael
Is it just me, or does the pricing seem a bit steep?
(<https://www.proxino.com/plan>) The free tier buys you roughly 33 page views
a day, which I'd expect to surpass just handing a site to a single user or
two. At $100/100K page views (which is not terribly hard to reach), that's
getting pretty pricey.

~~~
jonknee
I also wonder what they consider a page view? Since it's to debug JS, a fair
number of their target customers would be running apps that don't have
conventional page views, but load data through AJAX. On a similar note, with
caching there shouldn't be an incremental cost for each page view.

~~~
arnorhs
They probably count the page views by the times their JS script gets loaded

------
jcampbell1
This looks very interesting, though I'd really like a "lite" version that just
logs the error messages. I really don't want my javascript passed through a
startup's proxy.

~~~
thematt
Agreed. I'm not sure SaaS is the best business model for this. It looks
useful, but just sell it outright.

------
cromwellian
Considering that Chrome and Firefox have enough native Javascript stack trace
support to make this trivial, I'm not sure why you would want to do this in
production:

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.

~~~
Hovertruck
This doesn't (or shouldn't be) using try/catch, but rather just firing a
request to their server when the window.onerror event is triggered.

~~~
cromwellian
The Proxino blog/website says they parse the JS into an AST and add try/catch
blocks to every method.

------
mattj
Isn't this trivial to implement?

~~~
angelbob
Less so than you'd think. There's a great previous thread about it here on HN.

Similarly, the proxy isn't something you can do without, unless you fail to
catch several significant classes of errors.

------
robfig
Discussion from 12 days ago: <http://news.ycombinator.com/item?id=2869381>

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-...](http://blog.proxino.com/post/8388203148/catching-the-worlds-bugs-
instrumentation-via-proxy)

"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."

------
bialecki
How does this do on minified JS since that's often what's in production?

------
rorrr
Or you could just do this:

1) [http://mattsnider.com/languages/javascript/window-onerror-
ev...](http://mattsnider.com/languages/javascript/window-onerror-event/)

2) [http://mattsnider.com/javascript/catching-all-javascript-
err...](http://mattsnider.com/javascript/catching-all-javascript-errors-in-
all-browsers/)

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

~~~
gregdetre
Thanks for this code. We'll look over it carefully to see if there are some
tricks that we've missed.

But we've tried many libraries, and many approaches, to monitoring and
debugging javascript. The browser is a much more hostile, varied and foggy
environment than (say) Python. It's much harder to notice when something goes
wrong, which browsers and which pages it's common to, narrow it down to the
right subset of circumstances and contexts, and then effect a fix.

You can try sending an email every time you catch a window.onerror, but most
of what you receive will be irrelevant or inscrutable.

If Proxino can make more sense of things, they could make a huge difference to
rich-front-end development.

[I don't know them, I've not yet checked out their product, I'm just trying to
persuade you all that they're trying to solve a meaningful (at least to me)
problem]

~~~
rorrr
No need to email errors, you can AJAX it to whatever event
tracking/aggregating system you prefer. I love Splunk (which is pretty
expensive too for large projects), but there are open source alternatives.

------
drivebyacct2
I feel like I'm missing something.

