it looks to me like it covers the same funcionality as browser developer tools

but I am also pretty sure those are going away soon, which will mean the only way to inspect websites will be using tools like this (+ WASM binary formats + google controlled web-runtime[0] means the open web is not open anymore)

[0] https://thewebshowcase.withgoogle.com/bring-code-from-platfo...

Why do you think they'd go away? As far as I'm aware all major browsers continue to add new functionality to their dev tools.

Your browser's dev tools don't show you what's happening inside your server (and any downstream services) when responding to the browser's HTTP requests. Spotlight does. That's what's special about it.

What? JS isn't getting replaced by WASM. Also some quick Googling says WASM is a joint project by the W3C and multiple browser owners, and debug tools exist for it in Chrome and Firefox already

I also have no idea what it does. "Sentry for development", so it works like sentry but the errors are streamed to localhost??

That’s a good way to think about it yeah. It’s not 1:1, and also can be extended beyond Sentry, but that was our MVP.

I don't understand the use case. If it's local, I'll just get a nice traceback and I can use the normal debugger. So what's the point of this?

Not in all cases do you get a traceback into the UI. In some cases you have to look at your terminal or console. In this case it goes straight into your browser window. But additionally it also shows you a bunch of traces going on for instrumented calls.

This seems to be a super shared point of view. I’ll admit we were a bit fire-and-forget on the homepage and definitely agree with all the feedback that we need to explain what it is better.

Is this supposed to be intended for people who are already all-in with Sentry? Or can you possibly share some insight as to where this makes sense to use vs instrumenting with an OTEL SDK?

Both. Fwiw lots of folks have yet to invest in OTel so the market is super open. We’re also trying to adjust our approach to leverage OTels community instrumentation when it makes sense. That means that ideally you’ll be able to invest in OTel if you want and we’ll just consume those spans.

The other thing to note: OTel doesn’t do everything and Sentrys error context is a big part of the value prop.

Thanks for the reply. Would the Spotlight sidecar possibly be able to run independently and consume spans emitted by the Sentry exporter[0] or some other similar flow beyond strictly exporting directly from the Sentry SDK provided by Spotlight?

This tooling looks really cool and I'd love to play around with it, but am already pretty entrenched into OTel and funneling data through the collector and don't want to introduce too much additional overhead for devs.

[0] https://github.com/open-telemetry/opentelemetry-collector-co...

Yeah it absolutely could. Our docs aren’t great here and we may need to improve the APIs but it was important for us to not couple this to Sentry.

The idea is that any data source could stream to the sidecar and at the same time consume from it with a curated panel in the UI.

If you’re interested in poking around def hop in our Discord (https://discord.gg/sentry #spotlight) and let us know your thoughts.

I agree and find this is the case for many projects like this. I read the homepage and have no idea what the tool does and why I might find it helpful, it wasn’t until I read the inset block on the “Getting Started” page for this one that I had even an inkling what it did.

Most of these types of home page seem to be written assuming I already know what their tool does.