Tejas and friends: Mark Erikson
===

[00:00:00] Hi, and welcome to PodRocket. I'm Tejas, and today we're just having a casual talk with a dear friend and very smart person, Mark Erickson. You may know Mark from community projects like Redux, Redux Toolkit, and also from his excellent work on Replay, the time traveling debugger. Welcome to the show, Mark.

Hi, glad to be here. This should be fun.

I'm really excited. We spend so much time talking in the hallway track at conferences and sometimes on Discord, and I feel like to invite the broader community into a discussion like this might be helpful, and that's the context. Before we get started, do you mind sharing with people who you are, what you've been up to and what you're excited about these days.

So I'm Mark Erickson. My day job is a senior front end engineer at replay IO, building a time traveling debugger, a large portion of my free time is spent on working on lots of stuff around Redux and answering general questions in the React Redux ecosystem. The other part of my free time is spent playing golf, which sadly is about to come to an end because it's October and it's getting colder.[00:01:00] 

I answer questions anywhere there's a text box on the internet and people usually recognize me by my Simpsons avatar.

Yeah, it's funny. I'm glad you mentioned the Simpsons avatar because I'm looking at you as we record this and, gosh, everyone, he really is a Simpsons character in real life. No, I'm just kidding. Okay, so, I think people know you best from Redux and Redux Toolkit. Where were you before Redux?

What were you working on? And then what led you to Redux and Redux Toolkit?

, it's like Redux has always been a free time project. It's something I've done outside of my day job

Semi abbreviated version mid 2015. I'd spent a few years working with Backbone and some jQuery and also with a technology called GWT, Google Web Toolkit, which was a Java to JavaScript compiler. I felt like I'd hit the limits of what all those tools could do. I'd heard about React. I started, learning through reading blog posts and that sort of thing.

Found the React to FlexChat channels. Started just working [00:02:00] and trying to learn from other people's discussions. Started seeing questions that I knew the answers to, and I'd be helpful and respond. Started seeing questions where it's like, Oh, hey, I saw a blog post about this the other day. Let me go back in my browser history and copy paste the link.

Found myself pasting the same links over and over, started collecting those. By the end of the year, I was answering so many questions. They asked me to be a moderator and I still hadn't actually written any real react code yet. And then I ended up volunteering to write an FAQ page for the Redux docs at the start of 2016.

Had some free time, did that over the next couple of months. Dan merged the PR, gave me commit rights. He was already working on the react team at Facebook by that time. And eventually he got busy, too busy to work on Redux and gave the Redux keys to myself and a guy named Tim door. There was.

Further stuff like it was still another few months until I actually felt like I had the right to say how any of this stuff was supposed to be [00:03:00] used, but it was very definitely a process and not anything I was trained to get involved with in the first place.

Wow. That's so interesting. So you're working with the tools of the day. You mentioned GWT. I appreciate that shout out was to take us on a little bit of a tangent because the point of this is tangents, right? And I think it's tangents of community would appreciate GWT was a toolkit. And I've heard of the Google closure compiler or GCC.

Is that how does that fit into the toolkit? What does it fit into

I believe these are actually two different tool chains. And there was even, I think Google, there was actually a hacker news thread about closure compiler, just like a week ago and some of these things popped up. Okay. So a bit of background. Early, like mid 2000s, like around 2005, 2006 real, like what we actually know today as web apps, we're just starting to become a thing.

Google Maps was an earlier one maybe Outlook for web and a few other things. Google was always very heavy on Java and [00:04:00] C As their primary languages they were starting to use JavaScript at scale. And so different sections of Google invented some different technologies.

One of them was Google web toolkit, which was a compiler that started with Java source code, and it would read that in. And compile it to JavaScript. And they actually reimplemented large portions of the Java base class libraries with the JavaScript underpinnings so if your Java code was.

Kind of like relatively simple enough. You could actually just drop it into a GWT project and compile it and it would spit it out for use in a web browser. And this was a big deal because it would let, with existing Java experience start to write front end client apps, which kind of sounds like the sales pitch we have now for using JavaScript on both sides.

