Why We Only Support JavaScript
TrackJS is the best frontend error monitoring tool. It’s all we do and we do it well. To keep it simple we have just two different JavaScript agents. One for the browser, and one for Node server environments.
That’s it.
No other languages or platforms are supported. Just JavaScript.
Why Just JavaScript?
Most of our competitors support error monitoring for multiple languages, and we can certainly understand the initial appeal. But there’s a few good reasons we don’t, and probably will not, support additional languages in TrackJS.
Staying Small
We’re a small company. We want to stay that way. We like it that way. We can remain small and support our current surface area, so long as it’s just JavaScript.
As an alternative, consider the list of supported platforms for Sentry. That’s a huge list! Only a company with loads of employees could support all those platforms with any reasonable degree of competence.
Customer Support
Everybody who works at TrackJS is a very high level JS developer. All of us. When you contact support, your email goes in to a shared inbox that we all check every day. There’s no tier 1 support. There’s no ticketing system.
You will receive a prompt reply to your question from an engineer who knows everything about our product, because they build it. And everyone who works here has a minimum of 15 years of web development experience.
We pride ourselves on our customer support. It’s the best. Maybe the best of any company you’ve used, in any industry.
It’s that good.
But we can’t keep that level of support up if we add an additional 10 or 20 new languages. We’re not experts in Rust, so how could we hope to correctly monitor Rust errors, or write a Rust agent?
Actionable UIs
Every platform has different characteristics. Making JavaScript error reports useful from the web requires certain context. Things like screen size, browser name and version, console telemetry, user activity, etc. And it’s the same story on other platforms.
The problem is, the useful context you want to see in a JS error report is wildly different than the useful context you want to see in a Python error report.
Oh sure, there’s always some common ground. The user, the device, their location. But to make a good actionable UI that works well for Javascript and Python (and everything else) at the time is non-trivial.
In fact, we don’t think it can be done. Which is why we tailor made our UI for JavaScript errors. Everything about our UI is built on the idea of helping you find and fix your frontend errors. Stack trace parsing, sourcemap processing, telemetry gathering. All of it.
Frontend is Different
Frontend error monitoring is a different paradigm than backend. With frontend error monitoring you’re trying to capture errors that happen on remote devices out of your control. Oftentimes running a hodgepodge of incredibly untrustworthy interpreted code. And the errors often only happen in certain circumstances when users take specific actions.
Then all that data needs to be shipped over the internet back to a central location for processing and analysis. And there’s a lot of it. The error volume from frontend can easily be 10x or higher than backend.
Once you’ve got the data, you’ve got to figure out what the heck went wrong. Because things always go wrong in that kind of wild west environment, especially when end users are involved. You need all the telemetry and context you can get!
Contrast this with monitoring errors on a server in a language like Java. You own the hardware, you control all the code, and there are dozens of mature logging platforms for Java. In most cases you get reasonable stack traces that point right at the offending problem, out of the box.
Heck, at TrackJS, a huge percentage of our code is C#/.Net. We have a simple logger that pushes everything to an elasticsearch instance. We wrote a custom frontend to query it in about six seconds. We’ve never wanted more in 10 years.
The bottom line is you need a different kind of tool for frontend vs. backend error monitoring.
Summing it Up
We offer the best frontend error monitoring tool around. Seriously, we have the ratings to back that up. On top of that, we have exceptional customer support. But it’s all predicated on keeping our scope reasonable. We’d love to monitor all the languages and support every use case, but we’ve chosen a different approach.
We’ve decided to do one thing and do it well.
And that means we only support JavaScript.
