Podcasts about react training

On this Screaming in the Cloud replay, we're looking back to our conversation with Cassidy Williams, a Senior Director of Developer Advocacy at GitHub and the co-founder and chief product officer of Cosynd, Inc. Prior to these positions, she worked as the principal developer experience engineer at Netlify, an instructor and senior engineer at React Training, director of outreach at cKeys, a senior software engineer at CodePen, head of developer voice programs at Amazon, and a software engineer at Venmo, among other positions. Join Corey and Cassidy as they reflect on what Netlify is and what a developer experience engineer does, how JavaScript started off as a toy language and why everything that can be built with JavaScript will be moving forward, the benefits of using low-code development tools, how discovering TikTok helped Cassidy drum up a major following on social media, how Cassidy's humor is never directed at people or organizations and why that's the case, the differences between recording a podcast and live streaming on Twitch from the speaker's point of view, and more.Show Highlights(0:00) Intro(0:22) Backblaze sponsor read(0:49) What is Netlify and its role of a principal developer experience engineer(2:50) Is JavaScript the future?(7:46) Using low-code tools for web development(12:12) Having a goofy internet presence in a serious field(17:23) Social platforms as a means to teach(24:50) Twitch streaming and its inherent challenges(28:16) Cassidy's online coursework and how she answers, “So, what do you do?”(32:12) Unique ways of tracking Twitter followers(37:15) Where you can find more from CassidyAbout Cassidy WilliamsCassidy is a Senior Director of Developer Advocacy at GitHub. She's worked for several other places, including Netlify, CodePen, Amazon, and Venmo, and she's had the honor of working with various non-profits, including cKeys and Hacker Fund as their Director of Outreach. She's active in the developer community, and was one of Glamour Magazine's 35 Women Under 35 Changing the Tech Industry and LinkedIn's Top Professionals 35 & Under. As an avid speaker, Cassidy has participated in several events including the Grace Hopper Celebration for Women in Computing, TEDx, the United Nations, and dozens of other technical events. She wants to inspire generations of STEM students to be the best they can be, and her favorite quote is from Helen Keller: "One can never consent to creep when one feels an impulse to soar." She loves mechanical keyboards and karaoke.LinksTikTok: https://www.tiktok.com/@cassidooNewsletter: https://cassidoo.co/newsletter/Scrimba: https://scrimba.com/teachers/cassidooUdemy: https://www.udemy.com/user/cassidywilliams/Skillshare: https://www.skillshare.com/user/cassidooO'Reilly: https://www.oreilly.com/pub/au/6339Personal website: https://cassidoo.coTwitter: https://twitter.com/cassidooGitHub: https://github.com/cassidooCodePen: https://codepen.io/cassidoo/LinkedIn: https://www.linkedin.com/in/cassidooOriginal Episodehttps://www.lastweekinaws.com/podcast/screaming-in-the-cloud/memes-streams-software-with-cassidy-williams/SponsorBackblaze: https://www.backblaze.com/ 

