Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Time travel debugger for web development

replay.io

Post reply on HN
Print view View original

91–100 of 223 posts

Re: Show HN: Time travel debugger for web development

#91

Post by thamer »

matsemann wrote: post #73
LeonidBugaev wrote: post #49

For those who are looking to similar tooling in back end space, check - https://undo.io/ (It can also support Golang https://docs.undo.io/GoDelve.html ) - Mozilla RR https://rr-project.org/ - GDB https://www.gnu.org/software/gdb/news/reversible.html Unfortunately, works only in Linux. https://en.wikipedia.org/wiki/Time_travel_debugging

Not exactly similar, but in IntelliJ/java one can drop the current frame in the debugger. This jumps one step up in the stack, and allows you to enter the function fresh. Can drop arbitrary many stacks to go backwards. Of course, it doesn't rollback the heap or any shared state. And playing forward again it will redo things again. So beware of side effects. But in codebases with lots of immutable data structures (Kot…

Wow! Thank you so much for this comment. I have been using IntelliJ for over 10 years and I never knew this feature existed, I just gave it a try and it's incredibly useful.

One thing I wish Java debuggers supported was the ability to move the instruction pointer to a different line, as has been possible in other debuggers for ages. Is it a JVM limitation maybe? I remember being able to drag the "current line" pointer forwards or backwards in languages like C, C++, and C# in maybe 2003. I wish I could do this with Java; dropping the whole frame is useful but this feature lets you do a lot more, like break out of a loop or skip a block of code you _just_ realized shouldn't execute.

Re: Show HN: Time travel debugger for web development

#92

Post by tempodox »

rubyn00bie wrote: post #84

Isn’t this what was in Firefox for a while before it was ripped out and I guess made into a private company? I’m pretty damn bummed by this thing.

It does look like it has Mozilla's XUL as a component. However, I've got no idea about the history of how it got there.

Re: Show HN: Time travel debugger for web development

#93

Post by frant1c »

I'm an engineer at replit and I've been using this to find and fix a bunch of nasty bugs. I love the sense of confidence this gives me. When I have the recording captured — I know for sure I can get to the root cause of the problem.

Replay also makes it easier to jump into a new codebase, I can see how things work.

Re: Show HN: Time travel debugger for web development

#95

Post by jasonlaster11 »

hunterb123 wrote: post #19
gavinray wrote: post #8

Through $DAYJOB, I happened to have a meeting with one of the founders of this company some time ago -- not about Replay, but about a "How do you do this" sort of question. After prying for technical details, Replay came up, and I asked to see it out of curiosity. Really blew my mind. Every once in a while a piece of technology comes around that doesn't quite have an equivalent. I could immediately see where being ab…

> Every once in a while a piece of technology comes around that doesn't quite have an equivalent. I dunno, https://www.rrweb.io/ comes close (closer?) and it's open source. There's also other paid solutions like FullStory and LogRocket.

Session Replay records the DOM so it can be replayed like a video. Replay.io records the browser input so the browser session can be replayed again.

The biggest difference is that when you're viewing a replay, we're re-running the identical browser on our backend. This way you can debug the real thing.

Re: Show HN: Time travel debugger for web development

#96

Post by milofeynman »

jasonlaster11 wrote: post #4

Co-founder here. It feels incredible to be sharing Replay with all of you. It's been a labor of love the past five years! Replay started off as a simple experiment in what would happen if we added a step back button and rewind button to the Debugger. We quickly realized two things. First, nobody uses breakpoints. Second, being able to share is so much more powerful than being able to rewind. Here’s how Replay works t…

Everyone in the comments is talking about using this for their own debugging, however I think the way to win with this as a business is in two places QA and Automated QA. If you have real human QA people in your org and they could run this while doing QA. If they hit a bug, and could then share a simple link to the dev team that captured their issue + the stack.

Same goes with automated QA. Record the UI tests using this, and if one fails, store the state + stack.

There are a LOT of hard problems in that workflow... Good luck!

Re: Show HN: Time travel debugger for web development

#97

Post by optymizer »

vjeux wrote: post #81
optymizer wrote: post #45

Earlier quoted context omitted.

> First, nobody uses breakpoints. It saddens me that a lot of people don't use debuggers and default to adding print statements. As far as I can tell, it's for several reasons: 1. The debugger is primitive (e.g. Godot GDScript - no conditional breakpoints or watches). 2. The debugger is unstable (e.g. Android Studio - frequently hangs, or takes a long time to populate data needlessly) 3. The debugger's UI is not frie…

My theory is that breakpoints are not useful because they let you go forward. But if you have an issue somewhere where a variable is not in the right state, it's because somewhere in the past was the issue. But you can't go back with a normal debugger. Replay allows you to go back in time which is to me the biggest breakthrough. This actually makes them useful!

Breakpoints are a tool to stop execution and land in the present. It's the debugger that decides where you can go from there. Typically they'll allow you to go into the past, but only to inspect the stack frames, because the values on the heap get overwritten. I vaguely remember that some debuggers are able to record heap writes and thus are able to show the entire state of the app at each frame, effectively "going back" and replaying stack frames. My guess is that Replay does something similar.

Re: Show HN: Time travel debugger for web development

#98

Post by lostmsu »

thamer wrote: post #91
matsemann wrote: post #73

Earlier quoted context omitted.

Not exactly similar, but in IntelliJ/java one can drop the current frame in the debugger. This jumps one step up in the stack, and allows you to enter the function fresh. Can drop arbitrary many stacks to go backwards. Of course, it doesn't rollback the heap or any shared state. And playing forward again it will redo things again. So beware of side effects. But in codebases with lots of immutable data structures (Kot…

Wow! Thank you so much for this comment. I have been using IntelliJ for over 10 years and I never knew this feature existed, I just gave it a try and it's incredibly useful. One thing I wish Java debuggers supported was the ability to move the instruction pointer to a different line, as has been possible in other debuggers for ages. Is it a JVM limitation maybe? I remember being able to drag the "current line" pointe…

> I remember being able to drag the "current line" pointer forwards or backwards in languages like C, C++, and C# in maybe 2003

This is because Visual Studio debugger was always state of the art.

Re: Show HN: Time travel debugger for web development

#99

Post by Lio »

mysterydip wrote: post #9
jasonlaster11 wrote: post #4

Co-founder here. It feels incredible to be sharing Replay with all of you. It's been a labor of love the past five years! Replay started off as a simple experiment in what would happen if we added a step back button and rewind button to the Debugger. We quickly realized two things. First, nobody uses breakpoints. Second, being able to share is so much more powerful than being able to rewind. Here’s how Replay works t…

The problem with breakpoints is my loop runs 1000 times and I only care about the one time it errors. Making watch logic for that sometimes is too complicated or changes the outcome (race conditions especially). This seems like a great solution. I'll be checking it out!

If you can trigger a debugger from a keyword it's usually pretty easy to trigger it conditionally or on an exception in the code rather than through a GUI.

That works well for ruby and javascript and probably lots of others.

e.g. something like the equivalent of

  def foo
    bar.map do |b|
     b.do_something!
     debugger if b.state == :something_youre_interested_in
    end
  rescue => e
   debugger
  end
I'm really excited by Replay. I think it will be invaluable.
Post reply on HN