Kent C. Dodds (00:00):
Hello friends. This is your friend Kent C. Dodds, and I'm excited to be joined by my friends, Lydia and Evan. Say hi folks.

Lydia (00:07):
Hi everyone.

Evan (00:07):
Hey.

Kent C. Dodds (00:08):
I asked you to say hi folks, but that's okay. Just kidding. So yeah. Lydia, is it Halle?

Lydia (00:17):
It is Halley, but it's okay if you say Haley or Hill. I've heard-

Kent C. Dodds (00:22):
Heard them all.

Lydia (00:22):
Yeah.

Kent C. Dodds (00:24):
And it's Evan Bacon, which is fantastic. So just feel hungry all of a sudden. So actually this is the first time we've had two people on Chats with Kent at the same time, which is exciting. So Lydia, why don't you go ahead and go first, introduce to our friends who you are and then we can hear from Evan.

Lydia (00:47):
Yeah. So I'm Lydia, I'm a software engineering contractor, but you'll probably know me from either the JavaScript visualized articles or maybe the JavaScript questions, any of those more educational resources that I do on the side. Or as the avocoder on Instagram. If Evan ever calls avocado or avocoder, he means me. He never calls me by my normal name.

Kent C. Dodds (01:14):
I was originally introduced to you through a Medium article that you wrote years ago when you got into the industry, right?

Lydia (01:22):
Yeah, yeah, yeah. many years ago I wrote, I think it was called like advice from a 19 year old software developer or something. Yeah. That kind of blew up.

Kent C. Dodds (01:30):
It was a great article. I'll have to find it and stick it in the notes here.

Lydia (01:35):
Oh, thank you. Yeah, no.

Evan (01:37):
That's how I got introduced to you, too.

Lydia (01:38):
Yeah. He used to like, kind of introduce me as the girl who wrote the Medium article. I was like Evan, I'm with you everyday nonstop and I'm still just the Medium girl but whatever. I mean he's the marked out engineer, like cool.

Kent C. Dodds (01:55):
Your markdown is pretty good.

Evan (01:59):
Oh, okay. So yeah, I'm Evan Bacon. I'm an engineer at Expo, which is an open source platform for building apps with React for iOS, Android and web. And I've been doing open source for maybe like three or four years now. And I date the avocoder. Yeah. That's about all there is to me.

Lydia (02:19):
That's your resume.

Evan (02:21):
The whole thing.

Kent C. Dodds (02:22):
In a nutshell. Very good. Cool. Well, it's just a pleasure to have you both on, and you mentioned to me earlier that people often ask you what it's like to date somebody who does the same kind of work as you. And I imagine there are a handful of our listeners who have been or are in that situation now. But yeah, just to get rid of that elephant in the room, what is that like?

Lydia (02:48):
I mean, well, we kind of started living together right before the pandemic hit. So like we immediately had to spend quarantine together, like nonstop and we both are kind of workaholics. So in the beginning it was kind of weird because we were both just coding and working like 24/7. And I guess I got kind of-

Evan (03:08):
That didn't change by the way. That was in the beginning and also in the middle and end.

Lydia (03:13):
Yeah. Yeah. So what is it like? It's-

Evan (03:18):
It's pretty good. I think normally in other relationships I might have conversations about not exercising or something. And now I have conversations about node and [stack 00:03:30] traces, and-

Lydia (03:30):
Yeah. We often just kind of think about how JavaScript can be implemented, or TypeScript actually, and in other parts of the world, like Neuralink or I don't know, you name it. We kind of just sit on the rooftop, have a glass of wine, just think about what's possible with JavaScript.

Evan (03:53):
Microwave or something.

Lydia (03:56):
Yeah. That's kind of our everyday life. I'm so [inaudible 00:04:03]-

Kent C. Dodds (04:02):
All day, all day just talking about JavaScript.

