Hacker Newsnew | past | comments | ask | show | jobs | submit | sergeyski's commentslogin

Looks similar to replay.io


What I don't like about replay.io is that it requires you to use their custom browser.


Hi, I work at Replay.io. There's a very good reason for that "custom browser" requirement.

Session replay tools like LogRocket or Jam do capture a lot of information, but they can only capture what's _in_ the page, and are thus limited by the JS execution environment and permissions. This is still very useful for seeing what the user did in the page, and you do get a good amount of detail (video, DOM, network).

Replay.io works by capturing the browser's calls into the operating system. (This is really complicated! Our fork of Chromium has thousands of lines of custom C++ and JS modifications in order to capture the runtime information and make it queryable.) That enables actually _debugging_ any line of code that ran at any time. That's something that session replay tools _can't_ do.

So, yes, both Replay.io and session replay tools let you _see_ what happened, but only Replay.io lets you _debug_ the code _as it ran originally_. And that's only possible because we do capture the _entire_ browser's execution.

We've got some sections in our docs that dive into this in more detail:

- https://docs.replay.io/time-travel-intro/what-is-time-travel...

- https://blog.replay.io/how-replay-works

- https://docs.replay.io/comparison/session-replay

Not only does Replay.io let you _debug_ recordings of bugs, we've got a Test Suites dashboard that lets you record Playwright or Cypress E2E tests _as they ran in CI_. This is possible because we can run your E2E tests with our own browser, and thus record them as they're running.

Finally, a sneak peak: we're currently prototyping some new advanced functionality that would actually _diff_ passing and failing E2E tests to figure out where a failing test went wrong, surface that info to developers, and help them identify common failure reasons in their tests ("27% of your failures in the last month were due to Apollo Client failing to connect"). Still very early, but we've got the core functionality working! Again, this is only possible because we've recorded the _entire_ browser's execution, and can then replay that browser at will and query for every bit of JS execution that happened.


IDK.

Sanitizing chrome for testing makes a lot of sense as different versions of chrome have been proven to be unreliable.

Playwright uses a sanitized chrome version.

And Cypress does not, and allows users to use their own browsers which may be a reason for some not insignificant portion of flake. They definitely had multiple instances where a particular chrome version was unstable leading to lots of customer complaints regarding their reliability.


honestly that ends up being a feature rather than a bug for me, given how many chrome windows and chrome profiles going on, having it be a separate so entirely is a good thing in my book. I can understand others have a different opinion though. Given all the attention paid to the developer experience, what's weird is CORS not being called out in their browser.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: