Show HN: Time travel debugger for web development • Hacker News Board

Re: Show HN: Time travel debugger for web development

#201

Post by aryik » Thu, Sep 16, 2021, 5:32 AM UTC

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…

Congrats on the launch! This looks awesome. I would love to see this for Ruby and other backend languages, I will definitely check it out at that point. I really like the unique approach, and I frequently struggle with breakpoints in rails because the call stack gets so deep. Being able to set a break point where the error occurs and step back through time would be a huge win.

Re: Show HN: Time travel debugger for web development

#202

Post by danfritz » Thu, Sep 16, 2021, 6:41 AM UTC

jazzdan wrote: post #149

danfritz wrote: post #144

Earlier quoted context omitted.

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!

I just made an account did a recording but cannot seem to see the network request tab anywhere in the ui? I can make a brakepoint, add console.log statements and evaluate stuff (pretty cool tech) but where do I find network requests?

Re: Show HN: Time travel debugger for web development

#203

Post by quickthrower2 » Thu, Sep 16, 2021, 7:41 AM UTC

cambaceres wrote: post #198

mattmanser wrote: post #180

Earlier quoted context omitted.

Err, conditional breakpoints are your friend. Also the GP claims "nobody" uses breakpoints? Everyone in my team uses them all the time. Suppose it all depends on your language/tool chain, in my experience breakpoints are very commonly used by developers in visual studio.

I assume he referred to breakpoints in the browser.

Chrome does conditional breakpoints - just edit the breakpoint and type your condition in - but it massively slows down the page of that code gets hit a lot.

So much so that I prefer to put the condition in my local build as source code then put a normal breakpoint on that after it has rebuilt (a few millseconds with a good watcher)

Re: Show HN: Time travel debugger for web development

#204

Post by yreg » Thu, Sep 16, 2021, 8:04 AM UTC

jasonlaster11 wrote: post #115

z3j4e wrote: post #65

I would like to try it but sadly the only way to register an account is by using google. Thanks no.

Apologies for that. That was what was easiest. How would you like to sign up?

I prefer email. Why do I need to sign up anyway?

Re: Show HN: Time travel debugger for web development

#205

Post by yreg » Thu, Sep 16, 2021, 8:10 AM UTC

Is it correct that to use this I need to download their app and then enter my Google password inside it?

How do I know it's safe? Is there any other way to try it out?

Re: Show HN: Time travel debugger for web development

#206

Post by somehnacct3757 » Thu, Sep 16, 2021, 12:07 PM UTC

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…

I don't like that your marketing story normalizes not learning breakpoints. It's like the popular guy at school being self-deprecating and charismatic about being bad at math. You shouldn't position yourself as an alternative to breakpoints because you're going to alienate a lot of more experienced devs who are comfortable using a debugger.

Replay does look interesting. I'm wondering about an itch I can't yet scratch. If someone on my team knows how to repro, we don't really need Replay. I have repro steps and control of the environment. But if a customer in the field has a bug reproduceable that we can't reproduce in house, this is my itch. What is the least friction and least invasive way to get a Replay recording in that scenario?

Re: Show HN: Time travel debugger for web development

#207

Post by _hilro » Thu, Sep 16, 2021, 1:17 PM UTC

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.

If Firefox does anything to make itself more attractive to developers, then Mitchells puppet masters will stop giving her the vast sums of money needed to enrich herself and her social activist friends.

Better to spin out desirable features (like this) and buy in undesirable features(e.g. Pocket)

Re: Show HN: Time travel debugger for web development

#208

Post by edelhans » Thu, Sep 16, 2021, 1:27 PM UTC

This looks very cool! How well does this play together with browser APIs, specifically anything that uses the media source extension?

Re: Show HN: Time travel debugger for web development

#209

Post by jazzdan » Thu, Sep 16, 2021, 2:13 PM UTC

username3 wrote: post #200

Can this show code coverage like WebStorm’s spy-js to show which code was executed?

(Replay engineer): Kind of! In the code viewer's left hand side gutter, the one that shows line numbers, if a line of code was never executed it is greyed out. Otherwise if you hover over it we show you how many times that code was executed, and from there you can set a logpoint/breakpoint.

Re: Show HN: Time travel debugger for web development

#210

Post by fake-news » Thu, Sep 16, 2021, 2:57 PM UTC

jazzdan wrote: post #118

arathore wrote: post #106

Earlier quoted context omitted.

Currently the only way to sign up for a personal account is through google. Is there another way that I am missing, or are there any plans to provide email based signups in the future?

(Replay engineer) Google is currently the only way unfortunately. We wanted to support secure logins at launch, with SSO and Multi-factor Authentication, and focus most of our efforts on the core product. As a result we just went with Google for launch. We don't currently have any plans to add additional authentication mechanisms but we've heard this feedback from a couple folks and we'll sit down to prioritize it af…

Even for Google logins, would you consider using a token-based authentication system (like Spotify, Postman, etc. do)... i.e., your default browser opens, Google logs you in there (or you already are), and that sends a backend auth token to your service to connect your Google and Replay accounts.

I would like to try your product, but am wary of typing in my Google credentials into an unknown, black-box browser. It's too easy to MITM, especially if someone redistributes a copy with a keylogger shimmed in.

The token-based auth means you can still log in with Google but never have to share your Google password with the proprietary Replay browser. Probably many of the multi-login vendors support something similar already if you don't want to deal with it yourself.