Kent C. Dodds: 0:00 Hey, everyone. My name is Kent C. Dodds. I'm super excited to be joined by my friend, Michael Chan. Say hi, Michael.

Michael Chan: 0:06 Hey. How's it going?

Kent: 0:08 Good. You may have listened to the podcast already or maybe not. Michael is the interviewer or the host of the podcast. Now, I get to talk to Michael. I'm excited to just walk this around a little bit.

Michael: 0:22 It's good because I know that halfway through, you were like, "This feels a little bit uncomfortable like you're just asking me questions like over and over again." This is fun.

Kent: 0:31 Yeah. I wanted to [inaudible] remind a little bit. I'm glad that we get to do this.

Michael: 0:37 I'm happy to open it to you.

Kent: 0:39 Very good. Cool. Michael, with everybody that I talk with and I'm introducing them to the audience like we're buddies, I always like to go back and say, "I've known this person for X amount of time. Like, this is where we first met."

0:55 I think that the first time we met was at React Rally early or maybe it was React Conf, the second React Conference when I went to.

Michael: 1:04 I don't remember. Good question. I think that we were aware of each other probably via online, Twitter. I don't know. React Rally? Maybe, that seems weird.

Kent: 1:20 It was either one of those conferences, for sure.

Michael: 1:24 I don't remember a time meeting you.

Kent: 1:26 It's just like we knew each other. It's been a while. Maybe, five years or something like that, we've known each other for quite a while, maybe four. We were both into React the whole time, so React brought us together like so many of my friends.

1:50 [crosstalk]

Michael: 1:50 It did. It is one thing that I'm pleased about is that we we've met because of it.

Kent: 1:56 Exactly. Cool. Why don't you introduce yourself to us and let us get to know you a little bit and then we'll get to chat?

Michael: 2:05 My name is Michael Chan, and I go by Chantastic, just about everywhere. It's funny. You use your real name for your Moniker. I use a different one and I feel like I'm having a little bit of an identity crisis.

2:23 Some people will call me Michael and it sounds weird. Then, other people will call me Chantastic and it feels weird. I don't know. It's like split [inaudible] .

Kent: 2:31 I can relate to that because my middle initial, it's like branding, that is me. Even on my info page that I send to conferences, I say, "This is how you say my name and this is how you don't say my name. The C. is very important in there."

2:50 When I go to church or with my family or anybody outside of the tech world, to have them say Kent Dodds is so weird.

Michael: 2:59 Oh, for sure.

Kent: 3:00 It's like a rating. That's not how you're supposed to say it, but I know I'm wrong in thinking that.

Michael: 3:09 It's true. Kent C. Dodds, it's like all one word, right?

Kent: 3:12 Yeah, that's right.

Michael: 3:15 It's Kent C. Man, I was trying to think about how long I've been doing some type of programming now. It's been a while. Probably 15 years, maybe a little bit longer, I dabbled in some stuff.

3:37 I've been doing that. I started with PHP and all that stuff. I fell in love with CSS pretty early on, because it's weird. It's super weird, but I love how painfully declarative it is. Let's say painfully declarative. Again, I love how painfully declarative it is. For all its faults, it's my first love in web languages.

4:06 I fell in love with that front-end development after that. I wanted to get into products. JavaScript was taken off around the time that I was getting into programming languages.

4:21 JavaScript, React, after that. I press the advantage with early React and started making some React resources and host "React Podcast," which is my biggest non-work project today.

Kent: 4:42 If anybody listening who hasn't subscribed to React Podcast, I strongly advise, do that.

Michael: 4:49 Thank you.

Kent: 4:50 Even go back and start from the beginning. I've done this before, where a podcast...You have over 100. Maybe, 200 episodes, right?

Michael: 4:58 Yeah, over 100. We're getting close to 110 as of this recording right now.

Kent: 5:04 I've definitely jumped on podcast, when they were past 200 and listened to at all. This is definitely accomplishable for React Podcast and worthwhile.

Michael: 5:17 If you do listen, you'll hear Kent on there a couple times. Maybe, one of our first actual conversations was at react-reality. We're talking about your talk that year and what you've been learning about React. I think Downshift maybe was what you were working on at that time, maybe?

