Looks neat and particularly polished for a Show HN. I especially loved the sandbox demo. However, I don't see anything that this offers that LogRocket[0] doesn't already have. How does RootCause compare?
LogRocket is very neat looking but only does replay for Redux apps (as far as I know).
We record all events for any web app so you can replay session and fire the exact same mouse+keyboard+ajax events to reproduce the issue. Very similar tools but we wanted to make something generic targeting every web app
Not directly related to this product (looks good btw!), but I've been using static type checking (Flow/TypeScript) for almost 2 years and since then, I haven't seen a single JS error in production. I do believe it's as important as writing tests now, if not more.
Do you have client-side error logging setup? I find it very hard to believe you wouldn't encounter any browser bugs, or bugs due to external applications fucking around with the browser.
To give an example, I've seen lots of "antiviruses" inject code or perform unexpected DOM changes, causing certain things to break.
Other times a user shows up with a heavily tweaked browsers that behaves differently from what you'd expect.
For error tracking I've previously used Sentry [0]. I found it really easy to use and setup in a fairly large JS app. The best part is that it's open source, so you always have the option of hosting it yourself, which removes any fear of vendor lock-in. I'd say it's well worth paying for their SaaS offering.
EDIT: Looking through the docs, it seems they expect you to load their non-versioned third-party sourced script, and it's not even hosted on a CDN. That's a huge security risk, so it's an immediate blacklist for me.
I am not sure how I feel about these session recorders and probably want to start blocking them from my browser. It is akin to someone recording your every movement inside your house and watching the video to see what issues come up. Oh and you have no idea its happening.
Also wonder about how this data is protected. If videos of how I used Facebook were leaked (messages I started to type but didnt send for instance) it would be a huge violation of my privacy.
In the same token, its like free UX research, you can see where people struggle by watching them use the app. It is like standing over someone's shoulder to see how they are using the product and helps immensely in that realm. I still feel like it should be opt in though.
And, it's not just about production sites - another use case is using this internally as a tool between QA <-> Developers to speed up communication when new errors are found.
I find it funny that here on HN in one thread we complain about Facebook scanning all of our messages while in the next thread we praise a product that tracks JavaScript events, keystrokes and mouse movements...
Random question: I've had bugs which were a simple result of timing (mostly due to the cpu being used by other processes running on the users machine), how would something like this be able to replay that error for me? If I were to replay that same data on my machine, because of the availability of cpu horsepower on my machine, I wouldnt be able to reproduce the error. Does anyone have insight to this?
Race condition bugs are very tricky to reproduce indeed. While there will never be a guarantee our Live Replay will reproduce your issue - it should be possible since we replay all events in the exact sequence they were recorded. Our replay studio also has a 'Preserve timing' setting which uses the same delay between the events.
You'd want to be really careful recording/replaying sessions on pages that capture personally identifiable information; then again, you probably wouldn't be running a third-party service like this if you were.
> ... then again, you probably wouldn't be running a third-party service like this if you were.
While we'd like that to be true it's sadly not in practice.
The most common example is websites with sensitive data in the URL (ex: PII query parameters) using third party analytics services that receive the entire URL as a metric.
The RootCause API has multiple ways to scrub PII details from the session before posting it. And we also offer an on-premises version (Docker image) so that the data never leaves your own servers.
Unless you running a million-user app, I believe you shouldn't fall for this. I have, multiple times. I've tried to catch what users were doing and get a log of the exceptions they faced. Only despair followed from these attempts.
The best error handling technique is to catch exceptions and show up a big popup on the screen with the error details.
Your users will send those details to you instead of just saying "the app crashed".
In my experience, users can't be bothered to copy and paste those errors. One feature of <literally any error tracker> is to give the user a code instead of the raw stack. This pairs well with the feature to attach arbitrary data (like current state, or atleast just user id), then you can see the whole error data in the tool on your own computer. I've been able to fix bugs before the support staff approaches me about it.
You sum it up well. If you just get static text (call stack etc) from your error logger tool, it's of almost no use as it doesn't reveal the state of the app. With modern tools that have replay capability, this changes and the debugging process is so much nicer. :)
The fact that tools like this are needed should be understood to mean that JavaScript error handling is fundamentally broken.
In a reasonable language, you do something obviously wrong, and it throws an exception immediately, which gives you a stack trace that gives reasonable context for understanding what went wrong.
In JavaScript, the failure often happens silently: "foo" + 1 returns "foo1", {}.foo returns undefined, and program execution continues until it absolutely can't, finally failing far away from where the problem occurred. And when it does fail, it often fails in a callback deep within framework code with no clear, traceable execution path that leads back to the point where the error occurred. The errors have all the mysteriousness of C errors, without even the traceability.
The JavaScript community doesn't seem to be aware that there are better solutions, and seem happy with the way things are, even going so far as to use JavaScript on servers where far better tools exist. It seems that the only salvation that will come will be when mature tools exist on top of WebAssembly so that those of us who care about error reporting can use better toolchains.
You need a tool like this to monitor run-time browser errors. When browsers support a language that catches 100% of errors at compile time then you won't need tools like this.
But I see what you're saying. Except for the declarative style popularized by React and also implemented in Mithril, Preact and Inferno, and except for the rise in popularity of TypeScript, and except for a lot of attention paid lately to immutable data structures, and except for jslint being created in 2002 and lots of similar tools since then, and except for the wide variety of JavaScript-based unit test frameworks, it really seems like the JavaScript community has no clue that there are ways to prevent the errors you describe and no inclination to prevent them.
> In a reasonable language, you do something obviously wrong, and it throws an exception immediately, which gives you a stack trace that gives reasonable context for understanding what went wrong.
So how is it even possible that this tool works if JavaScript doesn't do this? I don't know why you're just making things up.
[+] [-] RussianCow|8 years ago|reply
[0]: https://logrocket.com/
[+] [-] jchook|8 years ago|reply
We use FullStory and it’s fantastic. Would be extremely difficult to convert me.
https://www.fullstory.com/
[+] [-] mankz|8 years ago|reply
We record all events for any web app so you can replay session and fire the exact same mouse+keyboard+ajax events to reproduce the issue. Very similar tools but we wanted to make something generic targeting every web app
[+] [-] ggregoire|8 years ago|reply
[+] [-] TheAceOfHearts|8 years ago|reply
To give an example, I've seen lots of "antiviruses" inject code or perform unexpected DOM changes, causing certain things to break.
Other times a user shows up with a heavily tweaked browsers that behaves differently from what you'd expect.
[+] [-] realharo|8 years ago|reply
[+] [-] armandososa|8 years ago|reply
[+] [-] TheAceOfHearts|8 years ago|reply
For error tracking I've previously used Sentry [0]. I found it really easy to use and setup in a fairly large JS app. The best part is that it's open source, so you always have the option of hosting it yourself, which removes any fear of vendor lock-in. I'd say it's well worth paying for their SaaS offering.
EDIT: Looking through the docs, it seems they expect you to load their non-versioned third-party sourced script, and it's not even hosted on a CDN. That's a huge security risk, so it's an immediate blacklist for me.
[0] https://sentry.io/welcome/
[+] [-] mankz|8 years ago|reply
We'll have a CDN up shortly, good point! You can also host the JS script yourself, or use the on-premises version (Docker image)
[+] [-] ggregoire|8 years ago|reply
[+] [-] audiolion|8 years ago|reply
I am not sure how I feel about these session recorders and probably want to start blocking them from my browser. It is akin to someone recording your every movement inside your house and watching the video to see what issues come up. Oh and you have no idea its happening.
Also wonder about how this data is protected. If videos of how I used Facebook were leaked (messages I started to type but didnt send for instance) it would be a huge violation of my privacy.
In the same token, its like free UX research, you can see where people struggle by watching them use the app. It is like standing over someone's shoulder to see how they are using the product and helps immensely in that realm. I still feel like it should be opt in though.
[+] [-] mankz|8 years ago|reply
1. We recommend all our users to use the opt-in prompt before an error is logged. Demo: https://app.therootcause.io/sandbox/confirmation/
2. We can also show a special icon in bottom right corner when video is recorded. Demo: https://app.therootcause.io/sandbox/videorecording/
And, it's not just about production sites - another use case is using this internally as a tool between QA <-> Developers to speed up communication when new errors are found.
[+] [-] vbsteven|8 years ago|reply
[+] [-] chacham15|8 years ago|reply
[+] [-] mankz|8 years ago|reply
[+] [-] hashkb|8 years ago|reply
[+] [-] k1ns|8 years ago|reply
[+] [-] nickreese|8 years ago|reply
[+] [-] bsimpson|8 years ago|reply
[+] [-] koolba|8 years ago|reply
While we'd like that to be true it's sadly not in practice.
The most common example is websites with sensitive data in the URL (ex: PII query parameters) using third party analytics services that receive the entire URL as a metric.
[+] [-] mankz|8 years ago|reply
[+] [-] spraak|8 years ago|reply
[+] [-] mankz|8 years ago|reply
[+] [-] hknd|8 years ago|reply
[+] [-] mankz|8 years ago|reply
[+] [-] fiatjaf|8 years ago|reply
The best error handling technique is to catch exceptions and show up a big popup on the screen with the error details.
Your users will send those details to you instead of just saying "the app crashed".
[+] [-] Can_Not|8 years ago|reply
[+] [-] mankz|8 years ago|reply
[+] [-] igotsideas|8 years ago|reply
[+] [-] mankz|8 years ago|reply
[+] [-] Annika11|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] kerkeslager|8 years ago|reply
In a reasonable language, you do something obviously wrong, and it throws an exception immediately, which gives you a stack trace that gives reasonable context for understanding what went wrong.
In JavaScript, the failure often happens silently: "foo" + 1 returns "foo1", {}.foo returns undefined, and program execution continues until it absolutely can't, finally failing far away from where the problem occurred. And when it does fail, it often fails in a callback deep within framework code with no clear, traceable execution path that leads back to the point where the error occurred. The errors have all the mysteriousness of C errors, without even the traceability.
The JavaScript community doesn't seem to be aware that there are better solutions, and seem happy with the way things are, even going so far as to use JavaScript on servers where far better tools exist. It seems that the only salvation that will come will be when mature tools exist on top of WebAssembly so that those of us who care about error reporting can use better toolchains.
[+] [-] brlewis|8 years ago|reply
But I see what you're saying. Except for the declarative style popularized by React and also implemented in Mithril, Preact and Inferno, and except for the rise in popularity of TypeScript, and except for a lot of attention paid lately to immutable data structures, and except for jslint being created in 2002 and lots of similar tools since then, and except for the wide variety of JavaScript-based unit test frameworks, it really seems like the JavaScript community has no clue that there are ways to prevent the errors you describe and no inclination to prevent them.
[+] [-] Can_Not|8 years ago|reply
So how is it even possible that this tool works if JavaScript doesn't do this? I don't know why you're just making things up.
[+] [-] kerkeslager|8 years ago|reply