Trackets BlogA Vision of Better JavaScript Error Tracking
Developing JavaScript applications is hard, but things get even harder when you launch them into production. Every one of your users will have a different environment, a different browser and different extensions that might be interfering with your application. Things get even harder if you are brave enough to develop single page applications, as one thing can easily lead to another and cause problems which are next to impossible to reproduce in development.
Let’s take a look at some more possible issues:
- Internet connection or the API server goes down for a couple of seconds while the user is using your app.
- User is “too fast” or does two conflicting actions at once while the app is still waiting for a response from the server (Yes, you should disable parts of the UI when request is in progress, but who doesn’t forget to do this once in a while?).
- Browser extension or a 3rd party library which isn’t used in development conflicts with the app and causes seemingly random problems.
- Part of the app silently fails without an error, which leads to an error in a completely different part a while later.
This is just a few of the possible problems, there are many more and you’ve probably experienced them as well. But we feel your pain and want to help you out solving these problems more easily.
Before we decided to build Trackets, we first tried to find an existing service that would address these issues, but we just simply couldn’t find anything good enough out there, so we decided to build our own. Many of the existing JavaScript error tracking tools do other things as well, they weren’t built specifically for JavaScript, which is why they fall into the good enough category.
But to build something truly great we had to make JavaScript a first class
citizen. Trackets goes way beyond a simple window.onerror and stacktraces, as
that doesn’t really help you much in a big application. If you’re using
something like Google Closure compiler which renames all of your variables you
might not even get out sensible data from your errors.
We want to be able to track what happened before the error, not just a simple stacktrace, since that doesn’t really tell us much in some cases. It is possible that we might not have a stacktrace at all, as some JavaScript constructs like to eat stacktraces for dinner. Some bugs might be caused by something completely different than what you see in the error message.
Some errors will only occur for some users and you might eventually run into a problem that a single user experiences many issues that other people never see, for example because his internet connection drops often. We help you solve this by enabling you to track each visitor and later inspect his actions.
There is much more than we could cover in a single blog post, which is why I invite you to sign up on our launch page and get notified when Trackets gets released.