Kent: 5:36 Yeah, because I was speaking about, "Simply React" was the title of the talk and Downshift was where I learned all the things that I was teaching in that talk. Those good times. Definitely a good podcast. I want to make sure that you talk about React Christmas.

Michael: 5:56 Oh, right, yeah.

Kent: 5:58 There's another one that you've got about the fundamentals of React. I forget what it's called.

Michael: 6:04 I have a couple resources. One of the most popular is that React Patterns and it's basically a short, one paragraph of each pattern, like render props, higher order component, whatever.

6:18 That was like your Downshift experience. That was me trying to understand, what all of these things are and if I could write succinctly what it was, and how to use it in a paragraph and one snippet of code? There's that.

6:35 Then every year around Christmas time, I try to do an advent calendar. I think it's at react.holiday. I'll remember in December when it comes around again. It's a daily thing, and it's super fun. My goal last year was just to go from writing 30, or I guess, 25, 20 minute videos, and I wanted to cover all of the major stuff in React.

7:04 We start from how to render a div and get all the way to hooks and touching into non-suspense and error boundaries. I was just amazed at how much we can cover in just two minutes over 25 days.

7:19 I don't know, I just love boiling things down to just these tiny, tiny, tiny, little minuscule lessons. I don't know, that's neither here nor there, but coming up Christmas time, react.holiday.

Kent: 7:34 It's great, I love it. It's good to know you, Michael.

Michael: 7:40 Thank you.

Kent: 7:44 Actually, I don't think it was on your React Patterns thing. I think maybe this is something else, but I remember on one of the resources that you've got, you talked about how to make these components that encapsulate their styling properties.

8:03 In your example, you're using classes, just regular classes, and how that is a really nice abstraction for just...We talked about styled components, CSS, and JS, but all of that stuff is implementation detail. It doesn't matter whether you're using CSS and JS or regular classNames.

8:22 At the end of the day, I'm just using the component, and I just render that component. I expect that it will apply the right styles based on the props that I give it and whatever. Maybe the only difference here is that I have to make sure that the CSS is on the page, but in certain scenarios, that just happens naturally. It doesn't really matter what the implementation is.

8:46 Anyway, that really spoke to me. This was years ago that I remember seeing this sounds like, "Yeah, that totally makes sense. I'm on board with that idea." I'd love to just open up our conversation to have you talk about how you think about styling in a React application context.

Michael: 9:06 I think that resource might be learnreact.com. It's very out of date and I do plan on making it again, but yeah, it was my exploration of function components. The whole goal was to write components that, I guess, gave some type of API around how you would render a button. I think we focused on a button the whole time, "How you render a button?"

9:32 My goal was, at the end of it, to be able to switch out the implementation of whether it was going to be bootstrap or...I don't know. There's a ton of them now. Basically, be able to hot swap underneath the hood, what the implementation or the CSS styling implementation that these components were targeting?

9:55 To demonstrate, this is a really amazing way to encapsulate an API that you use everywhere, but then don't have to think about the styling underneath and...

Kent: 10:06 Money right there. That's good, this is good stuff. This is what we love about React is, how easy it makes doing that?

Michael: 10:14 Absolutely, and I think, at the time, I even use the word function components. I think now in React, they're just components, right? We're trying to get away with the notion that there was ever a class component.

Kent: 10:27 Yeah.

Michael: 10:29 For me, it was really fun to just explore the boundaries of these things. How you compose them together? How you think about them? Since the beginning, I've always done this really weird thing where I have a basic button implementation and I'll make...The API, I always say for this is the danger button or the success button or whatever.

10:54 I'll make those different components. I don't have one God object component ever that knows how to make all of these different types of buttons, and how the sizes are, and all that stuff.

11:06 I have always had just one basic button, applies basic styling, and then a bunch of other buttons that compose, or abstract over that, and compose with other notions of buttons. I don't know, we could talk about composition all day, but...

Kent: 11:26 Yeah, for real. There's composition of the components, and then there's composition of the hooks, and React is just a bucket of composition. I'd love to get into a little deeper into how you do this at scale at a company, where you have lots of engineers who...I mean, so many companies.

11:47 I've worked at four companies, maybe not so many, but pretty much every company that I've worked at did not have a great way to make sure that team X over here is building and working on these buttons that are consistent with our style.

