BDHS seems strictly less powerful than a time travel debugger. You can just set a hardware breakpoint and run backwards until the value is set.

Why not just do proper time travel? Is that absent for Javascript?

▲

fcavallarin 4 days ago | parent | next [-]

Good point - in theory a full time-travel debugger is more powerful. The practical limitation is that time-travel for JavaScript usually requires instrumenting the code or running inside a custom record/replay environment. Today, JavaScript doesn’t expose any record/replay mechanism, access to hardware breakpoints, or the internal VM state needed to run execution backwards.

The browser’s debugging API (CDP) also doesn’t provide a way to capture or rewind engine state without modifying the application.

BDHS works within the constraints of zero instrumentation: it relies only on Debugger.paused and heap snapshots, so it can trace where a value originates without altering the code being debugged.

▲

acemarke 4 days ago | parent | prev [-]

We actually built a full-blown time travel debugger for Javascript at Replay.io:

- https://www.replay.io/devtools

	▲	fcavallarin 4 days ago \| parent [-]
		Replay is really impressive - having a record/replay runtime that can capture all the inputs to the JS engine and reproduce execution deterministically is in a completely different category from what CDP exposes. That’s what enables true time-travel debugging. Wirebrowser sits at the other end of the spectrum: it attaches to any unmodified browser that supports CDP and works directly with the live runtime. The workflows end up being very different, but it’s fascinating to see what becomes possible when the runtime itself participates in the recording.