Lydia (04:05):
It's really fun. It's really fun. I mean, he's doing, even though we're both JavaScript developers, he's doing stuff that's completely different to what I'm used to. So he's teaching me so much about native developments and-

Evan (04:17):
Yeah, and you teach me about LA express servers and draft [inaudible 00:04:20], things I should have already know but don't.

Lydia (04:22):
Exactly. So it's never boring. We teach each other a lot. So it's awesome.

Kent C. Dodds (04:29):
Well I think that's great. And it also kind of speaks to just the breadth of the JavaScript ecosystem in general is like you're both doing JavaScript, but they're very different parts of the JavaScript ecosystem. So yeah it's kind of interesting. It's fun.

Evan (04:44):
Yeah. It doesn't really overlap much, so.

Lydia (04:47):
No, not at all. And hopefully it'll only grow bigger. JavaScript could be applied to almost anything.

Evan (04:55):
Yeah, it's exciting.

Lydia (04:57):
Yeah. Yeah.

Kent C. Dodds (04:59):
Yeah. And we talk about how JavaScript is growing and everything, but the standard library for the most part is staying mostly the same. Like we have the TC39 working on different proposals and like Web Standards are working on things, but lots of the innovation and things going on in the JavaScript ecosystem are coming out of the JavaScript ecosystem, like new abstractions and things like that. And I know for both of you, that's kind of a topic or a hot topic, or just a topic that you think about a fair amount on how many layers of abstractions we're dealing with in the web, whether it be like ... well and that actually complicates things too because you mentioned you have some note and stuff, and then you've got also Native. And so you can't just copy and paste code from Stack Overflow and from one environment to another because we're dealing with all sorts of abstractions and things. Do you think that's a positive thing in the JavaScript ecosystem that it's just so broad and it solves so many things or are there some things to be concerned about with that?

Evan (06:02):
I think a job like listings that say JavaScript engineer should be more specific. Like a lot more specific. And as for Stack Overflow, I don't know. Maybe like-

Lydia (06:14):
Well, I think as something that we often notice is because yeah, whenever, sometimes he wants me to try out some expo related thing or like [inaudible 00:06:22] Native related thing. And I'm very used to I guess more like web technologies or back end technology. So then I kind of asked him, why doesn't it work this way or why doesn't it work that way? And then he gets more inspired to kind of I guess merge them together. So it becomes more one. So I guess eventually what we would want is that it's a lot more one-to-one all platforms.

Evan (06:46):
Like, yeah, web standards kind of come together, which you see this a lot too with Node, when Node releases new features like a work controller or is that right?

Lydia (06:56):
I don't know.

Evan (06:57):
Got to be from like, I think it was in the Browser and now it's in node. And then if you have other run times which use JavaScript, like taking inspiration and kind of just keeping it really collaborative, but at the same time helping everything grow and work better universally.

Lydia (07:12):
Yeah. I wish you could just learn something once and apply it to as many things as possible. that's the future.

Evan (07:19):
I think that's the dream of crypto type scriptors.

Lydia (07:21):
Yeah. Especially, yeah, just learn TypeScript and be able to apply it everywhere.

Evan (07:27):
Yeah. Well, yeah, we should specify whenever we say JavaScript, we actually always mean TypeScript.

Lydia (07:32):
Yeah.

Kent C. Dodds (07:35):
I'm on board with that as well. I'm definitely a TypeScript fan. It would sure be nice if I could just run my TypeScript file with Node. And so maybe that's where [Dino 00:07:45] comes in handy. But yeah, I'm definitely on board with the TypeScript train.

Evan (07:50):
Yeah. My favorite part of TypeScript is that when you write it, you don't need to write unit tests because it just exists. That was a special classic one just for you Kent.

Kent C. Dodds (07:59):
Yeah. Thank you. I hope your TypeScript types are really, really good so that you don't have to test any of the business logic your code is doing.

Evan (08:09):
I don't use any for objects.

Kent C. Dodds (08:13):
Yeah and you never have TypeScript errors either. That's great.

