Mark: honestly, I would be a completely different person, had I never gotten involved with Redux, it has shaped every area of my life over the last 10 years. The people I've met, the experiences I've had, the travel, um, even my current job,
[00:00:19] Intro
Andrew: Hello, welcome to Deb Tools fm. This is a podcast about developer tools and the people who make 'em. I'm Andrew, and this is my co-host Justin.
Justin: Hey everyone. Uh, we're really excited to have Mark Erickson on with us. Uh, if you have done any work in the Redux world, you know who Mark is, but for those of you who don't, uh, mark is, uh, the primary maintainer of Redux these days. Uh, and you're also a senior engineer over@replay.io, which we had, uh. Who do we have on Jason?
Like early in the back. In
the early days.
Mark: Jason Laster. Yeah.
Justin: Yeah. Yeah.
A long, long time ago. Uh, so we're so excited to have you on Mark. Um, before we dive into everything else, we would love to hear a little bit more about you. I.
Mark: Yeah. Um, I don't know. Where do we wanna start? So, I, I, I've been program a developer for 20 plus years now. Um, spent, uh, 14 ish years in the defense industry and moved to replay in early 22. So it's actually been right about four years so far. Uh, I have. Gotten to work on a lot of different things. My career has been a little weird in that most of the stuff I've worked on has been internal tools, a lot of SBAs, a lot of like smart interactive type stuff.
So I, I keep finding there's an awful lot of stuff I've never worked with. You know, I've never worked on e-commerce or million user platforms. And it actually, in a lot of ways, it makes me feel like I don't have the expertise to offer advice on a lot of things because I've never touched those. Um. But yeah, I've, I've been doing web dev since, uh, 2013 ish.
Um, one of the projects I worked on and. Uh, it's, that's been my area of expertise. I've, I've done a lot of full stack stuff. Um, most of the projects I worked on previously were, you know, front end, backend, database, whatever. Um, so I've got experience up and down the stack and weirdly, the stuff I've been doing at replay, the LA.
The last, almost three years now has all been internal in our backend and not even quote, front end stuff anymore because I've been building tools that instrument recordings of front end apps and dig into reacts guts in ways you're really not supposed to.
Andrew: Cool.
[00:02:39] Becoming the Redux Maintainer
Andrew: So, uh, I'd, I'd wager to guess a good amount of our listeners would recognize your profile picture. I've seen that little Simpsons guy everywhere. How did you become the Redux guy? How did you, uh, become the, the lead of this project that is behind so many different React apps?
Mark: Um, entirely by accident. Um, I. I'd done some jQuery and backbone internally, uh, 2013 through 2015. Um, found the limits of what you could do with backbone. Started looking at React to try to migrate actually a Google Web toolkit app that I'd written, uh, in the summer of 15. I'd heard about React and started doing my usual thing, read blog posts, learn about it.
Um, and by pure coincidence, it was at the same time that Redux came out. Um, 2014 to 15 was the flux wars where we had dozens of libraries implementing this flux pattern. And originally Dan created Redux just to be another example of the flux pattern. But with time travel stuff baked in. And I found the reactive Flex chat channels, uh, eventually on Discord, started working, started seeing questions I could provide answers to.
'cause hey, I just saw that in a blog post the other day. Um, started making a list of all the useful links and resources I'd found by the end of the year. They asked me to be a moderator, even though I still hadn't written any React code yet because I was answering all these questions and knew the theory.
And early 16, I was seeing all these redux questions come out and I volunteered to write an FAQ page for the Redux docs. And so I, I pulled all the questions and the resources and the links together, which has been a running theme of my life. Um, got that up. Dan gave me commit rights, and for the next few months, I really only felt in my head like I had permission to, you know, help triage issues, work on the docs some more.
Dan gave a talk one year later, summer of 16 about, you know, the, the anniversary of Redux, but he'd actually been hired by Facebook to work on React the previous fall, just a few months after Redux came out. So he got busy with React and Summer of 16, he sent a message to me and a couple other people saying, I'm busy.
Here's the keys. Have fun. It took me another few months to actually feel like I had ownership of this tool. There were a couple prs and issues specifically that forced me to actually dig in and understand the code and realize that I had the authority to say, I understand what this does and I think this is how it should work, and I think this is a direction we should go and this one isn't.
And so it wasn't until fall of 16. That I actually started using the word maintainer to describe myself, and then I started writing some blog posts and tutorials that reuse concepts from some of I, I'd started doing my first actual React and Redux app at work through 2016, um, converting that GWT app that I built previously, and so I was.
Learning the libraries and figuring out patterns for how to use them effectively. But it was all internal tools that I couldn't show off in public. So I started writing some tutorials that built a mini app that demoed some of the same concepts in a publicly showable way. Uh, that became a practical Redux blog series that's still up there.
Um. Then that led to, you know, answering a lot of questions in public, uh, which became its own thing. Um, eventually joined Twitter, you know, stack overflow, et cetera. Um, started using the Simpsons avatar because I didn't have any pictures of myself to show off. And then that became a trademark. And then. I don't know.
I think late 2017 was when I did my first conference talk and it, it all just sort of kept snowballing from there. None of this was ever a thing that I did intentionally. I, I had no goal. I certainly never dreamed that my wife would be completely shaped by all that. Um, but I, I, I really like what, uh, Sean Wong Swix had had to say about like, increasing your luck surface where if.
If you put yourself out there, if you volunteer, if you do things, if you be proactive, that doesn't guarantee that, you know, you'll get a big break or something will work out, but it puts you in a position where you're more visible, more you, you're interacting with people and there's the chance that something useful could happen to your life and your career.
Um, honestly, I would be a completely different person, literally in like. Actually, literally had I never gotten involved with Redux, it has shaped every area of my life over the last 10 years. Um, the people I've met, the experiences I've had, the travel, um, even my current job, I mean, I got my job at Replay because of the reputation that I'd already built.
I've, I've done a lot of, you know, personal development work on myself in the last few years. I'm happy with the person I am now. Um, and if I'd never like put in the effort to get involved with Redux back in 20 15, 16, I wouldn't be me. So it's, it, it literally has shaped who I am.
Justin: It's funny because, so maybe not to this degree. I think your, your path is exceptional in this sort of like depth and how far you followed it, but the open source story, this has so many echoes
of, of So many people that I've known,
I've been an open source maintainer, and I just like sort of fell into it. And a lot of times people fall into this as like,
oh, the,
the, primary maintainer has
like, stopped maintaining it. There's like.
these
things that I keep running into. I just like want them fixed. It's Like you email 'em, like, please just let me fix it.
I'll like, I'll, you know, help.
But you kind of fall into this role and you don't actually necessarily think about
it or, or whatever. But. That path that you're, you're expressing is, it's funny how often that happens. It's like We didn't intend
for it to turn into what it did.
Mark: Yeah, I mean even, even the other Redux maintainers, Len got involved with RTK because he liked TypeScript and wanted a better typed version of Redux to work with. Um, Ben got involved because he was already answering questions in our discord and started submitting prs, and we saw that he was hanging around and providing good quality contributions.
So, I mean, it it, it's really on people to attempt to get involved.
Justin: So it, it's, yeah, it'd be good to kind of like transition and talk about Redux a little bit
because, um, It has such a long history.
and and you know, the front end world has moved really fast. Uh, and there was a time there where it felt like every, like three to four months there was a new major like state management library that was landing and
the churn there was insane.
Mark: Do you have any idea how many times I've seen the words this kills Redux, or Redux is dead? Yeah.
Justin: I'm still here.
Mark: Yeah. I mean, I, I, I published it. Let, let's put it this way. I published a post in 2018 called Redux Not Dead yet, and that was three years after it came out.
Justin: Absolutely.
[00:10:12] Redux Evolution and RTK
Justin: So let's, let's talk about the evolution. Um, it was, you know, it was big. It was. Huge for the industry when we were talking about these flux libraries, because The state of state management
before that was
just not
great. And
so we
Mark: just
Justin: Yeah,
Mark: backbone models. Woo-hoo. Angular, angular services.
Justin: So it, it brought this rigor, um, and these like interesting capabilities.
Um, and then here we are, you know, many, many years later and there's like a plethora, you know, it's really the, the state management scene is burgeoned and there's like all these tools, um. Yeah. How, how do you, how has
things changed?
over that journey? Can you kinda look back and sort of reflect on Redux and.
Mark: Yeah, like, like, like many other things is a topic I can and have talked about for hours. Um. Uh, most things I will attempt to keep things short for the sake of time. 2015 ish. The mind, the mindset was state management and side effects. Um, partly because React and Redux were both very influenced by functional programming.
And so there, there was an attempt at separation and Redux was always designed to be very explicit and straightforward. There's the layer of indirection. You're dispatching an action, not just mutating a state field, but conceptually it's always UI dispatches in action. Reducer runs state updates, UI rereads.
The values selects diffs reruns, like it's several steps, but it's a guaranteed repeatable process. There's zero magic involved. Um. And what we found was, you know, number one, there's the whole S-shaped adoption curve thing where everyone sees the new shiny shoves. It everywhere realizes, oh no, we have made a mistake.
And there were a lot of places we never should have put this, like say redux and forms, for example. Um, and then you find out, and that you have to maintain these monstrosities of code bases you just put together and, you know, redux. The other word I hate at this point is boilerplate. That's still the word most people associate with redux.
And to be fair, that reputation was entirely deserved early on. Um, the docs showed somewhat intentionally verbose patterns. People adopted it without ever thinking about it. There were ways you could simplify that even early on, but everyone just went with it. Then he tacked on the early community written TypeScript patterns or use of redux, sagas and these other pieces, and that that added to the boilerplate, you know, three or four X as bad.
So. I did the work in 2018 and 19 to design Redux toolkit to try to simplify all those patterns. Um, I looked at the pain points. People were, you know, were having, how are they using redux? What are the, what are the bugs? What are, what's the boilerplate? How can we simplify that? Uh, shipped RTK in late 2019 rewrote the tutorials to make it the default in 2020 from our perspective, that did basically eliminate the boiler weight.
RTK has been the default for using Redux for, you know, pretty much six years now. Now I still see the word boilerplate thrown out a lot. You know, people will compare it to, you know, Zoot Stand, Joe Tai, et cetera, and just the fact that there are certain patterns in Redux, they point to those as boilerplate.
I, I can't change everyone's minds like we did our part redux is what it is. It's not going to magically, you know, get way shorter. But we've seen lots and lots of very positive feedback from people who enjoy using RTK. And as I've said many times, our, our goal is not to win market share. Our goal is just we've built a good tool and if it solves your problems and you choose to use it, it works well.
The other big shift has been data fetching. Um. What we, what the community figured out was that side effects, like 95% of side effects are actually just I want to fetch in cache server, in server state, and that's it. Um, and so again, the early redux patterns of lots of thunks and constants and everything else for fetching was very, very verbose.
That's why you saw people saying, I switched to React Query and deleted 5,000 wines of Redux Code. It's like, yeah, 'cause you had to write all that code by hand in the first place. We didn't provide a solution and so. The community adopted, you know, 10 tent stack slash react query, um, Apollo, uh, SWR, you know, various other similar tools.
We've got pages, router, app, router, TRPC, server components. You like all these different ways to get data from the server into the client. And I think the variety of those tools is evidence of how big that problem space is. And so we ended up shipping. And RTK query Data fetching layer in Redux toolkit optional, but highly recommended as the default, which is that same.
Hook based approach to doing data fetching, uh, with our own spin on the API design to make it friendlier for things like generating an entire set of properly typed endpoints from an open API schema. And so there's a lot of folks who have chosen to use RTK query in their apps, even if they weren't using Redux for client side state management.
Just because it, it, it makes it so easy to generate and use those all the way through. So all these different pieces have affected how we use Redux and how it fits in. Redux will never be anywhere as big as it was in 16 and 17. That's fine. But it is, it's still very widely used. It's still a very good choice if you have these kinds of problems.
Mm-hmm.
Andrew: Along the way you've had to make a lot of like different API changes. Uh, what's your like thinking about trying to like bring the user base on. Long with those API changes from, from my point of view, the back when I was on Twitter reading about, uh, the RTK toolkit migration, it felt like it ta it took a really long time to like get people from point A to point B.
So what's, what's your perspective on that?
Mark: Yeah, that, that brings up one of my, one of my funnest rants. Um, so we did, I did all the, I did all the docs work in 2020 and, you know, we, we updated. You know, rear the tutorials, updated templates, tried to make RTK the default, but there were still, you know, tons and tons of, you know, legacy redux code bases out there.
'cause that's what everyone knew how to do, as well as lots of outdated learning materials. Um, and as I've found over the years, a lot of people don't read the docs. A lot of people don't. Think to read the docs and if you're a junior learning in a bootcamp just following along from a curriculum that hasn't updated, you will never know that there is a new and modern way to do it.
So in early 2022, I started tossing around the idea of what if we mark the create store method as deprecated just in a a doc tag, which would just give it the strike through. When you import it in your editor, it doesn't change the behavior. Um, and my thought was, if market is deprecated, update the DOC block to say, please read this docs page about why you should use Redux Toolkit instead.
And my thought was, this is the only communications method I have to reach out to a lot of our users. And I did that and I promptly got a large amount of pushback from some very over opinionated people who. Didn't like what I was doing, and I, it, it, it actually got kind of vitri. Um, I had people saying like, you know, saying they don't wanna use RTK.
Okay, fine. Um, but like one of the examples that stood out to me was someone who said, you don't want people to use, you just want people to use your library instead of Dan Abramov. And I'm like, wait a minute. Dan worked on Redux for one year. Yes, he created it, but I've been working on it for six years.
Since then. I have shipped essentially every release of every redux based library in the last six years, and I'm doing this with a goal to make things better for our end users. Do I not have the right to say this is the right way to use the tool that I build? So. And then like the comments, like there was a Stack overflow issue where people kept arguing with me for months.
It, it was frustrating, frankly.
Justin: I, I wonder on that note, we have been talking internally at my company a lot about, um, how with AI tools, like there are small changes in how we think about code. Like we care about it a little less or a little less, you know, tied to it. And I wonder if. We'll see less of this over time,
as people adopt more tools like less like,
like
passion and vitrol about like this one specific API or this one specific shape because it's like they're a little further. removed. I don't know.
Mark: ~~Mm-hmm. I dunno, it, ~~it's certainly possible. Um, I mean obviously there's all kinds of debates and discussion about. Ai, how it's affect affecting programming.
I mean, I, I got my start during, you know, very much the programming as craft era, you know, eighth Light and Code Katas and all this other stuff. And this is its own entire separate podcast. But I, I do think that the shift from, I mean, sort of in the same way that we went from managing servers individually to managing them as infrastructure.
There is a little bit of that going on possibly at the code level as well.
Justin: makes a lot of sense. Well, getting back to Redux, so, uh, you know, it's, uh, 2026 now.
Um, Redux has been, you know, in development for a long time. It's had a lot of evolution. Um, and there are like other state management libraries that like folks like to, uh, toss around, uh, ZSAN and, and jota, like two,
like Pretty popular.
ones. Um, so with the modern version of Redux, with Redux toolkit, how do you sort of, when you're trying to educate people about the comparison, contrast of
like. These other libraries that they might know about, and like the new version of Redux, how do you sort
of position it?
Mark: version of ReadUP, how do you sort. Uh, the biggest thing I try to pitch these days is it's about providing consistent structure.
You know, redux will never be the, the smallest or the absolute fastest state management library out there, but it provides a guaranteed consistent structure for your app. Like if I look at a Redux code base, the first thing I always do is go straight to the reducer logic, look at the slices, see what does the state look like, what actions trigger updates, how is it managed?
That gives me a pretty good sense of what does this app do and when and why. Um, David, uh, David Korshe, David k piano will happily tell everyone in sight that an invent based architecture where the UI just says this is a thing that happened. And then another part of the app does the state machine thing, uh, is the, the most consistent way to scale a code base.
And I'd say that has a lot of pretty good points to it.
Andrew: Yeah, I've definitely employed that way of making things before, and it, the, the more you take outta your react components, the easier it is to reason about them, especially long term.
Mark: I mean, we, we've all seen the screenshots of the component with 100 used states in there.
Andrew: That's what my AI generated code looks like. So I try not to think too hard about it. I have some, I'm building an app on the side and one file for like, creating a grocery list has so many state blocks. It's crazy. I looked in there one time, I'm like, I'm good, I'm good. Uh, maybe in the future I will convert it to, to X state 'cause that'd be easier for me to manage, but I'm not sure.
Maybe not for the ai.
Mark: I think this is actually a place I, I don't have hard proof, but I, I would think that this would be the kind of thing that one AI can write better and hopefully also understand better as
Andrew: Yeah, structure is always good for the ai.
[00:22:21] Replay.io Time Travel Debugging
Andrew: Uh, so switching gears a little bit
about your day job a little bit. You work on replay io. Some
listeners might remember replay io from four years ago on our podcast. But, uh, can you give us like a little, uh, elevator pitch on what replay IO is and like why it might be useful for a developer?
Mark: Yes. Uh, the, the, the story has changed a little bit in the last couple years, and then again, even within the last week. So I'll start from what it was when I joined, uh, replay. Was, and it still is a time traveling debugger for JavaScript. Um, we, we've all had, you know, really difficult bugs that involve, you know, race conditions or you can't recreate it on your own machine, but it happens on someone else's machine.
And the idea was that by making essentially like a DVR type recording of your app running for 30 seconds, a minute, whatever, um. We can then capture everything that happened in the browser and enable you to jump to any point in time and see the code. And you know, what I've found over the years is that, number one, most people have never even thought about how to debug as a mindset.
I've, I've given talks about this. It really is the scientific approach. You need to understand the existing system. Understand what the intent is. A bug is something not matching the intended behavior. And then you need to, you know, form your hypothesis, change one variable, try it out, see what happens, compare results, and eventually narrow down what's going on.
But that requires understanding. And let's be honest, most people never actually think about this. Uh, they, I've also found that most people don't use graphical debuggers in the first place. They're happy to just, you know, drop in a bunch of console logs, refresh the page, rerun the script. And I mean, I, I do a lot of this myself.
So the idea, so replay was meant to, number one, make it possible to deeply investigate. Bugs that you probably couldn't do anywhere else with the existing tools. Um, number two, maybe a bug only happens on your colleague's machine in a full moon in January, but if they can make the recording now, anyone can go investigate it at their leisure.
Um, and the time travel stuff unlocks a lot of really powerful capabilities. For example, instead of needing to add console logs to your code, you can open up. The recording and the replay dev tools. Go to the source file, look at it, and we show you how many times each wine of code ran in the recording. So you just say, okay, uh, this, this reducer wine of code ran 11 times.
Um, let me add what we call a print statement here, kinda like a virtual console log, and I can just, you know, add an expression including a variable. Our backend fans out and evaluates the expression at every time. The line of code ran and then shows you 11 line log messages, one from every time the line got hit, and you're doing this after the fact as you're investigating.
You didn't have to have that in place before you made the recording. And that's just the dev tools ui. Um. After I'd spent a, a year or so working on replay, like our, our dev tools front end is actually built on a protocol, much like chrome dev tools, uh, both a bunch of additional methods. Things like, give me a paused browser instance in the cloud at point in time.
Then that's how most of the features work. Like to get the call stack, to get the variables, it actually sends an ev v to the paused browser instance in the cloud. And then we serialize the data all the way back. Um, and so what I got to start to do, it's like, wait a minute. We have this entire time travel API at our fingertips.
What other kinds of interesting tools could we start to build that are not just. A bugger gui, but with time travel built in. Um, so when I added our. React and redux dev tools. Integration for replay dev tools, uh, that works with time travel.
[00:26:42] React DevTools Injection
Mark: I had to modify our Chrome Fork to capture some data during the recording process and pretend to be the React dev tools extension.
So react in the app says, oh yes, here's all the rendering updates. And then afterwards I would run a post-processing step extract. I I, I actually injected the entire React dev tools extension JavaScript bundle into the paused browser via evals over the network, and then would say, run ahead to the next render.
Extract the component tree. Repeat, repeat, repeat. Stitch it back together. I could even go in and replace the minified component names from a production build with the original component names from the source code, and which is something the browser extension cannot do. Um, I also built a feature where, let's say like we, we know all the times that the user clicked in the recording.
We originally had just had a list of those, but there was no way to associate that with like what user code actually ran. And I was able to figure out, okay, if I look at the Dom, react actually stores a lot of its fiber data structures attached to the DOM tree. And you can look at that in a real browser in the app if, if you just dig down through the DO tree and if you looked at a JavaScript event, object.
It's actually got some data on it. Well, it's actually know, it's got the DOM node as event target and the dom node has a super secret react props object attached to it. And I can actually look and I figured out, okay, start from the quick event. Look at the event object. Look at the dumb node. Uh, if the dumb node has the props object, and the props object has say like an unclick prop.
Now I have a reference to the function that the user attached to the button, and I know where the function was defined in the source code. And I can find did that function run while this event was getting handled. And so in our dev tools ui, I could jump you straight to that line of code as it started to execute.
So you go from, I know that this button got clicked right to the click handler and now you can investigate. Um. So those were some of the things I added to the dev tools ui. And over the last couple years, as we've pivoted a bit away from trying to sell dev tools as a product, uh, we've continued to build out a lot of very sophisticated react instrumentation and analysis internally, which is where some of our current business ideas are coming from.
Justin: That's, that's so wild.
That's, uh, I mean, re replay's always
been magic. I remember the, the
early demos that we saw. I mean, just the, just the genius of like, oh, well, everybody cons the logs. We'll let you console log, and we'll turn that into like a real debugging session. And it feels so natural that you just sort of like fall into it, which I think is genius.
Um, and then what you've described there, that's, that's pretty crazy. I will say that using like
debugging react code in a debugger, it
kind of stinks. It's not great.
Mark: kind of stink. Oh, te tell me about it. I'm like, so replay heavily relies on having source maps available so that we can see the, like the readable version of your code and the library code. And what we found is that React had never shipped source maps for production builds like dev builds.
You can look at it. The dev build was unmodified. But react up through 18.3, shipped pre minified, compiled production artifacts. Um, and the react code is already complicated enough, even if you can read it, uh, both in source code form and then the, the combined transformations it goes through to strip out the feature flags and do the bundle.
Um, and then you, and then you minify it. It's like, okay, you can't read any of this. So I actually did a lot of work in. Spring 23, where I went in and modified the React Library, rollup build pipeline to add source map generation to that. And it got merged, uh, late in the year. The React teams not that great at managing external prs.
Um, unfortunately it then got ripped out a few months later and they, they went with a different tack where if you look at 19.0 and, and, and since then the production artifact is Unin Unified. So we at least have readable function names, but they've still run it through an optimizing compiler. And so a lot of those variables are garbage.
So it's, it's readable, but still, still a mess, but that is at least better than it used to be. Um, so from there you start to run into issues like if I'm paused inside a React component. React renders in a loop has ever since the fiber architecture came out in 16. And so conceptually what I want is like, who is my parent component and when did my parent component last render?
But it's not a straight function call stack. You can't just like go back up the stack. Um, and that was actually something we really wanted to figure out how to do with, with replay dev tools and right. Mid 24, right before our company shifted gears, some of the prototype instrumentation work we had done then.
Actually allowed us to start to prototype a way to connect the dots together in time with this sort of like an async dependency graph primitive that we built and say, okay, this parent render led to this react element being created, which turned into this to-do list item component with these props. So if you're paused in to-do list item number three, we're pretty sure that it happened because of to-do list rendering half a second ago.
And we can provide sort of a synthesized component stacked and what you go back in time to when the parent worked. And we, we had just gotten that proof of concept working when we shifted gears. But I honestly, I think the, the instrumentation layer we've gotten now is. A much more sophisticated version of that data wise, and we, we could probably resurrect that and improve on it if we spent the time on it.
Andrew: Well, if you guys find the time, that would be so useful, but debugging react code, especially when you're in a hook
and all you see above you is, oh, react called me and then. 14 frames of things I don't care about that end up
in an asy task that doesn't connect me back to anywhere.
And it's like, how? How am I supposed to debug this simplest of issues?
[00:33:48] Replay Pivot and AI
Mark: So that, that's actually where, where we get into what we've literally just started trying to do within the last week or two. Um, so as a company, what we, what we found was that there was unfortunately no market for selling a time travel debugger, um, which was a shock to me as well as, you know, all the other folks, uh.
I'd always assumed that it would be pretty straightforward. Like, I see how valuable this tool is. Of course everyone else will. Um, turns out that was wildly over optimistic, but there were a lot of reasons for it. Uh, like I said earlier. Very few people have thought about the process of debugging. It's something we, we pick up by osmosis in our careers.
Not something most people were ever trained or taught how to do. And the easiest path, like I said, is just spam. Some console logs, reload the page and, and try again. And so my fake but accurate. Statistics are, you know, 90% of developers don't use graphical debuggers in the first place. Um, you know, just chrome dev tools vs.
Code, whatever. We also find a lot of friction with our product. Um, the Magic works because we've got a full fork of Chrome itself that captures all the interactions with the operating system, but that also means that if you see a bug and you're in Chrome or Safari, you have to switch over to our modified browser, which you already have downloaded.
Redo the steps to make the recording, and now that you've got the recording, you can do the magic. But there was a lot of friction in making the recordings in the first place. So we, we looked at building a end-to-end test suites tool that could drive playwright or Cypress tests and do the recordings in ci, which again, like we, we built it and it worked.
And then we, we were trying to figure out, okay, and how, how do we get. You know, people would actually pay us money for this. Um, the infra is still up, by the way, if you wanna try that out. Um, so mid 24, the company pivoted and we, we started looking at, you know, what else can we do with the technology? We spent 2025 building an AI app builder, which, you know, problem is everyone else is also building an AI app builder and we've built it and it's working.
But really just within the last week or two, we've, we've been circling back. It's like, okay, what if we kinda revisit the debugging idea, but could we make it easier for people to make a recording in the first place? And could we use AI for the debugging part? So we're, we're actually playing with two new ideas right now, um, in order to make our app builder work.
We actually like, like, you know, it's got a user preview in the ui. Everyone does. And so you can click around the user preview, but we can capture the data that happened in session, like a session replay tool, like a log rocket kind of a thing. Um, and our system right now ships that to the backend and we make the recordings internally.
So we already had kind of like a stuff you can capture in page to simulation engine pipeline going on. Then we prompt our, our app builder, you know, write playwright tests, and if they fail, we, we can also make recordings and expose that data as context or tools to the AI so that it can hopefully identify the problems, fix the bugs, and the user gets a working application.
Um, so what we're playing with right now is what if we just had a basic Chrome extension? That had like your start stop buttons, you load up your own page in a normal browser, say, you know, you know cap capture the dom, the user, the network request the clicks. We ship those to our backend. We make the recording ourselves.
You didn't have to download the special browser in the first place. We, we modify our sim engine to do the recording and then once we've got a recording. So we literally just got this going within the last week. We now have an MCP for replays backend, and it's still early days, but we've already got some examples of like a Claude code session.
Looking at your app, you know, just on your own machine, and it's like, okay, let me go ask some questions about this recording. What was the dumb tree or the component tree at this point in time? And, and we've got a couple actual examples of, oh, now that I understand this information, I have enough info to actually fix the bug.
And so. It feels like we've circled all the way back around to the thing we were doing in the first place, just with less friction and more power, and it really ties all the pieces together. We've got the time travel. We're making it easier for people to make recordings. We're hopefully. Possibly eliminating the need for the user to do the debugging themselves.
And we built all this extra like react instrumentation in, in ways to slice and dice the data in the recording. So I'm actually very, very excited about where this could go. Mm-hmm.
Justin: Yeah, that sounds awesome. I mean, I think the one point of like UX dx, friction. For replay was you gotta download the browser and then like, replay it and like do it in the
browser. And there are other companies, like, uh, we had, um, the, the CEO of, uh, jam dev who came on. Yeah, yeah, yeah. Um, and
you know,
it was, it's a similar sort of idea, you know, you got a, a, a browser extension and you can like, uh, sort of like capture some stuff that happens there and like create a bug report like really easily, but. I don't think by any means do they get the granularity of the data that you're able to capture. Um, I'm sure that like capturing the, the like events and like what happened to the dom and whatever and packaging that up and then making a simulation that like maps to, that must be fiendishly difficult, right.
Mark: Yeah, I mean we, we, from, just from a marketing perspective, like there was, there's literally no one who has done what we've done for debugging. But we also struggle to differentiate ourselves from like a session, replay tool, log rocket, full story, et cetera. And what we found is that a lot of people don't even care about like the JavaScript code.
They just wanna, you know, see the user's journey or they wanna see what happened in production on an end user machine. And we were always, well, you, you have, someone has to have made the recording and you know, and there's. We, we can give you much more fidelity. We can show you what the code did, but mo most people didn't care about that deeper level.
And so, you know, a lot of that's still true, but I mean, especially with all these, you know, these five coded apps and everything these days where people didn't even understand the code that's there in the first place, um, you know, the, the AI is really going to struggle to be able to understand those. And so if we can.
Find a way to make it happen and make it easily possible for people to say, okay, there's, here's my app. Make a recording for me, and then I can let the AI do the investigation. I, I think there's actually something
Justin: Yeah, definitely. I've, I've played with, uh, there's this skill called, uh, it's like dev browser. I can't, I can't remember who, like put it together. Um. But you know, just a, a cloud code skill that will like pull up a browser session and you can do this with like playwright or any other thing. But I mean, the opportunity to sort of have this just like plug like slot right into something like that.
And at the moment that something fails, you have it, like automatically go through a debugging session and get
like
the exact
info that
it needs would be
kind of crazy.
Mark: ~~be ~~
Justin: because. Right now it's debugging cycles is like, yeah, it'll look at the console. It'll like, take pictures of the screen and it tries to like, you know, figure things out.
And it does like a, a, you know, you, you spin 10,000, 20,000 tokens just like in this loop and it's like not really getting anywhere. And it's like, I mean, if you can make debugging easier for humans, you can potentially make it easier for bots too. And that's, that's
interesting.
Mark: That's the idea.
Andrew: Yeah, I feel, I feel like if you guys make that powerful enough, there's some, uh, AI coding companies that'll wanna snatch you up. Uh, what, what, what I was thinking about, like what replay could be. In the context of ai, I'm like, I, I need that in my cursor, like right now. I need it yesterday.
Mark: I, I mean, we, we, uh. We've only begun to explore the possibilities of having a time travel. API, I mean, I, I have so many other, I, I mean, in fact, uh, I don't know, maybe summer 23 ish, I, I started to play with performance analysis, like the fact that I can find out exactly when certain wines of code got hit.
Uh, I had a proof of concept that could look at a, a redux dispatch. Trace through the whole React redux render cycle and tell you exactly which selectors ran, how long they all took, how long a given selector took over the lifespan of the recording, and do a full breakdown of where all the time was being spent in that process.
Uh, I, I would love to revisit that one too.
Andrew: Yeah, that is also a great idea. Like I, I, I can, Ima like you, you guys as a company realize that time travel debugging, nobody's gonna pay for that. Exactly. But people will pay for like, oh, you, you can make my React app fast again. Like, uh, we had the millions Js creator on and like, I was so surprised at how like, quickly all of his tools catch on with like actual companies because people are so hyperfocused on, I want my React app fast.
[00:43:29] Redux Future and Signals
Mark: Yeah, I mean, well that, that actually segues into, uh, some of the stuff I'm trained to do with, uh, Redux and React Redux at the moment. So like the, the Redux core is done. Like we, we, we, we have nothing else to change there. Um, Redux Toolkit is. Largely done. The outstanding work there is basically, you know, improvements to RTK query, you know, new features, um, improving the code gen, uh, various other things like that.
Um. But my attention has actually circled back around to React Redux in the last few months. Um, so React Redux has evolved a lot over time. Uh, we went from, uh, the, the old style connect API to hooks. The hooks implementation went from our own homegrown subscription logic to using React using sync external store hook, which, uh, I was actually the alpha tester for that, by the way.
Um, okay. I can go back through the the history another time, but the React team had an idea. We said, here's how use selector works. They realized their first idea wouldn't work, especially in conjunction with concurrent rendering. So they prototyped use syn external store. I whipped up a branch to swap out our implementation.
Came back and said, you know, half the tests are failing. It needs these options. Can you do it? And Andrew Clark and I went back and forth a few times and the theory was, if it works for React Redux, it'll work for everybody else. And it did. So one item. Is that use syn external store intentionally has a design limitation that it's, it's the sink part where if React is in the middle of a concurrent render and it paused halfway through the tree and it processes some events.
Now your external store updates, it will throw away the work in progress, render pass, and start over from scratch. And in one sense, that's just how React always work, but it also means you're losing the benefits of concurrent rendering and time slicing and being able to, to shift things back and forth.
So Jordan Eldridge, uh, is part of the Relay team. Uh, you might. Side projects like the web amp, uh, music player and things like that. Um, and so he, he's on relay at Meta and he's taken over this, the design of what they're calling the concurrent stores, API. And I first started hearing the name of this a year, year and a half ago, and I was keeping an eye out for anything that sounded relevant.
Turns out that early, early last year, the React Team filed a PR that had tests for this feature, but no implementation. Someone from the community said, aha, I could write my own polyfill based on these tests and hacking reacts, internals. And then Jordan had his own proof of concept, saw the polyfill. It's like, Hey, I, I think we could join forces and figure this out.
So that poly fill got published last year, and then I saw it and said, okay, um. I'm pretty sure this looks like the better replacement for use sync external store that I've been asking for, that other people have wanted, so that React Redux and Zs stent can be concurrent compatible. Uh, let me get involved.
So in the fall I had some discussions with Jordan. Uh, I put up, and you can see in the React Redux repo, a draft branch where I tried it out. And, you know, our, our test pretty much passed. That turned up some more things we'd have to figure out, like what happens when a selector throws an error. Um. And what about having, uh, equality check functions built in?
And so we went back and forth on this. Uh, I filed some Dr some prs against the polyfill repo, but just a few weeks ago, Jordan put up the first, uh, draft PR to actually add this, to react itself. And I've actually been shocked that there's basically been no discussion on that pr Like, why are, why are people not getting excited about this?
Um, so, uh. I been ha, I've been happy to see it happening. I've been very excited to be part of that process and trying to push it forward. The other thing I've been looking at is something that's been in my mind for the last three to four years, and that is the render, the store update performance case, react and Redux are very intentionally dumb.
80% solutions, Redux is your store is an event emitter with one case. Some action got dispatched. It's not even state got updated, like there could be no update, but we o and iterate over all the callbacks, we run all the selectors, diff, everything, and then figure out that, oh yeah, there's these three components that had to re-render.
And that's fine when you've got a hundred, 200, 500 connections and selectors and components. Uh. A few, but a few years ago I talked with Slack and they had like 20,000 connected components in their ui. And when you're running 20,000 callbacks and selectors for every dispatched action, that is a massive amount of JavaScript overhead.
So. They described all these incredibly hacky overrides and workarounds, and every time they, they listed one, I'm like, yep, yep. I totally understand why you had to do that. Just to keep performance behaving. And so, and you know, react itself is dumb because it's, you know, doing all the tree reconciliation and everything.
So, you know, what we had always found was the best way to do performance was keep as much of the data of the checking outside of React and then just say these three components need to re-render. Which, if you watch Joseph on his talk from, uh, react Conf back in the fall, that's basically what he said too, which is, uh, a little bit of a change of tune for the React team.
So I have been convinced for the last three to four years that there is something we could learn from the world of signals, um, to somehow mash together. Signals and observables and auto tracking with react redux and running selectors. And I, I have a couple other draft prs where I played around with ideas for like an afternoon or 2, 2, 3, 4 years ago, and I, I didn't have time to push these forward or really dig into them.
The signals. I, I, I only have so much brain capacity. I can only watch so many different things at once. But the signals world, Ryan Cardo, the solid folks, have been doing a lot of research into more advanced signals, implementations that like drastically speed up the performance of just accessing and tracking values.
So. I found a couple evenings in the last couple months to do some research, scan the landscape, um, look at some of these advanced signals libraries, and then try to do some brainstorming of what would like some kind of a react re redux signals wrapper look like. Like it wraps the current state and the store.
And then we could be able to figure out like this selector. Access these state fields and if we know those didn't change, why bother executing the callback in the selector in the first place and just bypass that? Um, obviously this assumes that your selector isn't doing anything weird, like flip flopping, which pieces of data it reads.
Uh, but so like, I don't know, maybe it becomes a new hook or something that has different behavior guarantees. So I, I really need to find time to try to keep pushing that forward, but I am tentatively hopeful that maybe there's something I could find. I don't know how that will end up integrating with Used store, the, the new concurrent hook, because that has its own subscription handling because it's trying to juggle, you know, we know these hooks and components are subscribed.
React has multiple copies of the fiber tree in flight at once. What's, which one's current, which one's in progress? Which one did this component last? See, we need to rerun the selectors with a state that never even actually existed to try to make this work in between. So I don't know how these pieces fit together yet, but boy is there a lot to investigate.
Justin: Yeah, the signals world is really interesting. Um, and I feel like also react their, the react team's willingness to explore new areas is definitely, you know, growing
too. Um, I mean, I, I know it's an aside, but the work around ran compiler has been really interesting.
Um, that's, that's a a, a pretty. Big shift, I think in a lot of ways, um, outta curiosity.
Have you? Uh, I haven't, I've been trying, like I tried for a while to keep up with the signals world. All, All, I remember is like, there was this library called like alien signals or
something from like
Stack Blitz or something. That was like a, Yep. That, that that's one of 'em.
I think it was like a, a pretty fast implementation, but I don't know like how it's evolved since then.
Mark: Yeah. Uh, so as, as I understand, alien Signals is one of the fastest signals implementations right now. And then, um, if you go watch some of Ryan Kerney auto's more recent streams, there's somebody from that ecosystem named Milo who has been, who put together another signals implementation called R three, which uses some new advanced techniques of like tracking signal height, depth.
Relations. Um, so Ryan has been working on solid 2.0 for like the last year, and if you watch his streams and his tweets, he's like, I'm on like my third or fourth implementation now. 'cause every time I think I get to the point of like, this is it. This is what I need. I have another brainstorm and have to go back to the drawing board and redoing it.
In fact, I think we're we're recording this on a Friday afternoon. Uh, I believed he was scheduled to do another stream today, so probably ending right about now. Um, where he was supposed to give another update on his async signals work, um, which, which is fascinating. The idea is that the signal graph itself encodes whether any of the data is async and pending.
Then your signal ui, your UI component just tries to read the value and it's essentially like an auto suspense kicks in. Um, so I, I don't, I don't pretend to understand it, but if anyone does, it's Ryan, he is pushing the bleeding edge of what they can do, and so highly worth going back and watching his last two or three streams where he talks about this async signal stuff.
Justin: Yeah, Ryan's incredible.
Mark: Mm-hmm.
Andrew: Uh, just wanna wrap up now or do, uh, the
~~future question. Um. ~~
Mark: ~~It's, uh, probably pretty ~~
Andrew: Okay, cool. Uh, uh, well that wraps it up for our questions. Mark. Thanks for coming on and like giving us this whole history about Redux. There's been a lot of ups and downs and with replay. Also really excited to see what you guys put out in the next, uh, the coming months. So thanks for coming on and talking about it.
Mark: History of tools seems to be my position at this point. Like I've been around enough to see a lot of things. I read a lot. I, I have an idea how the pieces fit together and I can talk about them in ridiculous amounts of detail. Um, yeah, like there, there, there's a lot of history,
but I am genuinely excited about the future of both React and Redux.
Um. You know, react and Redx are a little bit like COBOL at this point in that they're, they're going to be around for a very long time, and I don't see them getting fully obsoleted anytime soon. I mean, if, if anything reacts position in the ecosystem has been even more solidified by the rise of AI coding tools that default to react.
And even if Redux isn't the default in new apps these days, it's going to be around for a very long time. So. I have like, like I said, I have a lot of plans to keep working on, you know, RTK query, react Redux, who knows what else will pop up in the next two years. And I am very, very excited about some of these, you know, automated AI debugging possibilities and react analysis stuff for
replay.
Justin: Yeah, it all sounds super exciting.
Uh, Thanks, again mark.
Uh, this is fantastic. And you know,
I just wanna say just really appreciate all your work in the ecosystem. I mean, you're, you're a, a sort of solid, um, just example to us all of like good stewardship of open source. So I appreciate all the work.
Mark: Thank you. That means a lot.