12:08 Team Y over here, they're actually doing the exact same thing, making their own buttons that are still consistent. Then you look at them and they're, "That's not quite the same." They're doubling work and they're still not being successful at it. How do you avoid that problem at scale with styling components?

Michael: 12:29 I think about it almost completely opposite. I'm a little bit of a nihilist. I don't know if there's a term for me. Maybe a faithful nihilist or whatever, because I still believe in a God and that, but also I believe that things are maybe beyond repair in most cases.

12:54 That definitely plays out in the way that I think about code. One of the things that I have spent a lot of my career doing is exactly what you are talking about, in this space, where you have a lot of teams working autonomously building up different things.

13:14 There's always this notion that eventually, we can create some type of abstraction that is complete, and thorough, and just aggressively opinionated, so that everything will always look consistent and the same everywhere. I don't believe that's possible. I just don't believe in it. I don't think it's possible.

13:39 I have this, I don't know, maybe it's a personality disorder or whatever, but when I run up against a wall, my inclination naturally is to run in the exact opposite direction. I know that this thing is not possible. I know that we're never going to have perfect consistency.

13:55 That there is never going to be a perfect design system that can implement all of the nuances of what each page needs to do in every circumstance. For me, I like running opposite direction. For me, the question is, how can we do a really good job at exception handling?

14:14 How can we make systems that are able to...I guess, what's the best way to put it? How can we think about things in such a way that nothing is ever going to be consistent? How can we make it easier to get to consistency? Instead of thinking that one day, we're just going to bulldoze everything, over everything, and it'll be consistent.

14:38 You and I both know that, that's not the way the technology works. It's not the way the design works. Every year, there's some new hotness, some type of new thing that everyone's super excited about, and then we're like, "We're gonna rebuild everything with that." Now you have your app is always 50 pockets of differing technologies.

Kent: 14:56 We're going to build everything with that," yeah.

Michael: 15:00 The best example of this is you go to any of the major frameworks, like JavaScript frameworks websites, and you will see the same companies listed as users of that thing.

Kent: 15:13 That's true.

Michael: 15:16 I see this in a small way where all of the system that I work on is basically 10 discrete apps run by 10 different autonomous teams. What is it? They're all some mix of Rails and React. Some are like 99 percent React, others are 99 percent Rails.

15:42 I'm always fascinated in something that will...I have this belief that if we can build tools today that work with what we have today, and what we thought was the hotness 10 years ago, that those things will stand the test of time, and actually, move gracefully forward to the next 10 years.

16:04 I'm on those slow solutions. I'm not about whatever is hot on Hacker News right now. I want the slow, the standards. I love standards, like CSS, JavaScript, just the basics. I'm all about the...I don't know if I even said anything in that...

Kent: 16:22 Oh, no. It's...

Michael: 16:22 a mental mix of ideas.

Kent: 16:27 I see that, I guess a pessimistic view, or maybe a realistic view of the fact that we can't be 100 percent consistent. I understand why that is, but I would like to dig into that a little bit and maybe push back just a bit.

16:47 Let's assume that you're at a company and everybody's using React. Why couldn't I just build a button or a set of button components and then say, "Well, if you want to render a button, you've got to render this"? That would give me consistency.

17:03 This is where we get into having company component libraries and that sort of thing. What are some of the pitfalls that you see with just making a component library that everybody uses and how we're consistent?

Michael: 17:19 Something that I notice a lot is that we build a lot of these design systems, and these hard ideas around certain notions of user experiences and UIs that we'll be built with these things.

17:39 However, so often, these things get shifted just a little bit. Where, maybe use 16 pixels is your base font size for most of your UI, but then you have this one little sidebar thing and you don't want the whole thing to be 16 pixels. You just want it all squished out a little bit. That means that you put it in 14 pixels. Now that changes everything. Your avatars are going to change. Your inputs are going to change.

18:08 Everything shifts just a little bit. In order to make the design right, you have to break that system, or make a system that's effectively two systems anyway.

18:20 You have the system that's 16 pixels in a 14-pixel system. Then, when you have a larger thing, you got to have the 18-pixel version of all that stuff. All of your avatars are just an exponent of how many versions you have. I think that I identify as a designer.

18:39 There's a reason you go onto a Bootstrap site, and you're like, "Oh, this is a Bootstrap site." It was designed for internal tools. That's the reason that they made Bootstrap, was to make these internal tools. Internal tools are not polished bastions of beautiful design and user experience. They're very utilitarian. This is something that is not often considered in very opinionated design systems.

