DOM recording for web application demos | Hacker News Reader

DOM recording for web application demos

robert.ocallahan.org

93 pointsmodeless33 comments

Two open source alternatives: https://github.com/oct16/TimeCat and https://github.com/rrweb-io/rrweb we are working - at Telecom Paris - on synchronizing audio recording as well for pedagogical reasons (for example making programming tutorials) here https://github.com/Telecom-Paris/generic-rrweb-recorder . You can also try our "ace editor" specific recorder to make c programming and python programming tutorials https://github.com/France-ioi/codecast look at the recordings we have created here https://www.edx.org/course/c-programming-getting-started it includes a client side c interpreter . If you know any other tool to make pedagogical tutorials please let me know!

Those look cool. rrweb is about two years old, same as DOMRec, TimeCat started in February this year, so it's not surprising we didn't find them :-).

OMG you're the creator of https://rr-project.org/ ! That's the one I wanted to use first. Ho ! We have to talk :)

Sure, email me.

rr inspired me when I choose the name rrweb:)

Hello @yz-yu and thank you for this fabulous project rrweb ! We are developing educational tools out of it (programming tutorials with audio, for example)! Keep up the good work.

By the way, I find your pernosco debugger very interesting for pedagogical purposes. We are working on integrating Debug Adapter Protocol to preprocess the execution of a program and execute it line by line on the client side for teaching purposes but your solution looks much more elegant ! Any plan to make it compatible with Python and Java or other JVM languages ?

Right now we're focused on selling the product we have.

The infrastructure we built to support JS would extend pretty easily to Python. Extending to Java would be a lot more work. No plans to do either anytime soon (unless someone wants to pay us significant money for that).

PostHog is using rrweb for recording user sessions :D

James Micken's Mugshot paper describes the details of this technique well.

https://www.usenix.org/conference/nsdi10-0/mugshot-determini...

Have you seen anything more from this? I can only find papers that are near a decade old and no actual implementations.

I haven't seen any subsequent work from Mickens on session replay. Many commercial tools like Inspectlet, Fullstory, LogRocket, etc., are available, though.

Mickens has done subsequent work on web page load times with Ravi Netravali.

Interesting. At SessionForward (sessionforward.com) we have been using rrweb (rrweb.io), which is MIT, and works as expected.

rrweb looks cool. It started at around the same time as we first built DOMRec. rrweb looks much more polished though!

rrweb accepts sponsorship. They also have a "Who's using rrweb" section in their GitHub repository. You might want to add your company to it.

What excites me about this approach is that it has the potential to make demos that are also accessible to blind people. It would take some work though, possibly even including support from browsers and screen readers. The pseudo-focus and pseudo-caret features in particular are problematic. Also, blind people might need a playback mode that advances the recording manually frame by frame (only counting frames that actually include changes), rather than playing back in real time.

You could have a playback mode where you use real focus and caret. E.g. DOMRec could easily be modified to do this in fullscreen mode.

After that it might Just Work since the ARIA roles are in the DOM. Indeed it would be very cool!

How do you handle CSSOM changes which don’t generate mutation events?

I wrote a similar library and this was a pain for react-native-web apps, eg Twitter.

Nested iframes were also an issue, since the recording script needs to run in a context with access to all frames, in all origins. (IIRC you have to disable site-per-process in Chrome, at a minimum.)

Edit: I should add, very nice work and thanks for open sourcing!

DOMRec doesn't handle dynamic changes to rules in CSS stylesheets because our app doesn't do that. If we needed to do that, I'd try wrapping the CSSOM API prototypes.

(Of course DOMRec does handle changes to 'style' attributes on DOM nodes, because those do generate mutation notifications.)

Similarly, DOMRec doesn't handle cross-origin frames, because our app doesn't use them. To make that work I guess we'd have to port to a browser extension and even so it would make things quite a lot harder.

This is very cool, but for me the problem has always been the repeatability of demo videos. I make a demo video of our product, and two weeks later that demo is out of date and now I need to make the same video again.

Additionally, the need to add fake CSS pseudo classes to get it to work with focus, etc. seems like a bummer.

Nonetheless, seems like a nice compact way to make and share demos, so well done!

Repeatability can be such a pain. Company I used to work for had separate product and marketing teams that didn't talk to each other much. Which meant that by the time the recording was finished a new product update had been pushed out which made the whole recording obsolete.

This problem inspired me to build https://RecordOnce.com which does the re-recording automatically and periodically.

For the initial recording we also uses rrweb. (Can't wait to get us on the rrweb donor/supporter list!)

Justin’s cofounder here:

Example video that was completely generated by the bot: https://video.recordonce.com/play/dBZ66RussA8

That's addressed in the post too. They make their demos as Selenium scripts so in many cases they can simply re-record the demo when the UI changes.

Exactly — you could even automate this and add it to a CI pipeline, no? Very, very cool.

Yes, it would be very easy to do in CI, just one shell command.

We don't, because we don't need to update the demo movies often so it saves cycle time to trigger updates manually when required.

In my experience, Mutation Observers can be very punishing in terms of performance if you have large DOM structures, especially on page load.

On the other hand, if you have an SPA[0] that renders as little as possible, I'd say, go wild :)

[0]: I understand DOM size should be orthogonal to your rendering method but "In Real World (c)", that's usually not the case for some reason.

Mutation Summary is a nice little library to help with this. It coalesces mutation observer events so you get one minimal set of changes per animation frame.

https://github.com/rafaelw/mutation-summary#readme

In my experience, Mutation Observers can be very punishing in terms of performance if you have large DOM structures, especially on page load.

Mutation events are what kills performance, not mutation observers.

Yes, though browsers have long been optimizing this by simply never processing mutation events unless the page has event handlers for them.

MutationObserver is much more efficient than mutation events because it can group events into batches, vastly reducing the number of event handler callbacks when you're observing whole documents.

Performance during recording shouldn't be too much of an issue, especially if demos are scripted with Selenium as suggested.

This is super, super interesting. Is there other stuff out there like this? Seems like a cool way of making very native-feeling, impactful demos.

cool stuff!

Reply on news.ycombinator.com