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

141–150 of 223 posts

Re: Show HN: Time travel debugger for web development

#141

Post by [deleted] »

marcellus23 wrote: post #122
ddoolin wrote: post #120

Earlier quoted context omitted.

Just my anecdote: Personally I don't like using the one in Xcode (and maybe I'm missing something obvious) because I got so used to the debugger in JS land where I get access to a live REPL which functions just like the code I write. In Xcode, I'm stuck with some lldb prompt which I don't understand and definitely doesn't function like the one in JS tooling. I'm sure it could be more useful if I invested more time in…

in general, in lldb you can just do `e [swift or obj-c code]` and it will work like a REPL

[deleted]

Re: Show HN: Time travel debugger for web development

#142

Post by freediver »

skinnymuch wrote: post #138
freediver wrote: post #123

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

Your comment isn’t off putting for the reasons you gave. Your post feels smugly opinionated. If that wasn’t your intention, I don’t know what to say. Just look at your first two bullets. Passive aggressive and more.

Thanks, edited a bit for clarity. What is a better way to say it?

Re: Show HN: Time travel debugger for web development

#143

Post by hibbelig »

peheje wrote: post #128
hibbelig wrote: post #66

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.

Try to use the debugger, learn breakpoints and watches. Unsure what IDE you use, but if you use Intellij, this will get you started very quickly. https://www.youtube.com/watch?v=lAWnIP1S6UA

Very interesting. I can change a breakpoint to not break, but log, instead. This should be quite interesting. Also the option to "go back in time" by dropping a frame from the callstack is very useful. This way, it's possible to go over some part of the execution again without having to restart the whole application.

Re: Show HN: Time travel debugger for web development

#144

Post by danfritz »

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…

Does it record network calls? We often build fronts for API'S so bugs are most of the time mismatch between frontend va backend expectations

Re: Show HN: Time travel debugger for web development

#145

Post by skinnymuch »

freediver wrote: post #142
skinnymuch wrote: post #138

Earlier quoted context omitted.

Your comment isn’t off putting for the reasons you gave. Your post feels smugly opinionated. If that wasn’t your intention, I don’t know what to say. Just look at your first two bullets. Passive aggressive and more.

Thanks, edited a bit for clarity. What is a better way to say it?

It seems a lot better now. I just upvoted while before I abstained (while you appeared to be downvoted). I am in a bit of a rush right now so I only read the first two bullets. They both seem good to me now.

Thanks for not taking my comment badly or ignoring it!

I also found out about Orion by looking through your comments!

Re: Show HN: Time travel debugger for web development

#146

Post by kannanvijayan »

dorianmariefr wrote: post #136
dorianmariefr wrote: post #132

I logged in then I couldn't load my website, then it couldn't show me a recording (not sure if it saved it), then it crashed. IMHO having Firefox as a base is not a great idea, Chrome would be better and closer to what users use.

seems like it worked but now I'm stuck at "Uploading replay" https://app.replay.io/recording/8731334f-4731-4c10-beee-7e4a...

Thanks for reporting I'll take a look at what went wrong there.

I just visited the recording and the upload seems to have completed - I can view the recording from your link and debug it. I assume you shared it publicly?

Re: Show HN: Time travel debugger for web development

#147

Post by missblit »

jazzdan wrote: post #111
kodeninja wrote: post #102

Earlier quoted context omitted.

Congratulations! This looks super interesting! How are side effects (mutating HTTP calls, cookie creation, other I/O) handled?

(Replay engineer): we basically record all the inputs and outputs to a program. In the example of an HTTP request: when recording we'd record that a request was made, and the response. When replaying, rather than make the HTTP request, we return the response that was recorded. If you're interested you can learn more about how Replay works here: https://medium.com/replay-io/how-replay-works-5c9c29580c58

> Likewise, the raw pointer values don’t have an effect on the behavior of the JavaScript

There are actually some cases where raw pointer values can effect user-visible browser behavior indirectly. Notably if the pointer values affect iteration order in an associative data structure which the browser uses in some way that tickles JS differently depending on the order.

There are bunches of other bizarre edge cases you'd never think of as well that never come up (until inevitably one day they do). Another example: In old versions of Blink I've seen ligatures fail to form depending on what was in the font cache when the page was loaded.

Re: Show HN: Time travel debugger for web development

#148

Post by freediver »

skinnymuch wrote: post #145
freediver wrote: post #142

Earlier quoted context omitted.

Thanks, edited a bit for clarity. What is a better way to say it?

It seems a lot better now. I just upvoted while before I abstained (while you appeared to be downvoted). I am in a bit of a rush right now so I only read the first two bullets. They both seem good to me now. Thanks for not taking my comment badly or ignoring it! I also found out about Orion by looking through your comments!

Your comment was helpful and thanks for checking out Orion!

Re: Show HN: Time travel debugger for web development

#149

Post by jazzdan »

danfritz wrote: post #144
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…

Does it record network calls? We often build fronts for API'S so bugs are most of the time mismatch between frontend va backend expectations

(Replay engineer): Yes it does!

Re: Show HN: Time travel debugger for web development

#150

Post by glass_of_water »

I read the medium post (https://medium.com/replay-io/how-replay-works-5c9c29580c58), which gives an overview of how Replay works, but there are a few things I still don't understand.

1) How does the step backward functionality work? Do you take snapshots every so often of the Javascript environment? How do you handle destructive assignments?

2) Does Replay record actual syscalls made by the browser, or is it recording calls to the browser APIs by the javascript code (which I guess are effectively syscalls from the javascript code's perspective)?

3) The ordered lock technique described in https://medium.com/replay-io/recording-and-replaying-d6102af... makes sure that threads access a given resource in the same order, but what about threads accessing different resources in the same order? e.g. when recording, thread 1 accesses resource A before thread 2 accesses resource B. It seems like the ordered lock technique doesn't help you maintain that ordering in the replay. Is maintaining that kind of ordering across resources not actually necessary most of the time?

Post reply on HN