19:14 It's designed for some kind of beautiful mathematical working of exactly the font size that you're aware of. If you look at your personal home page for GitHub, you'll notice that most of it is set in a certain kind of font size. Then the side bars are a little bit different. It's a perfect example of these things where the whole UI adjusts a little bit.

19:38 For that reason, I don't think about a single design system. I think about atomic elements like components that can be anything and then having a number of systems that you would use, whether that be for a single view or a set of views or a collection of experiences.

20:03 These would have a system that's consistent for itself or consistent for a certain part of the UI, but that these things actually have a decoupled relationship with the actual atomic elements themselves. I don't know. I love CSS custom properties for this, but you could really achieve it in anything. As you said earlier, the browser doesn't care. Your users definitely don't care.

Kent: 20:32 Sure. I'd love to dig into several things like that. What's so hot about CSS custom properties as well as more taking a step back on what the heck even is a design system and a component library? In particular, what are you working on day-to-day to enable engineers to be effective with these things? Whichever one of those directions you want to [inaudible] on.

Michael: 21:01 Oh, my gosh. Let's see if we can knock some of those out because I feel like I've just blabbered on for a little bit. As a designer, it's super odd that design systems has been co-opted to mean React component libraries. I'm glad that you mentioned that.

21:24 Design systems are just everywhere. You could have design systems that mandate how architecture is done or print is done and all that. You can have a design system and no components and components and no design system.

21:43 Being able to separate the two can give us a little bit more freedom and being able to implement a design system for this kind of layout or for print or for our admin versus our user facing versus marketing. Having that separation of the notion of components and being able to place design systems onto them, if that makes sense, is a really powerful notion.

22:13 When you separate those two things, that's awesome. That's design systems versus component libraries.

Kent: 22:22 What's a deliverable? If I were to say, "OK, Michael. I am going to give you six weeks to go work on our design system," what do you give back to me when you're done?

Michael: 22:36 That's really interesting because a lot of times a design system will talk about some of those boundaries in the exception handling. You go say, "Hey, this usually presents like this. Our avatars are always 32 pixels by default." Then you have a situation where, just for the sake of example, you put it inside of an input. Now you don't have another size for that. What is this thing?

23:11 It's just something that's outside of your design system? Well, it might be outside of your component library. That might not have a solution for it yet.

23:19 Your design system should have considerations for that like, "Hey, in this type of environment where it's 14 pixels, we actually put these down a little bit," or "When you nest it inside of a button or an input, we actually have an exception for that and it should follow these guidelines in any time that it's one of these form elements," etc.

Kent: 23:43 A design system is like a document possibly with mockups of what the different types of user-interface problems people will face. When they face those problems, then they come to the design system to have some direction.

24:01 This is something that would be primarily used by designers or maybe component-library implementers to know, "OK, so I need to build this sort of layout. It's going to have these things. Let me grab some pieces from the design system, this document that maybe has some mockups so that I can promote consistency in our design."

Michael: 24:24 The beautiful thing about having that is that it can extend beyond your tooling. You might have an artifact of that design system that lives purely for Rails consumers or React consumers. They might be implemented with different technologies to optimize different user experiences.

24:48 Then having a separate thing that mandates how those things are handled allows you to have consistency in all of your artifacts, all of those implementations that you would have.

25:02 It's tough because a lot of times it is about exception handling. You can't just think long enough to manifest all of the exceptions. The exceptions come from actually building the product.

Kent: 25:17 Right. That's true. An exception is a thing that you weren't expecting, like it's by definition. That makes total sense.

Michael: 25:28 Otherwise, you'll exceed expectations.

Kent: 25:31 That's right. A design system is a living document. It's a thing that evolves over time as these exceptions come up so that you know more of those exceptions.

Michael: 25:43 To answer your earlier question, if you are at a company that's just using React, I think that these things do become one and the same. The concern that I have when I see them being conflated is that at some point, if your company has the privilege of being around for more than three years, there's going to be a next framework that your engineers are super excited about.

26:15 It will happen. There's going to be a next design phase that your designers are really excited about. When those things start to diverge and you mature as a company, and they will, you're going to have this question of, "OK. Do we rewrite the whole thing in React or in React-next placeholder for future framework?"

