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

81–90 of 223 posts

Re: Show HN: Time travel debugger for web development

#81

Post by vjeux »

optymizer wrote: post #45
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…

> 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!

Re: Show HN: Time travel debugger for web development

#82

Post by _0ffh »

jasonlaster11 wrote: post #28
throwaway59553 wrote: post #25

You guys have a download button for Mac OS X (apple logo), and you have a button with the Windows logo. But there isn't a windows version yet as the pop-up tells me. And why isn't there a linux button, if you actually have a linux version?

The button is platform specific. So if you're on linux, it should show the linux icon. Windows support is on the way. It just entered alpha two weeks ago and we're targeting Beta early october. We record low level windows os calls and replay them on linux in a virtualized environment. Frankly thrilled it works at all :)

I'm on Linux and I only get the Apple download button (on FF, and I have not messed with the browser ID string).

Re: Show HN: Time travel debugger for web development

#83

Post by jaril »

onionisafruit wrote: post #80
mysterydip wrote: post #76

Earlier quoted context omitted.

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.

Actually it might be even easier — if your specific error shows up in the console, there's a handy rewind button right beside it :)

Re: Show HN: Time travel debugger for web development

#85

Post by kannanvijayan »

LeonidBugaev wrote: post #68
jazzdan wrote: post #60

Earlier quoted context omitted.

(Replay engineer): We're big fans of RR and pernosco, I love to see those tools get their due. Replay is also designed to support backend programs. We [support Node]( https://github.com/RecordReplay/node ) today with more runtimes coming soon.

Do you support it only for dynamic languages, where possible to monkey patch code? All the debuggers mentioned above for the backend work only under Linux, because from what I understand, they use `ptrace` syscall, and on Mac have completely different format, and different capabilities. Do you plan support Golang, especially on Mac, maybe with custom fork, or similar? Thank you!

I'm not Dan but I also work at Replay.io.

The runtime infrastructure can support all of those. The current recorded browser runs on mac, and the mac image is replayed in a linux backend (with the system calls being handled by the replay engine).

Our initial launch is with a modified Firefox browser on Mac, but the infrastructure itself is generalizable to other runtimes and other operating systems.

However, we do need to "paravirtualize" the runtimes that are recorded on our system (modify the underlying runtime to make it aware that it's being recorded, and do some integration work for each runtime). The design of our system allows for new runtimes to plug in and use all the same infrastructure for replaying.

So the long answer is that we can support them, but support for each runtime will arrive as we prioritize and complete the implementation for them.

Currently we have the mac Firefox-forked browser. In the works we have a chrome browser, nodejs backend, and a firefox fork for windows. But realistically we should be able to support `(any runtime x any os)` within reasonable bounds. Record and replay all the things :)

Re: Show HN: Time travel debugger for web development

#86

Post by junon »

theryanjduffy wrote: post #79
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:/…

I'm using just a slightly outdated browser, which is probably the cause. I'm on Ungoogled Chromium 81 (by choice) which doesn't automatically update, and the ||= (boolean OR assignment) operator wasn't added until 85.

Your payload appears to compile down for older browsers (as is evident by the use of `var`, unless.. you actually write code using `var`) but it misses the ||= operator transformation it seems.

Thus, the browser throws a syntax error, which your app interprets as "new version" for some reason.

By the way, please don't disable right clicking. It doesn't actually solve any problems and only annoys users.

Re: Show HN: Time travel debugger for web development

#88

Post by jazzdan »

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…

(Replay engineer): re: Windows, we have an alpha build out now, with a wider beta release coming later this year.

re: on-prem, it's definitely something we plan to support, and something we have engineered in to the infrastructure. If you're interested email hi@replay.io, we'd love to talk more.

Re: Show HN: Time travel debugger for web development

#89

Post by mhdhn »

optymizer wrote: post #45
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…

> 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…

I think it's often that the compiler/environment do not leave enough information for the debugger, typically by optimizing out local variable names and their values. By the time you figure out the obscure settings to be able to see the live values of variables and other state, you may have done a lot more surgery on your build system and slowed things down to a crawl compared to adding a few print statements.

Re: Show HN: Time travel debugger for web development

#90

Post by bichiliad »

optymizer wrote: post #45
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…

> 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…

I think print statements are actually useful in ways that typical debuggers are not meant to be; they make it easy to show changes over time, and they provide a tight feedback loop between observing the value of some data and performing interactions that update that data. For example, if you wanted to know how a coordinate calculation changed as you scrolled the page, print statements would be more useful than a debugger. I don't think this is exclusively why debuggers get less use, but I think that print statements aren't inherently a thing to optimize away from.
Post reply on HN