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!<p>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.<p>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.<p>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.<p>Want to check it out? You can download Replay today. Can’t wait to hear what you think!<p>Interested in learning more, here is our announcement blog post <a href="https://medium.com/replay-io/launching-replay-the-time-travel-debugger-for-the-web-f886f0897d38" rel="nofollow">https://medium.com/replay-io/launching-replay-the-time-trave...</a>
For those who are looking to similar tooling in back end space, check<p>- <a href="https://undo.io/" rel="nofollow">https://undo.io/</a> (It can also support Golang <a href="https://docs.undo.io/GoDelve.html" rel="nofollow">https://docs.undo.io/GoDelve.html</a>)<p>- Mozilla RR <a href="https://rr-project.org/" rel="nofollow">https://rr-project.org/</a><p>- GDB <a href="https://www.gnu.org/software/gdb/news/reversible.html" rel="nofollow">https://www.gnu.org/software/gdb/news/reversible.html</a><p>Unfortunately, works only in Linux.<p><a href="https://en.wikipedia.org/wiki/Time_travel_debugging" rel="nofollow">https://en.wikipedia.org/wiki/Time_travel_debugging</a>
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.<p>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.<p>Replay has saved me hours of time. And that isn't hyperbolee. On a couple occasions due to laziness and familiarity I'd do stuff the traditional way and be stuck still after hours (sometimes days) on the same bug. With Replay I was able to shorten that time to about an hour on even the trickiest of bugs.<p>So stoked to now have Replay available to others to help record reproductions of their bugs.
That landing page looks right out of Bret Victor's time travel demos (<a href="https://www.youtube.com/watch?v=EGqwXt90ZqA" rel="nofollow">https://www.youtube.com/watch?v=EGqwXt90ZqA</a>, or <a href="http://worrydream.com/LearnableProgramming/" rel="nofollow">http://worrydream.com/LearnableProgramming/</a>). Communicates the value instantly. Incredibly well done!<p>IMO the most time consuming issue in triaging bug reports is reproducing them. Replay definitively solves the "can't repro this" problem.
Engineer @ Replay here - If you're a console.log kind of developer (isn't everyone at least some of the time?), you should check this out. Imagine being able to add console.log() statements to code that already ran and seeing the results immediately! It's a bit mind blowing the first time you use it.
If you're interested in non-Javascript time travel debugging: pernos.co (which is layered over Mozilla's rr time-tracking debugger) is an absolutely amazing tool which will save you days and days of wasted development time.<p>Pernosco's tool is described pretty well on their website, but basically it allows you to view a program inside and out, forwards /and/ backwards, with zero replay lag. Everything from stack traces to variable displays (at any point in time in your code execution) is extremely easy to view and understand. The best part is the lightning fast search functionality (again: zero lag).<p>On top of this: extraordinary customer service if anything breaks (in my experience, they fix bugs within 24 hours and are highly communicative).
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.<p>After prying for technical details, Replay came up, and I asked to see it out of curiosity.<p>Really blew my mind. Every once in a while a piece of technology comes around that doesn't quite have an equivalent.<p>I could immediately see where being able to have your users or coworkers record bug reproductions or features and submit them in issues or PR's would save monumental amounts of time.<p>Wishing Replay team best of luck, I was thoroughly impressed.
Congrats on launching!<p>The good:
I checked out the tool and seems to work as advertised. Also nice to see Replay browser based on a Firefox fork.<p>The bad (and this is more your marketing/PR/branding, not product):<p>- 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 email to support a launch on product hunt.<p>- With the amount of engineering that went into it, I would expect you to be proud of the craftsmanship and your team. Instead the top of your website states you are proud of getting money from investors. This is more a vote against this trend, than your particular behavior.<p>- I was able to find the post "How Replay works" [1] which is the actual content addressing your target market. The post conveys 2000 characters of information and uses 4.3MB of data to do that for a signal/noise ratio of 0.04%. It is the type of web obesity [2] that we are used to nowadays, so nothing new. Mentioning this only because you are a web engineering-centric company. Promoting the right values of web performance and engineering attention to detail is IMO important for a product talking to web engineers.<p>I realize this may come as unpopular/beyond conventional wisdom but getting a different perspective is what HN is good for. Use the feedback at your discretion.<p>Props for making an innovative product and good luck!<p>[1] <a href="https://medium.com/replay-io/how-replay-works-5c9c29580c58" rel="nofollow">https://medium.com/replay-io/how-replay-works-5c9c29580c58</a><p>[2] <a href="https://idlewords.com/talks/website_obesity.htm" rel="nofollow">https://idlewords.com/talks/website_obesity.htm</a>
I read the medium post (<a href="https://medium.com/replay-io/how-replay-works-5c9c29580c58" rel="nofollow">https://medium.com/replay-io/how-replay-works-5c9c29580c58</a>), which gives an overview of how Replay works, but there are a few things I still don't understand.<p>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?<p>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)?<p>3) The ordered lock technique described in <a href="https://medium.com/replay-io/recording-and-replaying-d6102afee273" rel="nofollow">https://medium.com/replay-io/recording-and-replaying-d6102af...</a> 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?
Replay employee here. Personally, I'm excited to see maintainers slowly phase out "Please include steps to reproduce" in issues, and replace it with "Can you make a replay"?<p>Partly because I want to see the product do well, but also selfishly as an engineer, because we've been dogfooding replay and it's made squashing bugs 10x easier. Having somebody attach a replay to an issue makes that issue immediately better than an expertly-written one, which as an engineer, I can start debugging in seconds with minimal back-and-forth.
I just learned about it here and tried it out on a small to medium-sized TypeScript React app. It worked right out of the gate! The original TypeScript files appeared in the Source browser. Time travel works. And the video replay too of course.<p>Really impressive. Will keep it around for sure to try debugging a real issue next time. Congrats on the launch and the great app!
Looks very cool. When I've been working on native code on Windows, the WinDbg time-travel feature has been a magical experience that's saved countless hours (<a href="https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/time-travel-debugging-overview" rel="nofollow">https://docs.microsoft.com/en-us/windows-hardware/drivers/de...</a>). I expect and hope this will do the same for web development.<p>p.s. On some pages (e.g. <a href="https://www.replay.io/pricing" rel="nofollow">https://www.replay.io/pricing</a>), I only see the Mac download button, even though I'm running Edge on Windows.
We've been using Replay heavily here for the past 6-7 months and it's rapidly become the preferred way to do any form of debugging. Training our support staff to capture replays and submit them in tickets has made turn around time on bugs significantly faster.
I'm an engineer at replit and I've been using this to find and fix a bunch of nasty bugs. I love the sense of confidence this gives me. When I have the recording captured — I know for sure I can get to the root cause of the problem.<p>Replay also makes it easier to jump into a new codebase, I can see how things work.
Replay has been amazing for me to debug hard to reproduce issues like live collaboration issues. You just record the bug, share it with others, place some console.logs (after the fact!) and scrub through the recording to see where things went wrong.<p>Also nice side-effect is that it's amazing to explore other code-bases, just being able to put a console.log somewhere to see how often it's run when using an application is a lot of fun.
This looks fantastic. Can't wait to try it out.<p>I want this to succeed, so I want the company to succeed. On that note I think you guys should change up your pricing.<p>Seems like there's too big a gap b/w the free forever (individual) and $20/mo/user for team.<p>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.
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.
Man, I wish I could use something like this for my Swift macOS app [1]<p>I’ve got tons of crash reports in Sentry that I have no idea what to do about.<p>On things like:<p><pre><code> CFRelease() called with NULL
</code></pre>
replay could help me find where the heck that NULL came from as I don’t have any CFRelease call in my code<p>Or the more annoying<p><pre><code> BUG IN CLIENT OF LIBDISPATCH: Assertion failed: Block was expected to execute on queue [com.apple.main-thread]
</code></pre>
Like, how does that specific line run perfectly fine thousands of times and then every once in a while it decides it needs the main thread. I wish I could replay that traceback to see why the main thread is suddenly needed.<p>[1] <a href="https://lunar.fyi" rel="nofollow">https://lunar.fyi</a>
Having played with Replay already, I have to say it feels nothing short of magic. I can't tell you how much something like it would have made debugging weird issues in the depths of something like Webpack a whole lot easier.
This looks exciting and I’m going to give it a try.<p>For what it’s worth, if it helps with marketing: I am immediately skeptical that it’s going to be some mix of tedious to get working with my specific webpack dev server setup, be slow or unreliable, or never actually keep the state I need.<p>I’m hoping to be wrong on all of that. But when I scrolled the (beautiful) website, I would have loved to see some really nasty example in addition to the very elegant introductory “show don’t tell” example.<p>I want to see the first and think “okay I get it” and then be shown something really complicated to illustrate just how durable the tool is.
Can the creators describe this product's advantage over FullStory and LogRocket? Also, it seems challenging to get this to work in production, since users wouldn't consent to this level of monitoring.
One thing I've thought would be useful to have is a combined debugger/logging system. I work on SQL Server and we rely heavily on dumps to figure out what happened when something goes wrong. However, that only tells you what happened at a given point of time. Obviously recording all the system state over time would be too expensive and logs can be difficult to decipher due to their volume and lack of (explicit) connection with source code.<p>What I'd love to see is a logging framework which records the values of program specified variables while running as well as the current stack trace plus a monotonic time so you can piece together what happens through a thread of execution over time. However, unlike traditional logging, it would be connected to the source code like how a debugger works so you could mouse over a variable to see its state over time.<p>Honestly it'd be really cool with a tracing system like this to be configurable without modifying source as well. Maybe trace specific functions by noting the stack trace and arguments when invoked as well as the return value.
I love this, and apart from its intended purpose it seems like a potentially valuable learning tool for devs new to a language.<p>Years ago I used Adobe LiveCycle, a horrible "low code" enterprise framework foisted on us from far above.<p>One thing I always did like about it though was its replay tool which this reminds me of. I was always surprised it wasn't more of a thing in the dev space, it seems very useful.
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.
While I both love it and need exactly what it provides, I have to say I felt very disappointed when I clicked the CTA with a windows icon only to be greeted by a notice that it just isn't there yet.<p>Would it be possible to communicate this by disabling the button and adding some kind of "coming soon" messaging straight to its right?
VERY impressive. I downloaded it this morning and took it for a spin on my current project. I love how much you pack into this tool and make everything work seamlessly together. If those source files in the DevTools view are editable, I won't need my IDE anymore! Thank you for bringing us this tool.
Happy Replay user here. One of the most time consuming parts of bug triage and resolution is often just reproducing the bug in the first place. Replay helps us reproduce customer bugs and find their root cause much faster. I wish I had it in past roles.
Windows has this for time travel debugging : <a href="https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/time-travel-debugging-overview" rel="nofollow">https://docs.microsoft.com/en-us/windows-hardware/drivers/de...</a>. Visual studio also supports TTD <a href="https://devblogs.microsoft.com/visualstudio/introducing-time-travel-debugging-for-visual-studio-enterprise-2019/" rel="nofollow">https://devblogs.microsoft.com/visualstudio/introducing-time...</a>
Dan Abramov 2015
<a href="https://www.youtube.com/watch?v=xsSnOQynTHs" rel="nofollow">https://www.youtube.com/watch?v=xsSnOQynTHs</a><p>But there was one earlier presentation I cannot find it, guy was showing live debugging of the video game. Not sure is it TED or one of conferences ...<p>Edit:<p>This is it:<p>Bred Victor:
<a href="https://youtu.be/EGqwXt90ZqA?t=1006" rel="nofollow">https://youtu.be/EGqwXt90ZqA?t=1006</a><p>2013 Future of programming
<a href="https://www.youtube.com/watch?v=8pTEmbeENF4" rel="nofollow">https://www.youtube.com/watch?v=8pTEmbeENF4</a>
Wonderful product! I do use debugger; statements a lot, but I'm also somewhat ashamed to admit that I love console.log()! :-)<p>Replay debugging is a huge step forward, and gives console.log() much more power.<p>Thank you!
Side note:<p>There used to be a product called "Chronon" back 10-12 years ago... The blog spammed Dzone and a lot of other websites and refused to pay for advertising. Their CEO encouraged people to stop writing log statements out and just run their debugger all the time. Looks like it's defunct now: <a href="http://www.chrononsystems.com" rel="nofollow">http://www.chrononsystems.com</a>
Surely not as fully featured, but the general idea has been possible for ClojureScript Re-frame with: <a href="https://github.com/day8/re-frame-10x" rel="nofollow">https://github.com/day8/re-frame-10x</a>
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.<p>IMHO having Firefox as a base is not a great idea, Chrome would be better and closer to what users use.
What are the limits for the recordings in terms of time and input data size?<p>Edit: on Ubuntu 18.04 I get the following error:<p>$ ./replay<p>./replay: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./replay)
Is it correct that to use this I need to download their app and then enter my Google password inside it?<p>How do I know it's safe? Is there any other way to try it out?
Today I spent maybe more than an hour tracing a bug that a screen I created turned inaccessible after a merge, tests died suddenly.<p>It turned out to be multiple cases, one was that a colleague changed a default export to a named one which excluded my screen. Another was an in an unrelated test which missed a React context wrapper so I needed to refactor her tests.<p>I don't know what kind of magic debugging tool would help with these kinds of things.
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?