Evan (08:13):
Yeah it's really good.

Kent C. Dodds (08:17):
Yeah. Well, that's awesome. So because the JavaScript ecosystem is so broad, there's so many things that you can do. Let's say that I'm a developer who wants to be able to work effectively on one end of the spectrum all the way on the other and just transfer my skills really well. What are some tips and advice that you could give to somebody who wants to be able to do that? Where should they focus their time and energy in learning?

Evan (08:41):
Definitely just understanding the abstraction and the ... sorry, the layers of abstraction that are going on with JavaScript. So if you understand what parts of your app are the browser, like the navigator API, and then what things come from Node, assert or file system, then it's very easy to understand what part is actually JavaScript. And then you can pick that up and put it in whichever runtime and understand like, okay, I'm into this Native runtime, like where is the file system API? Or how do I assert an error? And I think that's just pretty powerful. Any additional thoughts to that?

Lydia (09:16):
Yeah, I agree. It's really just getting back to kind of the core, the fundamentals. As long as you understand that, I think slowly you can kind of build up, add more tools to that, but-

Evan (09:28):
Yeah. Which is kind of double-edged because we have tools like really great tools, like [Versel 00:09:34] and [XJS 00:09:35] which tried to abstract so much of everything away from even PHP. And those names where it's like, actually it's PHP. And it's like, they're really good and they help you move super fast, but it's also important to understand what's going on behind the scenes.

Lydia (09:55):
Exactly. Yeah, and I think people often see people trying to reinvent the wheel, it's like they come up with those new tools that are actually solving what's been solved long ago, but it's just abstracted away so much that you didn't see what they're doing. And this is also a problem that I've been seeing. For example, when you use [inaudible 00:10:13] a lot is they add so much Webpack config or so many optimizations that you don't even know are there or why they're necessary.

Evan (10:21):
And then you try to write your own Webpack content. You're like, how hard could it be?

Lydia (10:25):
Exactly. Yeah. Yeah, still, I mean, it's good. Like I'm glad that they make it possible for so many people to write really optimized web apps.

Evan (10:37):
Right. Like enjoy your favorite tools, but also figure out what they're doing.

Lydia (10:41):
Yeah. Just stay curious, you know? I don't know, just don't be too lazy about it.

Kent C. Dodds (10:47):
Yeah. Yeah. I think that's great. There's an interesting thing at play. I guess the thing, for lack of a better word where, or it's an interesting balance where sometimes you'll hear the gate keeping of, you're not a real developer if you don't know these fundamentals, like start with the fundamentals. But then there's the other end of the spectrum where what we're talking about, where you're just barely piecing things together. You're doing things in a suboptimal way because you don't understand those fundamentals. So for me, if I'm a new developer just getting started, where's the best place for me to start? Should I try to get those quick wins and get excited about coding because I can actually build something, or should I focus on okay, I'm going to build my own JavaScript compiler so I can understand the ASD? Like where where's the starting point there?

Evan (11:37):
Yeah. Definitely learn assembly first. Correction, if you use [inaudible 00:11:43] you're not even a real developer. Yeah, getting inspired by coding is definitely number one most important thing.

Lydia (11:51):
Definitely. And I feel like this is kind of hard to say because I often forget what I struggled with in the beginning, but I think what really got me super excited about coding was just making so many random things, even though I had no idea what I was doing, but you know, it worked, so it was fine. And probably when I look at it now, I'm just embarrassed of everything I've built. But then after you've built something, then you should kind of try to think like, okay, but what is it actually that I just did? Why did I have to initialize that? What does this [inaudible 00:12:22] actually do? Yeah. I don't know. Just ask the right questions after you've built something. But I don't think it's a good place to start, no. That would just get boring and overwhelming. That's not-