Kent C. Dodds, a JavaScript engineer and teacher known for Epic Web Dev and the Remix web framework, reflects on his journey in tech, including his tenure at PayPal and his transition to full-time teaching. Kent's passion for teaching is a constant theme throughout. He transitioned from corporate roles to full-time education, capitalizing on his ability to explain complex concepts in an accessible manner. This transition was marked by the creation of successful online courses like "Testing JavaScript and Epic React," which have significantly influenced the web development community. An interesting aspect of Kent's career is his involvement with Remix, including his decision to leave Shopify (which acquired Remix) to return to teaching, which led to the development of his latest project, Epic Web Dev, an extensive and innovative web development course. This interview provides a comprehensive view of Kent C. Dodds's life and career, showcasing his professional achievements in web development and teaching, his personal life as a family man, and his unique upbringing in a large family. Epic Web (https://www.epicweb.dev/) Remix (https://remix.run/) Follow Kent C. Dodds on LinkedIn (https://www.linkedin.com/in/kentcdodds/) or X (https://twitter.com/kentcdodds). Visit his website at kentcdodds.com (https://kentcdodds.com/). Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Transcript: WILL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with me today is Kent C. Dodds. Kent is a JavaScript engineer and teacher. He has recently released a massive workshop called epicweb.dev. And he is the father of four kids. Kent, thank you for joining me. KENT: Thank you so much for having me. It's an honor to be here. WILL: Yeah. And it's an honor for me to have you. I am a huge fan. I think you're the one that taught me how to write tests and the importance of it. So, I'm excited to talk to you and just pick your brain and learn more about you. KENT: Oh, thank you. WILL: Yeah. So, I just want to start off just: who is Kent? What do you like to do? Tell us about your family, your hobbies, and things like that. KENT: Yeah, sure. So, you mentioned I'm the father of four kids. That is true. We are actually expecting our fifth child any day now. So, we are really excited to have our growing family. And when I'm not developing software or material for people to learn how to develop software, I'm spending time with my family. I do have some other hobbies and things, but I try to share those with my family as much as I can. So, it's starting to snow around here in Utah. And so, the mountains are starting to get white, and I look forward to going up there with my family to go skiing and snowboarding this season. During the summertime, I spend a lot of time on my one-wheel just riding around town and bring my kids with me when I can to ride bikes and stuff, too. So, that's sort of the personal side of my life. And then, professionally, I have been in this industry developing for the web professionally for over a decade. Yeah, web development has just worked out super well for me. I kind of focused in on JavaScript primarily. And when I graduated with a master's degree in Information Systems at Brigham Young University, I started working in the industry. I bounced around to a couple of different companies, most of them you don't know, but you'd probably be familiar with PayPal. I was there for a couple of years and then decided to go full-time on teaching, which I had been doing as, like, a part-time thing, or, like, on the side all those years. And yeah, when teaching was able to sustain my family's needs, then I just switched full-time. So, that was a couple of years ago that I did that. I think like, 2018 is when I did that. I took a 10-month break to help Remix get off the ground, the Remix web framework. They got acquired by Shopify. And so, I went back to full-time teaching, not that I don't like Shopify, but I felt like my work was done, and I could go back to teaching. So, that's what I'm doing now, full-time teacher. WILL: Wow. Yes, I definitely have questions around that. KENT: [laughs] Okay. WILL: So many. But I want to start back...you were saying you have four kids. What are their ages? KENT: Yeah, my oldest is 11, youngest right now is 6, and then we'll have our fifth one. So, all four of the kids are pretty close in age. And then my wife and I thought we were done. And then last December, we kind of decided, you know what? I don't think we're done. I kind of think we want to do another. So, here we go. We've got a larger gap between my youngest and the next child than we have between my oldest and the youngest child. WILL: [chuckles] KENT: So, we're, like, starting a new family, or [laughs] something. WILL: Yeah [laughs]. I just want to congratulate you on your fifth child. That's amazing. KENT: Thank you. WILL: Yeah. How are you feeling about that gap? KENT: Yeah, we were pretty intentional about having our kids close together because when you do that, they have built-in friends that are always around. And as they grow older, you can do the same sorts of things with them. So, like, earlier this year, we went to Disneyland, and they all had a great time. They're all at the good age for that. And so, they actually will remember things and everything. Yeah, we were pretty certain that four is a good number for us and everything. But yeah, we just started getting this nagging feeling we wanted another one. So, like, the fact that there's a big gap was definitely not in the plan. But I know a lot of people have big gaps in their families, and it's just fine. So, we're going to be okay; just it's going to change the dynamic and change some plans for us. But we're just super excited to have this next one. WILL: I totally understand what you mean by having them close together. So, I have three little ones, and my oldest and my youngest share the same exact birthday, so they're exactly three years apart. KENT: Oh, wow. Yeah, that's actually...that's fun. My current youngest and his next oldest brother are exactly two years apart. They share the same birthday, too [laughs]. WILL: Wow. You're the first one I've heard that their kids share a birthday. KENT: Yeah, I've got a sister who shares a birthday with her son. And I think we've got a couple of birthdays that are shared, but I also have 11 brothers and sisters [laughs]. And so, I have got a big family, lots of opportunity for shared birthdays in my family. WILL: Yeah, I was actually going to ask you about that. How was it? I think you're the 11th. So, you're the youngest of 11? KENT: I'm the second youngest. So, there are 12 of us total. I'm number 11. WILL: Okay, how was that growing up with that many siblings? KENT: I loved it. Being one of the youngest I didn't really...my experience was very different from my older siblings. Where my older siblings probably ended up doing a fair bit of babysitting and helping around the house in that way, I was the one being babysat. And so, like, by the time I got to be, like, a preteen, or whatever, lots of my siblings had already moved out. I was already an uncle by the time I was six. I vaguely remember all 12 of us being together, but most of my growing up was just every other year; I'd have another sibling move out of the house, which was kind of sad. But they'd always come back and visit. And now I just have an awesome relationship with every one of my family members. And I have something, like, 55 nieces and nephews or more. Yeah, getting all of us together every couple of years for reunions is really a special experience. It's a lot of fun. WILL: Yeah. My mom, she had 12 brothers and sisters. KENT: Whoa. WILL: And I honestly miss it because we used to get together all the time. I used to live a lot closer. Most of them are in Louisiana or around that area, and now I'm in South Florida, so I don't get to see them as often. But yeah, I used to love getting together. I had so many cousins, and we got in so much trouble...and it was -- KENT: [laughs] WILL: We loved it [laughs]. KENT: Yeah, that's wonderful. I love that. WILL: Yeah. Well, I want to start here, like, how did you get your start? Because I know...I was doing some research, and I saw that, at one point, you were an AV tech. You were a computer technician. You even did maintenance. Like, what was the early start of your career like, and how did you get into web dev? KENT: I've always been very interested in computers, my interest was largely video games. So, when I was younger, I had a friend who was a computer programmer or, like, would program stuff. We had visions of...I don't know if you're familiar with RuneScape, but it's this game that he used to play, and I would play a little bit. It was just a massive online multiplayer game. And so, we had visions of building one of those and having it just running in the background, making us money, as if that's how that works [laughter]. But he tried to teach me programming, and I just could not get it at all. And so I realized at some point that playing video games all the time wasn't the most productive use of my time on computers, and if I wanted my parents to allow me to be on computers, I needed to demonstrate that I could be productive in learning, and making things, and stuff. So, I started blogging and making videos and just, like, music videos. My friend, who was the programmer, he was into anime, or anime, as people incorrectly pronounce it. And [laughs] there was this website called amv.com or .org or something. It's Anime Music Videos. And so, we would watch these music videos. And I'd say, "I want to make a music video with Naruto." And so, I would make a bunch of music videos from the Naruto videos I downloaded, and that was a lot of fun. I also ran around with a camera to do that. And then, with the blog, I wrote a blog about Google and the stuff that Google was, like, doing because I just thought it was a fascinating company. I always wanted to work at Google. In the process of, like, writing the blog, I got exposed to CSS and HTML, but I really didn't do a whole lot of programming. I also did a little bit of Google Docs. Spreadsheets had some JavaScript macros-type things that you could do. So, I did a little bit of that, but I never really got too far into programming. Then I go to college, I'm thinking, you know what? I think I want to be a video editor. I really enjoy that. And so, my brother, who at the time was working at Micron, he did quality assurance on the memory they were making. So, he would build test automation, software and hardware for testing the memory they build. And so, he recommended that I go into electrical engineering. Because what he would say is, "If you understand computers at that foundational level, you can do anything with computers." And I'd say, "Well, I like computers. And if I go into video editing, I'm going to need to understand computers, too. So yeah, sure, let's let's do that." I was also kind of interested in 3D animation and stuff like that, too. Like, I wasn't very good at it, but I was kind of interested in that, too. So, I thought, like, having a really good foundation on computers would be a good thing for me. Well, I was only at school for a semester when I took a break to go on a mission for my church [inaudible 09:42] mission. And when I got back and started getting back into things, I took a math refresher course. That was, like, a half a credit. It wasn't really a big thing, but I did terrible in it. I did so bad. And it was about that time that I realized, you know what? I've been thinking my whole life that I'm good at math. And just thinking back, I have no idea why or any justification for why I thought I was good at math because in high school, I always struggled with it. I spent so much time with it. And in fact, my senior year, I somehow ended up with a free period of nothing else to do. I don't know how this happened. But, I used that free period to go to an extra edition of my calculus class. So, I was going to twice as much calculus working, like, crazy hard and thinking that I was good at this, and I superduper was not [laughter]. And so, after getting back from my mission and taking that refresher course, I was like, you know what? Math is a really important part of engineering, and I'm not good at it at all, obviously. And so, I've got to pivot to something else. Well, before my mission, as part of the engineering major, you needed to take some programming classes. So, there was a Java programming class that I took and a computer systems class that included a lot of programming. The computer systems was very low level, so we were doing zeros and ones. And I wrote a program in zeros and ones. All that it did was it would take input from the keyboard, and then spit that back out to you as output. That was what it did. But still, you know, many lines of zeros and ones and just, like, still, I can't believe I did that [laughter]. And then we upgraded from that to Assembly, and what a godsend that was [laughs], how wonderful Assembly was after working in machine code. But then we upgraded from that to C, and that's as far as that class went. And then, yeah, my Java class, we did a bunch of stuff. And I just remember thinking or really struggling to find any practicality to what we were doing. Like, in the Java class, we were implementing the link to list data structure. And I was like, I do not care about this. This does not make any sense. Why should I care? We were doing these transistor diagrams in the computer systems class. And why do I care about that? I do not care about this at all. Like, this is not an interesting thing for me. So, I was convinced computer programming was definitely not what I wanted to do. So, when I'm switching from electrical engineering, I'm thinking, well, what do I do? And my dad convinced me to try accounting. That was his profession. He was a certified public accountant. And so, I said, "Okay, I'll try that." I liked the first class, and so I switched my major to go into the business school for accounting. I needed to take the next accounting class, and I hated that so much. It was just dull and boring. And I'm so glad that I got out of that because [laughs] I can't imagine doing anything like that. WILL: [laughs] KENT: But as part of switching over to business school, I discovered information systems. What's really cool about that is that we were doing Excel spreadsheets and building web pages. But it was all, like, with a practical application of business and, like, solving business problems. And then, I was like, oh, okay, so I can do stuff with computers in a practical setting, and that's what got me really interested. So, I switched, finally, to information systems–made it into that program. And I was still not convinced I wanted to do programming. I just wanted to work with computers. What ended up happening is the same time I got into the information systems program, I got married to my wife, and then I got this part-time job at a company called the More Good Foundation. It's a non-profit organization. And one of my jobs was to rip DVDs and upload those videos to YouTube, and then also download videos from one site and upload those to YouTube as well. And so, I was doing a lot of stuff with YouTube and video stuff. And as part of my information systems class, I was taking another Java class. At that same time, I was like, you know, what I'm doing at work is super boring. Like, can you imagine your job is to put in a [inaudible 13:45] and then click a couple of buttons? And, like, it was so boring and error-prone, too. Like, okay, now I've got to type this out and, you know, I got to make sure it's the same, try and copy-paste as much as I can. And it was not fun. And so, I thought, well, I'm pretty sure there are pieces of this that I could automate. And so, with the knowledge that I was getting in my information systems programming class, that was another Java class, I decided to write a program that automated a bunch of my stuff. And so, I asked my boss, like, "Can I automate this with writing software?" And I'm so glad that they said I could. WILL: [laughs] KENT: Because by the end of it, I had built software that allowed me to do way more than I ever could have before. I ended up uploading thousands of videos to their YouTube channels, which would have taken years to do. And they ended up actually being so happy with me. They had me present to the board of directors when they were asking for more money [laughs] and stuff. And it was really awesome. But still, I was not interested in being a programmer. Programming, to me, was just a means to an end. WILL: Oh, wow. KENT: Yeah, I guess there was just something in me that was like, I am not a programmer. So, anyway, further into the program of information systems, I interned as a business intelligence engineer over that next summer, and I ended up staying on there. And while I was supposed to be a business intelligence engineer, I did learn a lot about SQL, and star schema, and denormalized databases to optimize for read speed and everything. I learned a lot about that. But I just kept finding myself in positions where I would use my programming experience to automate things that were problematic for us in the business realm. And this was all still Java. It was there that I finally realized, you know what? I think I actually do want to be a programmer. I actually really do enjoy this. And I like that it's practical, and it makes sense for me, so… WILL: What year was that? KENT: That would have been 2012. Then I got a new job where my job was actually to be a programmer at a company called Domo, where they do business intelligence, actually. So, it got my foot in the door a little bit since I was a business intelligence engineer already. I got hired on, actually, as a QA engineer doing automated testing, but I never really got into that. And they shifted me over pretty quick into helping with the web app. And that is when I discovered JavaScript, and the whole, like, everything flooded out from there. I was like, wow, I thought I liked programming, but I had no idea how fun it could be. Because I felt like the chains had been broken. I no longer have to write Java. I can write JavaScript, and this was just so much better. WILL: [laughs] KENT: And so, yeah, I was there for a year and a half before I finally graduated. And I took a little break to work at USAA for a summer internship. And when I came back, I had another year and then converted to full-time. And so, yeah, there's my more detail than you were probably looking for, story of how I got into programming [laughs]. WILL: No, I actually love it because like I said, I've used your software, your teachings, all that. And it's amazing to hear the story of how you got there. Because I feel like a lot of times, we just see the end result, but we don't know the struggle that you went through of even trying to find your way through what your purpose was, what you're trying to do. Because, at one point, you said you were trying to do accounting, then you were trying to do something else. So, it's amazing to see, like, when it clicked for you when you got into JavaScript, so that's amazing. KENT: Yeah, it is kind of funny to think, like, some people have the story of, like, I knew I wanted to be a programmer from the very beginning, and it's just kind of funny for me to think back and, like, I was pretty certain I didn't want to be a programmer. WILL: [laughs] KENT: Like, not only did I, like, lots of people will say, "I never really thought about it, and then I saw it, and it was great." But I had thought about it. And I saw it, and I thought it was awful [laughter]. And so, yeah, I'm really glad that it worked out the way it did, though, because programming has just been a really fun thing. Like, I feel so blessed to be doing something that I actually enjoy doing. Like so many of our ancestors, they would go to work because they cared about their family and they just wanted to feed their family. I'm so grateful to them for doing that. I am so lucky that I get to go to work to take care of my family, but also, I just love doing it. WILL: Yeah, I feel the same way, so yeah, totally agree. After you found out about JavaScript, when did you figure out that you want to teach JavaScript? What was that transition like? KENT: I've been teaching for my whole life. It's ingrained in my religion. Even as a kid, you know, I'd prepare a talk, a five-minute talk, and stand up in front of 30 of my peers. And even when you're an early teenager, you get into speaking in front of the entire congregation. It took a while before I got good enough at something, enough hubris to think that people would care about what I have to say -- WILL: [laughs] KENT: Outside of my religion where, like, they're sitting there, and I've been asked to speak, and so they're going to listen to me. And so, when I started getting pretty good at programming, I decided, hey, I want to teach this stuff that I'm learning. And so, when I was still at school and working at Domo, the business intelligence company, one of our co-workers, Dave Geddes, he put together a workshop to teach AngularJS because we were migrating from Backbone to Angular. And I asked him if I could use his workshop material to teach my classmates. This was, like, soon after ng-conf, the first ng-conf, which my co-workers at Domo actually put on. So, I wasn't involved in the organization, but I was very much present when it was being organized. I attended there and developed a relationship with Firebase with the people there. I was actually...they had a developer evangelist program, which they called Torchbearers or something. And actually, that was my idea to call them Torchbearers. I think they wanted to call us torches, and I'm like, that just doesn't make sense. WILL: [laughs] KENT: I developed a relationship with them. And I asked them, "Hey, I want to teach my classmates AngularJS. Would you be interested in sponsoring some pizza and stuff?" And they said, "Yeah, we'll send you stickers, and hot sauce, and [laughs] a bunch of..." Like, they sent us, like, headphones [laughs] and stuff. So, I was like, sweet. I taught my classmates AngularJS in a workshop, brought a bunch of pizza, and it was, you know, just an extracurricular thing. And actually, the recording is still on my YouTube channel, so if you want to go look at one of my early YouTube videos. I was very into publishing video online. So, if you are diligent, you'll be able to find some of my very early [laughter] videos from my teenage years. But anyway, so, yes, I've been teaching since the very beginning. As soon as I graduated from college, I started speaking at meetups. I'd never been to a meetup before, and I just saw, oh, they want a speaker. I can talk about something. WILL: Wow. KENT: And not realizing that, like, meetups are literally always looking for speakers. This wasn't some special occasion. WILL: [laughs] KENT: And one of the meetups I spoke at was recorded and put on YouTube. And the guy who started Egghead io, John Lindquist, he is local here in Utah. And he saw that I spoke at that meetup, but he wasn't able to attend. So, he watched the recording, and he thought it was pretty good. He thought I would do a good job turning that into a video course. And that first video course paid my mortgage. WILL: Wow. KENT: And I was blown away. This thing that I had been doing just kind of for fun speaking at meetups, and I realized, oh, I can actually, like, make some legit good money out of this. From there, I just started making more courses on the side after I put the kids to bed. My wife is like, "Hey, I love you, but I want you to stay away for now because I've just been with these tiny babies all day. WILL: [laughs] KENT: And I just need some alone time." WILL: Yes. KENT: And so, I was like, okay. WILL: [laughs] KENT: I'll just go and work on some courses. And so, I spent a lot of time for the next couple of years doing course material on the side. I reached out to Frontend Masters and just told them, "Hey, I've been doing courses for Egghead." I actually met Marc Grabanski at a conference a couple of years before. And so, we established a little bit of relationship. And I just said, "Hey, I want to come and teach there." So, I taught at Frontend Masters. I started putting on my own workshops at conferences. In fact, just a few months after graduating, I got accepted to speak at a conference. And only after I was accepted did I realize it was in Sweden [laughter]. I didn't think to look where in the world this conference was. So, that was my first international trip, actually, and I ended up speaking there. I gave, actually, two talks. One of them was a three-hour talk. WILL: Whoa. KENT: Which was, yeah, that was wild. WILL: [laughs] KENT: And then, yeah, I gave a two-day workshop for them. And then, I flew straight from there to Amsterdam to give another talk and also do a live in-person podcast, which I'd been running called ngAir, an Angular podcast. It just kept on building from there until finally, I created testingjavascript.com. And that was when I realized, oh, okay, so this isn't just a thing I can use to pay my mortgage, and that's nice. This is, like, a thing I can do full-time. Because I made more with Testing JavaScript than I made from my PayPal salary. WILL: Oh wow. KENT: I was like, oh, I don't need both of these things. I would rather work half as much one full-time job; that's what I want, one full-time job and make enough to take care of my family. And I prefer teaching. So, that's when I left PayPal was when I released Testing JavaScript. WILL: Wow. So, for me, I think so many times the imposter syndrome comes up whenever I want to teach or do things at the level you're saying you're doing. Because I love teaching. I love mentoring. I remember when I came into development, it was hard. I had to find the right person to help me mentor. So now, I almost made a vow to myself that if someone wants to learn and they're willing to put in the energy, I'm going to sit down however long it takes to help them because I remember how hard it was for me whenever I was doing it. So, you said in 2014, you were only a couple years doing development. How did you overcome impostor syndrome to stand in front of people, teach, go around the world, and give talks and podcasts? Like, how did you do that portion? KENT: Part of it is a certain level of hubris like I said. Like, you just have to be willing to believe that somebody's going to care. You know, the other part of it is, it's a secret to getting really, really good at something. They sometimes will say, like, those who can't do teach. That's total baloney because it requires a lot of being able to do to get you in a position where you can teach effectively. But the process of teaching makes you better at the process of doing as well. It's how you solidify your experience as a whatever. So, if you're a cook, you're really good at that; you will get better by teaching other people how to cook. There's an element of selfishness in what I do. I just want to get really, really good at this, and so I'm going to teach people so that I can. So yeah, I think there's got to be also, like, a little bit of thick skin, too, because people are going to maybe not like what you have to share or think that you're posing or whatever. Learn how to let that slide off you a little bit. But another thing is, like, as far as that's concerned, just being really honest about what your skill set is. So, if somebody asks me a question about GraphQL, I'm going to tell them, "Well, I did use GraphQL at PayPal, but I was pretty limited. And so, I don't have a lot of experience with that," and then I'll answer their question. And so, like, communicating your limitations of knowledge effectively and being okay being judged by people because they're going to judge you. It just is the way it is. So, you just have to learn how to cope well with that. There are definitely some times where I felt like I was in over my head on some subjects or I was involved in a conversation I had no business being there. I actually felt that a lot when I was sent as PayPal's delegate to the TC39 meetings. Wow, what am I doing here? I've only been in the industry for, like, two or three years at [laughter] that point. It takes a certain level of confidence in your own abilities. But also, like, being realistic about your inexperience as well, I think, is important too. WILL: Yeah, I know that you had a lot of success, and I want to cover that next. But were there any failures when you were doing those teaching moments? KENT: Years ago, Babel was still a new thing that everybody was using to compile their JavaScript with new syntax features down to JavaScript that the browser could run. There was ES Modules that was introduced, and lots of us were doing global window object stuff. And then we moved to, like, defining your dependencies with r.js or RequireJS. And then, there was CommonJS, and Universal Module Definition, and that sort of thing. So, ECMAScript modules were very exciting. Like, people were really interested in that. And so, Babel added support to it. It would compile from the module syntax down to whatever you wanted: CommonJS or...well, I'm pretty sure it could compile to RequireJS, but I compiled it to CommonJS. And so, there was a...yeah, I would say it's a bug in Babel at that time, where it would allow you to write your ES modules in a way that was not actually spec-compliant. It was incorrect. So, I would say export default some object, and then in another module, I would say import. And then, I'd select properties off of the object that I exported, that default I exported. That was allowed by Babel, but it is superduper, not how ECMAScript modules work. Well, the problem is that I taught, like, a ton of people how to use ECMAScript modules this way. And when I realized that I was mistaken, it was just, like, a knife to the heart because I was, like, I taught so many people this wrong thing. And so, I wrote a blog post about it. I gave a big, long talk titled “More Than You Want to Know About ECMAScript Modules,” where I talk about that with many other things as well. And so, yeah, just trying to do my part to make up for the mistake that I made. So yes, I definitely have had mistakes like that. There's also, like, the aspect that technology moves at a rapid pace. And so, I have old things that I would show people how to do, which they still work just as well as they worked back then. But I wouldn't recommend doing it that way because we have better ways now. For some people, the old way to do it is the only way they can do it based on the constraints they have and the tools that they're using and stuff. And so, it's not, like, it's not valuable at all. But it is a struggle to make sure that people understand that, like, this is the way that you do it if you have to do it this way, but, like, we've got better ways. WILL: I'm glad you shared that because it helps. And I love how you say it: when I make a mistake, I own up to it and let everyone know, "Hey, I made a mistake. Let's correct it and move on." So, I really like that. KENT: Yeah, 100%. MID-ROLL AD: Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? We know maintaining your own servers can be costly and that it's easy for spending creep to sneak in when your team isn't looking. By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops. WILL: I want to go back to what you were saying. When you left PayPal, you released Testing JavaScript. How did you come up with the idea to write a Testing JavaScript course? And, two, how long did it take to take off and be successful? KENT: That was a pretty special thing, honestly. In 2018, I had put together a bunch of workshops related to testing. There was this conference called Assert(js) that invited me to come, taught them. In the year prior, I went to Midwest JS and taught how to test React. I had this material about testing. I'd gotten into testing just because of open-source stuff. I didn't want to have to manually go through all my stuff again every time I wanted to check for breakages and stuff, so that got me into testing. And whatever I'm into is what I'm going to teach. So, I started teaching that testing. And then my friend, Ryan Florence, put together...he separated from Michael Jackson with React Training, and built his own thing called Workshop.me. He asked me to join up with him. And he would, like, put together these workshops for me, and I would just...my job was just to show up and teach. And so, I did that. I have a picture, actually, in this blog post, The 2010s Decade in Review, of me in front of 60 people at a two-day workshop at Trulia in San Francisco. WILL: Oh, wow. KENT: And this is where I was teaching my testing workshop. Well, what's interesting about that photo is that two weeks before that, I had gotten really frustrated with the tool that everybody uses or used at the time for testing React, and that was Enzyme. And so I was preparing this workshop or working on it. I had already delivered it a number of times, but I was working on it, improving it, as I always do [laughs] when I'm preparing. WILL: [laughs] KENT: I can never give the same workshop twice, I guess. And I was just so frustrated that Enzyme was so difficult to work with. And, like, I was going to prepare this document that said, "Here are all the things you should never do with Enzyme. Like, Enzyme encourages you to do these things; you should not do these things. And let me explain why." And I just hated that I needed a document like that. And so, I tweeted, "I'm seriously starting to think that I should make my own very small testing lib and drop Enzyme entirely. Most of Enzyme's features are not at all useful and many damaging to my test bases. I'd rather have something smaller that encourages better practices." And so, I tweeted that March 15th, 2018. I did that. I did exactly that. What I often do in my workshops is I try to build the abstraction that we're going to use so that you can use it better. So, I was, like, building Enzyme, and I realized the jump between what I had built, the little utilities that I had built as part of the workshop, from that to Enzyme was just a huge leap. And so, I thought, you know what? These utilities that I have built to teach Enzyme are actually really good. What if I just turned that into a testing utility? And that became Testing Library, which, fast forward to today, is the number one testing library for React. And it's recommended for testing React, and Vue, and Angular. The ideas that are in Testing Library got adopted by Playwright. If you're writing tests for anything in the browser, you are very likely using something that was either originally developed by me or inspired by the work that I did. And it all came from that testing workshop that I was working on. So, with that, I had not only that testing workshop; I had a number of other workshops around testing. And so I approached Joel Hooks from Egghead.io. I say, "Hey, I'm getting ready to record a bunch of Egghead courses. I've got, like, six or seven courses I want to do." And he'd seen my work before, you know, I was a very productive course creator. And he said, "Hey, how about we, you know, we've been thinking about doing this special thing. How about we make a website just dedicated to your courses?" And I said, "That sounds great." I was a little bit apprehensive because I knew that putting stuff on Egghead meant that I had, like, a built-in audience and everything that was on Egghead, so this would be really the first time of me just branching out with video material on my own. Because, otherwise, if it wasn't Egghead, it was Frontend Masters, and there was the built-in audience there. But yeah, we decided to go for it. And we released it in, I think, November. And it was that first week...which is always when you make the most is during the launch period. But that launch week, I made more than my PayPal salary for the entire year. And so, that was when I realized, oh, yeah, okay, let's go full-time on this because I don't need two PayPal salaries. I just need one. And then I can spend more time with my family and stuff. And especially as the kids are getting older, they're staying up later, and I want to hang out with them instead of with my computer at night [laughter], and so... WILL: I love how you explain that because I came in around 2018, 2019. And I remember Enzyme, and it was so confusing, so hard to work with, especially for, you know, a junior dev that's just trying to figure it out. And I remember Testing JavaScript and then using that library, and it was just so much easier to, like, grab whatever you needed to grab. Those utils made the biggest difference, and still today, they make a huge difference. So yes, I just resonate with what you're saying. That's amazing. KENT: Aw, thank you so much. WILL: Yeah. You did Testing JavaScript. And then what was your next course that you did? KENT: I quit PayPal, go full-time teaching. That first year, I actually did an update to Testing JavaScript. There were a couple of changes in Testing Library and other things that I needed to update it for. And then I started working on Epic React. So, while I was doing all this testing stuff, I was also very into React, creating a bunch of workshops around that. I was invited to speak all over the world to talk about React. And I had a couple of workshops already for React. So, I was invited to give workshops at these conferences about React. And so, I thought, you know, let's do this again, and we'll do it with React this time. The other thing was, I'd never really planned on being the testing guy. It just kind of happened, and I actually didn't really like it either. I wanted to be more broad than just testing. So, that kind of motivated me to say, hey, let's do something with React to be a little bit more broad. Yeah, so I worked on putting those workshops together and delivered them remotely. And then, yeah, COVID hit, and just really messed everything up [laughs] really bad. So, I had everything done on my end for Epic React by March of 2020, which is, like, immediately after COVID got started, in the U.S. at least. And so, yeah, then we actually didn't end up releasing Epic React until October that year, which, honestly [laughs], was a little bit frustrating for me because I was like, "Hey, guys, I have recorded all the videos and everything. Can we get this released?" But, like, that just was a really rough year for everybody. But yeah, so Egghead got the site put together. I did a bunch of interviews and stuff. And then we launched in October of 2020. That was way bigger than Testing JavaScript because Testing JavaScript was still very informed by my experience as an Egghead instructor, which, typically, the Egghead courses are, like, a video where watch me do this thing, and then you'll learn something and go apply it to your own stuff. And that's kind of what Testing JavaScript was built as. But as part of the update of Testing JavaScript in 2019, I added another workshop module called Testing Node Applications. And in that one, I decided, hey, typically, I would have a workshop version of my material and a course version. The workshop version had like instructions and exercises. And the course version was no instructions or anything. It was just, like, watch these videos. And it was just me doing the exercises. And with the update of Testing JavaScript, I added that Testing Node workshop, and I said, hey, what if we just, like, embrace the fact that these are exercises, and it's just, like, me recording the workshop? How I would deliver the workshop? And so, I tested that out, and that went really well. And so, I doubled down on that with Epic React. And I said, okay, now, this isn't just, like, watch these videos. This is a do the exercise and then watch me do the exercise. So, Epic React was not only a lot more material but the format of the material was more geared for retention and true practice and learning. And so, Epic React ended up doing much better than Testing JavaScript, and even still, is still doing a remarkable job as far as course material is concerned. And, like, so many people are getting a lot of really great knowledge from Epic React. So yeah, very gratifying to have that. WILL: Once again, I've used Epic React. It's taught me so many...stretched me. And I do like the format, so yes, I totally agree with that, yeah. The next thing, Remix, correct? KENT: Yeah. So, how I got into Remix, around the same time we finished recording Epic React videos, I was doing some other stuff kind of to keep content going and stuff while we were waiting to launch Epic React. And around that same time, my friend Ryan Florence and Michael Jackson––they were doing the React training thing. And so, we were technically competitors. Like I said, Ryan and I kind of joined forces temporarily for his Workshop Me thing, but that didn't end up working out very well. And Michael really wanted Ryan back, and so they got back together. And their React training business went way better than it had before. They were hiring people and all sorts of stuff. And then, a training business that focuses on in-person training just doesn't do very well when COVID comes around. And so, they ended up having to lay off everybody and tried to figure out, okay, now what are we going to do? Our income has gone overnight. This is a bit of a simplification. But they decided to build software and get paid for it like one does. So, they started building Remix. Ryan, actually, around that time, moved back to Utah. He and I would hang out sometimes, and he would share what he was working on with Michael. We would do, like, Zoom calls and stuff, too. I just got really excited about what they were working on. I could see the foundation was really solid, and I thought it was awesome. But I was still working on Epic React. I end up launching Epic React. He launches Remix the very next month as a developer preview thing. Yeah, it definitely...it looked a lot like current Remix in some ways but very, very different in lots of others. But I was super hooked on that. And so, I paid for the developer preview and started developing my website with it. And around the next year in August, I was getting close to finishing my website. My website is, like, pretty legit. If you haven't gone to kentcdodds.com. Yet, it is cooler than you think it is. There's a lot that goes into that website. So, I had a team help me with the product planning and getting illustrations and had somebody help me implement the designs and all that stuff. It was a pretty big project. And then, by August of 2021, Ryan and I were talking, and I said, "Hey, listen, I want to update Epic React to use Remix because I just think that is the best way to build React applications. But I have this little problem where Remix is a paid framework. That's just going to really reduce the number of people who are interested in learning what I have to teach. And on top of that, like, it just makes it difficult for people to test things out." And so, he, around that time, was like, "Hey, just hold off a little bit. We've got some announcements." And so, I think it was September when they announced that they'd raised VC money and they were going to make Remix open source. That was when Ryan said, "Hey, listen, Kent, I think that it's awesome you want to update Epic React to use Remix. But the problem is that Remix isn't even 1.0 yet. The community is super small. It needs a lot of help. If you release a course on Remix right now, then you're not going to get any attention because, like, nobody even knows what it is." So, part of me is like, yeah, that's true. But also, the other part of me is like, how do people find out what it is [laughs] unless there's, like, material about it? But he was right. And he said, "Listen, we've got a bunch of VC money. I've always wanted to work with you. How about we just hire you? And you can be a full-time teacher about Remix. But you don't have to charge anything. You just, like, make a bunch of stuff for free about Remix." I said, "That sounds great. But, you know, to make that worth my while because I'm really happy with what I'm doing with this teaching thing, like, I'm going to need a lot of Remix." And so, Michael Jackson was like, "How about we just make you a co-founder, and we give you a lot of Remix?" And I said, "Okay, let's do this." And so I jumped on board with them as a year-delayed co-founder. I guess that's pretty common. But, like, that felt kind of weird to me [laughs] to be called a co-founder. But yeah, so I joined up with them. I worked on documentation a little bit, mostly community building. I ran Remix Conf. Shopify was interested in what we were doing. And we were interested in what Shopify was doing because, at the time, they were working on Hydrogen, which was one of the early adopters of React Server Components. And, of course, everybody was interested in whether Remix was going to be adding support for server components. And Ryan put together a couple of experiments and found out that server components were nowhere near ready. And we could do better than server components could as of, you know, the time that he wrote the blog posts, like, two years ago. So, Hydrogen was working with server components. And I put us in touch with the Hydrogen team—I think it was me—to, like, talk with the Hydrogen team about, like, "Hey, how about instead of spending all this time building your own framework, you just build on top of Remix then you can, you know, make your Shopify starter projects just, like, a really thin layer on top of Remix and people will love it? And this is very important to us because we need to get users, especially really big and high profile users, so people will take us seriously." And so, we have this meeting. They fly a bunch of their people out to Salt Lake. They're asking us questions. We're asking them questions and saying, "Hey, listen, this is why server components are just not going to work out for you." Well, apparently, they didn't listen to us. It felt like they were just like, "No, we're highly invested in this. We've already sunk all this cost into this, but we're going to keep going." And they did end up shipping Hydrogen version 1 on top of server components, which I just thought was a big mistake. And it wasn't too long after that they came back and said, "Hey, we're kind of interested in having you guys join Shopify." So, right after Remix Conf, I go up into Michael's room at the hotel with Ryan. And they say, "Hey, listen, Kent, we're talking with Shopify about selling Remix and joining Shopify," and kind of bounced back and forth on whether we wanted to do it. All of us were just not sure. Because when I joined Remix, I was thinking, okay, we're going to build something, and it's going to be huge. This is going to be bigger than Vercel, like multibillion-dollar company. So, I really kind of struggled with thinking, hey, we're selling out. Like, we're just getting started here. So, Ryan and I ended up at RenderATL in Atlanta at that conference. We were both speaking there. And Ryan didn't fill out the right form. So, he actually didn't have a hotel room [laughs], and so he ended up staying in my room. I intentionally always get a double bedroom just in case somebody needs to stay with me because somebody did that for me once, and I just...it was really nice of them. So, I've always done that since. And so, I said, "Yeah, Ryan, you can stay with me." And so, we spent just a ton of time together. And this was all while we were trying to decide what to do with Shopify. And we had a lot of conversations about, like, what do we want for Remix in the future? And it was there that I realized, oh if I want to take this to, like, multi-billion dollar valuation, I've got to do things that I am not at all interested in doing. Like, you've got to build a business that is worth that much money and do business-related things. On top of all of that, to get any money out of it...because I just had a percentage of the company, not actually any money. There was no stock. So, the only way you can get money out of a situation like that is if you have a liquidation event like an IPO, which sounds, like, awful—I [laughs] would hate to go through an IP0—or you have to be bought. And if you're worth $2 billion, or 3, or whatever, who can buy you? There's almost nobody who can buy you at that valuation. Do you really want to outprice anybody that could possibly buy you? And then, on top of that, to get there, that's, like, a decade worth of your life of working really superduper hard to get to that point, and there's no guarantee. Ryan would always say a bird in the hand is worth two in the bush. He was saying Shopify is a bird in the hand, and we do not know what the future holds. And so, we were all finally convinced that, yeah, we want to sell, and so we decided, yeah, let's sell. And as the sale date grew closer, I was getting excited because I was like, oh, I can be back on the TC39 because Shopify is, like, I don't know if they're actually sending delegates to the TC39, but I'm sure that they would be interested if I ask them to, like, "Hey, let's be involved in the evolution of JavaScript." And I know they're on the Web Working Group. Like, they're on a bunch of different committees and stuff. And I just thought it'd be really cool to get involved in the web platform again. And then, on top of that, I just thought, you know what? I'll just spend all my time teaching Shopify developers how to use Remix. That sounds like a lot of fun. As things drew closer, I got more and more uneasy about that. And I thought, you know, I could probably do just as well for myself by going full-time teacher again. I've done this thing before. I just really like being a teacher and, like, having total control over everything that I do. And if I work at Shopify, they're going to tell me, "Hey, you need to, like, do this, and that, and the other." And I don't know if I want to go back to that. And so, I decided, this is awesome. Super, super good job, folks. I think I've done everything for you that you need me to do. I'm going to bail out. And so, yeah, Shopify wasn't super jazzed about that. But the deal went through anyway. And that's how I ended my time at Shopify. WILL: I love it. It's lining up perfectly because you say you left Shopify to go back doing more teaching. And then you released another course; that's Epic Web, correct? KENT: Right. That was the reason I left Shopify or I didn't join up with Shopify is because I wanted to work on Epic Web. In this 2010s blog post, one of the last things that I mention...toward the bottom, there's a section, KCD EDU, which is basically, like, I wanted to help someone go from zero to my level as an engineer in a single place where I teach just all of the things that I can teach to get somebody there. And so I wanted to call it KCD EDU, but I guess you have to be an accredited university to get that domain or something. But that was the idea. Erin Fox, back in 2020 she said, "I'm expecting you to announce your online Kent C. Dodds engineering bootcamp." And I replied, "I'm planning on doing this, no joke." So, I've been wanting to do this for a really long time. And so, leaving Remix was like, yeah, this is what I'm going to go do. I'm going to go build KCD EDU. And I was talking with Ryan at some point about, like, what I was planning on doing in the future. And something he said or something I said in that conversation made me realize, oh, shoot, I want to build Epic Web Dev. So, I've got Epic React. I don't want Epic Remix. I want people to, like, be web developers. Remix is just, like, an implementation detail. And so, I went and I was relieved to find that the domain was still available: epicweb.dev, and so I bought that. And so, I was always planning on, like, even while I was at Remix, eventually, I would leave Remix and go build Epic Web Dev. So, that's what I did. Starting in August, I decided, okay, how about this: I will build a legit real-world web application, and then I will use that to teach people how to build legit real-world web applications from start to finish. If it's included as, like, knowledge you would need to build this web app, then that's knowledge you need to be able to build a full-stack application. That was the idea. So, I started live streaming in, like, August or September, and I would live stream almost everyday development of this web app. So, people can go and watch those on my YouTube channel. I would livestream for, like, sometimes six hours at a time with breaks every 45 minutes. So, I'd just put it on a break slide, go for a quick walk, or take a drink, whatever, and then I would come back. And I would just, like, so much development and live streaming for a long time. Once I got, like, in a pretty good place with that, the app I was building was called Rocket Rental. It's like Airbnb for rocket ships. So, you could rent, like, your own rocket ship to other people to fly. So, it had to be, like, realistic enough that, like, you could relate it to whatever you were building but not realistic enough that people would actually think it was a real product [laughs]. I worked with Egghead again. They actually have a sister company now called Skill Recordings that's responsible for these types of products. And so, I was working with Skill Recordings on, like, they would get me designs. And then I would, like, work with other people to help implement some of those designs. And then, I started working on turning this stuff into workshops. And with Epic React, we have this workshop app that you run locally so that you can work in your own editor, in your own environment, and with your own editor plugins and all that stuff. I want you to practice the way that you're going to actually exercise that practice when you're done––when you're working at work. And so we have this workshop app with Epic React. Well, that was built with Create React app, very limited on what you could do. And so, I started working on a new workshop app that I just called KCD Shop, that was built with Remix. And so, now we've got a bunch of server-side stuff we can do. And this server side is running on your machine. And so, so much stuff that I can do with this thing. One of the big challenges with Epic React was that the video you watch is on epicreact.dev, but the exercises you run are on localhost. And so, you have to keep those things in sync. You'd see, okay, I'm in exercise one on the videos. Let me go find exercise one in the app and then find the file exercise one. So, you've got, like, three different things you've got to keep in sync. And so, with the workshop app for Epic Web, I said, how about we make it so that we can embed the video into the app? And so, you just have localhost running, and you see the video right above the instructions for the exercise. And so, you watch the video that kind of introduces the problem that you're going to be doing, and then you read the instructions. And then we can also make it so that we have links you can click or buttons you can click in the app that will open your editor exactly where you're supposed to go. So you don't have to keep anything in sync. You go to the app, and you watch the video. You read the instructions. You click this button. It opens your editor. And so, that's exactly what I did. And it's an amazing experience. It is phenomenal, not just for the workshop learners but for me, as a workshop developer, like, creating the workshop––it's just been phenomenal. Because, like, we also have this diff view where you can see the difference between your work in progress and the solution. So, if you get stuck, then it's very easy to see where you went wrong. It also means that we can build even very large applications as part of our workshop and our exercise where there are dozens or hundreds of files. And you don't have to worry about finding them because it'll tell you exactly which ones you need to be working in, so all sorts of really, really cool things. So, this workshop app––actually, took a lot of time and effort to build. But now that it's done, like, people are going through it now, and they're just loving it. So, I built the workshop app, I put the first workshop of Rocket Rental into this workshop app, and I delivered it. And I found out very quickly that a full application with all the bells and whistles you'd expect, like, tons of different routes and stuff, was just too much. Even with the workshop app, it was just really pretty difficult for people to gain enough context around what they were building to be effective. So, I was concerned about that. But then, around the same time, I started realizing that I had a marketing problem. And that is that with Testing JavaScript, people know that they're customers because they're like, I'm a JavaScript developer, and I know how to test––boom. I'm a Testing JavaScript customer. With Epic React, I join this company; they're using React; I need to know React, boom. I'm a customer of Epic React. But with something like Epic Web, it's just so broad that, like, yeah, I am a web developer. I just don't know if I'm a customer to Epic Web. Like, is Epic Web for only really advanced people, or is it only for really beginner people? Or is it only for people who are using this set of tools or... Like, it's just a very difficult thing to, like, identify with. And so I wanted to de-emphasize the fact that we used Remix because the fact is that you can walk away from this material and work in a Next.js app or a SvelteKit app and still use so much of the knowledge that you gained in that environment. So, I didn't want to focus on the fact that we're using any particular set of tools because the tools themselves I select them, not only because I think that they are really great tools but also because the knowledge you gain from these tools is very transferable. And I'm going to teach it in a way that's very transferable. That was the plan. But I still had this issue, like, I need people to be able to identify themselves as customers of this thing. So, what I decided to do through some, like, hints and inspiration from other people was how about I turn Rocket Rental into a much simpler app and make that a project starter? And while I was at Remix, actually, I directed the creation of this feature called Remix Stacks. It's basically the CLI allows you to create a Remix app based on a template. I said I can make a Remix Stack out of this, and I called it the Epic Stack. And so, just took all of the concepts that came from Rocket Rental; applied it to a much simpler app. It's just a note-taking app, but it has, like, all of the features that you would need to build in a typical application. So, it's got a database. It's got deployment, GitHub integration. So, you have GitHub Actions to run tests and stuff. It has the tests. It has authentication already implemented, and even two-factor auth, and third-party auth, and file upload, and, like, just tons and tons of stuff built in. And so, people can start a new project and ship that and have a lot of success, like, skip all the basic stuff. So, I presented that at Remix Conf. I wasn't working at Remix anymore, but they asked me to run Remix Conf again, so I did. And I told them, "If I'm running it this year, I'm going to select myself to speak." And I spoke and introduced the Epic Stack there. And then that was when I started to create the workshops based on the Epic Stack. And so, now it was no longer we're going to have workshops to build Rocket Rental; it was we're going to have workshops to build the Epic Stack, with the idea being that if you build the thing, you are able to use it better, like, still following the same pattern I did with Testing JavaScript where we build a framework first. Like, before you start using Jest, we're building Jest and same with Testing Library. We do the same thing with React. Before we bring in React, I teach you how to create DOM nodes yourself and render those to the page and all of that. And so, here with Epic Web, I'm going to teach you how to build the framework that you can use to build applications. So, that is what Epic Web is, it's effectively we're building the Epic Stack. In the process, you learn all about really basic things, like, how do you get styles onto the page all the way to really complex things like, how do you validate a user's email? Or how do you implement two-factor auth? Or how do you create a test database? So, you don't have to mock out the database, but you can still run your test in isolation. Around this time was when my wife and I were trying to become pregnant. And we got the news that we were expecting, and we were super excited. And so, I'm thinking, okay, I've got to ship this thing before the baby comes. Because who knows what happens after this baby comes? So, I am talking with Skill Recordings. I'm saying, "We've got to get this done by October." I think it was May. And so, I was thinking like, okay, I've probably got, like, maybe eight days worth of workshops here. And so, kind of outlined all of the workshops. Like, I know what needs to be included. I know what the end looks like because I've got the Epic Stack. The end is the Epic Stack. The beginning is, like, a brand new create Remix app creation right there. So, I know what the start and the end looks like. I kind of can figure out how much time I need to teach all of that. And I said, "Let's do eight days." And so, we got that scheduled and started selling tickets. And we sold out 30 tickets in just a couple of days, and that's what we originally planned for. I'm like, well, gosh, I can handle 80 people in a workshop. I've done that before, but that's about as far as I go. I don't really like going that much. In fact, online, especially, I only like to go up to, like, 40. But we said, "Hey, let's knock this out of the park." So, we doubled it, and we sold another 30 seats. And so, it was sold out before even the early bird sale was over. So, that was pretty encouraging. The problem was that I hadn't actually developed this material. I'd already given one workshop about testing with Rocket Rental, and I'd given one workshop about the fundamentals with Rocket Rental. But I hadn't done anything of the authentication or, the forms, or data modeling. Also, like, Epic Notes app is different from Rocket Rental. So, I got to rebuild those workshops. Like, the first workshop was going to start in, like, two weeks, maybe three weeks. And so, I'm working on these workshops. And I'm like, I've finished the first workshop, which was going to be a two-day workshop, and so I get that done. And so, that next week, I'm getting close to finished on the forms workshop, and then I start the workshops. And that was when I started to realize, oh, shoot, I am in huge trouble because I have to not only deliver two workshops a week, so that's two days a week that I'm not able to work on the workshops, really. And then also develop the material as I go, which I don't normally do this at all because I just don't like stressing myself out so much. But, like, I'd had this timeline put together, and I'm like, I need to ship this by October. For about five weeks, I worked 80 to 100 hours a week, maybe more, in a row to get those workshops created [laughs]. And I do not recommend this, and I will never do it again. I can tell you this now. I didn't tell anybody at the time because I was worried that people would think, well, geez, is that the type of product you create, like, you're just rushing through this stuff? But I can tell you this safely now because the results speak for themselves. Like, these people loved this stuff. They ate it up. It was so good. I won't do this again. It's not something that I typically do. But it worked. And, like, I put in a crazy amount of work to make this work. People loved it. And yeah, I'm really, really happy with that. The next step, though, so it was eight days' worth of workshops in four weeks. And I realized, as I almost always realize when I'm presenting workshops, that, like, oh my gosh, I have way more material than I have time for. So, by

As a developer have you ever worked on an API endpoint but you can't easily find the documentation for the API to see how pieces work, or can't find the specific sequence diagram on how your domains interact, or how about using some clunky outdated internal tool that you have to use to compile your code, well your user experience is suffering, more specifically your developer experience is poor. The term “developer experience” or DX is becoming more and more pervasive in the tech industry as companies realize how important it is for the success of their businesses. But what is DX you ask? Well, in today's episode I am joined by a very special guest to answer that question and explore the realm of DX engineering and how you can help yourself and your team become more productive and build the experience you deserve. Our guest today, Cassidy Williams, spreads the joy of tech through her contagious positivity and accessible content. She earned her Bachelor of Science in Computer Science from Iowa State University and is a startup advisor and investor and developer experience expert. Currently, she is the CTO at Contenda, an AI content generation platform. Previously, she was the Director of Developer Experience at Netlify and has also worked at a variety of large and small companies like Remote, React Training, CodePen, Amazon and Venmo. She's active in the developer community, has given hundreds of talks around the world, and also co-hosts the Stack overflow podcast and The Dev Morning Show (at night) podcast. She is one of Glamour Magazine's 35 Women Under 35 Changing the Tech Industry and LinkedIn's Top Professionals 35 & Under. She wants to inspire generations of STEM students to be the best they can be. When Cassidy is not inspiring the next generation of coders she is playing music, singing karaoke, creating memes, building mechanical keyboards, and hanging out with her sister. Connect with Cassidy: Twitter The Dev Morning Show (at night) LinkedIn Website Show notes and helpful resources: CTO at Contenda Glamour Magazine's 35 Women Under 35 Changing the Tech Industry Subscribe to Cassidy's newsletter it won't disappoint Cassidy's fav joke at the time of recording “I adopted my dog from a blacksmith. As soon as we got home, she made a bolt for the door!” Obsidian note taking software for productivity As a developer experience engineer you are making developers live's easier through content generation, demos, tutorials and anything that can get them from zero to 1, the “Time to Hello World” Make Time by Jake Knapp and John Zeratsky Cosynd App - The fastest and most affordable way for content creators to register their works Visit podcast.unfilteredbuild.com for more info Building something cool or solving interesting problems? Want to be on this show? Send me an email at jointhepodcast@unfilteredbuild.com Podcast produced by Unfiltered Build - dream.design.develop.

