TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

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

69 pointsby schlichtmover 13 years ago

9 comments

arnorhsover 13 years ago
Seems to be an interesting product, but..<p>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)<p>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)<p>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.<p>This is just got released, but still there are a few things that strike me as odd/worrying:<p>- 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)..<p>- 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<p>- Note: 100k of JS to load in the head is a LOT of KB before the user starts downloading some HTML.<p>- 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.<p>- This taken from their docs:<p>&#62; 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:<p>"Which has never happened" -- didn't they JUST launch? That seems a bit immature.<p>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.
pcarmichaelover 13 years ago
Is it just me, or does the pricing seem a bit steep? (<a href="https://www.proxino.com/plan" rel="nofollow">https://www.proxino.com/plan</a>) 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.
评论 #2914443 未加载
评论 #2914467 未加载
评论 #2914580 未加载
jcampbell1over 13 years ago
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.
评论 #2914464 未加载
cromwellianover 13 years ago
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:<p>1) introduce added network latency (time to proxy / parse / instrument) + risk of downtime of proxy<p>2) adding try/catch to every function in your program will make it larger and increase download / parse time<p>3) try/catch blocks can cause performance hits on some JS VMs, so you're slowing down your runtime as well.
评论 #2914548 未加载
评论 #2914535 未加载
mattjover 13 years ago
Isn't this trivial to implement?
评论 #2914518 未加载
评论 #2914526 未加载
robfigover 13 years ago
Discussion from 12 days ago: <a href="http://news.ycombinator.com/item?id=2869381" rel="nofollow">http://news.ycombinator.com/item?id=2869381</a><p>The most interesting item was kalvin's find about why they proxy your code (and what their value-add is over window.onerror):<p><a href="http://blog.proxino.com/post/8388203148/catching-the-worlds-bugs-instrumentation-via-proxy" rel="nofollow">http://blog.proxino.com/post/8388203148/catching-the-worlds-...</a><p>"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.<p>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:<p>window.onerror = function(e){ console.log(e) }<p>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.<p>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.<p>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.<p>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."
bialeckiover 13 years ago
How does this do on minified JS since that's often what's in production?
rorrrover 13 years ago
Or you could just do this:<p>1) <a href="http://mattsnider.com/languages/javascript/window-onerror-event/" rel="nofollow">http://mattsnider.com/languages/javascript/window-onerror-ev...</a><p>2) <a href="http://mattsnider.com/javascript/catching-all-javascript-errors-in-all-browsers/" rel="nofollow">http://mattsnider.com/javascript/catching-all-javascript-err...</a><p>I have no idea what kind of lazy developer would pay so much money for this.
评论 #2914600 未加载
drivebyacct2over 13 years ago
I feel like I'm missing something.