Evan (12:35):
Yeah. I think a good way to ask these questions is after you've built something is trying to figure out how to make it more performant or just optimized. And then usually in doing that, you inspire yourself to dig deeper, like how do I do bundle splitting or something? And when you actually have a goal in mind of why bundles putting is important to optimize your website and make it load faster on people's devices, then it's actually interesting. But if I just go up to someone and I'm like, hey, let me tell you about bundle splitting, you're going to be really bored very quickly. Like Evan, please leave me alone.

Lydia (13:10):
Yeah. I think something that I personally always did was I tried to recreate the libraries that I was using, which sometimes it worked. But it was really good because then I actually saw why it was necessary that I had to add it and what they did exactly that, I don't know. I kind of liked that because I could still use the tools that I'd already built.

Evan (13:10):
Yeah. That's good.

Lydia (13:30):
Yeah. And see if it actually worked.

Evan (13:32):
Yeah because often you can recreate a library. I'm doing quote fingers for anyone not with visuals, by just doing something very basic, like you don't actually have to make all the quality of life features involved in the library. And that you maybe just make the core, like a bundler for instance. You can gather up all the JavaScript, you might not have all the extra features, but you do understand critically what's going on.

Lydia (13:58):
Mm-hmm (affirmative). Yeah. And I often just read documentation or the source code. Like I often just read through the V8 source code, which might sound super boring, like-

Kent C. Dodds (14:08):
Here's a fun way to get you excited about coding.

Lydia (14:09):
It's real bad. But I mean, you learn so much from that. Or at least I do. I don't know. Maybe I'm just weird, but.

Evan (14:19):
Yeah. I think that's it.

Kent C. Dodds (14:20):
I've seen some V8 code myself and they commented, some code is not commented as well as others, but there are areas of the V8 code that are pretty well commented and it's more consumable for a regular JavaScript developer than we might think.

Lydia (14:35):
Yeah. No, I agree. Yeah.

Evan (14:37):
That's pretty good. Yeah.

Kent C. Dodds (14:40):
I think what I'm hearing is that you're best served by learning just one level down from the level of abstraction that you're using, right? So you understand how to connect the tools together, but then you also want to understand how those tools work and like why do you think it's important to understand how these tools work? Why can't I just take this Lego brick over here and stick it with this Lego brick over there? Like what's the benefit of actually understanding how they work?

Lydia (15:11):
I mean, I definitely think that you could, but often you run into certain errors or certain bugs that you see maybe pretty often and you don't really know what they mean. I mean, you probably know how to solve it, but you're just like, I don't know, at least this is what happened to me. It's like, I don't really know what's going on. I don't really know why this happened or this error happens. And the more you understand about how a certain tool is used and how it works internally, I feel like you write better code that way. You know how to optimize your own code in order for the tool to run more efficiently.

Evan (15:44):
Yeah. I definitely see this doing Open Source when people share error messages because for me, a lot of their messages will make sense to me because I understand the internals. But then to other people they might not understand. And a lot of the times it usually it's just like undefined, it's not a function. But sometimes it'll be like-

Kent C. Dodds (15:44):
It's not very helpful.

Evan (16:02):
Yeah, they'll be like why is this not work? But yeah, sometimes it points to something. And if you understand a lot of how things work, then you'll recognize and you can just debug things much faster. And-

Lydia (16:12):
And you'll see often, or sometimes, that tools are just using something that is so completely unnecessary. And it's like this tool is actually pretty broken.

Kent C. Dodds (16:26):
Yeah. Fair point. And then you can go fix it. Yeah, and it's just a lot easier to ... when you install an Open Source library, you now are a part owner in that library and it's success too, right? And so having an understanding of how it works will help you as a part owner of this library, right? To be able to contribute back. And yeah, and get yourself unstuck, like you said. So, yeah. I agree. I think that it's really critical to get a good understanding of how your abstractions work. One of the abstractions we use is JavaScript though, and that's, I mean, we talked about reading V8 source code, but there's got to be another way to get a good, foundational understanding of JavaScript. Do you have any tips on that?

