Brian: PodRocket is sponsored by LogRocket, a front end monitoring and product analytics solution. Don't know what that is. Go to logrocket.com. Thanks. Brian: Hi, welcome to PodRocket. I'm here with Ben Edelstein. Hey Ben. Ben Edelstein: Hey Brian. Brian: Hi. Ben Edelstein: Hi. Brian: And we are here with Mark Erikson. Mark, if you don't mind, maybe introduce yourself, because I'm sure you're better at introducing yourself than I am. Mark Erikson: Hi, I'm Mark Erikson. I am a Redux maintainer, and the primary one in some ways. You may know me as that guy who pops up in every comment thread that mentions the word Redux. You may know me as the person who spends most of his time answering questions about React and Redux. That guy who writes 5,000 word blog posts, or also that guy with [inaudible 00:00:55] avatar. Brian: That is a super accurate description actually because I know you for all of those things. When I started at LogRocket almost four years ago, you were the easiest person to remember because of the avatar. I was like, "Oh, well he's the guy with the [inaudible 00:01:11] avatar. I know that." And then I saw the word Redux. Well, welcome. We're excited to have you today. We'll talk about Redux and really whatever else pops up. What I want to maybe lead off with is I know that there have been some changes really recently between the legacy syntax and the more modern syntax. Of those, what are the things that people should know the most, if you could communicate only a few things about the either, I don't know if you consider an update a new version. Mark Erikson: Sure. I could go on about this for a while. I'll try to keep it relatively. Brian: We have so much time to fill, so please. Mark Erikson: Okay. So, from the very beginning, people have pointed out that writing a lot of Redux code tends to be very verbose. The word boiler plate gets thrown around frequently. In fact, one of the earlier Redux docs pages ever written was entitled reducing boiler plate. And people mean different things when they say those words, but typically they point to things like having to write action creator functions or having to define action type strings as separate variables like const add to do equals quote add to do in upper screaming snake case, or having to write nested object spread operators to do immutable updates in reducers and things like that. Mark Erikson: And strictly speaking, very little of that is actually entirely necessary to use Redux. You've never had to write action creator functions. You've never had to define your action type strings as separate const variables. The object spreads are necessary because Redux relies on immutability and JavaScript is a mutable language by default. But, a lot of the practices that you commonly see around Redux and really the ones that we've even taught in our docs over the years have not strictly been necessary, but there's been good reasons why those practices existed. And a lot of people don't like and have not liked the fact that they've had to write a lot of this extra code. And to be fair, I can definitely understand how it can get very annoying. Mark Erikson: Another common one that pops up is switch statements. A lot of people apparently hate switch statements. And so really as far back as like 2017, I had filed a discussion thread saying, what can we do to improve the user experience around Redux. What are maybe some simple abstractions we can put together that would help simplify common use cases and make it easier for people to learn how to use Redux and write less code? And that eventually turned into a new library that is called Redux Toolkit. Mark Erikson: And the idea is that it wraps around the Redux core library and it provides a set of individual APIs that you can pick and choose from. And they simplify most of the common standard things you would write. For example, there's a configure store API that wraps around the base create soar function and it simplifies the process by automatically adding the thunk middleware, which everyone uses anyway, automatically turning on the Redux dev tools extension integration, automatically adding some middleware in development mode that catch common mistakes like accidental mutation. And it also takes all these options as a single named options object rather than positional perimeters. So you can clearly say like, "Here is my reducer function. Here are my array of middleware, et cetera." So it's doing the same job, but it's cutting the number of lines of code you have to write and it's setting up the obvious defaults just with the basic call. Mark Erikson: Another thing we have is a function called create slice. And this does several things for you. One is that it automatically generates the action type strings and the action creator functions automatically based on the names of the reducer functions that you provide. It also automatically uses a really cool library called Immer. Immer is from Michel Weststrate the author of Mobx. And it lets you write immutable updates using mutating JavaScript syntax. So I can write code that says state.X equals one, two, three, or state.todo's.push new array or new item, which normally would mutate the data, but Immer attracts those and it automatically turns them into safe, correct immutable updates. So when you use the create slice API, really all you're doing is you're writing your reducer functions. You get the actual creators for free. The action types are now like a background implementation detail that you don't even think about and your reducer functions can quote mutate the state and it all just works correctly. So the idea is that it's still Redux. You're still dispatching actions and writing reducer functions. You're just writing way less code to do it. Mark Erikson: The other thing that goes along with this is back in 2019, we released a hooks API for React Redux. Traditionally our major API is connect, which is a higher order component where you pass in a map state function that extracts some data and a map dispatch object or function that lets you dispatch actions. And those all get passed as prompts to your own component. And when hooks came out in late 2018, basically like 30 seconds after the announcement, we had people filing issues on our repo asking, "React Redux hooks, when?" And it took us a little while to get to that because there were some fundamental changes we had to make to our implementation to make it possible. And there were multiple several hundred issue discussion threads that I was trying to shepherd around as we worked through some of the design discussions, how should the API look, what should it be called, what should the parameters be? Mark Erikson: But we were able to ship the hooks API in June 2019. And really at this point, we now teach the hooks API as the default way to use React Redux. The connect API is still around. We don't have plans to remove it, but the hooks API is generally simpler to use in almost all scenarios, especially if you're writing your application in TypeScript. Connect was notoriously hard to use in the TypeScript application. And with the hooks API, use selector just takes one function as an argument that returns a value and use dispatch just gives you dispatch and then you do something with it. So it's way easier to use from a TypeScript perspective. Mark Erikson: So when you put all this together, the Redux code that you would write today between Redux toolkit and React Redux hooks is drastically different than the code you would have written even just a couple of years ago. So I've taken to referring to it as modern Redux versus legacy Redux. So it's still the same concepts, same general application behavior, but the code you write and how you approach thinking about it is very, very different. Brian: I'm interested in a couple of things you said there, particularly because I'm an example of a person who wrote a lot of legacy Redux and basically zero ... I'm learning about all this modern Redux stuff for the first time right now, essentially. But I did write a ton of legacy Redux a few years ago and I totally get the problem of writing a lot of boilerplate. Yes, every time you were going to add a new action or more like every time you're going to add some new piece of functionality to your app, you have to go through a few different files. And that's what seems like boiler plate. Brian: However, one of the things that I really appreciated about Redux even while writing that boiler plate, that it was really easy to understand what the code was doing, because you were just writing simple JavaScript, passing around strings and objects. And it's really easy to reason about the code and easy to debug, especially if you have Redux logger or LogRocket and production or something like that. So I'm curious, with some of these new tools that make their value to write less boilerplate or do some things that seem magical like Immer, do you lose any of that easy to understand property and easy to debug property, or you feel like you've been able to maintain those great aspects of Redux while also reducing boilerplate? Mark Erikson: That's a great question. So as I've grown in my career as a developer, my favorite word is now tradeoffs. Nothing's black and white. Nothing's absolutely good or bad. Everything has trade-offs. And nothing comes for free. So as you said, when you're writing handwritten Redux code, the pro is that you have control over exactly everything that's happening. You know exactly how all the pieces fit together. There is no magic. The problem is you're writing a lot of additional code. When you use something like Redux toolkit, on the one hand, the abstractions are fairly thin. And especially if you've written Redux code by hand, you ought to be able to look at the Redux toolkit APIs and get a pretty good idea right away of here's what this create slice or create reducer or create async thunk API is actually doing for me internally. Mark Erikson: There are some levels of magic involved and there are some additional things you have to be aware of. for example, even with Immer involved, Redux still requires immutability. So if you start actually mutating your state, the dev tools won't work right. React Redux might not understand that some piece of data actually changed and now your UI doesn't rerender. So immutability is still key, but now the problem is you're writing this mutating syntax in your reducers. And my number one concern with teaching this as the default approach is that, okay, let's say someone writes a complete app with Redux toolkit and Immer powered reducers. And some new developer who's never used Redux comes in and they weren't on the job and they're looking at this code and they see all these mutating lines inside reducers, and they think this is the way it always works. And then they go off and they're writing their own application, and they don't realize that there's magic behind create reducer and create slice. And now they're actually mutating their data. Mark Erikson: That has been my number one concern, and I don't have a full solution for that. So the best thing I've been able to do, last year, I went through and I rewrote the Redux docs tutorials from scratch. I wrote a brand new tutorial called the essentials tutorial, 25,000 words, long that actually jumps in at a higher level, teaches Redux toolkit as the default standard way to write Redux code, builds a real world-ish application. And I plastered that thing with warnings about, immutability is an important thing, and here's how it works. And Oh, by the way, in these reducers we have Immer, and here's how Immer works. And the magic only works inside these functions. Mark Erikson: And I followed that up by taking the existing basics advanced tutorial sequence, and I heavily reworked that almost from scratch. So it still starts off by teaching writing all this code by hand, but it takes some very different approaches to the explanation sequence and how some of those explanations work. Still puts a very, very strong emphasis on immutability. And then the last section is now that you know how to write all this code by hand, here's Redux toolkit, here's how you can switch this handwritten code to use Redux toolkit instead. And Oh, by the way, this still only works with the Immer magic inside. Mark Erikson: There are also a couple other trade-offs. So Immer works by wrapping your data in a JavaScript proxy. And unfortunately, if you do console.log, some proxy wrapped value, the way browsers show that in the console is awful. It's like this weird funky object with these unknown fields that you can't understand, plus internally it's actually got Immer's own data structure inside of it. And that does actually make the typical trick of I want to log my current state in a reducer a lot harder. The half work around that we have is that Immer exports a function called current, which grabs that proxy wrapped value and extracts the plain JavaScript version of whatever it is right now. So it's a documented work around. It's not ideal, but it does exist. Mark Erikson: All that said, the benefits that Immer gives you far outweigh the potential negatives here. It basically eliminates the possibility of accidental mutations. Your code is way shorter and easier to understand and you're just literally writing less code. So trade-offs, but from my perspective, the trade offs are far, far in favor of actually using Immer. Brian: In your opinion, what's the best way for someone to transition from legacy to modern, either learning it or actually applying it? Ben Edelstein: I was just going to add to that, I was thinking if you have a large-scale application written and legacy Redux, maybe you can add on to that what is the transition path look like to bringing in the new toolkit? Mark Erikson: Yeah. And the great news is that you can totally migrate incrementally at whatever pace you choose. So Redux toolkit is just a set of individual APIs and you can use any one of them or combination of them as much or as little as you want to. So typically, the transition path would be you would start by switching your existing store setup logic to use Redux toolkit's configure store API, and that's a one-shot thing. And then from there you would pick a slice reducer and its associated actions and you would just switch that out for Redux toolkit's create slice API. You still have a reducer and associated action creators. You just fix up the imports as needed and then keep repeating. And then potentially bring in something like create async thunk to replace some of your handwritten thunks. if you're dealing with some normalized state, bring in create entity adapter for those cases. Mark Erikson: And in terms of learning how to do it specifically, that last page in the fundamentals tutorial sequence is entitled modern Redux with Redux toolkit, and it shows here's this "to do" app we've been building by hand, and now we're going to go through each of these APIs and sections of code and switch from create store to configure store, a handwritten reducer to create slice, handwritten thunk to create async thunk all the way through. So that basically is the migration tutorial. Brian: I'm curious, now with this new paradigm of writing Redux with less boilerplate and addressing a lot of the ... It sounds like addressing a lot of the complaints people had about Redux a couple of years ago. How do you look at Redux as compared to Mobx or the other state management tools? And it seems like Redux has taken a big step forward. As I understood it, part of the appeal of Mobx was that it's a bit less boilerplate code. So I'm curious how you could help people think through that decision now when building a new app. When is Redux the right choice, when is it the wrong choice, et cetera? Mark Erikson: Yeah, this is a topic I've spent a lot of time talking about. I've actually written multiple, multiple blog posts and covered this in other podcasts, but I can definitely go through it again. So, there are lots of reasons why people have chosen to use Redux over the years. One is that maybe they had complex client side state and they saw that Redux was a good pattern to use and to help solve that. Maybe they really liked the idea of writing some of their logic as pure functions separated from the UI. Maybe they wanted to write their application, state management layer first and then slap a UI on top of that or something. Maybe they were just told they needed to use Redux because everyone else is using Redux and they assume they had to use it. Or maybe they saw that Redux can help solve the prop drilling problem, where I need to use this data in lots of different places, but especially up near the top and down near the bottom of my component tree and Redux helps me avoid passing that data all the way through. Mark Erikson: So, there's been lots of potential use cases and reasons to and people who have chosen to use Redux. And the thing is that over the last few years as the React ecosystem has evolved, there are lots of other tools that overlap with those use cases. One of the reasons people picked Redux early on was because it solved the prop drawing problem at a time when React only had its legacy context API, which was basically broken by design. And when React introduced the new context API in 16.3, it was specifically designed for the purpose of solving the preparatory problem. You put some data in the top, it pops out the bottom and whatever other component wants it. And that is what context is designed for it. So if the only thing you were using Redux for was to avoid [inaudible 00:20:09], well, context solve that use case. Mark Erikson: A lot of people have chosen to cash server state in Redux. You fetch your list of do's from the server and you put it in there. And what I've seen over the last few years is that there's really been a shift in the problems that people are trying to solve. When Flux was first announced in 2014, Facebook was trying to solve the problem space of my backbone models are triggering events and I don't know what's going to change where, and things might get out of sync. And so Flux was invented to solve that and Redux was based off the Flux pattern. Mark Erikson: Over the last couple of years, what we've seen is that people are shifting more into wanting to solve data fetching and caching. People don't want to have to think about reducers and thunks and dispatching actions. They just want to say, "Here's a URL, go fetch it for me and give me back my is loading flag and a data field. And let me know when it's ready and I'll render a spinner or my list as appropriate." And you've seen libraries like Apollo and Urkel and React Query and SWR becoming very popular over the last couple years because they were purpose designed for that use case of solving the data fetching problem. And you can totally fetch data and store it and Redux, it's just that Redux doesn't give you anything out of the box to do that because frankly Redux doesn't give you much of anything out of the box at all. Mark Erikson: Tanner Linsley, the author of React Query, has retweeted a bunch of folks who are like, "I switched to Redux React Query, and I dropped 5,000 lands code in my application." And to be honest, it's not surprising because that was probably a lot of handwritten thunks and loading state flags and the action creators and stuff. I get a little annoyed when I see him tweet that, but it's a totally fair point because we didn't give you anything for that. Mark Erikson: So we do actually have something in the works for that use case. I have a couple of very, very talented co maintainers on Redux toolkit. Lens Webber and Matt Sutkowski, and late last year they sat down and they started building a library that we've called RTK Query. And the idea is that it's a data fetching solution specifically built on top of Redux toolkit that takes a lot of very obvious inspiration from React Query and Apollo and those sorts of libraries. And it's built on top of Redux tool kit. So it's UI agnostic. You can use it outside of any UI if you want to. We've had people building integrations with NgRX for angular and Vue and Svelte. Right now it's technically an alpha, but we're in the process of finalizing will be the last alpha. And at the moment it's a standalone package for the initial development purpose, but as soon as this last alpha is done, we're going to be taking that code base and the docs and merging it back into Redux toolkit directly. And it will be going out in the next Redux toolkit minor release, tentatively version 1.6. So we're hopeful we'll have that here fairly soon in the next few weeks. Mark Erikson: So to finalize and actually go back and answer the original question, like I said, there's lots of reasons you could choose to use Redux. The existence of all these other tools with overlapping use cases means there are a lot fewer times when you would have to use Redux to solve those specific problems. So I would say the main reasons that you might want to consider reusing Redux today are things like the emphasis on rating as much of your code as predictable pure functions as possible, keeping state management logic out of the UI, the ability to use the dev tools to track when, where, why, how state changed over time, middleware and the rest of the tools in the Redux ecosystem. Those are really the strong points of Redux still. Brian: I have a few questions. I don't know if I get to all of them, but I have a few questions that I have less to do with perhaps the technical details about Redux and more about Redux as part of the front end of zeitgeist, If that's okay. For example, my first question is, why do you think so many developers are borderline obsessed with commenting on whether or not Redux is dead or alive? Full disclosure, LogRocket is not blameless in this. I know that we just published something. I was like, "Redux is not dead. It's alive." Mark Erikson: Yes. I already saw that post and comments on it. Brian: Yeah, I saw, I saw. But I'm curious, you must see it every week, all the time. Mark Erikson: You have no idea. Brian: Yeah, yeah. Yeah. Mark Erikson: There's multiple factors here. So every technology goes through the, what is it, the classical S curve? There's the early adopters who get excited. There's the majority who finally get interested and then it trails off into obscurity or at least it loses its shine. And Redux is no exception. Redux was a new and different thing in 2015 and 2016, and then it became standard and you had everybody insisting that if you are using React, you have to use Redux in 16 and 17 and so on. And then, like I said, over the last couple of years, you've had all these other tools coming in that overlap with Redux as use cases. And people also realized that Redux was legitimately being way overused. A combination of people not understanding when they really needed it and being told to use it without realizing what problems it was actually trained to solve. Mark Erikson: So there's been an inevitable backlash against it. And some of that's been justified. Well and truly Redux is overused, but at the same time, people take that too far and they say, "Well, just because I no longer need it, it clearly must be dead." Or, "Hey, somebody announced the 30th new state management library this week. Redux must be dead." That sort of thing, I take exception to. I don't want everybody to use Redux. I'm not insisting that everybody has to use it. I just want people to take the time to think about what problems you are trying to solve in your own application, understand what kinds of problems each of the different tools that are out there are trying to solve and evaluate for yourself, do these tools solve my problems? And if so, maybe I should consider using it as a side item. Mark Erikson: I actually got fed up with this problem recently, and I decided to try to do something about it. And I put up a new repository that I tentatively dubbed the React community tools and practices website. I'm conceptually modeling this off of the React TypeScript cheat sheet, which is a wonderful site started by Sean Wong. It's basically the de-facto guide to how to use TypeScript and React together. And my mental model for this is that it should be a curated community effort that lists the most common tools in a bunch of different categories and the most common techniques for solving various problems. And it should be slightly biased and curated in the sense that it shouldn't end up as a list of like 5,000 state management tools with one star and GitHub a piece, but it should be unopinionated in the sense that it's not use tool X instead of tool Y, instead it should be like a best faith effort from an expert, perfectly the author of each of these tools saying, "Here's what this tool does. Here's its strengths and weaknesses. Here's when it makes sense to maybe use this, here's when you should consider not using this." Mark Erikson: At the moment, the site is barely a skeleton. We've got a Netlify URL and a Docu sort of site that has two pages, which I wrote in about four hours one afternoon because I had time. One is just an overview of what the state management mean in React. And then one is a page for Redux describing when you might want to consider using it and when not. I want to get the rest of the React community involved in this. And some other people have indicated an interest in contributing, but I've been focused enough on Redux toolkit things over the last couple months that I haven't had time to go back and really push people to try and contribute to that. Brian: Sure. The reason I ask is I've been making and aware of front-end content now for a few years, and I've never seen anything ... There's nothing else that I can think of where people have those kinds of opinions like Redux. Maybe because of its connection to React, and React is obviously popular but- Mark Erikson: I know. I know. Part of it might just be that it is the quote unquote the front runner in React state management combined with the fact that it is overused, but I don't get the waves of hate. And it frustrates me because I want there to be nuance. And unfortunately most of this happens on Twitter, and Twitter is the worst possible place for nuance discussions. Brian: Yeah. That's your first problem, is Twitter, yeah. That does actually remind me, not the Twitter part, but obviously there's a, I don't know if you'd call it a cottage industry of front-end content that's created by not the creators and authors, but there is a fair amount of Redux and other content that you didn't make that's out there and some is good and maybe some is not so good. What's the best way to go about creating secondary source if you're the primary, when you were in your maintainers, what's the best way to do [crosstalk 00:30:49]? Mark Erikson: That's a good question actually. I have repeatedly expressed frustration that even now in 2021, after we've been recommending Redux toolkit as a default for close to a year now, people are still writing new tutorials on various sites, and sometimes even well-known sites, that are still showing legacy syntax purchase. And of course there's thousands and thousands of other tutorials and articles and videos out there that were published years ago that will never, ever, ever go away. And I also realize that in a lot of cases, it takes time for people to update things. I noted the other day that Codecademy and freeCodeCamp are still showing older Redux and React practices. And it takes time to go through and update that stuff. I totally get that. Mark Erikson: But certainly the current Redux tutorials are by far the most up-to-date because I re-wrote them from scratch recently. So I guess part of the question is if you are wanting to write a tutorial on a given topic, you need to try to find a way to do it and give it your own spin so that you're not just blindly copy pasting some API reference examples or blindly copy pasting what's in the docs already, some kind of a unique example or voice or scenario or explanation, something to make it worth reading. This also goes off into the discussion of should new developers blog if they have no worthwhile experience to talk about? I don't want to discourage anyone from getting involved in writing, but there are so many tutorials that just blindly regurgitate what's in a tools documentation already. Mark Erikson: I think the best examples are ones that offer some piece of information or explanation or nuance that aren't in the docs. I'll give two examples. One for myself and one from Dan Abramov . So the React docs have mixed reviews. Some people love them. Some people hate them. The React team is actually in the middle of rewriting them from scratch right now. They don't go into a lot of details about how React works beyond talking about some of the API functions. And so Dan Abramov, a couple of years ago, shortly after hooks came out, ended up writing a massive article called the complete guide to use effect. It's like a 45 minute read. And it goes into all kinds of details talking about like JavaScript closures and the intricacies of writing a use interval hook. And from my perspective, it's basically required reading for anyone who's gotten past the basic React tutorial. And that's because it's exceptionally well-written. It's from someone who knows what they're talking about on the topic, and it covers a ton of important information that is not in the docs yet. Mark Erikson: In May of last year, I ended up spontaneously writing an article called the mostly complete guide to React rendering behavior. And it was inspired by people who were confused over sometimes why are my state updates batched and other times they're not, or what happens when I pass down new props versus when I call set state but don't pass down any new props, why is my components still rendering? And it's because React rerenders everything rightful. And I've covered a ton of information in there and I've kept adding to it over time. I think it started off at like 5,000 words and now it's like 8,500 words, something like that. And I'm not saying that everyone has to go out and find some specific thing that's totally uncovered and write a 5,000 word article on it, but the best approach you can take when trained to write your own version of something is to make it your own version and not just a copy paste of what's in the docs. Brian: Yeah, no, I agree. That's good advice. And believe me, we see our fair share of ... And sometimes we have to point out, I don't know, you just cut and paste this from the docs. Do you want to maybe try something else? I think this isn't about Redux specifically but it is about front end and maybe front end content. So for context, a couple months ago, just to see whether or not it would work, I put a little [inaudible 00:35:31] because the audience is developers. I put a very tiny pop-up in the bottom left-hand corner of the blog that was like, "Hey, we're thinking about starting a research program. Do you mind answering some questions?" And to my great surprise, many people said they would, and they were three open-ended questions. Brian: And one of the questions was, what is your biggest complaint about frontend now? And again, open-ended questions and the winner far and away was that there are too many things to follow. It's too complex. I don't have the time. I like cheat sheets and all that, but honestly, there's just too much going on. The question here is, is that something that resonates with you and what's the answer? It's a hard question. Mark Erikson: Well, it definitely resonates. I'm an information junkie by nature. I read really fast. I like reading and absorbing a lot of information, and really reading them and absorbing information is how I've ended up in the situation I'm at. I got my start with Redux by offering to rate an FAQ page back in early 2016. And it was because I happened to be hanging out in a React reflux and reading Reddit and reading stack overflow and seeing the same questions pop up. And I had also seen most of the answers already. And for a couple of years there, I was trying to maintain a links list repository of useful and interesting articles that I'd read on various React and Redux related topics in the Redux ecosystem libraries archive page. And I actually had to give that up in 2018 because it was basically causing me to burn out, just trying to keep up with this on a weekly basis. Mark Erikson: And I still spend way too much time reading articles and discussions and spending too much time on social media and whatnot. So I absolutely am in total agreement that it's a giant fire hose. And even with me trying to scope back and narrow down what I'm focusing on, there's way too much to follow. And I don't know how most other people even try to deal with it. And I think there's lots and lots of reasons for this. One is that front end is a very, very broad ambiguous term. And there's been plenty of people who've written good articles on this. I think Chris Coyier, however you pronounce it from CSS-Tricks, has written some articles on how front-end devs now can basically cover everything from writing JavaScript to doing CSS to, look, doing serverless functions. That's all our domain now. Mark Erikson: But at the same time, it's like, Oh, you've got your business logic, Javascript erating people. You've got your component library making people. You've got your designery people. You've got your accessibility people. There's so much overlap in what we term as front end. And now when you factor in that the web is basically the primary application delivery mechanism today and everyone has to do front end somewhere for every application to some extent, combined with the fact that the browser gives you relatively little out of the box and we have to keep creating all these tools to fill in gaps in functionality, it is just this ridiculously huge fire hose of stuff to come up with. I don't have an answer for how to keep up with that. I guess in a sense, my notional community tools practices documentation site is meant to help with one very small piece of that, but I certainly don't have an answer for it in the general sense. Brian: No, I wouldn't. If you did, I'd be amazed because I've seen the same thing. And also, you know in the last episode of rocket surgery that I did with Caitlin, who's our front end developer here, we talked about there was Chris's article and then also Brad Frost article, the middle of the front end, the front of the front end and the back of the front. That's several people. That's not just one person. So yeah, it's tricky. For me anyway, it feels like the time flew by here, but [inaudible 00:40:02] we are coming up on the end of the episode. I like to end this on a positive note. So, what is it that you're looking forward to in web dev over the next, I don't know, six months a year, what are the things that you're excited about outside of, well, maybe it is Redux the modern implementation? Mark Erikson: Well, yeah. The immediate thing I am excited about is actually getting this RTK Query library finalized, merged back into Redux toolkit and getting that new release out the door. I've been very, very happy about the enthusiastic response. We've got people trying it out, even though it's an alpha, people asking questions about it, even though just an alpha. So clearly there's an interest in actually having to ship that. That's my immediate train of thought. On a slightly longer term, I'm very, very curious to see what React suspense and concurrent mode finally look like when they're actually out the door. It's been a very, very long journey. I've paid attention to it. In some ways I've decided I'm not going to pay any attention to it until it's actually out and done. Mark Erikson: I think in some ways, it won't change much. In other ways, it might drastically change a lot and we won't fully know how it's all going to play out until it's really available and people have a chance to start getting hands-on with it for real. We're likely going to end up doing a new version of React Redux sometime after that comes out once we have a chance to play around with it and see how it actually interacts with our APIs. But, that certainly is a big thing that a lot of people have been waiting for. Mark Erikson: And then the other, I guess, tool related thing that I'm starting to keep an eye on is the new generation of built tools that are coming out, especially stuff revolving around esbuild, which for those who aren't familiar with it, is a JavaScript compiler and a bundler that is written in the Go language instead of a JavaScript. And it's designed to be non ironically blazingly fast. And Sunil Pai did a great video with Jason Lengstorf a few weeks ago, where they talked about the implications of what happens if I can compile my whole app in a quarter of a second, how does that change my workflow? And we actually just merged in a switch to Redux toolkit's own build pipeline, where we actually switched out from using Babel and Rollup to using esbuild to do it for various reasons. So there's esbuild by itself. There's other toolkits like [Veet 00:42:59] from avenue, the view maintainer that build on top of that. It's not like create React app and Webpack are about to be obsolete overnight, but there are some very intriguing things going on in that space. Brian: I didn't really sneak it in. I'm glad I asked the question, that part about a quarter of a second, I think people are going to be real excited about that. So I'm glad we ... Okay. The other things that we have time for, obviously plugs and stuff, but I also like to ask, who are the people that impress you that maybe deserve a little more attention? If you're around, you see them either Twitter, Reddit, people who are actually making stuff on GitHub. I just revealed one of my own biases, that if you're on Twitter, maybe not you're making stuff. But yeah, who are the people you feel like deserve a little bit more attention at least? Mark Erikson: well, I mentioned them earlier, but I'll give them plugs again. My code maintainers for Redux toolkit, Lenz Weber and Matt Sutkowski. Redux toolkit would not be what it is right now without their efforts over the last year and a half or so. Honestly, in a lot of ways, I can't entirely write a whole lot of code for Redux Toolkit because the TypeScript types are now complex enough that I don't really understand them. Lenz is our resident TypeScript genius, and he's done so much work in that area. And Matt has done a lot of work in filling out the edges as well as implementing a lot of the RTK Query stuff. So I totally want to plug them. They deserve some attention. Mark Erikson: Honestly, the first two other names that pop into my head are just Sunil Pai, who always has a lot of really good thoughts about, I guess, almost philosophy of JavaScript development and stuff. And Sarah Drasner, who was just amazingly awesome at everything to the point of making me feel bad about myself. It's not like they're not well known already, but just literally the first two people who pop into my head as people who were awesome and I fully respect. Brian: For sure. I think we're all interested. At least I am into where Sarah will land. Yeah. Well, cool. This was really easy. I felt like we could go for another 45 minutes. Unfortunately, I'm not sure that the audience would listen to it. Thanks Mark. It was a pleasure. Mark Erikson: Thanks. Glad to be here. Appreciate it. Brian: See you later. Hi, thanks for listening. Please remember to like, subscribe, email me if you want, even though none of you do. Go to logrocket.com and try it out. It's free to try, then it costs money, but yeah, we'll see you next time. Thanks.