I'm going to put in a very relevant self-plug for the tool that I work on.
I work at Replay.io, and we're building a true "time traveling debugger" for JS. Our app is meant to help simplify debugging scenarios by making it easy to record, reproduce and investigate your code.
The basic idea of Replay: Use our fork of Firefox or Chrome to make a recording of your app, load the recording in our debugger UI, and you can pause at _any_ point in the recording. In fact, you can add print statements to any line of code, and it will show you what it _would_ have printed _every time that line of code ran_!
From there, you can jump to any of those print statement hits, and do typical step debugging and inspection of variables. So, it's the best of both worlds - you can use print statements and step debugging, together, at any point in time in the recording. It also lets you inspect the DOM and the React component tree at any point as well.
I honestly wish I'd had Replay available much earlier in my career. I can think of quite a few bugs that I spent hours on that would have been _much_ easier to solve with a Replay recording. And as an OSS maintainer for Redux, there's been a number of bugs that I was _only_ able to solve myself in the last year because I was able to make a recording of a repro and investigate it further (like a tough subscription timing issue in RTK Query, or a transpilation issue in the RTK listener middleware).
If anyone would like to try it out, see https://replay.io/record-bugs for the getting started steps to use Replay (although FYI we're in the middle of a transition from Firefox to Chromium as our primary recording browser fork).
I also did a "Learn with Jason" episode where we talked about debugging concepts in general, looked at browser devtools UI features specifically, and then did an example of recording and debugging with Replay: https://www.learnwithjason.dev/travel-through-time-to-debug-...
I'm the author of the article and my advice is that you stop reading it and go learn about Replay.io instead. It's the most slept on web tech and will up your debugging game immensely. Seriously, go check it out.
>> you can use print statements and step debugging, together, at any point in time in the recording
I am working on something similar. I am building an IDE that allows to jump from the line printed by a console.log call to a corresponding code location, and observe variables and intermediate expressions.
It also displays a dynamic calltree of a program, allowing to navigate it in a time-travel manner.
Currently it only supports pure functional subset of JavaScript, but I am working on support for imperative programming (mutating data in place).
Once I can replicate an issue locally, I don’t normally find it too difficult to understand what’s happening.
Harder is reproducing a bug based on what I’ve got to go on in Sentry. Mostly it’s easy enough to figure out but the traces you get in JS are very light in information compared to what you get in Python for example.
Anyone have any tips on getting more information in the initial report?
We might be able to replay the app as a whole, but we don't currently support debugging workers that I know of. I know we don't support recording WebGL at the moment, and there's probably a couple similar recording limitations I can't think of off the top of my head.
We've got some articles linked in our docs that talk about how the recording/replay mechanism uses "effective determinism" that's close enough to the original to be accurate:
Replay's founders originally worked as engineers on the Firefox DevTools (and in fact our debugger client UI started as a fork of the FF Devtools codebase, although at this point we've rewritten basically every single feature over the last year and a half). So, the original Replay implementation started as a feature built into Firefox, and thus the current Replay recording browser you'd download has been our fork of Firefox with all the recording capabilities built in.
But, Chromium is the dominant browser today. It's what consumers use, it's devs use for daily development, and it's what testing tools like Cypress and Playwright default to running your tests in. So, we're in the process of getting our Chromium fork up to parity with Firefox.
Currently, our Chromium for Linux fork is fully stable in terms of actual recording capability, and we use it extensively for recording E2E tests for ourselves and for customers. (in fact, if you want to, all the E2E recordings for our own PRs are public - you could pop open any of the recordings from this PR I merged yesterday [0] and debug how the tests ran in CI.)
But, our Chromium fork does not yet have the UI in place to let a user manually log in and hit "Record" themselves, the way the Firefox fork does. It actually automatically records each tab you open, saves the recordings locally, and then you use our CLI tool to upload them to your account. We're actually working on this "Record" button _right now_ and hope to have that available in the next few weeks.
Meanwhile, our Chrome for Mac and Windows forks are in early alpha, and the runtime team is focusing on stability and performance.
Our goal is to get the manual recording capabilities in place ASAP so we can switch over and make Chromium the default browser you'd download to make recordings as an individual developer. It's already the default for configuring E2E test setups to record replays, since the interactive UI piece isn't necessary there.
Also, many of the new time-travel-powered features that we're building rely on capabilities exposed by our Chromium fork, which the Firefox fork doesn't have. That includes the improved React DevTools support I've built over the last year, which relies on our time-travel backend API to extract React component tree data, and then does post-processing to enable nifty things like sourcemapping original component names even if you recorded a production app. I did a talk just a couple weeks ago at React Advanced about how I built that feature [1]. Meanwhile, my teammate Brian Vaughn, who was formerly on the React core team and built most of the current React DevTools browser extension UI, has just rebuilt our React DevTools UI components and started to integrate time-travel capabilities. He just got a working example of highlighting which props/hooks/state changed for a selected component, and we've got some other neat features like jumping between each time a component rendered coming soon. All that relies on data extracted from Chromium-based recordings.
Thanks! Yeah, the browser runtime team is doing incredible work to make this possible, backend has made great progress speeding up requests and improving scaling, and us frontend folks are getting to build on top of that.
We're not currently doing active dev work on the FF fork due to the focus on Chromium, and I think the goal is to fully try to move over to Chromium as the user recording browser. So, we probably _won't_ be maintaining the FF fork going forward due to limited resources. I think our next runtime focus after Chromium parity will be Node. We've already got an alpha-level Node for Linux fork that actually works decently - I've used it myself to record Jest or Vitest tests or Node scripts, and debug them. But that does need a lot of work to flesh it out.
Replay takes data privacy seriously. Recordings can be shared, but you control who has access to them, and we need to know who owns each recording. Our user accounts are currently based on Google auth, so you have to log in before recording so we can track ownership.
Afraid not, sorry. The recording and debugging process is the same whether it's an end user or QA submitting a report, or a dev making the recording yourself. All recordings have to be uploaded in order for our backend to do the replaying work. It takes some pretty massive EC2 instances to make the replaying process happen - it's not something you'd be able to run locally.
I work at Replay.io, and we're building a true "time traveling debugger" for JS. Our app is meant to help simplify debugging scenarios by making it easy to record, reproduce and investigate your code.
The basic idea of Replay: Use our fork of Firefox or Chrome to make a recording of your app, load the recording in our debugger UI, and you can pause at _any_ point in the recording. In fact, you can add print statements to any line of code, and it will show you what it _would_ have printed _every time that line of code ran_!
From there, you can jump to any of those print statement hits, and do typical step debugging and inspection of variables. So, it's the best of both worlds - you can use print statements and step debugging, together, at any point in time in the recording. It also lets you inspect the DOM and the React component tree at any point as well.
I honestly wish I'd had Replay available much earlier in my career. I can think of quite a few bugs that I spent hours on that would have been _much_ easier to solve with a Replay recording. And as an OSS maintainer for Redux, there's been a number of bugs that I was _only_ able to solve myself in the last year because I was able to make a recording of a repro and investigate it further (like a tough subscription timing issue in RTK Query, or a transpilation issue in the RTK listener middleware).
If anyone would like to try it out, see https://replay.io/record-bugs for the getting started steps to use Replay (although FYI we're in the middle of a transition from Firefox to Chromium as our primary recording browser fork).
I also did a "Learn with Jason" episode where we talked about debugging concepts in general, looked at browser devtools UI features specifically, and then did an example of recording and debugging with Replay: https://www.learnwithjason.dev/travel-through-time-to-debug-...
If you've got any questions, please come by our Discord and ask! https://replay.io/discord