Brad Westfall is an amazing friend and has led sessions on React at Adobe, The Washington Post, AMex, and more! He also has a sweet platform to help vet developers!

In this episode of the Modern Medic, the whole TacMed Training team jump on the mic to talk about the new TacMed REACT Training Centre in Brisbane. www.tacmedaustralia.com.au

This week we chat with Michael of React Training and learn everything we need to know about React Router v6 — what's in store, how to update, and what he's learned about empathy in the process.

In this episode of Technically True, we will chat with Cassidy Williams, who is a software engineer and instructor at React Training. We will explore her journey and utilize her experience to learn about getting started with public speaking, dealing with procrastination, handling live demos like a boss and establishing your personal brand. Featuring: Cassidy Williams (twitter.com/cassidoo) Hosts: Tanay Pant (twitter.com/tanay1337) Notes: The journal that Cassidy mentioned is Dabble.Me and the slide software that she mentioned is Deckset.

Cassidy walks us through her career and gives us insight on choosing jobs, quitting them, and focusing on what's important to you. We also discuss keeping track of her many ideas, teaching workshops at React Training, why Amazon was a poor fit, and much more.

Tilde Club: It’s your chance to LARP as a 70s sys admin! What you do on your computer is your business. Don’t be tricked by scammers.Paul makes the mistake of sharing his Anxiety Box on This American LifeSara’s favorite Kanye tweet is available, beautifully framed, for only $75. cKeys is an amazing Seattle non-profit that teaches folks how to make their own keyboards!When we recorded this episode Cassidy worked at CodePen, but not she works at React Training, so check them out.