26:45 Also, do we remember why we have all of these conditionals and weird cases implemented in the code, but what was the reasoning for that? We know what it looks like, but why did we make those decisions? Being able to separate those is a long-term strategy. Maybe you'd want to be out of the game in three years, so "Yes. Do it in React. That's fine."

Kent: 27:08 Good point. Part of me feels like React is the last UI framework. We were tweeting about this.

Michael: 27:15 We did talk about this.

Kent: 27:18 For the benefit of those listening, I feel like React might be the last framework we need to know because, before it falls out of style, the computers will be doing everything for us.

Kent: 27:30 It will last long enough for the singularity.

Michael: 27:39 I do feel like React may be the...Maybe we have slightly different versions of what will inevitably happen. I do agree that we will get very quickly to a point where designers can work in some type of design tool and that will be good enough for the front end of the UI.

28:06 You can build it in a design tool and make your flows, make your designs, and all that kind of stuff, and then just dream-weaver that crap to the Web.

28:19 The job of engineers is going to change pretty significantly where I just don't know if we're going to have this division of UX, UI, front-end developer. I don't see a long-term future for all of those things being three distinct roles. Once you can commit code from a design tool, that's just one person now.

Kent: 28:45 Right. The real crux of it will be, "Can we get the computer to write the logic for us?" The GPT-3 thing where you just say, "I want this to do that."

Michael: 28:58 Yeah.

Kent: 28:58 Then it'll be a longer-term thing before the computer can make a design that we like. Maybe you'll still have designers where you can say, "Hey, AI. I want you to use these components and build this." I don't know. We'll see.

Michael: 29:15 We'll definitely get there. We need to be prepared for it. The takeaway is the same. I think that we generally agree that React may be the last thing whether it's AI, whether it's better design tooling. I don't see an area where there's going to be a new JavaScript framework. Maybe there's a Rust framework that we can write UI in, and it's amazing. I don't know.

29:48 I just don't see us writing another JavaScript framework that's significantly better than what we have right now.

Kent: 29:53 I don't know. I could just be blinded or in denial, but React is older than jQuery was when React was announced.

Michael: 30:02 That's true.

Kent: 30:03 It has some pretty solid steam power. Anyway...

30:08 You got the design system. That's not actually using any Web technologies to create that, right?

Michael: 30:15 Right.

Kent: 30:15 This is how we handle exceptions and whatever. When we go around to actually implementing this in a technology that can be consumable and actually built with, you probably want to avoid the situation where Team X and Team Y are both implementing the design system. You want to have some way to have Team Z be responsible for implementing this. Then Team X and Y can take advantage of that shared skill and code.

30:47 When I was at PayPal, this was the last thing that I worked on. It was getting them on track to actually implement our design system into something that was shared across teams, which is really surprising to me that it hadn't already happened.

31:05 I really fought for CSS in JS and was finally convinced that design systems or component libraries should actually be built on top of more generic technology, the standardized technology, just like regular classes and stuff. Technology, even in the last few years, has really evolved. The standards have evolved.

31:27 I'd love to hear your take on how we can leverage those standards to be really productive in building out these design systems.

Michael: 31:37 We might be just past our time, so I'll try to keep it brief.

Kent: 31:41 We're good. We're good.

Michael: 31:43 I really love standards. I know that they move super slow. A lot of times you have stuff that you want to do that's on the edge. I have always believed that, if you can come back and carve out the things that you don't need anymore and replace them with standards...

32:07 Where standards have come up, try to replace those pieces as you can as you're working on your tooling or frameworks and whatnot. A really interesting example of this is Theme UI. Mostly for performance reasons, they actually spit everything out as custom properties. This is a really interesting marriage of CSS and JS and using the standards of custom properties because it allows you to...

32:37 You're going to get these browser-performance tuning out of the box by using the standards. The browser is not concerned necessarily with your framework and the hottest hacker news project. It is concerned with making the standards wicked fast, like as fast as possible.

33:00 That is something to concern yourself with when you are thinking about React tools. Under the hood, is it honoring the standards that are at play? A lot of mature projects really try to do their best to acknowledge the standards and move to them as they can.

33:22 Now sometimes you end up having to cut out a lot of browser support. That limits the availability of these projects to you, but it's very much worth considering.

