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:
"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."
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.
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.
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?
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.
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.
Wow, that's pretty nifty. Somehow I missed it when I looked at the home page. Did you change it? If not, I think I might have missed it because local was only in the finer print. If the header said "Worry Free Local Fallbacks" I think more visitors will notice it.
BTW please see my other comment about changing the API; "secret" in client-side JavaScript is confusing.
Edit: never mind, didn't realize my other comment was replying to you. You've already noticed that secret is a misnomer. :)
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.
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.
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."