Tilde Club: It's your chance to LARP as a 70s sys admin! What you do on your computer is your business. Don't be tricked by scammers.Paul makes the mistake of sharing his Anxiety Box on This American LifeSara's favorite Kanye tweet is available, beautifully framed, for only $75. cKeys is an amazing Seattle non-profit that teaches folks how to make their own keyboards!When we recorded this episode Cassidy worked at CodePen, but not she works at React Training, so check them out.

On this episode of if/else, host Mayuko Inoue explores a choice faced by many front-end developers: which JavaScript framework should you use?There are many frameworks available, including Angular, Relay, Next, Aurelia, Svelte, Ember, Meteor, Knockout, Backbone, Node, and Polymer. But we're going to focus on the two most popular ones: React and Vue.js.Mayuko explains the history and philosophy behind these two frameworks, and you'll hear from several developers about their experiences with React and Vue.You'll also meet Al. Al works at a small IoT firm, and is getting back into front-end development after a long hiatus. He has some experience with JavaScript, but wants to take advantage of the efficiency gains of a JavaScript framework. Al has heard about React and Vue, but he hasn't committed to either option. To help Al decide which one will work best for his projects, we've enlisted the help of two industry experts.Cassidy Williams is an instructor and developer at React Training and the director of outreach at cKeys. Erik Hanchett is a senior software engineer at Cerity and the author of the book Vue.js In Action. He is also co-host of the Self Taught or Not podcast.Cassidy and Erik join Mayuko to discuss the guiding principles of each framework, along with their strengths and weaknesses. The idea is to give Al, or anyone else facing a similar decision, the information needed to make a solid choice.if/else is an original podcast by CTO.ai, makers of The Ops Platform. The Ops Platform makes it easy for development teams to create and share workflow automations without leaving the command line. Visit cto.ai/platform to join the beta.If you enjoy the show, please leave a ⭐⭐⭐⭐⭐ rating or review on Apple Podcasts.

