Most of the websites on the internet aren’t just static pages anymore. Half of the internet is using jQuery, and with the growing popularity of single page applications we have even more JavaScript in our apps.

This however leads to completely different problems which aren’t present in standard server-only architecture. When something goes wrong on your backend, it’s usually just a single request that failed and you have all the context available.

The problem with JavaScript is that the applications usually live for more than just a single request. One thing might silently fail and cause an error a few minutes later in a completely different part of the UI, as the user continues on using your application.

Problems unique to JavaScript applications

Errors on the backend can break the frontend in unexpected ways.

Some users might click on everything twice, causing race conditions.

Internet connections are sometimes flaky.

Requests which usually takes 150ms might suddenly take 15 seconds.

Users will have your application open for hours without a page-reload.

Client side data might get corrupted and break seemingly unrelated parts of your application.

This screenshot is from a top100 site on the internet.

It just took a few page reloads and oops there’s an error. It doesn’t seem to impact the page at first sight, but who knows. Maybe it’s causing some backend service to not function properly, maybe some analytical data isn’t being collected, or maybe it will cause another error after using the site for a while. The interesting bit here is that the error doesn’t happen all the time, which means it might go overlooked when the application is being tested, but then it starts happening to actual customers.

Your application has these problems too

Now if a huge site like this has these problems, your application probably has them as well, you’re just not aware of it. Here’s where Trackets will help you.

You’ll see all runtime errors with detailed information about the context in which they occur. If a user clicked on a button which caused the error to happen, you’ll see it in the error message. Without any overhead or impact on your application.

You might be thinking that there is already a lot of exception trackers that are able to handle these kind of problems. The problem with a lot of them is that they weren’t designed to solve JavaScript errors in particular. Most of the existing solutions just support JavaScript as yet another platform among many. This approach works for backend languages, where there is no user interaction, but the frontend needs more.

Every client session is different and every user interacts with your application in a different way. Some users might double-click on a button where they should click just once. This will work for regular links, but not single page applications full of AJAX calls, where it might result in a race condition that breaks the app’s functionality.

All of these problems are just a small fraction of what can go wrong in your application.