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

71–80 of 223 posts

Re: Show HN: Time travel debugger for web development

#71

Post by loganfsmyth »

parksy wrote: post #35
loganfsmyth wrote: post #12

Earlier quoted context omitted.

Once a recording is made, you can jump around in it as much as you like. The network requests will only be made during the initial recording process as they would normally, and when debugging it will all be pulling the request/response data from the recording itself rather than querying the network.

That's a big selling point for me, props to the engineering team for accommodating this, I work mainly on integrations and the trickier bug reports are weird edge cases that involve a lot of getting specific descriptions of what happened and replicating it manually on a sandbox so as not to impact API calls, getting on the phone to talk through exactly what they're doing, asking for screenshots via email, clarifying…

> What's the timeline on Windows support?

Work on Windows support in ongoing now and we're hoping to have at least an initial beta Windows release some time in the next month or two ideally, though it certainly depends on if anything unexpected comes up.

Re: Show HN: Time travel debugger for web development

#73

Post by matsemann »

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 (Kotlin ftw) it works great.

Combined with hot swapping, one can even drop the frame, change the implementation of the function and then reenter, making it possible to test code changes without spending long time getting back into the same state/context.

Re: Show HN: Time travel debugger for web development

#74

Post by parksy »

Cthulhu_ wrote: post #14
parksy wrote: post #10

In my line of work I've found the most difficult issues to debug are asynchronous dependencies on API actions. How nicely does replay work with POST data, if I scrub back and forth will I retrigger POSTs or is the request/response captured and emulated in the replays? If replay handles this nicely then I'm very very interested in adding it to our workflows.

It's definitely possible to abstract away HTTP requests for debug purposes; Cypress is one example, which makes a snapshot of the DOM and a log of what happened for every event, and allows the user to stub out HTTP requests. Redux's time traveling debugger omitted HTTP entirely, instead only logging changes in the state.

Cheers for the heads up on cypress, not sure how I've missed it but I've added to my reading list and I'll be doing a deep dive. I'm using redux on my current side project and loving being able to scrub through state changes.

My angle on this thread is that I don't have much control over the frontend frameworks and usually when I land in an enterprise integration job a lot of the broader architecture is already in place - longer term I can have some influence but generally debugging involves numerous stakeholders. A tool like replay seems useful because most testers / users are reporting issues from their direct experience using the frontend, and being able to record and scrub through their interactions would be a massive timesaver, in lieu of setting up custom testing frameworks etc.

I get what you're saying though, and I'll definitely check out cypress, just wanted to add some context.

Re: Show HN: Time travel debugger for web development

#75

Post by eljimmy »

rubyist5eva wrote: post #46
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…

>nobody uses breakpoints Lost me here, using breakpoints are an invaluable tool for people that actually take the time to use their tools correctly.

I'm inclined to agree - I use breakpoints all the time when I'm debugging JS code and it is most definitely an invaluable tool.

It can be a bit cumbersome to setup and it can be a little buggy especially when you're working with transpiled code, but to say no one uses breakpoints is a bit disingenuous.

Re: Show HN: Time travel debugger for web development

#76

Post by mysterydip »

rubyist5eva wrote: post #48
mysterydip wrote: post #9

Earlier quoted context omitted.

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!

Which debugger do you use because I live in JetBrains tools and their debugger front-end support for conditional or on exception break points is phenomenal

What I mean is coming up with a condition to make as a watch/breakpoint isn't always obvious. Especially with errors that happen "sometimes randomly".

Re: Show HN: Time travel debugger for web development

#77

Post by otrahuevada »

While I both love it and need exactly what it provides, I have to say I felt very disappointed when I clicked the CTA with a windows icon only to be greeted by a notice that it just isn't there yet.

Would it be possible to communicate this by disabling the button and adding some kind of "coming soon" messaging straight to its right?

Re: Show HN: Time travel debugger for web development

#78

Post by criddell »

billti wrote: post #27

Looks very cool. When I've been working on native code on Windows, the WinDbg time-travel feature has been a magical experience that's saved countless hours ( https://docs.microsoft.com/en-us/windows-hardware/drivers/de... ). I expect and hope this will do the same for web development. p.s. On some pages (e.g. https://www.replay.io/pricing ), I only see the Mac download button, even though I'm running Edge on Windows…

I use WinDbg for analyzing crash dumps and there's so much I don't understand about the process (I basically follow a step-by-step sequence I made a few years ago).

Any advice for leveling up WinDbg skills, especially as they relate to post mortem analysis? I suspect I also need to develop better assembly (or is it machine?) language skills. I'd like to learn a lot more about this stuff but resources (free or paid) are hard to find.

Re: Show HN: Time travel debugger for web development

#79

Post by theryanjduffy »

junon wrote: post #29

I just get "Replay has been updated - please refresh" in an endless loop.

Hey! Sorry to hear you're having an issue. That message occurs when we try to asynchronously load a JavaScript bundle for the app and it fails. Typically, that's because we've updated the app and that bundle has been replaced with another file.

That shouldn't be the case for you though so perhaps there's a network issue? Clearing your cache and trying again might resolve it. Feel free to jump on our discord (https://replay.io/discord) and we can help troubleshoot more together.

Re: Show HN: Time travel debugger for web development

#80

Post by onionisafruit »

mysterydip wrote: post #76
rubyist5eva wrote: post #48

Earlier quoted context omitted.

Which debugger do you use because I live in JetBrains tools and their debugger front-end support for conditional or on exception break points is phenomenal

What I mean is coming up with a condition to make as a watch/breakpoint isn't always obvious. Especially with errors that happen "sometimes randomly".

That’s exactly where replay should shine. Stick a breakpoint in your error handler, then rewind when it breaks.
Post reply on HN