In this episode, Michael Jackson of React Training and Rob DeLuca and Taras Mankovski of The Frontside talk about what is a component, and what a component is specifically in the context of React. They also discuss when it stops being a component and becomes something larger, how it has changed the way we develop UI, and thoughts on container and presentational components being synonyms for controller and view. References The Tweet that started it all Wil Wilsman: Does my application work in real life? Do you have opinions on this show? Want to hear about a specific topic in the future? Reach out to us at contact@frontside.io or on Twitter at @thefrontside. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. TRANSCRIPT: ROBERT: Hello, everyone. Welcome to Episode 103 of The Frontside Podcast. I'm Robert DeLuca, a developer here at the Frontside and I'll be today's episode host. We're going to be discussing what is a React component or what is a component with Michael Jackson. I'm pretty excited about this topic, a sort of off from a tweet that I sent out after a long workday, when it is something being called "component" because it was built with React components but it was more like a mini application? Then Michael replied to my tweet, as they're happening and he said, "What is your definition of a component?" which is exactly what we're going to be discussing today. I thought that was a really great question. With me, as a co-host is Taras Mankovski. TARAS: Hello, hello. I'm also a developer at Frontside. ROBERT: Before we get into the discussion, I would like to make a little announcement. We've been working on building a suite of testing tools to make acceptance testing JavaScript apps like React or Vue or Ember or anything else kind of JavaScript, fast and easy to maintain over the past few months. We call it BigTest. If you follow me on Twitter, I'm kind of loud about it. I love this project that we were working and one of my coworkers just published a blog post, giving an introduction to acceptance testing on React applications with BigTest. If that sounds interesting to you, you should check it out. We'll leave a link in the show notes. Now, let's jump right into it. Hi, Michael. How are you doing? MICHAEL: Hi Robert, I'm doing well. Thank you for inviting me to be on the podcast. ROBERT: Oh, no. Thank you for joining. I feel like this going to be really fun conversation. We went back and forth on Twitter a little bit and I was like, "You know what? This serves really well like a free flowing conversation." MICHAEL: Yeah, it's something I really like to talk about, specifically, when we're talking about components or when we're talking about React components. I think there's a lot stuff there to discuss and I think that React, specifically has really, at least defined that word for me. When you were talking about your mini application, I was like, "Oh, yeah. That's cool," and to me, that's kind of what these components have the potential to be, what these React components have the potential to be. It's kind of like almost these miniature applications that you stitched together to make a bigger one. ROBERT: Yeah, that's really cool. I was frustrated at the end of that day, just because that had so much logic crammed into it and you can kind of see that come through in the tweet but I'm not going to lie. After I sent that tweet, I was a little disappointed with myself because it came off a little bit like flangy but I guess we could just kind of jump right into defining what is a component. MICHAEL: When I saw your tweet, I was like, "Oh, you know like --" and of course, I don't know the component that you're looking at. It could have been terrible. Totally, it could have been terrible. I'm totally willing to believe that it was not a good component. But writing React is hard, especially writing good React is actually hard. At first, I thought it was easy but I think it's easy to solve your immediate problems but to write React to that is generic enough to solve lots of different problems, I think it's actually very, very hard and it's something that I've spent the last couple years learning. Anyway, that's kind of a tangent. But regardless of the component that you were looking at, the way that I've tend to think about these components is we used to have a model for thinking about how to build frontend applications -- ROBERT: Like MVC? MICHAEL: MVC, that's the one. That's the one that talking about. You have, here's your model, here's your view, here's your controller. You know, there are separate logical entities and lots of times, those even live in separate files on the file system and we keep them sort of separate and spaced out. As far as I can tell, that's a sort of paradigm. I learned it in school. By the time universities catch up with industry is at least, like twenty years, so it's probably something that was invented back in the 60s or 70s. ROBERT: I think it was like the 80s because Charles talks about it a lot and sort of Taras, actually because we're building something that's like a composable model, just like the Vue of React is a composable view, its components. I think it's interesting because I was listening to the Changelog Podcast and it sounds like you worked with Ember for a while. MICHAEL: I did, yeah. ROBERT: I forget, which podcast that was but we can find it and we'll link it to the show notes but I thought that was really interesting that you also came... Oh, maybe not came from Ember. You had experience with for, at least a couple years and that's where I came from. That's kind of where that tweet came from and was like, "Man, I don't like what happened to the word component," because when I think of component, it's like something that is encapsulated in a small piece of UI. But I'm okay with letting go of that. MICHAEL: Well, yes. Ember came out of something called SproutCore, which actually originated at Apple. Tom Dale used to be a developer at Apple. I'm sure you all know all of this but just for some sort of back story for others who might not. Apple was a place where MVC was really, really big. The whole Cocoa frameworks. They're all very much like, here's your controller, here's your view, core data has all of your models, that kind of thing. It's a software development philosophy that goes back a long time and has deep roots and I'm not here to suggest that because it's old it's bad, because lots of old things are actually very, very nice and good, especially in programming. We're starting to see a resurgence of functional programming ideas, for example, which have been around forever, since at least, the 60s or even earlier than that. It's not necessarily that I think that because it's old, that it's bad. I don't. ROBERT: Right, right. MICHAEL: But the thing that I do see in these React components is they kind of go very much against the grain. If you had, for example your model, your view and your controller as these vertical silos, just imagine turning that whole thing on its side and then cutting a slices of that, so that each of your React components has elements of MVC in it. They're all sort of mixed together. I run a training company called React Training and whenever I'm doing one of my training workshops, the way that I talk about it is a component is able to encapsulate three things: markup, which is the view essentially; state, which is essentially your data or your model; and behavior, which is essentially the controller, so what happens when the user is interacting with the view and clicking on the buttons? What do we do in response to the user input? You've got all three of those MVC elements in the React component. In fact, I've been meaning to kind of coin the term for a while. Instead of MVC, I call it MSB -- markup, state and behavior. ROBERT: You heard it here first. MICHAEL: That's right, here on The Frontside Podcast, we're coining new terms. ROBERT: That's pretty great. I guess coining off of that, is it fair to say that MVC kind of still lives on, except it's now in React? Or it's kind of more sliced up into smaller, more digestible pieces? We can always come back to this composability element, right? Would you say like really React would made it possible to compose many little MVC apps? MICHAEL: Yeah, exactly. The thing that people really, really love about MVC, I think you still have it in React. MVC, the thing that people always come back to is the separation of concerns. Let's just say, "I don't want everything sort of mingled together. I want it to be very clear. What is my model? What is my controller? And what is my view?" The cool thing about a React component is if you look at it, you still have very clear separation within the single component. You have a very clear separation of all three of those concerns: your state lives in an object called 'this.state,' then your view is whatever you return from your render method. That's in a completely separate spot, since still in the same component and then your behavior or your controller usually has its own method, so you can inline those in your render method or you can pull them out if this is how you'd like to do it. You can pull them out into instance methods. You can still have kind of that separation of the concerns within a single component. I think to your point, the React component model is all about composition, so this is kind of a term that we've actually adopted in other areas in technology. It's sort of just coming to frontend. The idea is you've probably heard of a service-oriented architecture for design in backend systems. These servers over here are application servers, these are database servers, here's our caching tier, here's our Ingress or LoadBalancer and maybe, you stitch them all together on the backend into one coherent system. You know, here's our storage and our image-resizing services. You stitch them all together on the backend into one coherent system but it benefits you to not build them all as one part of sort of monolith. We've got a lot of benefits from the decoupling. For one, if one piece of the system fails, the whole thing doesn't go down, so you can like swap it out or upgrade it and replace it with something else. I feel like that is kind of a similar idea to what is going on the frontend with these React components. ROBERT: Oh, microservice components. MICHAEL: Yeah, exactly. Each component is kind of like you said. It could be like a miniature application and it could be totally self-sufficient and I could drop it onto a page and it could just do its own thing or what I could do is I could take that app, that component and I could drop it into a larger app that can speak to it and can communicate state to it via the props that it sees and then can get state back out of it via these callbacks. I kind of view it as like all of these miniature systems that they can either be completely encapsulated and self-governing on their own or you can take them and compose them with a larger app. ROBERT: That's really interesting. I guess what is a component specifically in the context of a React. I guess, we kind of just answered that, that you can bundle all these things together, right? Does that make sense? MICHAEL: Yeah. The beautiful thing about this composition model is you can have all three of those things in the same component: markup, state and behavior. You can have all three of them right there, encapsulated in one component or once you discover more advanced patterns with React, you can actually make it so that a component only has two of the three or one of the three. ROBERT: And then it kind of like passes callbacks or props or state around? MICHAEL: Exactly. It can essentially delegate the responsibilities for handling the other pieces that it misses to other components around it. There's a pattern that I kind of coined last year called render props. ROBERT: Oh, yes. I remember hearing this on Changelog Podcast. I was actually one of the people that at first thought it literally was a prop name render. MICHAEL: Well, I mean it's not a bad way to think about it. It could be a prop name render. ROBERT: But then I found out it actually is a prop that you send JSX too and render whatever is there. MICHAEL: Yeah, exactly, a prop that you used to render stuff. It's the way that I describe it. When you think about it, any component, for example that accepts a render prop is really just delegating it's rendering to some other function. It can contain the two pieces: the state and the behavior, but then it can sort of delegate this third piece, which is the markup and say, "You know what? I don't really care about, specifically what I have to render." I don't have an opinion about that. You just give me a function and I'll give you my state and possibly, some behavior callbacks and then you can tell me what to render. I'm like a component that I have two of those three pieces. I don't have the markup, you just give me a function, that I will call when I need the markup. ROBERT: That's really powerful. MICHAEL: Yeah, exactly. I can have all three in one place or I can also with this component model, just delegate one piece or even two pieces, using these kinds of patterns to other components, so it's really nice. ROBERT: I'm always have to come back to this because this is where I kind of cut my teeth in the frontend world. I feel like render props are very similar to the yield pattern in Ember, where you can yield out a component and place it anywhere inside that template block. I think it's really similar. Because we have a large base of Ember developers that listen and they needed a draw like a parallel, I would say that's almost a parallel. I might be off on that. Taras, would you agree with that? TARAS: Yeah, it's very similar. There is one little 'gotcha' with render props in React, which I think Ember deals with a little bit more gracefully. I do use React all the time now. I use it much more often than I use Ember but -- ROBERT: Same. TARAS: Yeah and I'm kind of curious, Michael if you would think about this. Because there are certain things that, for example, JSX does, like one of the attributes of using render prop is that you want to pass stable functions, like something that is actually defined in init hook, so you're not necessarily recreating a new identity for this function every time that you pass into the render prop. Is that right? I think for someone who is might not be familiar with this, it's a little bit counterintuitive because it just kind of like, you just pass something and then you later realize, "Actually, I can't really do that because now your components were rendering over and over again." I'm curious like where can we kind of innovate in that? Because in Ember world, for example, it's really safe to use render props. If you're delegating to the context to do the rendering, you can very easily pass a block of template into the component and then the component will know how to render that in a performant way. My experience with render props in React was that the pattern in Ember is it's a very common behavior to delegate to the context of how the children of a component are rendered. This is the primary purpose of the yield in Ember and this is used by a lot of the components to provide APIs, so essentially, you're yielding, you're sending into the children function behavior that you want the developer to use while consuming your component. The parallel with React is that you would have, essentially a function, like you have a children render prop, which is a function that receives so that when a component is rendering the children render prop, it's passing some data into that function and it's invoking the children function and it's passing to it some data and then that data is being used inside of the children render function. Now, this mechanism works really well in Ember because Ember is using its own templating engine, so it manages every placeholder in the entire template as being passed into the component. It knows exactly what has changed in the function. Looking at that, the value just passing through component as a whole thing. It's actually managing each individual spot where the dynamic elements needs to be rendered. What that does is it allows it to manage the entire children function so you don't need to worry about stabilizing the render props. You don't need to assign them. Because there's also other challenges that kind of arise when you have to move the actual function that you pass into children. You have to move into the body of the actual component. Your ability to compose the state that is within the render function is kind of limit because you now have kind of broken up into different places. I'm a little bit curious what are your thoughts about this? And if there's any innovation that's going to require or improvements that will require in the way that React handles render props. ROBERT: I definitely remember seeing some tweets from you, Michael about this, like very recently. MICHAEL: Yeah, just yesterday in fact, I was talking about this on my Twitter. First of all, thanks for the question, Taras. I appreciate it. I think you kind of nailed it with the difference between Ember and for example, just JSX -- Handlebars, really and JSX is that Handlebars is not JavaScript. Handlebars is a language of its own, really. As the implementers of that language, the Ember team or the Handlebars team has complete control over how things work. For example, when functions are allocated. If they have a yield block, for example, that yield block does not have access to things like JavaScript Scope. It really is just a block within the templating language and so, they can decide when they're implementing that language. They can say, "We're only going to ever allocate one function for this yield block." JSX on the other hand, it really is just sort of some syntax sugar over JavaScript, which is nice lots of times because you can use things like JavaScript functions scope. You can do things like refactor it, like you would any other piece of JavaScript and pull that function out into its own variable or something like that. In a lot of ways, it's more flexible but with that flexibility comes this extra concern of what happens with the prop passing and it's a real concern but I don't think it's as big of a problem as most people have heard or might think it is. The real problem, the root of the problem is that if you have a pure component in React, the pure component is optimization tool in React, if you find that your component really is a pure component of just a pure function of its props and state, and that it will never render anything different, if it receives the exact same props and state, you can declare that that component is a pure component. Instead of just a regular component, it's now a pure component and so, it will actually opt out of the render cycle if it receives the exact same props and state on subsequent render. By exact same, what I mean is like identity triple -- ROBERT: Yeah. MICHAEL: -- Same. That's an optimization tool that you can use in React to say for example, maybe I've got a component and for some reason, it's always receiving the exact same props and it's rendering a lot. I can say, "You know what, React? Don't even waste your time re-rendering this component and doing the reconciliation around it and everything like that. If it receives the exact same props, don't even waste your time. This is a pure component. It received the same props. It's going to render the exact same stuff as it rendered last time, so it will completely opt out of the render cycle," so React won't even call the render method, won't even bother doing the reconciliation for that component or its descendants. It's actually a really, really nice way to get a little performance boost in that situation. ROBERT: Interesting. Does that mean, rather than passing some JSX that returns out an anonymous function, you would rather have like a pure component over that? MICHAEL: All it really means is that when you identify a place in your app where this is happening, instead of extending React component, you can extend React.PureComponent and now you component opts out of the render cycle. ROBERT: Gotcha. Because I see a lot in React applications, it will just return some JSX out of anonymous function, kind of think, Taras was getting at, when each re-render happens, it's recreating a new function and all of it were done inside of it, from the JSX because it's just a new function that's being bound each time. I think my takeaway from that and correct me if I'm wrong, is don't pass JSX and an anonymous function or I guess, from your tweets yesterday, that's kind of a premature optimization. Maybe, not pass as anonymous function but pass as pure component. MICHAEL: I hadn't yet gotten to directly addressing Taras's concern but the idea is -- ROBERT: -- Jumping the gun. MICHAEL: Yeah, it's fine. If you do have a pure component, that is when you're going to have a problem with this render prop pattern because you can't pass a render prop to a pure component. They just don't go together. Well, sorry. I should actually qualify that. You can pass around a prop to pure component but you need to make sure that it is always the exact same function, otherwise why are you making this thing a pure component, so there's a little bit of a problem there. I actually wrote the documentation on React's website on render props and there's a little caveat section where I discuss how you could get around this, you could convert it into an instance method or something else but then the concern at this point and this is why I said it's not such a huge problem because we're getting very, very specific now. Let's assume that we've got a pure component that is the child that we want to render and it accepts a render prop and that render prop depends on state and/or some sort of scope that it needs in the render method. Now, we've got a problem because we need to generate a new function in the render method and the fact that we're generating a new function and passing it to a pure component means that we are essentially negating all the benefits of extending pure component in the first place. First of all, in order to experience the problem, you have to get very, very specific and it's not easy to actually get into a point where the problem manifests itself. But then for the second part, fixing the problem is actually not tricky, so the way that you would fix this issue, there's a couple of ways to fix it. The most common way, I think to fix it would be to just say that pure component, let's just move that down one level and we'll put it inside the render method of the component that takes the render prop. The component that takes the render prop is no longer pure but the pure component has dropped down one level and we can still get all of the benefits of a pure component and again, its whole descendant tree lives underneath it. ROBERT: That make sense. MICHAEL: So, we can still get all the benefits of having a pure component, while still being able to use the pattern. But again, just getting back to what we were saying at the beginning. The render props is just one example of an advanced pattern that actually lets you delegate one of these three pieces to somewhere else. It's just one pattern. It's not like there are others as well. ROBERT: Yeah, so getting back to what is a component, is there ever a line that's drawn, like when does it stop becoming a component and it becomes something larger. MICHAEL: It's actually interesting because for a long time, we didn't have a component model on the web and I think -- ROBERT: It's very true. MICHAEL: -- still, like we mix to all three things together in our jQuery code. It was just like there was some state mixed in with some markup, mixed in with some behavior. It was all kind of mixed into one place. ROBERT: Nice plate of spaghetti. MICHAEL: Yeah, exactly. As soon React came along and actually gave us a real component model that really worked where we could actually identify these pieces, then all of a sudden, everything is a component and you really can make if you want, like if you really wanted to, you could make your entire application out of components. It could just even behavior stuff like, "I want to fetch some data," that could be a component or, "I want to listen to the window scroll or the window size," that could be another component. "I want to render an image or a bit of text or do some measuring or I want to do some parsing of some data or something like that," all of this stuff could be represented as components if you wanted it to. Of course, you can still extract those functions out into their own bag of utility methods and lots of times when I write a React Apple, I have a little bag of utils and I'll go and reach in there and grab those as I need them. But for the most part, most of my React apps are just components all the way down, so there's not much that I can't do with a component. The cool thing about that is what do you get when you have components, where you get reusability and sharability. I can make a component and I can just share it with you, Robert. I could say, "You want a component for listening to the windows size? Here you go. Here's the components. Got to render --" ROBERT: Drop it in. MICHAEL: "-- It will give you the size when you need it," so that ability to share code is, I think super important. ROBERT: Yeah, I think so too and it really helps you build applications rapidly because you can just start dropping these little components that are contained in composable throughout your entire app. I guess, I'm still clinging onto like there is maybe a line that is drawn and I think from the React community, there were a couple of terms coined called the container component and the presentational component, in which I immensely mapped those to basically being synonyms for controller and view. It's like the container components is kind of like a controller, like it delegates the view... Or decorates the view, not delegates. And the presentational component is just like we're talking earlier -- pure component. It's just taking props and rendering that. Is that fair to say? MICHAEL: Yeah. As far as I can tell, that's a pattern that was first talked about by the redux community, specifically I think Dan is the first to discuss that that pattern and it's a pattern that I think can work well. I haven't ever found it to be especially useful in my code but I can see how other people could like it for their code. I really just think it has to do with how your brain works. If you prefer structuring things like that, if you prefer like the vast majority of your components to just be these little view layers and then your main container components to hold all of the logic, I want fault you for that. I'd say, that's fine you can build your app like that. But I do think that when you're thinking about components like that, you are thinking about the much less like these miniature applications. Basically, in my opinion it's kind of a false separation. It's a separation that doesn't really need to exist because essentially, the thing that I really love about these components is you have encapsulation. You encapsulate everything. As soon as you adopt this pattern of containers and essentially, just these presentational leaf nodes, they're not as useful on their own. They just encapsulate some of the rendering logic. ROBERT: That's very true and they're not reusable. I mean, it's very, very hard to make those reusable. MICHAEL: Well, yeah. Most of the time, they're designed to be used with a very specific container. It is like, "Why couldn't we just put that in a container." Like I said, I really don't fault anybody for using them. It's just not how my brain works. I tend to think more about components as if they were these miniature applications and they're going to be useful on their own for the most part. One place where I have started to do that, the fourth thing that your components can encapsulate is style information, which is really just kind of the markup but it's the fourth thing and I think that I've really started to employ that kind of pattern when styling comes in. But it's not for this separation of containers and leaf nodes. It's just because I would like to encapsulate some of the styles down at a lower level or be able to reuse some of the styles down at a lower level, so that's when I'll typically start breaking up one of my components into multiple kind of tightly-coupled components but it's just for the sake of the styling, not really in any of the control flow or the logic. ROBERT: Right. When I first got into doing React, I was first like a little befuddled and then, I fell in love. I was like head over heels. When I hear about separation of concerns, it's always talked about like we need to separate HTML, JavaScript and CSS. They're all different things. They just need to be separate. I understand that. I kind of come from there but for me, my personal opinion is coming from the context of single-page apps, there is no feature that you can ship without the three. I don't think there is a complete feature that exists. Sure, there's edge cases that's like a blanket statement but I think those lines of separation is way more blurred these days and I think that's what React just unlocked. That's kind of where all of this is sort of rolling downhill and it's not a train. It's really powerful to be able to encapsulate all of those things together and then just think of your UI as these components. That's why we call them components. They componentized. Like when I have a butt-in and I drop it on the page, I don't want to have to go and make sure that I have the right class that's wired up in some other file. I can just drop the button in there and it's going to do its thing. I can pass the props, it'll change it, that's fine. It lives within itself. MICHAEL: Yeah, I would say you're absolutely right. You can't ship anything meaningful without having, at least some styling in there, unless you're shipping very, very basic behavioral style components. It's kind of one piece, I think like the React components are able to encapsulate their own styles but there's no, I guess officially recommended way to do it, which is where I think React get some of the critique, like some people come in and say like, "There are a million different ways to do styling in React and therefore, React is supposed to something like --" I guess, yeah, some of the other frontend frameworks have like, "This is how you do styling in our framework." ROBERT: Right, like the lack of convention. MICHAEL: Yeah, exactly. It's a blessing and a curse, though. If there's a lack of convention, it's harder for newcomers to know exactly what to do. ROBERT: Yeah, or like what's best for their use case. MICHAEL: Yeah, exactly but then on the other side, it's kind of a blessing because people are free to experiment and they don't have to feel like if they're experimenting, they're going sort of against the grain of what the community has already accepted to be the answer. I think that freedom to get out there and experiment is really valuable as well. ROBERT: You can see but I'm nodding. TARAS: I'm just curious what your thoughts were. This Suspense API is something that's... React kind of lead the way with components and now, the changes that are coming in with Suspense API coming in and it'd be great, if you can, are you able to explain a little bit about what it does for people that are not familiar and I'm curious what your thoughts about it. MICHAEL: Yeah, for sure. The Suspense API, I think is actually, with regards to what we've been talking about, with the encapsulation of markup, state and behavior and possibly styles, I think the Suspense API is kind of the React teams attempt to sort of encapsulate or generalize, at least one more thing, which is asynchronous behavior. The truth is, the most common async behavior that we know of, that most people are familiar with is a fetch, a data fetch -- you go and fetch some data. But there are others, there are things like loading of images and animations and navigation and things like that, where you have some time that passes in between when you initiate an operation and when you're actually able to render as a result of completing that operation. How do we manage or how do we generalize that and how do we think about it? The Suspense API is basically a way to declaratively say, "I need this async operation to be done." Let's just use the example of a fetch. I need this fetch. I need to have fetched this data in order to render this view and don't even attempt to render this view, unless the data has been fetched. Before the async API or Suspense, as they're calling it, you would basically have to manage this asynchronous behavior yourself. You would basically have to say, "Go and do the fetch," and while we're doing the fetch, maybe I'll set a loading flag in my state and say, "Loading is true," and then when the fetch gets back, I'll say, "Loading is false," and then I'll render. Maybe, while loading is true, I'll show like a spinner or some loading dots or something. What the Suspense API allows us to do or what they're hoping to do, again it's all very like... I don't know if I made this clear. It's still very, very, very, very early days for this API and I don't actually know when it'll be ready. But anyway, the idea is to be able to say -- ROBERT: Would you say the Suspense is killing the community? MICHAEL: The suspense around suspense. ROBERT: A terrible pun. MICHAEL: Anyway, the API is basically just a more declarative way to indicate where this asynchronous stuff is happening and give React sort of clues, if you will, to say, "There's some asynchronous stuff happening here, just so you know." That has many applications in the real world. Let's say for example, you were navigating in a master detail view and you're tapping down the master view and loading these detail views, if you tap a master view and you haven't yet loaded the information for the detail view, instead of sliding to the detail and showing the data still loading there in the detail view, you might want to show some sort of loading indicator while you're still in the master view. Then, if it's taking a while to load, they can actually select something else from the master view and in that case, you would cancel the old fetch and start another fetch. It's just supposed to make things like that, kind of feel a little bit more fluid and a little bit more intuitive to the programmer, so you don't have to think so hard about managing a lot of that complexity in your own head. ROBERT: Yeah. By the way, I love the mobile first language that you used. You tapped here, you tapped here, that slides in. MICHAEL: Yeah, for sure. It's all we're building these days. ROBERT: Yeah, it's very true. TARAS: It's interesting because the Suspense API, you wouldn't really imagine it to be within the scope of a view in a traditional sense, to [inaudible] but considering the scope of a component in React, it makes sense but I think people might not imagine as being something that would become part of core, potentially in React. I'm curious like what do you think other areas of React and I'm glad that the scope of components in React is so broad because it kind of opens up this question to be pretty much anything in React ecosystem. But is there an area of React building or the aspects of applications that you would like to see an improvement in or some kind of a change or something that hasn't seen the right amount of innovation in the same way that we've seen in other areas? MICHAEL: Basically, is there a place where I would like to see the React ecosystem improve? TARAS: Yes. MICHAEL: I know this goes kind of contrary to what I just said but I would like to see a little bit more cohesiveness. I feel like in some ways, the freedom is good but I also feel like in some ways, for the last couple of years, we've been just sort of like rehashing the exact same old problems again and again because React really made everything else so easy, like a lot of the stuff that was hard about building web apps, just got really easy when React came along. I'm not saying that because I have React training company. Of course, my livelihood right now depends on React but honestly, if it wasn't for React, I think I probably would have quit and done something else because it was actually getting really, really difficult for me. I was trying to build an app in Ember before I started with React and I just couldn't do it, you know? I just couldn't get the level of polish that I wanted in my app and get all the bugs out and get it working exactly how I want it to. It frustrated me, actually that I've spent a lot of time. I spent about 18 months, about $100,000 of my own money, just down the drain trying to build this app, trying to get it out the door and I wasn't able to finish it off. At the end of the day, I really started to question like, "Was it me? Do I just suck? Am I not a great developer? Is that the problem?" You really have to start asking ourselves hard questions like that when you put everything you have into something and it doesn't work out and then React came along and I was like, "I was just using the wrong tools." The tools were the problem. It wasn't me. There is a different way to think about this about building stuff. I thought the way that I was doing it was the only way that existed to build things but it turns out, it's not. I used to not understand what were people talking about when they were talking about functional programming or what do they talk about when they're talking about composition, solving problems with composition, instead of inheritance. I didn't even understand what that meant. But all I knew is really smart people would say stuff like that and I was like, "What are you talking about?" Now I feel like, because of React, I've gotten it. Again, to get back to your question, Taras, React made a lot of the stuff that we used to worry about, that we used to think about. It made it easy and so, we could build amazing things now a lot more easily. But now, for the last couple of years, I feel like we've just been sort of rehashing a lot of the same stuff. I would really like to see us, as a community sort of tackle the next level problems. I think the React Suspense stuff is definitely getting there. That's a problem that I really don't see anybody else sort of address, which is how do I make it easy to deal with the fact that applications by their nature -- these networked applications -- are asynchronous. How do I deal with that in a declarative way? That's why I'm encouraged by that work because I do think that it's kind of one of the more forward thinking things right now that's going on in the React community but I would like to see us in general, sort of like get past talking about styling and get past talking about service and rendering and move on. ROBERT: Right and I'm going to assume you have this really unique experience since you do a lot of trainings. I follow you on Twitter and it's just always talking about where you're flying to and who you're training, so the things have to come up there where you see these things in pattern over pattern over pattern. MICHAEL: Yeah, exactly. I see like a lot of and this again, gets back to Taras's question. I train a lot of people who are very new to React and I see people who are new to React, they really don't have a ton to go on besides just like blog posts and Medium pieces and podcast like this one and who am I? A lot of people in their React community don't even know or care who I am. It's like, "There's a guy out here who are saying stuff about React. Maybe I should listen to him. Maybe I should listen to somebody else," and it's confusing. It's confusing, I feel like, for people who are just getting into React. It's confusing. Like I said, experimentation is good but I guess, I wish the experience of coming to React was a little bit more like the experience of coming to Vue because -- ROBERT: Oh, like it was a beaten path. MICHAEL: Exactly. I don't actually think there's not a whole lot about the Vue technology that is compelling to me and let's not dig on it. It's just -- ROBERT: A personal preference? MICHAEL: Yeah, exactly, just preference but I do think the thing that is very compelling about the Vue experience is just the cohesiveness of it all. You go to Vue and there's like a way to do server-side rendering with data fetching and styling and -- ROBERT: They have a CLI and -- MICHAEL: And a CLI and a component and all these stuff. Yeah, and a router built right in. Anyway, I think that's a way that the React community could improve. I don't know if that'll ever happen because the React community at heart is artists and hackers and those people are traditionally very reluctant to be corralled and like I said, it's a blessing but I think from the perspective of people who are new to the community, it does tend to cause some confusion. TARAS: I want to add to what Michael is saying. What's interesting and I'm sure Michael sees this in his training but the kind of people that use React is very diverse. There's this kind of original group or there's kind of mentality that prompted the early adopters of React and now, we're seeing these companies that are traditionally enterprise-y with MSE backgrounds and coming into React. It's really interesting to see all this kind of worlds collide and then see what's happening as a result. It's definitely interesting on what's going on now. ROBERT: This is an excellent stopping point. I really agree. I come from Ember background so I would like to see a little bit more convention but I think it's okay. It would be nice to see that. Thank you, Michael for coming on. Is there anything that you would like to give a quick plug for and where people can reach you? MICHAEL: If you want to support the work we're doing, you can sign up for one of our upcoming workshops. We've got one right now on ReactTraining.com. We've got a workshop coming up, actually in my hometown of Carlsbad. You can come out here in July and hang out with us and do some React training. We got a really awesome host here who's right here in town. We're doing some React training workshops on July 25th through 27th, I think and then, other ways that you can support what we're doing is publish in all my open source code at GitHub.com/ReactTraining or you can follow us on Twitter at Twitter.com/ReactTraining or at my personal account at @MJackson -- Michael Jackson. ROBERT: Awesome. I really appreciate you taking the time to come on. MICHAEL: Yeah, thank you so much. It's been a pleasure. ROBERT: This is a great talk. Cool. Thank you everybody for listening. We are The Frontside and we build UI that you can stick your feature on. If you would like to give us feedback, you can always reach out to us on Twitter at @TheFrontside or you could email us at Contact@Frontside.io. We're always looking for any new topics or things you would like to talk about or things that are interesting to you. As always, thank you Mandy for producing our podcast. It's @therubyrep on Twitter and on June 28th, we're going to have Chris Martin on to discuss blockchain development.

