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?
replies(2):
I'm building a JavaScript debugger called Wirebrowser. It combines network inspection, request rewriting, heap snapshots, and live object search.
The main experimental feature is BDHS (Breakpoint-Driven Heap Search): it hooks into the JavaScript debugger and automatically captures a heap snapshot at every pause and performs a targeted search for the value or structure of interest. This reveals the moment a value appears in memory and the user-land function responsible for creating it.
Another interesting feature is the Live Object Search: it inspects runtime objects (not just snapshots), supports regex and object similarity, and lets you patch objects directly at runtime.
Whitepaper: https://fcavallarin.github.io/wirebrowser/BDHS-Origin-Trace
Feedback very welcome, especially on whether BDHS would help your debugging workflow.
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.
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.