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.
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.
Everybody who works at TrackJS is a very high level JS developer. All of us. When you email support at firstname.lastname@example.org, 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?
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.
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.