Meanwhile, They were also building [00:05:00] applications like Gmail and a whole bunch of others. And some of those were being written in real JavaScript, kind of like the, some of the first times this was being done at a large enterprise scale and JavaScript as a language was not designed for that.

So the closure compiler was a very advanced and very early on. Compiler that did a lot of the things that we would now understand with TypeScript and Webpack and Tercer and other tools. It would, I can't remember if it would bundle. I know that it had comment based type annotations So like the JS doc syntax that TS now supports.

So you're saying it's a variable, but you're seeing like it's a number or a string, but you're doing so by putting a comment. And it was a very advanced and still is a very advanced minifier. And in fact, even today [00:06:00] react uses the closure compiler in its build tool chain, because it ekes out that like extra 2 percent compression.

Compared to some other minifiers.

Okay. So you were using the tools of the day and recognizing, okay these things don't quite meet the need. And then, so around 2013, so 10 years ago, React comes around and you start getting into it. And you mentioned, did I hear that right? You answered a lot of questions in a lot of places before even writing React code.

I started learning react summer, mid 2015 reacted, been out for a couple of years and was in the adoption curve was starting to go up. Purely by coincidence, it was literally the exact same time that Redux was being developed. I had no idea. And yeah, like I was pattern matching and I, absorb information.

And I would see somebody answer a question, remember the answer later on. Someone else asks that same question. Like I know this, even though I haven't done it [00:07:00] myself and at the day job, I didn't write my first react code until I'm going to say December, 2015. It's like it'd been like five to six months.

That I'd been working and starting to answer questions in the reactive flex chat channels, and I was answering a lot of these questions before I'd actually written a the code. So theory over practice.

when you started then writing React code eventually What was that experience like? Was it, did it feel like, okay, I knew all of this stuff in theory, but now to put it into practice I'm fluent, I'm, it's easier, there's no friction, or.

There was absolutely a learning curve when I tried to write the first code. I have a work journal. I could go back and look at what I was writing. On those days, like it can't do it right at the second, but like I could actually go back and look it up afterwards. The very first react code I tried to write.

So I had an existing GWT application that it showed stuff on a 3d globe. There was a left hand sidebar with a tree of some list of points and lines on the map. [00:08:00] And for some reason I picked. Recreating the tree view as the very first react and Redux code. I wanted to write like, I, I didn't skimp.

Like I jumped right into something pretty meaningful. And I think my thought process was if I can make that work, that proves out enough. Pieces. That this is a viable strategy for rewriting the whole client side.

And it took me I'm going to guess two, three, four weeks to actually build it out.

Maybe I'd have to check. But I got it working. I rewrote most of the rest of the client over the course of 2016 weird project management shenanigans occurred. And then as a team, we finished it out in like late 2017.

Interesting. So the first time you used it was for a work thing. There was no like weekend side project where you bought a domain and went nuts. Interesting.

Like honestly, I really haven't worked on pure side projects of my own since before [00:09:00] 2015, partly because I've gotten involved with Redux and probably because the day job mostly scratches the itch for needing to build something.

This is, I think, okay, I'd love to talk a little bit about practical takeaways for people listening, because I bet there's a lot of people listening who are wishing they could do that. They could maybe they're forced to use something like, I don't know, React. I guess that's the de facto standard today in their work.

And they're using React, day in, day out, 40 hours a week. But they keep hearing about Astro. Astro is great. Astro this, Astro that. Islands, solid, ooh, signals, runes. And, like you with React, even though it wasn't your daily driver, you develop this working understanding of it such that You could explain, even teach it to other people.

I'm curious if we can maybe extract a protocol there, maybe a vague pro a very crude protocol there for people who are in a similar situation, right? They're not using the thing daily, but they're interested in the thing. How might they go about learning about things that well?

So I, I always feel a little weird [00:10:00] trying to give advice in this kind of an area because I feel like My personal learning style does not seem to be all that common. Like I routinely see people asking I want to learn. We're next. What's the best you to me course or who's the best YouTuber about this?