Tracy Lee (@Ladyleet, Co-founder of This Dot, GDE, RxJS core team) and Ben Lesh (@benlesh, RxJS core team, Angular core team, Co-founder of This Dot) discuss Async React and the context API with... Michael Jackson (@mjackson, Founder of React Training, creator of unpkg) and Jay Phelps (@_jayphelps, RxJS core team, GDE, Chief Software Architect @ This Dot)   To learn more visit thisdot.co Follow us on Twitter @moderndotweb

John Lindquist, co-founder of egghead.io, interviews Michael Jackson, co-creator of the react-router library, and co-founder of React Training. Michael discusses his experiences with running a massively popular repo with a relatively small code-base, pioneering of new features, and the future of CDN based importing.Michael gets into the early days of the react-router repo, and what he had to do to steward the library. "In open-source, you are not just coding all day." It's mostly management, with it being a relatively small code-base that had a lot of users created a situation where you had to have excellent communication and a lot of deliberateness with what you change.React is just Javascript, meaning that it enables multiple solutions and allows innovation within the library. It also means that there will be some discourse in the direction that things should go. Michael also discusses how to keep an open dialogue with the React community, even though doing so may pose some challenges.Michael is extremely excited about the future of the CDN and unpkg. He says that it would be awesome if Facebook or Pinterest only needed to load the package once, or even if individual modules were loaded instead of entire libraries. unpkg is excellent and predictable. No need to read the documentation on how to include the library in your app. No need to worry about builds, webpack, bundling. It brings back a fresh perspective and lets you just use the web!Transcript"React Router with Michael Jackson" TranscriptResourcesReact TrainingunpkgMichael JacksonMedium BlogTwitterGitHubJohn LindquistTwitteregghead.ioGithubWebsite