Lydia (17:09):
Oh. It's really difficult. I mean, I think personally, I try to ... for example, generators and iterators, they are such a small thing of JavaScript that you probably ... not everyone uses them even. But reading the spec, which I think is on TC39? That helps me a lot with ... it's kind of the same, I guess, as reading the source code, but just reading the spec always helps me.

Evan (17:39):
Yeah. I find researching Babel, what little Babel plugins do is really helpful because you're like, oh, this basically works the same as this code and I understand how this code works, but not this other code. And so now you kind of have a better understanding of how stuff, and then you can also do it in little chunks just by language features.

Lydia (17:59):
I think a lot of it for me, it was really just trying it out. You know, it's also just years of coding that you eventually kind of know how things fit together, but it might not always make sense if you just get started. That's for me the hardest part, kind of like emphasizing with people that are now getting into the React community because when I started, we didn't have hooks, we didn't have all that. So how does it feel for them to start with React using hooks? That must be pretty confusing. I mean, I would be super confused, but.

Evan (18:35):
I'm just, yeah always confused.

Lydia (18:36):
Yeah, I'm still confused. Yeah.

Evan (18:39):
it's better now there's not much Redux being used everywhere.

Lydia (18:43):
Yeah. That was the confusing part when I started Redux. But, okay that kind of didn't answer the question at all.

Evan (18:52):
If you let us talk long enough, we'll go onto a tangent.

Kent C. Dodds (18:54):
You know, it's interesting. And I actually think that for folks getting into React now, they don't have to unlearn classes and life cycles to learn hooks. So in my experience, it's lucky for them that they don't have to unlearn their classes and stuff because I think hooks are more confusing until you separate, okay classes and hooks are very different things conceptually, mental models. But as we're getting into this, one thing that I've noticed, especially when I'm teaching React is often the struggle that people have isn't necessarily with React, but it's actually with JavaScript. And so finding a way to draw a line around the here's the React part of this, but everything else you're doing is just JavaScript and getting a firm understanding of JavaScript helps a lot in that.

Lydia (19:48):
Yeah. I completely agree.

Evan (19:49):
Yeah. I find it's actually a little bit easier now with when I do hooks because before, my first experience with JavaScript was using React because I came from like a Native background. And I thought that all classes had that weird thing where functions weren't bound by default. And I was like, why is JavaScript like this? And then React was like that.

Lydia (20:11):
Yeah. Yeah. No, it's definitely hard to kind of understand in the beginning what part is React and what part is JavaScript, even though that sounds weird because React is JavaScript. But yeah like where certain errors come from, who to blame?

Evan (20:28):
It's who to blame, it's who-

Lydia (20:28):
On the wrong [inaudible 00:20:30].

Kent C. Dodds (20:32):
Exactly. Yeah. And what to Google for, how do I add numbers together in jQuery? It's like the meme of stack overflow. It's like, yeah well clearly you don't understand the difference between jQuery and JavaScript and then maybe it's not your fault. Maybe it's us as the educators that need to do a better job of drawing these lines around these different abstractions. It's actually why in epic React, my first lesson about React is we don't even bring in React, we just build Dom nodes with JavaScript manually and then we bring in React later just because I think that learning these things in isolation is the best way to be able to ... I say this a lot, but draw lines around abstractions, understand where one abstraction stops and the other starts and then how they interplay with each other.

Lydia (21:20):
Yeah. I think also understanding what problem is React trying to solve. At least that always really works for me. It's like, why? Why am I doing this? Why does this tool exist? Why is hooks a thing? What problem did they solve?

Evan (21:36):
Yeah. That's a really nice way of teaching by the way, the Dom nodes thing because whenever anyone asks me how to get into web development, I want to say React, but I also know that if they don't know HTML, it's going to be a problem. But I don't want to say HTML because it's like they might fall down that rabbit hole of like-

Lydia (21:57):
I think just generally like knowing Dom [API 00:21:57].

Evan (21:57):
Yeah. Yeah. That's pretty interesting.

