Show HN: A web debugger an ex-Cloudflare team has been working on for 4 years
It’s called Jam and it prevents product managers (like I used to be) from being able to create vague and un-reproducible bug tickets (like I used to create).
It’s actually really hard as a non-engineer to file useful bug tickets for engineers. Like, sometimes I thought I included a screenshot, but the important information the engineer needed was what was actually right outside the boundary of the screenshot I took. Or I'd write that something "didn't work" but the engineer wasn't sure if I meant that it returned an error or if it was unresponsive. So the engineer would be frustrated, I would be frustrated, and fixing stuff would slow to a halt while we went back and forth to clarify how to repro the issue over async Jira comments.
It’s actually pretty crazy that while so much has changed in how we develop software (heck, we have types in javascript now*), the way we capture and report bugs is just as manual and lossy as it was in the 1990’s. We can run assembly in the browser but there’s still no tooling to help a non-engineer show a bug to an engineer productively.
So that’s what Jam is. Dev tools + video in a link. It’s like a shareable HAR file synced to a video recording of the session. And besides video, you can use it to share an instant replay of a bug that just happened — basically a 30 second playback of the DOM as a video.
We’ve spent a lot of time adding in a ton of niceties, like Jam writes automatic repro steps for you, and Jam’s dev tools use the same keyboard shortcuts you’re used to in Chrome dev tools, and our team’s personal favorite: Jam parses GraphQL responses and pulls out mutation names and errors (which is important because GraphQL uses one endpoint for all requests and always returns a 200, meaning you usually have to sift through every GraphQL request when debugging to find the one you’re looking for)
We’re now 2 years in to the product being live and people have used Jam to fix more than 2 million bugs - which makes me so happy - but there’s still a ton to do. I wanted to open up for discussion here and get your feedback and opinions how can we make it even more valuable for you debugging?
The worst part of the engineering job is debugging and not even being able to repro the issue, it’s not even really engineering, it’s just a communication gap, one that we should be able to solve with tools. So yeah excited to get your feedback and hear your thoughts how we can make debugging just a little less frustrating.
(Jam is free to use forever — there is a paid tier for features real companies would need, but we’re keeping a large free plan forever. We learned to build products at Cloudflare and free tier is in our ethos, both my co-founder and I and about half the team is ex-Cloudflare) and what we loved there is how much great feedback we’d get because the product was mostly free to use. We definitely want to keep that going at Jam.)
By the way, we’re hiring engineers and if this is a problem that excites you, we’d love to chat: jam.dev/careers
239 comments
[ 3.3 ms ] story [ 253 ms ] threadYeah, I fell into that trap, but it's a holiday here.
They really should have gone for JSVM IR or something, but that would sell it to no one.
Joking aside, this looks really cool!
It was so neat and useful that as an engineering team we had to hide it from the rest of the company because we were worried it would be used to “spy” on employees. (Id like to note that it was only ever installed on internal tooling that was custom built)
How has jam addressed this concern?
Also, is there self hosting?
Rather than passively record sessions like the tool you’re describing, Jam is an active model. It lets you actively choose when to record the screen. That way we’re able to avoid any creepiness!
We actually get a lot of requests for self hosting and it’s something I think would be great to add in the future.
Also how future proof it is with Google changing Chrome addons permissions / API etc...?
We do two things to address that:
The first is nothing gets recorded and saved (or even sent to our backend) until the user actively chooses to log a bug. So it’s like actively choosing to save a HAR file when there’s a bug.
The second is we scrub all network requests on the client side for anything that resembles PII or sensitive data. We just don’t want it on our servers.
Is there anything else you think we should do?
Definitely building on the Chrome platform there’s always API risk of something changing but I hope Chrome and other browsers will keep it possible to provide a better debugging experience through extensions like ours for people who want it.
Edit: it looks like this is already the case!
The tool seems to be built for people who don't know what to include in a proper bug report (As they are maybe not technical enough), so not sure how helpful that choice would be for them.
My suggestion is to have a setting that lists default headers you think should be obfuscated, and the user/team can remove and add to them as they like.
0. https://jam.dev/docs/product-features/dev-tools/security
Yes! I think that's a great idea.
https://news.ycombinator.com/item?id=22376732
I generally agree with you. I think there's a few important things to note:
- Since Jam is a browser extension, its functionality only applies to the user that installed it (i.e., only you, not everyone that visits website X) - All captured data stays locally in your browser until _you choose_ to submit a bug and its details* - You can choose which sites the extension is enabled on if you want to further limit the scope of functionality - We have some user preferences to enable/disable certain functionality of Jam already, and I'm confident we'll add more over time!
* to be fully transparent: we _do_ collect application telemetry so we can identify bugs and performance issues, but we take great care in reporting information that is centered around what our application is doing, not what it is capturing.
Our company has just grown to where it isn't just some engineers and a few sales guys. Now we're trying to keep engineers working efficiently. / accurately, and the support team is ramping up. Making it easy for the sales or support guys to log a good ticket or bug is a never ending challenge. This looks like a great option.
I worked in support for ages and later moved to an engineering role, it's a mountain to climb to get good communication / reproducing things accurately enough for the engineers to really take action effectively.
+1 –– when I worked at Cloudflare, the support team had to teach all of us how to export HAR files from our browsers for engineers. It's definitely a mountain to climb to get good bug reporting working internally.
I have some feedback on your homepage & messaging.
Initially scrolling the home page I thought it was a tool for viewing customer bug sessions, similar to TrackJS or Sentry.
Reading this post it became clear this is for product managers and/or team members to file bugs. The line "Built for everyone" on the home page threw me off.
I think if you make the distinction that this is an internal tool for teams vs. an external tool for tracking customer issues it might help make this messaging clearer.
I'm not sure of your plans (perhaps you also intend for external users to use it) this was just my first pass impression.
I think this is a great tool. The structured format combined with the information provided by the extension are what make it valuable to me. The last minute feature is also nice as re-creating bugs can be a PITA.
As a dev, I would ideally also want to be able to view stack traces with source maps, but having a consistent structured format combined with the extension data is enough of a value prop to start using it.
And that's really nice to hear, thank you so much! Stack traces with source maps. I agree. We integrate now with logging tools like Sentry and I wonder if we can just use sourcemaps from that.
It's NOT built for everyone.
Right?
Session replay tools like LogRocket or Jam do capture a lot of information, but they can only capture what's _in_ the page, and are thus limited by the JS execution environment and permissions. This is still very useful for seeing what the user did in the page, and you do get a good amount of detail (video, DOM, network).
Replay.io works by capturing the browser's calls into the operating system. (This is really complicated! Our fork of Chromium has thousands of lines of custom C++ and JS modifications in order to capture the runtime information and make it queryable.) That enables actually _debugging_ any line of code that ran at any time. That's something that session replay tools _can't_ do.
So, yes, both Replay.io and session replay tools let you _see_ what happened, but only Replay.io lets you _debug_ the code _as it ran originally_. And that's only possible because we do capture the _entire_ browser's execution.
We've got some sections in our docs that dive into this in more detail:
- https://docs.replay.io/time-travel-intro/what-is-time-travel...
- https://blog.replay.io/how-replay-works
- https://docs.replay.io/comparison/session-replay
Not only does Replay.io let you _debug_ recordings of bugs, we've got a Test Suites dashboard that lets you record Playwright or Cypress E2E tests _as they ran in CI_. This is possible because we can run your E2E tests with our own browser, and thus record them as they're running.
Finally, a sneak peak: we're currently prototyping some new advanced functionality that would actually _diff_ passing and failing E2E tests to figure out where a failing test went wrong, surface that info to developers, and help them identify common failure reasons in their tests ("27% of your failures in the last month were due to Apollo Client failing to connect"). Still very early, but we've got the core functionality working! Again, this is only possible because we've recorded the _entire_ browser's execution, and can then replay that browser at will and query for every bit of JS execution that happened.
Sanitizing chrome for testing makes a lot of sense as different versions of chrome have been proven to be unreliable.
Playwright uses a sanitized chrome version.
And Cypress does not, and allows users to use their own browsers which may be a reason for some not insignificant portion of flake. They definitely had multiple instances where a particular chrome version was unstable leading to lots of customer complaints regarding their reliability.
It seems extremely inexpensive.
Even though it's not a direct comparison, look at https://www.hotjar.com/pricing/ (and switch to the "pay by month" pricing view)
They are currently quite generous with how much you can use for free or cheap, but the limits being so vague means they are subject to change without any transparency, potentially pulling the rug on you at any time. That's what I mean by suspiciously cheap.
[1]: https://www.reddit.com/r/programming/comments/lfa1il/why_you...
The reddit post you linked seems to not really have any content anymore, but I would be willing to bet they broke TOS given you are only really supposed to serve html content over CDN when on lower level plans when you are not using the developer platform to host the content such as videos/images/etc.
Fwiw though, if you are a business you probably should at the very least upgrade to business for the SLA and to create support tickets if needed.
edit: figured out why the article doesnt exist the OP removed it because it was an issue on his end not Cloudflares. (Using bot fight mode on a route supposed to be used by bots) https://news.ycombinator.com/item?id=26072153
From a funding perspective things are very different than when CF started.
Jam is for your employees to download an extension and manually submit the recordings when they have issues and is a pay per employee based model.
Jam will generally have very low volume compared to Hotjar which is where the price difference really is
I really like this idea and if Firefox support was added I would purchase it in a heartbeat.
This looks like one of those tools that is genuinely really useful. I would love be able to tell my users to just fireup a browser extension and record a bug, rather than having to step them through how to capture all that data manually.
Well Done!
Bookmarking this page for the futuere: https://jam.dev/docs/downloads-and-browsers/browser-support
So agree, the PdM should not be using Chrome.
I suggested the Kagi Orion path elsewhere in this comment page too, since that would give the PdM extensions, while still seeing what users see.
https://blog.kagi.com/orion-features
https://blog.kagi.com/orion-new-features
Someone said Safari fork but not WebKit fork.
https://news.ycombinator.com/item?id=40323838
"Can we have Firefox support? It would really help promote the Open Web."
"Sure, it was on our roadmap already."
"AKTLY You need to rewrite your app for Safari support and WebKit coverage because if you ignore that then imagine how bad the iOS experience will be!!! People will blame you instead of themselves because they're simply too domesticated to fix technology issues, so do their work for them!"
...rinse and repeat for everything Apple refuses to support themselves. We wouldn't be begging people for Safari support if it was a successful browser or if people actually cared about it in the first place.
Developers might not like it but people use it. Personally I use it for almost everything now.
We've noticed many tool devs think everyone uses Chrome (because those devs got non tech people in their social circle to install Chrome so "everyone they know" uses Chrome), but users who don't know devs just use whatever's there, and that means iPad, iPhone, and most Mac "end users" are Safari.
Along with being needed for those users, any tool that looks this good and works this magically is also going to appeal to dev teams that can appreciate why users like iPhones and designers like Macs, those teams will want this to work in Safari too.
That said, if you couldn't readily support Safari, I wonder if your extension could be adapted to work in Kagi's Orion browser that supports Chrome and Firefox extensions (to an extent), while being based on WebKit. Perhaps that's a path that could allow webkit debugging.
We would definitely pay for a Safari extension to be installed from Apple app store for each of our UX devs, product managers, and canary users.
For enterprise deployment, it needs to come from Apple app store or be distributed as an installable package through an automation mechanism. MAS (Mac app store) is easiest.
The extension needs to either be free, or have a "full price" version, so that it can be licensed per seat/user through corporate volume purchasing to run on employee devices. The way managed devices work, there's no way for companies to pay for employees to use in-app purchases (IAP).
[1]: https://gs.statcounter.com/browser-market-share
God I wish there was something like this for mobile apps, though. Or a website running on the user's mobile device browser. I know Firefox Android does support extensions, but most people on Android use Chrome. And I think on iOS the browser extension situation was miserable the last time I read about it. Either way, an app would probably be the best way to do it.
Edit: never mind - I see this is a browser extension, so kind of a non-starter.
I like the idea of the browser extension being able to offer these kinds of tools where you wouldn't need to install a heavy Javascript snippet -- but I do think that taking the manual steps out of debugging wherever you can is the most efficient. With Bugsnag et al, I don't need to wait for a user to contact me. I shouldn't have to wait for someone to submit a Jam report in order to see how healthy my app is.
Sentry/Bugsnag etc track code errors and exception. But sometimes for an user an error is not a code exception, but the software having the wrong behaviour.
Some examples:
> "The button brings me to the wrong page"
> "I filled out the whole form but the submit button is not enabled"
> "The video should autoplay but is stuck loading"
Those things do not show up in Sentry logs.
This tool allows the reporter to select when data should be collected