Panel:  Charles Max Wood Guest: Nader Dabit This week on My JavaScript Story, Charles speaks with Nader Dabit. Nader is a familiar guest on JavaScript Jabber, talking about the state of React Native. Nader is the host of React Native Radio, another podcast on the Dev Chat TV network. Nader is a React Native trainer that does consulting and workshops in major cities in the US. Nader dives into his background and how he began his journey as a developer. Interestingly, Nader became successful as a developer without any formal training, but, by only learning to code on the job. This is a great episode to learn specific ways to build a career without formal training, and how to present yourself for the job. In particular, we dive pretty deep on: React Native Radio and the React Native world React Training and pop up workshops How Nader got into programming Learning HTML and Web Development E-commerce, WordPress Nader talks about getting his first job Positioning  yourself as a developer for success Specialization Presenting yourself for the job How Nader learn to do JavaScript Learning a viable option Ionic What is it about React Native that interest you? React Native In Action - Book! React Native Elements  Sharing Content and much, much more! Links:  React Native In Action reactnative.training https://github.com/react-native-training Ideas anyone? Picks Nader Audio Book- A Guide To the Good Life  Charles The Way of Kings Scratching your own itch!    

Panel:  Charles Max Wood Guest: Nader Dabit This week on My JavaScript Story, Charles speaks with Nader Dabit. Nader is a familiar guest on JavaScript Jabber, talking about the state of React Native. Nader is the host of React Native Radio, another podcast on the Dev Chat TV network. Nader is a React Native trainer that does consulting and workshops in major cities in the US. Nader dives into his background and how he began his journey as a developer. Interestingly, Nader became successful as a developer without any formal training, but, by only learning to code on the job. This is a great episode to learn specific ways to build a career without formal training, and how to present yourself for the job. In particular, we dive pretty deep on: React Native Radio and the React Native world React Training and pop up workshops How Nader got into programming Learning HTML and Web Development E-commerce, WordPress Nader talks about getting his first job Positioning  yourself as a developer for success Specialization Presenting yourself for the job How Nader learn to do JavaScript Learning a viable option Ionic What is it about React Native that interest you? React Native In Action - Book! React Native Elements  Sharing Content and much, much more! Links:  React Native In Action reactnative.training https://github.com/react-native-training Ideas anyone? Picks Nader Audio Book- A Guide To the Good Life  Charles The Way of Kings Scratching your own itch!    

Panel:  Charles Max Wood Guest: Nader Dabit This week on My JavaScript Story, Charles speaks with Nader Dabit. Nader is a familiar guest on JavaScript Jabber, talking about the state of React Native. Nader is the host of React Native Radio, another podcast on the Dev Chat TV network. Nader is a React Native trainer that does consulting and workshops in major cities in the US. Nader dives into his background and how he began his journey as a developer. Interestingly, Nader became successful as a developer without any formal training, but, by only learning to code on the job. This is a great episode to learn specific ways to build a career without formal training, and how to present yourself for the job. In particular, we dive pretty deep on: React Native Radio and the React Native world React Training and pop up workshops How Nader got into programming Learning HTML and Web Development E-commerce, WordPress Nader talks about getting his first job Positioning  yourself as a developer for success Specialization Presenting yourself for the job How Nader learn to do JavaScript Learning a viable option Ionic What is it about React Native that interest you? React Native In Action - Book! React Native Elements  Sharing Content and much, much more! Links:  React Native In Action reactnative.training https://github.com/react-native-training Ideas anyone? Picks Nader Audio Book- A Guide To the Good Life  Charles The Way of Kings Scratching your own itch!    

In this episode we learn about animating with JavaScript. We’re joined by a special guest, Sarah Drasner, who is an expert in JavaScript and SVG animations. Having good animations in your product is really important for the overall user experience. In the episode we discuss various libraries to help create animations in your websites or applications. Sarah shares a lot of valuable information. Items mentioned in the episode: Coin, GreenSock, Weighing SVG Animation Techniques (with Benchmarks), Mac Pro parallax, Mo.js, Lego Mushroom, SnapSvg, D3, Sara Soueidan, React Motion, Sarah Drasner's CodePen, Framer JS, React Training, A Comparison of Animation Technologies, SVGOMG, SVGO, IcoMoon Guests: Sarah Drasner - @sarah_edo Panelists: Ryan Burgess - @burgessdryan Augustus Yuan - @augburto Derrick Showers - @derrickshowers Sarah Federman - @sarah_federman Picks: Sarah Drasner - Val Head's book Sarah Drasner - Valio Con Ryan Burgess - Sleep no more Ryan Burgess - Internet trends 2016 Augustus Yuan - Jankfree.org Augustus Yuan - Icon System with SVG sprites Derrick Showers - how2 Derrick Showers - Werker Sarah Federman - Transitions and Animations in CSS Sarah Federman - Alexa / Pebble Core integration