9 ms·

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 experi

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 today. Somebody on the team records a bug with the Replay Browser and shares the replay url with the team. From there, developers jump in and add print statements. The logs appear in the Console immediately so you don’t need to refresh and reproduce a thing. Over the past year we’ve talked to hundreds of users, recorded 2.5 million replays, and worked incredibly hard to ensure Replay would be fast, secure, and robust from the get go. Want to check it out? You can download Replay today. Can’t wait to hear what you think! Interested in learning more, here is our announcement blog post https://medium.com/replay-io/launching-replay-the-time-travel-debugger-for-the-web-f886f0897d38 https://medium.com/replay-io/launching-replay-the-time-trave...

swyx 5y ago
are there any public replays you can share so pple can get a feel of the product without downloading?
- jasonlaster11 5y ago
  Yep! Tons on the site. Here's a Replay with an algolia search bug. Try adding a print statement in Hits.js! https://app.replay.io/recording/cf2da81f-3a74-45ba-9241-f6d4361a52f5 https://app.replay.io/recording/cf2da81f-3a74-45ba-9241-f6d4...
maxmcd 5y ago
How does it work? Are you making memory snapshots? Something higher level?
- jasonlaster11 5y ago
  Long story short, we forked the major browsers so that when you record we can capture the browser input (OS Library calls). Brian walks through our approach here https://medium.com/replay-io/how-replay-works-5c9c29580c58 https://medium.com/replay-io/how-replay-works-5c9c29580c58
  - maxmcd 5y ago
    thank you!
  - donio 5y ago
    How will this work on the long run? Will you try to upstream the required changes or will the forks have to be maintained perpetually?
    - jazzdan 5y ago
      (Replay engineer): In the long run we'd love for Replay to prove to the major runtimes that they should build support for this in to the runtime itself, rather than us maintaining many forks. The API that we designed for recording a runtime is open source and available here https://replay.io/driver https://replay.io/driver and could serve as a good starting point.
      - eurasiantiger 5y ago
        That’s gonna be a pipe dream unless an open source client appears. Consider releasing your tech as a self-hosted, turnkey solution and slap on some dual enterprise licensing.
        jazzdan 5y ago
        Self-hosted is on the roadmap, but getting this to be a universal technique is definitely going to be hard, no arguments there. Gotta start somewhere though!
- deleted 5y ago
  [deleted]
mysterydip 5y ago
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!
- rubyist5eva 5y ago
  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
  - bentlegen 5y ago
    The debugger in devtools also has these capabilities.
    - spicybright 5y ago
      Can confirm. Use it often both on Chrome and Firefox. I love the idea of reply, but is it targeting the wrong people to get the post leverage out of it? Print statements generally don't need to be used for debugging if you know how to use a debugger. Which really isn't difficult if you spend maybe half an hour learning it's features.
  - mysterydip 5y ago
    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".
    - onionisafruit 5y ago
      That’s exactly where replay should shine. Stick a breakpoint in your error handler, then rewind when it breaks.
      - 5y ago
scns 5y ago
Looks amazing, thank you for building it. Since React got mentioned several times on the landing page, i need to ask: is it framework agnostic?
- loganfsmyth 5y ago
  (Replay employee here): We have experimental support for some react-specific features using react-devtools since React is such a common framework, but the Replay is a general debugging tool and will work with other frameworks well too.
  - scns 5y ago
    Great. First saw one in Elm years ago, someone already mentioned prior art by Bret Victor though. Glad to see an agnostic tool for everyone.