Kent C. Dodds (22:01):
Yeah. It's kind of tricky especially for brand new people, you have to walk that balance like we were talking about earlier of using abstraction so you can build something exciting and keep yourself motivated, but also not missing out on really important fundamentals. And so what I often will tell people is I'll say start with abstractions that can help you build something fast. Just ship something interesting to get you excited, and then when you're ready to level up, then you dive deep on the abstractions that you're using. And so that's when you get into the monotony, I guess you could call it of like understanding the low-level Dom APIs and stuff like that.

Lydia (22:42):
Mm-hmm (affirmative).

Evan (22:43):
Yeah. Smart.

Lydia (22:45):
Yeah. I like that.

Kent C. Dodds (22:46):
So we're reaching toward the end of our time here. And so I just want to ask you, is there anything else that you wanted to talk about or any other ideas around understanding how things work under the hood that we didn't get to touch on already?

Lydia (22:59):
Oh, the-

Evan (22:59):
Is that for me? I thought that was a question for you.

Lydia (23:02):
Yeah, well maybe some Native thing.

Evan (23:04):
Oh yeah. So I don't know, React Native is pretty interesting way to kind of expand your way of thinking about JavaScript because you have the browser environment and the node environment, but I find with React, you don't often switch between running your react code in a node environment in a browser environment. But with React Native you often like, or I like to call it just Native React, but you often switch between an iOS run time and an Android run time and a web run time. And so you definitely see if you do something that seems kind of simple, like navigator dot, and then you get the location, you'll find that that's not available on iOS, but it is available on web. And then you kind of see like, oh, this is because this is a feature, a Native feature exposed through the browser to JavaScript. And so you need to find the iOS equivalent to that, or the Android equivalent to that. So I find that that's a pretty nice way to expand your way of thinking about the different layers that make up a React app or a universal React app.

Lydia (24:04):
Yeah. And I think that also kind of shows what's part of React Dom versus React Native. You kind of understand what part is kind of core JavaScript, or core React.

Evan (24:14):
Because yeah I mean, I always like, even though I know that when you do div in a React component that it's not HTML, I don't really fully grasp what it means for it to actually just be a React component until you start working in a universal way and you're like, okay, this view is on iOS, Android, web, it's the same. And it's like, this div is actually a component wrapped around a Native element. I forget what they actually call them, properly host components I believe. It's not like an actual host component. So I definitely think React is super nice for its ability to just pick you up and drop you in a different run time. And if you want to try that, you can do it with the Expo.

Kent C. Dodds (24:57):
Cool.

Evan (24:57):
If I was going to throw out a recommendation, you can try Expo with it.

Kent C. Dodds (25:01):
Yeah. Well, I actually Expo is the only time I've ever used React native is a little hello world thing. And it blew my mind how easy it was to get going. So I mean, relative to what I was expecting I guess.

Evan (25:13):
Yeah, yeah, yeah. It's kind of, it gets easier every few months. React Native is still really pumping out new features and getting better all the time. It's very reminiscent of React maybe a couple of years ago where you were like, wow, every time there was a new React release, you were just kind of changing the way you were thinking about it. And it was like Christmas every time a new release. That's kind of how being in the React Native community is right now, the Native React community.

Kent C. Dodds (25:44):
Yeah. I think that if somebody wanted to level up their game on React, a good, or just JavaScript, it's just like think about all of the different environments in which these can run and pick out their differences. And if you want to make people really happy, find a way to write an abstraction that allows you to run the same code on any of those given environments. And then you can have just adapters for each of those [inaudible 00:26:15]. You find stuff like this all the time. I mean, like you said, React Native is basically an adapter, a reconciler for React in the native environment. And then we have React On, we have React VR. There's a bunch of these.

Evan (26:28):
Yeah. It basically just takes the JavaScript engine on your device and enables you to take JavaScript and sends it to that and then surface it to React. So it's, a reconciler is not special across, or it is, it's very special, but across different platforms it is the same concept. So if you do know how React On works, you can understand React Native fairly easily.

