compare · jam
A Jam alternative for React teams who want the file.
Zidl runs inside the app, so it resolves the component and file behind the click. Jam watches from a browser extension, which is exactly why it cannot.
What Zidl does that Jam cannot
An extension observes your app from the outside. Zidl is loaded by your app, so it reads React internals directly — and that one difference is the whole list.
- Component and file, not coordinates. The clicked element resolves to
src/components/Checkout.tsx:87:11and opens in the editor. - The repro is code. Recorded steps export as a Playwright spec using role, test-id and label locators — a test that outlives the report.
- It is a board, not a link. Reports carry severity, labels and assignees and sync to one list per project. See the board.
Extension or script tag: the trade you are making
Jam and Zidl sit on opposite sides of one decision, and almost every difference between them falls out of it.
| The consequence | |
|---|---|
| Jam: a browser extension | Installs per person, not per app. Works on every site including production, from the first minute, with nothing shipped. Hooks devtools, so it sees console and network. Cannot see React's fiber tree, because that is in the page's memory, not the browser's. |
| Zidl: a script tag in your app | Installs per app, not per person, so everyone who opens the app has it. Same-origin, so it reads the fiber tree and resolves the file. Needs a build that carries debug data, which means staging or development, not production. |
Neither side of that is a bug. It is why a team that wants the file path has to accept a tag on the build, and why a team that wants zero deployment has to accept coordinates instead of a component name.
What the developer actually receives
From Jam: a link to a replay with the last stretch of console output and the network requests attached, plus the environment it happened in. From Zidl:
BUG-014 · high · bug
"Place order" overflows its container at 375px
source src/components/Checkout.tsx:87:11
route /checkout?tab,id
surface modal
steps 4 recorded → checkout.spec.tsJam's artifact is richer about what the browser was doing. Zidl's is more specific about where in your codebase to go and how to get back there. Which one is worth more depends entirely on whether your bugs are usually a broken request or a broken screen.
Side by side
| Jam → Zidl | |
|---|---|
| Source file, line and component | Zidl only |
| Repro as a runnable Playwright test | Zidl only |
| Opens the element in your editor | Zidl only |
| Annotations over the live DOM | Zidl only |
| Severity, labels, assignees on a shared board | Zidl |
| Everyone gets it by opening the app | Zidl |
| Console and network capture | Jam only |
| Instant replay of what just happened | Jam only |
| Nothing to install in your app | Jam |
| Works on production and any framework | Jam |
| Works on sites you do not own | Jam |
Where Jam is the better choice
Jam hooks into devtools, so it carries things a page script cannot easily see — inspectable network requests, the last stretch of console output, an instant replay — and there is nothing to deploy, on any site including production. For an incident you did not ship a tag for, that is not a small advantage; it is the only thing that works.
It also has a distribution advantage that is easy to underrate. An extension is installed by the person, so it is there on every site they visit, including the third-party tools and vendor dashboards where your team also finds bugs. A script tag only exists where you put it.
Moving over
Do not. This is the one comparison on the site where the honest recommendation is to run both, because they fail in opposite directions.
- Keep the extension for production incidents and for sites you do not own.
- Add the Zidl tag to staging, where the debug data exists and the reports come from your own QA. See the docs.
- Send anything visual — layout, state, "this component is wrong" — through Zidl, so the file path is waiting on the other end.
Questions people ask when comparing the two
Does everyone on the team have to install something?
No, and this is the quiet advantage of a script tag. Zidl arrives with the app, so anyone who opens staging already has it — including the person who found a bug once and would never have installed an extension for it. An extension has to be installed by each reporter individually before it can help.
Can we run Jam and Zidl at the same time?
Yes. They do not interact — Zidl mounts in a shadow root inside the page and an extension operates from the browser. There is no reason to choose, and good reason not to.
Why can an extension not resolve the component?
Because React's fiber tree lives in the page's own memory, not in the DOM and not in anything the browser exposes to an extension. Code has to be running on the same origin inside the app to read it, which is the entire reason Zidl asks for a script tag rather than shipping as an extension. See source detection.