Show HN: Time travel debugger for web development

One thing I've thought would be useful to have is a combined debugger/logging system. I work on SQL Server and we rely heavily on dumps to figure out what happened when something goes wrong. However, that only tells you what happened at a given point of time. Obviously recording all the system state over time would be too expensive and logs can be difficult to decipher due to their volume and lack of (explicit) connection with source code.

What I'd love to see is a logging framework which records the values of program specified variables while running as well as the current stack trace plus a monotonic time so you can piece together what happens through a thread of execution over time. However, unlike traditional logging, it would be connected to the source code like how a debugger works so you could mouse over a variable to see its state over time.

Honestly it'd be really cool with a tracing system like this to be configurable without modifying source as well. Maybe trace specific functions by noting the stack trace and arguments when invoked as well as the return value.

Congrats on launching!

The good: I checked out the tool and seems to work as advertised. Also nice to see Replay browser based on a Firefox fork.

The bad (and this is more your marketing/PR/branding, not product):

- You require an account signup, OK. It's a Google only signup, OK step over that. But it did not clearly mention that you this put me on a mailing list and surely 5 minutes after I signup, I get a random email to support a launch on product hunt.

- With the amount of engineering that went into it, I would expect you to be proud of the craftsmanship and your team. Instead the top of your website states you are proud of getting money from investors. This is more a vote against this trend, than your particular behavior.

- I was able to find the post "How Replay works" [1] which is the actual content addressing your target market. The post conveys 2000 characters of information and uses 4.3MB of data to do that for a signal/noise ratio of 0.04%. It is the type of web obesity [2] that we are used to nowadays, so nothing new. Mentioning this only because you are a web engineering-centric company. Promoting the right values of web performance and engineering attention to detail is IMO important for a product talking to web engineers.

I realize this may come as unpopular/beyond conventional wisdom but getting a different perspective is what HN is good for. Use the feedback at your discretion.

Props for making an innovative product and good luck!

[1] https://medium.com/replay-io/how-replay-works-5c9c29580c58

[2] https://idlewords.com/talks/website_obesity.htm

Thanks!

(Replay engineer): In the long run we'd love for Replay to prove to the major runtimes that they should build support for this in to the runtime itself, rather than us maintaining many forks. The API that we designed for recording a runtime is open source and available here https://replay.io/driver and could serve as a good starting point.

Wonderful product! I do use debugger; statements a lot, but I'm also somewhat ashamed to admit that I love console.log()! :-)

Replay debugging is a huge step forward, and gives console.log() much more power.

Thank you!