And a lot of people are really looking for. A comprehensive course that is going to walk them through all the concepts and the pieces. A lot of times they're looking for something video based. And I don't at all want to disparage those. Everyone has different learning styles. My own learning style has always been very text based.

I want technical details. I want documentation. I want to jump into the source code of a tool and poke around at it and see what it's doing inside. And then I want to get hands on and actually just try using it myself and see what's happening. And I get the sense that puts me in a distinct minority.

The other factor is that [00:11:00] most of the things that I've learned over the years have been directly driven by, I need to build this thing for work. I don't know how to build this thing for work. I have a partial idea where I should get started, but I'm going to have to go frantically Google up a whole bunch of things.

And then I'm like grabbing little pieces and ideas and snippets of source code and like cobbling together something that works based on a half different, half dozen different Googled up pieces. And so I personally have never actually purchased a course to learn from In a sense, my learning is very self directed and ad hoc and as needed.

I do think as a whole that there is a lot of value for people actually getting hands on again, like courses are, it can be useful watching someone else describe and show and put things together. It can be useful for myself. I think actually [00:12:00] trying to build something, whether it's You know, like following along with the tutorial and actually retyping all the code yourself or just, I have just a project that I want to try.

Maybe I'll switch out one or two technologies that I've never used before or like I have a feature I want to build. I don't know how to do it. Let's figure it out. Is a very valuable method of trying to actually learn things.

That's really, that speaks to me, because I also have never purchased a course. I don't do, I don't learn that way. I don't learn with... No disrespect to Andrew Clark, but I don't learn with Andrew Clark telling me to not use a framework. I want to know why. What do frameworks do? Why do you have getServerSideProps, for example?

Why do exports need to be default exports? In Next. js, things like that. And I, so what I'm hearing is a lot of it is based on Reading both source code, supporting documentation. And I think the real takeaway for me is questions. I never thought to go read questions and read the answers and then learn the answers so [00:13:00] I can teach others.

That's something I might work into my daily practice. And also scratching your own itch. You mentioned solving your own problems with the code. Yeah, brilliant let's talk a little bit about what you're using all of the stuff you've learned on. So thank you, by the way, you gave us a really great overview into how you got into it, where you were before Redux, how you even were given the keys to the kingdom.

But let's pivot and time travel, haha, pun intended. Today what is it that you're working on today that, that's really scratching your itch?

So a year and a half ago, I joined replay IO as my day job. We're a startup building a time traveling debugger for JavaScript. And I picked this company for a whole bunch of reasons. It is a great team of great people. Like I legitimately like everybody on the team. Everybody is an excellent engineer. The product itself is inherently useful because it saves developers time.

And I wish I'd had this tool in my own day job work years ago. It is technically [00:14:00] challenging. I am getting to solve unique and interesting problems on a daily basis. And I am like. Hyper, super excited about the stuff we're going to get to build in the next couple of years. If we had an hour and a half here, I would sit and tell you about all the cool stuff I've gotten to build in the last year and a half and all the cool stuff I want to build that we just haven't had time to.

So I am literally loving my day job because of all these factors right now.

You talk about the people, your team, and how much you love them, and I can only agree. I was texting with Gerald yesterday who was... Who is now crushing his running. He's running like six miles a session now, which is great. And he felt the need to report that to me because I got him into it in React

Gerald is a hoot.

Yeah, your entire team, man, really brilliant people. Okay, so you mentioned you're really, living your best life solving, I believe it's unique. And complex engineering problems. What's one of them?

I'll attempt to briefly list some [00:15:00] of the stuff I've done. So the idea of replay is you make a recording of an app with our modified browsers of Chrome and Firefox, and then we can time travel debug it up in the cloud. So in your UI, you're looking at a recording of the app for a couple of minutes.

You've got , a debugger that shows you source code and video and console messages and all that stuff, but you can jump to any point in time in the recording. You can add a print statement that shows you messages every time a line of code got hit and all that is powered by our backend API. The real magic happens up in the cloud.

