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

61–70 of 223 posts

Re: Show HN: Time travel debugger for web development

#61

Post by gavinray »

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.

I asked about this (whether it could be done as a browser extension) and the answer I was given was that the browser was required because they do things like hook syscalls and other close-to-the-metal stuff

From: https://www.notion.so/How-Replay-works-cc65abf5eb11443586abb...

  So if you can’t capture API calls directly, what do you do? You drop down one level and record the browser system calls. This probably sounds like a terrible idea. We started off with a simple 3 line JS program with one API call and one clock and instead of just recording these two calls, we’re now recording a program with millions of lines of C++ and the complexity of an Operating System. Yep! It’s crazy, but works, and it’s pretty awesome.

  So the nice thing about system calls is there are not too many of them and they don’t change that often. This means that instead of recording an API call directly, we can record the network engine’s system calls to open socket and process packets from the server. And by recording at this level, it’s possible to replay the website exactly as it ran before, with the same performance characteristics and everything else. It’s a little bit like putting your browser into “the Matrix” and tricking it into believing everything is normal, when in fact it is just running in a simulation.

Re: Show HN: Time travel debugger for web development

#62

Post by theryanjduffy »

jalopy wrote: post #52

This looks fantastic. Can't wait to try it out. I want this to succeed, so I want the company to succeed. On that note I think you guys should change up your pricing. Seems like there's too big a gap b/w the free forever (individual) and $20/mo/user for team. I'd love to pay for this as an individual at a smaller amount - like $10/mo - for a few extra features. Or maybe reduce the functionality of free forever.

(Replay employee): Thanks for the feedback and so glad to hear you're excited about Replay! Our focus right now is getting Replay into more people's workflows so we can learn and improve the product.

The great thing about the individual plan is that you have access to the complete feature set of recording and replaying and can invite collaborators to work with others.

I'd encourage you to jump in, start using the product and sharing feedback with us and that'll help Replay immensely.

Re: Show HN: Time travel debugger for web development

#64

Post by bentlegen »

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

The debugger in devtools also has these capabilities.

Re: Show HN: Time travel debugger for web development

#66

Post by hibbelig »

At my job, we do Java, and it would be wonderful to have something like this. I litter System.err.println around the code then run it so I can better understand the behavior, so the idea of doing the equivalent in a recording would be awesome! I don't know how my colleagues manage with a regular debugger, it's like looking through a pinhole, you only see a tiny part of reality.

Re: Show HN: Time travel debugger for web development

#67

Post by Vinnl »

ryansolid wrote: post #33

I am a JavaScript framework author, and was one of those fortunate to get early access and honestly it is the most useful tool I've ever used in the debugging space. Sometimes things are complicated. Often there is a need to do digging to uncover the issue. Being able to move forward and backwards and even jumping between seemingly disjoint parts of the timeline are all at your disposal with Replay. Replay has saved…

I've also been so lucky as to have been able to play with it for a while now, and can corroborate that it's super useful. It's not just a better alternative to something else; it's a whole new category of debugging tools, in the sense that there were problems that were pretty hard to debug and are much easier now that Replay is available.

Re: Show HN: Time travel debugger for web development

#68

Post by LeonidBugaev »

jazzdan wrote: post #60
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

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

Re: Show HN: Time travel debugger for web development

#69

Post by ziml77 »

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…

It's certainly a combination of these things. I use breakpoints all the time when I'm working with C# because I'm inside Visual Studio. It's super easy to work with the debugger there. With Source Link I can even step into other libraries of ours. Debugging C++ under VS is also not bad, and Python in PyCharm is a good experience.

But if I don't have VS or PyCharm available, I'll switch to printf debugging.

Though there are some cases where even with a good debugger I'll end up debugging by modifying the code. Sometimes it's necessary for performance reasons. Conditional breakpoints when debugging C# are extremely expensive so tossing one on a line that's executed many times may make the process far too slow. In that case it's better to compile in an if statement and then drop the breakpoint inside there. Other times the debugger is just limited in what information it can provide. Pointers to arrays in C++ are a common annoyance since the debugger has no length information.

Re: Show HN: Time travel debugger for web development

#70

Post by parksy »

kannanvijayan wrote: post #38
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.

Logan already answered this somewhat but I thought I'd elaborate. During replay we sandbox the entire replaying browser and trap all external IO requests using custom handlers which feed in the original recorded response for that IO request. Replay does this at the system API level, catching network IO, disk IO, IPC, and any other system interaction done by the recorded browser. Async dependencies are a tough nut to…

It's definitely a well-considered approach. I don't have to care about the framework that's been used or set up a custom proxy to capture and replay / simulate API actions, you're literally recording system-level calls and that would be extremely valuable for replaying those annoying edge-case race conditions that seem nigh-impossible to track down without significant effort at replicating exact steps and timings.

I mentioned in my other comment about Windows support, but even better if you could do something like browserstack, where I could just direct users to a URL where in the backend you guys are running the replay browser, but from their perspective they're just "using the website", that would be a killer feature. "Here, go to this URL and make the bug happen again, as soon as it happens click the little bug icon" - wouldn't have to convince an IT department to allow custom software on their COE, I could foot the bill and pass it on in my invoices so don't need to convince their accounting to approve licensing, etc, and you wouldn't need to compile OS-specific clients...

Anyway I digress, really cool stuff and thanks for expanding a bit on how it works, taking something so low-level as syscalls and wrapping it up in a user-friendly interface is no mean feat - good luck!

Post reply on HN