33:36 I think that, for those that have a long vision for the workability of their applications, standards are great because they go with you from framework to framework. Every day, I have to think about, "How can I provide the same tools to both React and Rails developers?

34:00 Something I love about standards is that they have no notion of either of those frameworks. That's actually a really good thing. The more that I can lean into those, the more both of those development environments will have consistency. Not consistency of design necessarily, but consistency of that underlying implementation.

34:22 As we make changes, we have more places that we can do that and offer that consistency and share those abstractions between sometimes super-disparate consumers.

34:34 I don't know. It's something that I'm super passionate about. There's a lot that we can do to make everybody happy. There's a part of me that believes that everyone can be opinionated and everyone can also be happy sharing stuff.

34:55 That's where I love standards for. OK, here's an area that moves slowly. This is something pretty much all Web developers agree on at this point. Maybe let's just use that.

Kent: 35:09 I hate to bring this up, but I know that somebody is thinking about Web components in this context.

Michael: 35:16 Yeah, yeah.

Kent: 35:18 Actually, are you OK with just a 30-second thing on how Web components plays into this?

Michael: 35:23 Oh, of course. Of course. I don't know.

Kent: 35:27 That's very honest.

Michael: 35:35 I think that for me, I wish that Web components and React got along better. I know the reasons that they don't. I wish that they did. It seems to be, as of right now, that Web components really don't necessarily have a future. I don't know. We could talk about all the reasons why the writing feels like it's on the wall or whatever.

36:03 I feel like React destroyed any interest in Web components.

Kent: 36:10 It certainly did for me. I have zero interest in Web components because I have React. Honestly, Web components never seemed like a good way to build a full application. That was my intuition. Then it was confirmed by the multiple companies that hired me to teach them React because Web components weren't working for them well.

Michael: 36:30 I would love for them to have been the way that we share atomic abstractions, right?

Kent: 36:39 Right.

Michael: 36:39 Because that would be amazing. That would be truly amazing to be able to build things that are browser-native and then build our applications in React. To have a standard for a component would be amazing. It just didn't really get there in the time before React ate its lunch.

Kent: 37:00 It's really unfortunate. I don't think that it's just because React doesn't work well with Web components. I think that there's a failing on Web components in the way that it was designed and implemented. Because of those failings, the React team just became disinterested in compatibility, which is a crying shame. It is what it is.

Michael: 37:28 It is.

Kent: 37:28 Michael, this has been a pleasure...

Michael: 37:30 Always.

Kent: 37:30 to chat with you as always. Thank you so much for giving me some of your time today.

37:35 Is there anything else that we didn't talk about that you want to just mention and throw out there really quick before we wrap up?

Michael: 37:41 No. That's pretty much it. I just hope that you can be happy in the work that you're doing. I recommend standards for that so much. I love them. Just embrace the CSS. Just love on it because it's so good. That's it.

Kent: 38:00 Cool. Do you have any resources for folks who want to do that embracing?

Michael: 38:06 Oh, gosh. If I was super smart and business-savvy, I would, but I don't.

Kent: 38:14 Well, that's all right. There's NDN.

Michael: 38:19 CSS-Tricks" is a real classic. Their flexing grid resources are amazing. NDN is an awesome resource. Between those, you'll be able to find a lot of what you need to know. There's a lot of really good resources out there.

38:40 It's mostly just about taking the time and desire to actually go and be like, "What are these custom properties? Now that I can use them, why should I care?"

Kent: 38:50 That sounds great. As the last thing really quick, if somebody wants to keep up with you and what you're up to, what's the best way for them to do that?

Michael: 39:02 I am @chantastic on GitHub, Twitter, whatever, Instagram I guess, though I don't even think I have it on my phone.

39:13 Those are the best places. I'm in that zone with you right now where I'm a little bit over Twitter. I'm thinking about doing a Discord thing, but again...

Kent: 39:24 Nah.

Michael: 39:24 those are just ideas. I don't have anything to pitch right now. I'd like to get off Twitter and just have reasonable conversations with people that I want to spend my day with.

Kent: 39:37 For real. That's why we're going to wrap this up and run over to your family and...

Michael: 39:43 Hey, thanks for having me on, Kent. This is always a pleasure.

Kent: 39:46 Likewise. Thank you. We'll see everybody around the Internet. Bye.