ChrisMarshallNY 5y ago
Looks great! I hope that you can make this work.
sillysaurusx 5y ago
Love that everyone can comment on the demos :) https://app.replay.io/recording/aae188fb-57d2-46af-a23a-0adba3ed0687?point=649037107316876511996339753582719&time=777.3&hasFrames=true https://app.replay.io/recording/aae188fb-57d2-46af-a23a-0adb... Thanks for making this. It's so cool!
optymizer 5y ago
> 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 friendly (e.g. Android Studio - hitting a breakpoint in multiple threads causes unexpected jumps or loss of current state; VSCode C++ debugger - doesn't display information properly or easily (arrays of objects) or displays too much information (CPU registers, flags, memory addresses); C++ debugger for D - doesn't display D data types). 4. The debugger is not properly integrated into the environment - can't find symbols, libraries or source files, or finds the wrong source files, etc. Need to jump through hoops to configure those. 5. Platforms don't support debuggers properly (e.g. again Android - ANRs when debugging the main thread, can't leave a debugging session overnight without some timer killing the process) 6. Developers got used to the workflow of "add a print statement, rerun and check the console" since high school and nobody taught them a more powerful tool 7. Developers code all day, so adding print statements by coding feels more natural than switching to the debugger's UI and way of doing things. (e.g. "if (i == 100) console.log(value)" allows you to stay in the same code, as opposed to setting a breakpoint, finding out how to add the 'i == 100' condition and pray that there's no issue with variables being optimized out at runtime). I like Replay's features and that it's improving the state of the current tools. At the end of the day, adding print statements in Replay doesn't seem to affect the state of the application, so in that sense it's similar to gdb commands in that it's just a UI choice, but I wouldn't go as far as encouraging print-based debugging. Outside of Replay, print-based debugging is still a primitive way of analyzing the state of the app and promoting this state of affairs reduces the pool of people who use and would hopefully improve the existing debuggers. We all appreciated Firebug and the Chrome DevTools because of the powerful features they give us to inspect the state of the application. Imagine a person who adds print statements to their code every time they want to inspect the DOM or check the current CSS attributes. It works, but we have better tools, and we should make them even better.
- b3morales 5y ago
  Maybe 2a. Executing code (like a print) in an auto-continuing breakpoint action makes the program itself pause; especially tiresome when you're looking at a timing or performance issue.
rubyist5eva 5y ago
>nobody uses breakpoints Lost me here, using breakpoints are an invaluable tool for people that actually take the time to use their tools correctly.
- eljimmy 5y ago
  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.
- yanndinendal 5y ago
  That's the point: looks like a tool made to be the best of both worlds: You get access to the full debugger, at any point in time, instead of clicking "next" a hundred times and then not being able to go back if you missed something. Here you go forward or back in time, and you can visualize where you are. This thread sums-up much better than me why people use print debugging (not just because they don't want to learn a tool, or are dumb), and why Replay is the best of both worlds: https://twitter.com/geoffreylitt/status/1438152748449636360?s=20 https://twitter.com/geoffreylitt/status/1438152748449636360?...
milofeynman 5y ago
Everyone in the comments is talking about using this for their own debugging, however I think the way to win with this as a business is in two places QA and Automated QA. If you have real human QA people in your org and they could run this while doing QA. If they hit a bug, and could then share a simple link to the dev team that captured their issue + the stack. Same goes with automated QA. Record the UI tests using this, and if one fails, store the state + stack. There are a LOT of hard problems in that workflow... Good luck!
- tedmielczarek 5y ago
  You're right on the mark here. I saw rr used at Mozilla to diagnose and fix flaky tests that failed just often enough in CI to make life miserable, but were nigh-impossible to reproduce in a local development environment. Being able to take that to the next level and collaboratively investigate a bug using a recording that captures it is game-changing technology from the future. Imagine a world where instead of ignoring, skipping, or marking "known failure" on all those flaky tests your CI hits (we all have them) you could capture recordings of them, and then actually investigate and fix them! That world is possible!
kodeninja 5y ago
Congratulations! This looks super interesting! How are side effects (mutating HTTP calls, cookie creation, other I/O) handled?
- jazzdan 5y ago
  (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 https://medium.com/replay-io/how-replay-works-5c9c29580c58
  - kodeninja 5y ago
    Thanks!
  - missblit 5y ago
    > 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.
    - bhackett 5y ago
      (Replay employee) Yeah, later in the post (https://medium.com/replay-io/effective-determinism-54cc91f5693c https://medium.com/replay-io/effective-determinism-54cc91f56...) we mention needing mitigations to ensure that hashtable iteration is deterministic in cases where it affects how the browser interacts with the JS engine. There are others needed as well to ensure that the browser behaves the same across a large range of websites, my favorite is handling sites that sniff information about the system's math libraries by e.g. calling Math.sin() on specific values and testing the results --- the values when replaying need to be bitwise identical with what happened while recording.
arathore 5y ago
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?
- jazzdan 5y ago
  (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 after the excitement of launch has died down. Sorry about that!
  - arathore 5y ago
    Thanks for the update. I had a feeling that this might have been the case due to the launch crunch and it's perfectly understandable. Really excited for the future of this project!
  - fake-news 5y ago
    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.
djstein 5y ago
Congrats Jason! Know you and the team have been working super hard on this
danfritz 5y ago
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
- jazzdan 5y ago
  (Replay engineer): Yes it does!
  - amelius 5y ago
    What if the network calls depend on state in the browser and returned data depends on state at the server? And what if you are debugging a race condition in network calls?
    - jazzdan 5y ago
      Replay deterministically replays the recording, so if the state of the application when you recorded it caused a network call, then when replaying it we will also "make" a network call _but_, instead of actually going out to the network we will instead return the exact data that was returned when you recorded it. You can learn more about how Replay works here https://medium.com/replay-io/how-replay-works-5c9c29580c58 https://medium.com/replay-io/how-replay-works-5c9c29580c58 Can you expand more on what you mean by a race condition in network calls? If it's a series of network calls that the browser could make in any order than we will make them in the order that they occurred when you recorded it. If it's a race condition that occurs in your backend, then the Replay browser won't really help there (though it will show you the responses you got from your backend when you recorded it). For help with that, you might want to use Replay on the backend. Right now we have Node support (https://github.com/RecordReplay/node https://github.com/RecordReplay/node), but other runtimes are on the roadmap.
  - danfritz 5y ago
    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?
faraaz98 5y ago
Doesn't replit have a similar feature? Where you can link to different debugging states? Are you aware of that? If yes how is it different?
- jazzdan 5y ago
  (Replay engineer): Yes, replit has been working on adding similar functionality (https://blog.replit.com/debuggest https://blog.replit.com/debuggest). In fact: we've been collaborating with them on it! :)
aryik 5y ago
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.
somehnacct3757 5y ago
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?

swyx 5y ago

are there any public replays you can share so pple can get a feel of the product without downloading?

jasonlaster11 5y ago
Yep! Tons on the site. Here's a Replay with an algolia search bug. Try adding a print statement in Hits.js! https://app.replay.io/recording/cf2da81f-3a74-45ba-9241-f6d4361a52f5 https://app.replay.io/recording/cf2da81f-3a74-45ba-9241-f6d4...

maxmcd 5y ago

How does it work? Are you making memory snapshots? Something higher level?

jasonlaster11 5y ago
Long story short, we forked the major browsers so that when you record we can capture the browser input (OS Library calls). Brian walks through our approach here https://medium.com/replay-io/how-replay-works-5c9c29580c58 https://medium.com/replay-io/how-replay-works-5c9c29580c58
- maxmcd 5y ago
  thank you!
- donio 5y ago
  How will this work on the long run? Will you try to upstream the required changes or will the forks have to be maintained perpetually?
  - jazzdan 5y ago
    (Replay engineer): In the long run we'd love for Replay to prove to the major runtimes that they should build support for this in to the runtime itself, rather than us maintaining many forks. The API that we designed for recording a runtime is open source and available here https://replay.io/driver https://replay.io/driver and could serve as a good starting point.
    - eurasiantiger 5y ago
      That’s gonna be a pipe dream unless an open source client appears. Consider releasing your tech as a self-hosted, turnkey solution and slap on some dual enterprise licensing.
      - jazzdan 5y ago
        Self-hosted is on the roadmap, but getting this to be a universal technique is definitely going to be hard, no arguments there. Gotta start somewhere though!
deleted 5y ago
[deleted]

mysterydip 5y ago

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!

rubyist5eva 5y ago
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
- bentlegen 5y ago
  The debugger in devtools also has these capabilities.
  - spicybright 5y ago
    Can confirm. Use it often both on Chrome and Firefox. I love the idea of reply, but is it targeting the wrong people to get the post leverage out of it? Print statements generally don't need to be used for debugging if you know how to use a debugger. Which really isn't difficult if you spend maybe half an hour learning it's features.
- mysterydip 5y ago
  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".
  - onionisafruit 5y ago
    That’s exactly where replay should shine. Stick a breakpoint in your error handler, then rewind when it breaks.
    - 5y ago

scns 5y ago

Looks amazing, thank you for building it. Since React got mentioned several times on the landing page, i need to ask: is it framework agnostic?

loganfsmyth 5y ago
(Replay employee here): We have experimental support for some react-specific features using react-devtools since React is such a common framework, but the Replay is a general debugging tool and will work with other frameworks well too.
- scns 5y ago
  Great. First saw one in Elm years ago, someone already mentioned prior art by Bret Victor though. Glad to see an agnostic tool for everyone.

ChrisMarshallNY 5y ago

Looks great! I hope that you can make this work.

sillysaurusx 5y ago

Love that everyone can comment on the demos :) https://app.replay.io/recording/aae188fb-57d2-46af-a23a-0adba3ed0687?point=649037107316876511996339753582719&time=777.3&hasFrames=true https://app.replay.io/recording/aae188fb-57d2-46af-a23a-0adb... Thanks for making this. It's so cool!

optymizer 5y ago

> 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 friendly (e.g. Android Studio - hitting a breakpoint in multiple threads causes unexpected jumps or loss of current state; VSCode C++ debugger - doesn't display information properly or easily (arrays of objects) or displays too much information (CPU registers, flags, memory addresses); C++ debugger for D - doesn't display D data types). 4. The debugger is not properly integrated into the environment - can't find symbols, libraries or source files, or finds the wrong source files, etc. Need to jump through hoops to configure those. 5. Platforms don't support debuggers properly (e.g. again Android - ANRs when debugging the main thread, can't leave a debugging session overnight without some timer killing the process) 6. Developers got used to the workflow of "add a print statement, rerun and check the console" since high school and nobody taught them a more powerful tool 7. Developers code all day, so adding print statements by coding feels more natural than switching to the debugger's UI and way of doing things. (e.g. "if (i == 100) console.log(value)" allows you to stay in the same code, as opposed to setting a breakpoint, finding out how to add the 'i == 100' condition and pray that there's no issue with variables being optimized out at runtime). I like Replay's features and that it's improving the state of the current tools. At the end of the day, adding print statements in Replay doesn't seem to affect the state of the application, so in that sense it's similar to gdb commands in that it's just a UI choice, but I wouldn't go as far as encouraging print-based debugging. Outside of Replay, print-based debugging is still a primitive way of analyzing the state of the app and promoting this state of affairs reduces the pool of people who use and would hopefully improve the existing debuggers. We all appreciated Firebug and the Chrome DevTools because of the powerful features they give us to inspect the state of the application. Imagine a person who adds print statements to their code every time they want to inspect the DOM or check the current CSS attributes. It works, but we have better tools, and we should make them even better.

b3morales 5y ago
Maybe 2a. Executing code (like a print) in an auto-continuing breakpoint action makes the program itself pause; especially tiresome when you're looking at a timing or performance issue.

rubyist5eva 5y ago

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

eljimmy 5y ago
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.
yanndinendal 5y ago
That's the point: looks like a tool made to be the best of both worlds: You get access to the full debugger, at any point in time, instead of clicking "next" a hundred times and then not being able to go back if you missed something. Here you go forward or back in time, and you can visualize where you are. This thread sums-up much better than me why people use print debugging (not just because they don't want to learn a tool, or are dumb), and why Replay is the best of both worlds: https://twitter.com/geoffreylitt/status/1438152748449636360?s=20 https://twitter.com/geoffreylitt/status/1438152748449636360?...

milofeynman 5y ago

Everyone in the comments is talking about using this for their own debugging, however I think the way to win with this as a business is in two places QA and Automated QA. If you have real human QA people in your org and they could run this while doing QA. If they hit a bug, and could then share a simple link to the dev team that captured their issue + the stack. Same goes with automated QA. Record the UI tests using this, and if one fails, store the state + stack. There are a LOT of hard problems in that workflow... Good luck!

tedmielczarek 5y ago
You're right on the mark here. I saw rr used at Mozilla to diagnose and fix flaky tests that failed just often enough in CI to make life miserable, but were nigh-impossible to reproduce in a local development environment. Being able to take that to the next level and collaboratively investigate a bug using a recording that captures it is game-changing technology from the future. Imagine a world where instead of ignoring, skipping, or marking "known failure" on all those flaky tests your CI hits (we all have them) you could capture recordings of them, and then actually investigate and fix them! That world is possible!

kodeninja 5y ago

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

jazzdan 5y ago
(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 https://medium.com/replay-io/how-replay-works-5c9c29580c58
- kodeninja 5y ago
  Thanks!
- missblit 5y ago
  > 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.
  - bhackett 5y ago
    (Replay employee) Yeah, later in the post (https://medium.com/replay-io/effective-determinism-54cc91f5693c https://medium.com/replay-io/effective-determinism-54cc91f56...) we mention needing mitigations to ensure that hashtable iteration is deterministic in cases where it affects how the browser interacts with the JS engine. There are others needed as well to ensure that the browser behaves the same across a large range of websites, my favorite is handling sites that sniff information about the system's math libraries by e.g. calling Math.sin() on specific values and testing the results --- the values when replaying need to be bitwise identical with what happened while recording.

arathore 5y ago

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?

jazzdan 5y ago
(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 after the excitement of launch has died down. Sorry about that!
- arathore 5y ago
  Thanks for the update. I had a feeling that this might have been the case due to the launch crunch and it's perfectly understandable. Really excited for the future of this project!
- fake-news 5y ago
  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.

djstein 5y ago

Congrats Jason! Know you and the team have been working super hard on this

danfritz 5y ago

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

jazzdan 5y ago
(Replay engineer): Yes it does!
- amelius 5y ago
  What if the network calls depend on state in the browser and returned data depends on state at the server? And what if you are debugging a race condition in network calls?
  - jazzdan 5y ago
    Replay deterministically replays the recording, so if the state of the application when you recorded it caused a network call, then when replaying it we will also "make" a network call _but_, instead of actually going out to the network we will instead return the exact data that was returned when you recorded it. You can learn more about how Replay works here https://medium.com/replay-io/how-replay-works-5c9c29580c58 https://medium.com/replay-io/how-replay-works-5c9c29580c58 Can you expand more on what you mean by a race condition in network calls? If it's a series of network calls that the browser could make in any order than we will make them in the order that they occurred when you recorded it. If it's a race condition that occurs in your backend, then the Replay browser won't really help there (though it will show you the responses you got from your backend when you recorded it). For help with that, you might want to use Replay on the backend. Right now we have Node support (https://github.com/RecordReplay/node https://github.com/RecordReplay/node), but other runtimes are on the roadmap.
- danfritz 5y ago
  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?

faraaz98 5y ago

Doesn't replit have a similar feature? Where you can link to different debugging states? Are you aware of that? If yes how is it different?

jazzdan 5y ago
(Replay engineer): Yes, replit has been working on adding similar functionality (https://blog.replit.com/debuggest https://blog.replit.com/debuggest). In fact: we've been collaborating with them on it! :)

aryik 5y ago

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.

somehnacct3757 5y ago

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?