
Show HN: RootCause – Record, Replay and Reproduce JavaScript Errors - mankz
https://therootcause.io
======
RussianCow
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?

[0]: [https://logrocket.com/](https://logrocket.com/)

~~~
jchook
I agree. Very polished.

We use FullStory and it’s fantastic. Would be extremely difficult to convert
me.

[https://www.fullstory.com/](https://www.fullstory.com/)

~~~
saganus
Both LogRocket and FullStory are blocked by default by uMatrix.

Any idea why?

~~~
willriker
I believe they are both classified as analytics tools which is why they are
blocked. It's annoying that uMatrix will still block a tool even if you
purposefully navigate to their site (versus if the tool is used for analytics
on a different company's site).

~~~
saganus
I see. Thank makes sense.

Yes, I also think it's annoying that they do this.

------
ggregoire
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.

~~~
armandososa
that's impressive. What would you recommend between flow and typescript for an
existing react app with an already large codebase?

~~~
RussianCow
I know React devs tend to gravitate towards Flow (which makes sense, since
both are developed by Facebook), but I personally recommend TypeScript solely
because it has a larger ecosystem and far more library type definitions. The
actual type systems are pretty much identical these days, but having type
definitions for almost every external library makes the out-of-the-box
experience much, much better. Also, I found TypeScript very easy to integrate
into an existing webpack setup, whereas I had a lot of trouble getting Flow to
work seamlessly (though, apparently many others have had the opposite
experience, so take that with a grain of salt).

------
TheAceOfHearts
Unfortunately, site is down.

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/](https://sentry.io/welcome/)

~~~
ggregoire
The main difference here is that they track all the mouse moves and clicks so
they can replay the user session right before the error happened.

~~~
TheAceOfHearts
Sentry tracks the last few events prior to the exception happening as well.
You can't replay the actual interaction, but seeing the activity log has
always been enough to meet my needs.

------
audiolion
Looks like a direct competitor to
[https://sessionstack.io](https://sessionstack.io)

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
Very valid points, great feedback and we completely agree, here's how we
address this:

1\. We recommend all our users to use the opt-in prompt before an error is
logged. Demo:
[https://app.therootcause.io/sandbox/confirmation/](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/](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
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...

------
chacham15
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?

~~~
mankz
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.

------
hashkb
Hugged to death. Wonder what they use for backend errors.

------
k1ns
This is great. Well done. The demo had me laughing in a very good way (I was
genuinely having fun watching it replay).

------
nickreese
Wow, this is impressively polished. Will look for an opportunity to test it
out on a project we're working on.

------
bsimpson
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.

~~~
koolba
> ... 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.

------
spraak
I wonder why they didn't register
[https://www.rootcause.io/](https://www.rootcause.io/) (i.e. why the "the" in
the url)

~~~
mankz
Taken already

------
hknd
Didn't think that I'll find an application in 2018 which will use ExtJS, but
therootcause dashboard is using it (:

~~~
mankz
Curious - why does it matter to you if the UI is built using Ext, Vue or
React?

~~~
hknd
[disclaimer: I'm a java/js/... dev at a faang company, and I've used Ext
before]

Imho Ext is a specialty of all the existing UI frameworks, and imho it's shit.
Tbh I though it would die directly after being bought by Idera. Even most of
the most Senior people left or got fired after that.

Most annoying things (imho): \- lock in: all their widgets, and tooling, and
everything only works for Sencha products, and is by far worse than the
current open source counterparts \- price: for a SMB/big-company this doesn't
matter, but you pay a premium to use "widgets" which are worse (imho) than
open source \- Sencha Widgets compile into clunky and non-semantic HTML
(thousands of divs), which also impacts performance a lot: simple apps usually
have 3-5MB \- debugging is difficult as you have to go through their "OOP"
layers (can be 5-10 layers) [Java Developers created this Web Framework]

People argue that it's great because many rich widgets are already available
and because the framework tells you how do to stuff. But everyone will run
into a point in time where something is just extremely hard because of extjs
constraints, which usually ends in a hacky solution.

~~~
mankz
Sounds you had a very bad experience with Ext JS, but we hope you'll give
RootCause a go anyway :)

~~~
hknd
Well, I'll definitely try it out. I don't make up my mind just because I don't
like a technology personally.

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

~~~
mankz
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. :)

~~~
Can_Not
Every error tracker I've ever used allows you to send arbitrary data (which
could be your entire flux store, for example) and has great documentation on
how to start using it.

~~~
mankz
We also allow you to attach any custom data to the error report. But this
doesn't necessarily help you put the web application into the state where it
crashes. Demo of custom data:

[https://app.therootcause.io/sandbox/addingcustomdata/](https://app.therootcause.io/sandbox/addingcustomdata/)

------
igotsideas
The site is down for me.

~~~
mankz
Issue with GoDaddy load balancing :( We're on the phone with them now

~~~
mankz
Site back up :)

------
Annika11
Nice!

------
kerkeslager
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.

~~~
brlewis
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.

~~~
kerkeslager
> 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.

Eh, I don't think that logging runtime-in-the browser is the value added here.
I can wrap my codebase in a try-catch that catches exceptions and calls home
with the stack trace in < 100 lines of code. Avoiding that < 100 lines of code
isn't the value added.

~~~
mankz
You could, but the point is that the stacktrace is useless in most apps
(unless you have stateless minimalist website). As soon as you make a web
_app_ and you have state - stacktrace doesn't help reproduce the bug.

~~~
kerkeslager
> As soon as you make a web app and you have state - stacktrace doesn't help
> reproduce the bug.

It does in a reasonable language. That's my point.

~~~
brlewis
What's an example of a reasonable language that has state? I figured you had
to be thinking of a pure functional language.

~~~
kerkeslager
Python, Ruby... the concern isn't so much state as that it throws the
exception where the mistake actually happens instead of failing silently.

