

Show HN: Proxino - optimize and monitor your javascript - zaveri
https://www.proxino.com

======
kalvin
I'm going to repost this here because it actually tells me why I'd want to
route all my JS through a third party, and I had to click through the blog
link below to find it:

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

~~~
Cushman
Hmm— I wonder how that works with exception-handling code. It'd be a pain in
the ass to get notifications for normal behavior.

They must have thought of this, and it'd easy enough to ignore functions that
are already inside `try` blocks, but it's strange that it's not mentioned.

~~~
tlrobinson
I haven't looked at it yet, but perhaps they rethrow exceptions. This will
mess up line numbers in stack traces but otherwise should behave similarly to
original code.

------
yodasan
This was originally posted 2 weeks ago before their name change from Taazr to
Proxino. For original discussions on the site:
<http://news.ycombinator.com/item?id=2833945>

------
tmcw
Any indication of what you get out of this service? I know the fundamentals,
but the site's sneak-peek content consists of a TextMate screenshot and
documentation. That's all push - what's the pull?

------
toast76
This is really cool, and exactly what I need.

Consider me signed up.

------
dstein
You can do this pretty easily without a third-party by just using
window.onerror, and then doing an ajax request to log it.

~~~
unignorant
Not necessarily -- window.onerror isn't fully supported by some browsers and
libraries:

[http://blog.proxino.com/post/8388203148/catching-the-
worlds-...](http://blog.proxino.com/post/8388203148/catching-the-worlds-bugs-
instrumentation-via-proxy)

~~~
dstein
Yeah and just as easily you can put a try/catch around your code and do the
same ajax logging.

~~~
zaveri
Sure, that is possible if you want to spend the time wrapping every function
in your code with a try/catch block. Most people don't, and so we provide
automatic code instrumentation. You can't just wrap your js file in a single
try/catch.

~~~
boucher
I understand why you'd rather not provide this as a standalone tool, but I'd
much rather run such a tool as part of my existing compilation process than
use your proxy service.

------
IanDrake
Am I reading the docs correctly...put your secret key in the client side
script block?

<https://www.proxino.com/docs/getting_started>

~~~
zaveri
Secret is a misnomer; it is actually a public key.

~~~
benatkin
Many APIs call it a _client key_ or a _client ID_. That makes a lot more sense
than _secret_.

I suggest that Proximo change it in their API and in their docs.

~~~
zaveri
Noted. We will change it soon. Thanks!

------
photon_off
I'm interested, but before I continue I'd like to see screenshots or a demo so
I can get a feel for the product.

------
ben_hall
What happens if Proxino goes down?

~~~
zaveri
Your scripts will load from local urls. More details on this can be found in
the docs: <https://www.proxino.com/docs/getting_started>

~~~
JeremyBanks
Does that work for CoffeeScript files? Looking at proxino.js, it doesn't
appear to work for it. If you could have a version that included the
CoffeeScript compiler, I'd be very likely to use this.

~~~
JeremyBanks
After signing up I received an email asking if I had any questions. I asked
this one, and they responded that they don't support it yet, but they're
working on it.

------
wyclif
Is it not proper to spell JavaScript with a capital J and S?

~~~
strager
Either Javascript or JavaScript is acceptable.

~~~
Stratoscope
What do you think of Jquery?

