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.
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.
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.
The pricing is insane. I just looked at one of the projects I worked on, at 300 req/sec, this will cost $1080 per hour or $25K/day (if I didn't mess up the math). Seriously, who is rich enough to pay that much?
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.
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.
Yes, but on the bright side it's not yet another photo sharing app.
YC targets the really-really-low-hanging fruit. Nobody is going to be producing cheap fusion energy, solving world hunger, or kicking off the singularity on $16k.
"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."
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]
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.
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.