And we have API calls that lets us basically treat time travel as a toy to play with. And we've used that API to build a super powered debugger, but we are barely scratching the surface of what you can do with it. In the last year, I've built features like our support for React DevTools in when you make a recording with Chrome jump to code features where when you made a click in [00:16:00] the app, we can figure out like what React on click handler, Ran Redux dev tools.

I've built out a couple of proof of concept features where I can give you a hint of every time you called set state in your react app, or. A proof of concept profiler that finds every Redux dispatch and breaks down the time spent like running the reducer, notifying the subscribers, trying to find the render that happened finding every selector that got called and figuring out how many times it ran and how long those added up to.

And a lot of this is still proof of concept. It's not even close to being a shipping feature, but these are still barely scratching the surface. had a company offsite last week and we're talking about like the react features we want to build like just in the next six months or so.

And that's things like showing, if you're paused. In the time travel inside of a react component, being able to detect what the component stack of its parents [00:17:00] is displaying that show every time that the component rendered and committed, like there are so many things we can build that we just haven't had time to do, which is ironic,

Wow. Yeah. That level of granularity doesn't exist at all. Like not even in the reactive tools and the ability to even visualize timing. Now you got me thinking about what we can expose, right? The ability to visualize the time between render and commit even could really give some insight into your use transitions and where things may be blocking, for

Ironically enough, that's one of the ones we might not be able to do due to technical limitations. We were arguing about that one during the offsite.

Okay, I would personally love to see that. Mainly because I've used quite a few buggy user interfaces where. I'll click a, so for example, a little comment user interface, right? I'll click a plus button to add a comment, and the comment form pops up, but this delay takes quite a while to commit.

And so somewhere, rendering is, I'm assuming, being blocked, but I have no way [00:18:00] of knowing, right? Until a tool like Replay can literally show me that in a time travel way.

there's a couple levels of complication here that I could spend a lot of time going into. One is that React's Dev tools integration exposes some data, but a lot of the stuff that I just talked about actually requires like using time travel and knowing that if I poke into the right place inside of react, I can get some information, but it's absolutely not public at all.

And there's certain things that are very fragile and could change as the react team just like refactors their code and moves pieces around. And so we have concerns about trying to build features. On pieces of grabbing data that is not necessarily stable or reliable. Another factor is that react doesn't currently ship source maps and it never has.

So they ship a dev and a prod bundle. Dev has all the comments and original variable names. Prod is already minified [00:19:00] and there's no source map for it. I will note, I have a PR up. That's been sitting in react repo for five months now where I changed their build system to generate source maps.

Nice.

And then I've also done the work to backport that and generate source maps for existing versions of react and someone else from century contributed build tool plugins.

So you can just update your web pack V or a couple other build tool configs and it will automatically swap in the source maps for the version of react. That you're using and having source maps at least makes it a little more consistent because now you can search inside reacts internals for functions by name to grab data instead of making really stupid hacky guesses like it's still hacky, but it's less hacky.

It's been cool getting to work on all these sort of interrelated pieces as part of my day job and see the ways that they start to stack on each other and let me build something interesting

Yeah, that, that does sound [00:20:00] extremely interesting. I feel like replay should, or you really from replay should join the react core team. And then you can, protect the things that you're scared of changing and really build. On things in a more confident way. Anyway, probably a discussion for another time.

Also, by the way, while I'm dropping unwanted suggestions if Replay ever has a rebrand it has to be called Kang, The Conqueror, DevTools. Because that's exactly what it allows you to do. But Mark, listen, I can't believe we're out of time. If you ask me, it's criminal. I could sit here for at least another two hours with you but I, I do want to acknowledge, thank you for making the time to come on here. Share with us how you got into things and what you're currently excited about.

And on my behalf, of everyone at the podcast, I want to thank you seriously for coming on and enlightening us.

I definitely appreciate the invite. I appreciate chances to talk and share and babble about stuff that I'm working on, but I honestly always appreciate a chance to talk to you seriously.

Wow. Thank [00:21:00] you. It means a lot.