Lydia (26:49):
Yeah. And I think this way you also learn more about your JavaScript engine, what it's actually responsible for as well as the browser system, like the pixel pipeline, how it actually works on the web versus natively. Yeah. That, for me, that's very helpful to know, what part's controlled where? Who's in control, who builds those tools?

Kent C. Dodds (27:11):
Yeah. And I think that there's a big difference between JavaScript syntax and the Dom API. And understanding that difference will allow you to understand that when you're looking at some code and it's using Dom APIs, you know that this isn't going to run on the server, like you just know that's not going to happen. And I mean, unless you're using JS Dom, but that's a real server.

Evan (27:34):
That's great for production.

Kent C. Dodds (27:37):
Yeah. Yeah. But yeah. So having an understanding of, okay, so here are the Dom APIs, here are the Node APIs, and then here's the core JavaScript syntax that ... and I guess the spec can kind of help you identify what features, generators are part of the JavaScript API, but Fetch is actually not, it's a separate thing altogether. And maybe it uses promises under the hood, but promises are part of the speck, Fetch is not. Or document is not. So yeah. Drawing lines around these different abstractions can help you use all of them more effectively.

Evan (28:13):
Yeah. Yeah. I think if you know these things as a JavaScript developer, you're going to be pretty unstoppable. Like if someone brings you a new platform or tool as a new project, something you want to work on, there's already so many great tools out there and knowing this will just help you step into it very easily.

Lydia (28:31):
Yeah.

Kent C. Dodds (28:32):
That's the thing I love about JavaScript is just like so many things that you can do with it. So always been on JavaScript.

Lydia (28:39):
Definitely.

Kent C. Dodds (28:40):
Cool. Well with the-

Evan (28:43):
You mean TypeScript.

Lydia (28:43):
Yes. TypeScript.

Kent C. Dodds (28:44):
Yeah, TypeScript. Yes of course. Very good. Cool. So this has been a great time chatting with you. Our homework for everybody is to take 30 minutes to dive deeper, to understand how a tool you use works under the hood. So that could be like JavaScript or it could be, it could even be like HTML or CSS. We didn't really talk about those too much. But those work under the hood as well. So, or React or whatever, even a library for React, like React Router or something like that. You'll understand it better. Anything to add to that?

Evan (29:20):
Yeah, like also just using, I think, other run times. A great one that I just thought of was like, I think, it always slips my mind because Versel is so good at hiding it. But with an XJS, that code does run in a node environment at some point, and then in the browser. So that actually shows a lot of similarities with what I was saying about React Native. So if you're familiar with an XJS, kind of see where things work in a node environment versus when they work in the browser.

Kent C. Dodds (29:50):
Yeah. Actually it comes to mind that a first good step for that is just like understanding what part of your code runs in which environment. And so you put console logs everywhere and look at the [crosstalk 00:30:02] and look at the client and see, okay, this ran on both, this ran on one, this ran on the other.

Lydia (30:10):
Yeah. And understand why. Why did they do it that way?

Kent C. Dodds (30:15):
Yeah. Exactly. Cool. Well, it's been such a pleasure to chat with you. I'm going to put your links in the show notes, but do you want to share your Twitter handles or what's ... I guess, let me rephrase that. What's the best way for people to keep up with each of you and what you're doing?

Evan (30:30):
What are the kids doing these days?

Lydia (30:35):
My Twitter handle is just [buddyhalle 00:30:36]. I think that's my main.

Evan (30:39):
Yeah, I'm [baconbrix 00:30:40] with an X because I was a teenager when I made it.

Lydia (30:45):
No excuse.

Kent C. Dodds (30:47):
That's excellent. I love it. All right. Awesome. Thank you so much. And yeah, we'll see everybody in the future. Bye.

Evan (30:54):
Sweet.

Lydia (30:54):
Bye bye.