Storybook with Michael Chan

Episode Description

Michael Chan discusses Storybook, Chromatic, design systems vs. component libraries, React 18's gradual adoption, and navigating JavaScript hype cycles.

Episode Summary

In this episode, Michael Chan joins to discuss his role at Chromatic and breaks down how Storybook serves as both a development environment and a documentation and testing tool for UI components. He explains how Chromatic extends Storybook by providing visual regression testing in CI pipelines, comparing branch deploys to catch unintended UI changes across browsers. The conversation takes a meaningful detour into the distinction between design systems and component libraries, with Chan arguing that design systems govern an entire brand's visual language across all mediums, while component libraries are code artifacts that implement portions of that system. Using examples like McDonald's and Starbucks, the hosts illustrate how design consistency operates at a scale far beyond what most developers consider. The discussion then shifts to React 18, where Chan explains its gradual adoption strategy that allows developers to upgrade without immediately opting into concurrent features, and how the new createRoot API serves as the gateway to React 18's full capabilities. The episode closes with a broader conversation about JavaScript fatigue, framework identity, and the hype cycle, with all three hosts encouraging developers to evaluate tools based on personal need rather than social media pressure, suggesting small experiments like building a Wordle clone to genuinely assess new frameworks.

Chapters

00:00:00 - Introduction and Michael Chan's Role at Chromatic

The episode opens with some lighthearted banter before Anthony introduces Michael Chan, who works at Chromatic with the title of Community Engineer. Michael explains that Chromatic has a philosophy where everyone in any role maintains some level of engineering responsibility, which shapes how advocacy and community work function at the company.

Michael reflects on how his identity in the developer community shifted after React Podcast. Despite doing engineering, design systems, and front-end architecture work professionally, the community came to know him primarily as a podcaster and content creator. This realization led to his connection with Chromatic, which started with Storybook swag and turned into a role where he now produces content like the YouTube series Storytime with Fantastic, interviewing figures like Brad Frost and Tom Preston-Werner about design systems and tooling.

00:03:22 - Storybook 101 and Chromatic's Visual Regression Testing

Anthony steers the conversation toward explaining Storybook for listeners who may be unfamiliar, noting its importance within the Redwood framework. Michael describes Storybook as a tool for documenting, developing, and testing components in isolation, highlighting newer features like the built-in test runner that provides a GUI for React Testing Library. He admits he was a surface-level user before joining Chromatic and continues learning through the company's support rotation.

The discussion moves into Chromatic's core value proposition: visual regression testing that runs automatically in CI. Michael compares Chromatic's branch-based Storybook snapshots to Netlify's deploy previews, explaining how each pull request generates a visual diff against the last merged version. This allows teams to catch unintended UI changes across browsers without manually checking every component, offloading the cognitive burden of tracking how API changes ripple through a design system.

00:08:59 - Storybook as a Development Environment and Chromatic Hosting

Anthony shares his own experience discovering Storybook through Redwood, describing the moment of seeing all component states laid out visually as a revelation. Michael then explains Chromatic's hosting capabilities, noting that while Storybook can be deployed anywhere as a static build, Chromatic adds embeddable stories that can be integrated into tools like Zero Height, Notion, or InVision.

This leads into a discussion about Zero Height and similar platforms that approach design systems from a visual editing perspective rather than a code-first approach. Michael sets up the important distinction between these tools and Storybook, noting that Storybook's code-based approach provides version control, testability, and merge capabilities, while visual tools offer the freedom of what-you-see-is-what-you-get editing for broader design system documentation.

00:11:53 - Design Systems vs. Component Libraries

Michael carefully distinguishes design systems from component libraries, using McDonald's and Nike as examples of brands where design systems govern everything from billboards to mobile apps to business cards. He argues that engineers have co-opted the term "design systems" to mean component libraries, when in reality a component library is just one artifact governed by a broader design system.

Chris reinforces the point by describing how walking into a Starbucks in the UK, America, or Singapore produces the same experience down to the environment and feel. The hosts discuss how corporations invest heavily in subtle brand decisions like choosing the right shade of gray. Michael adds that design systems are aspirational, representing a standard that all products should eventually rise to meet, particularly relevant during company acquisitions where a new product must gradually align with the parent brand's design language.

00:18:54 - Practical Storybook Workflows and Progressive Enhancement

Chris raises the common developer concern of finding time to document and test components when shipping code is the priority. Michael responds by advocating for a top-down, progressive approach rather than the bottom-up component-first methodology typically associated with Storybook. He suggests starting with full page stories and then extracting individual components into their own stories as complexity grows organically.

Michael illustrates this with the example of a greeting component that might encounter edge cases like missing last names, emoji characters, or extremely long names. Chris candidly admits that only about ten percent of his components have proper stories and tests, describing how most developers code the golden path and move on. The conversation acknowledges this reality while emphasizing that incremental testing, even adding one story when a bug appears, builds a valuable safety net over time.

00:25:05 - Testing Philosophy and Storybook's Testing Continuum

Michael outlines where different testing tools fit in the development workflow, arguing that Jest snapshots of code are largely redundant given version control and that visual snapshots through Chromatic provide far more meaningful assurance. He positions Cypress as ideal for critical end-to-end flows like login and payment, while Storybook fills the middle ground of component-level visual testing.

The conversation explores the concept of "soft exceptions" in UI, where something technically works but looks bad. Michael describes using Storybook to document known visual issues that can't be fixed immediately but need tracking. He also highlights upcoming Storybook features in version 6.5, particularly play functions and Component Story Format 3, which allow developers to compose stories with async interactions, making form testing feel more natural and code-like than traditional beforeEach patterns.

00:31:44 - React 18 Release and Gradual Adoption Strategy

The conversation shifts to React 18's release, with Michael expressing surprise that it actually shipped after four years of development around concurrent features. He explains React 18's gradual adoption strategy, where installing the update without code changes runs everything in a compatibility mode identical to React 17, making it effectively non-breaking for existing applications.

Anthony and Michael walk through the technical details of the new createRoot API, which serves as the opt-in mechanism for concurrent rendering features. Michael mentions his egghead course covering migration pitfalls, including changes to state update flushing heuristics and the removal of the render callback. The discussion also touches on the React Working Group's concentric-circle approach to managing ecosystem changes, where core team decisions flow through library maintainers before reaching the broader community.

00:39:13 - Server Components, Framework Identity, and React's Maturity

Chris notes that React 18 feels like a "snooze fest" without flashy features, prompting a discussion about how frameworks like Next.js will likely surface React 18's capabilities to end users. Michael argues this represents a maturity in the React ecosystem where developers increasingly identify with their framework of choice rather than with React itself, comparing it to how Ruby developers identify with Rails rather than with Rack.

Anthony agrees with this take despite acknowledging its controversial nature. The hosts debate whether developers should identify as generalists or specialists, with Michael suggesting that being a "React developer" is now a generalization rather than a specialization. The real specializations, he argues, are in areas like React performance optimization, React Canvas rendering, or edge computing with frameworks like Hydrogen.

00:44:58 - Navigating JavaScript Hype Cycles and Developer Advocacy

The final segment addresses the constant churn of JavaScript tools and the pressure developers feel to adopt the latest technology. Chris points out that Gatsby still has valid use cases despite being "shamed upon" by the Twitter developer community, and that end customers rarely notice or care what framework powers their application.

Michael offers perspective on the attention economy around developer tools, noting that developer advocacy often works by making problems seem bigger and solutions easier than they are. He shares his personal approach of evaluating tools based on actual need, citing his decision to never use Redux because it didn't serve his use cases. Anthony recommends spending a few hours building a hello world with any tool that's been generating buzz for a year, while Michael suggests building something like Wordle as a more meaningful benchmark. The episode wraps with Michael inviting listeners to join the Discord community and stay focused on their own development goals rather than chasing trends.

Transcript

00:00:00 - Anthony Campolo

I've had a question for you, Michael, that involves Chris. How do we get his mic to not peak so much when he starts yelling?

00:00:05 - Michael Chan

Oh, man.

00:00:18 - Anthony Campolo

Michael Chan, welcome back to FSJam.

00:00:21 - Michael Chan

Hey, thanks for having me. It's good to be here.

00:00:22 - Anthony Campolo

Great to have you. We are going to be getting into Storybook and Chromatic because of your role there. Now, is your role a developer advocate for Chromatic?

00:00:31 - Michael Chan

Yeah. So Chromatic, we don't really have developer advocate roles. There's this really interesting philosophy that everyone in any role at Chromatic should be some level of engineer. I think as we grow, I'm sure that will change or adapt or whatever. So I think my official title, which I never use anywhere, is Developer Community Engineer, which is a mouthful. I know that Demetrius Clark has a really similar title at Netlify, so maybe it's gaining some traction. Who knows?

00:00:58 - Anthony Campolo

That's cool. So instead of just talking titles, why don't we talk responsibilities? What do you do day to day? What is a day in the life of Michael Chan like?

00:01:06 - Michael Chan

That's a really interesting question. Let's talk about things in the abstract for a second. There's this weird thing that kind of happened where React Podcast fell off a cliff for me in the time afterward. It was interesting because a lot of people's interest in me, when they were reaching out to me or interested in having me on their team, turned into more podcasting, media creation, dev-type stuff. And that was kind of a weird thing for me because, up to that point, I hadn't really thought of myself as a creator.

00:01:37 - Anthony Campolo

Which is hilarious to me. That's all I've ever seen you do. That's how I got to know you and why we even know each other in the first place.

00:01:45 - Michael Chan

It's so funny. I think we don't really have a good sense of who we are to the rest of the world. But I really did learn that through the last handful of years of React Podcast. You are what you show, at least to other people. If you're regularly showing something, that is how they're going to think of you. So while I was doing engineering, design systems, front end architecture, that was my work and I'd occasionally tweet about it. Really, what people knew me for doing was React Podcast.

00:02:09 - Michael Chan

That was really interesting when things kind of blew up at my previous job and did not end well. I think it started with swag. I saw some Storybook swag and I was like, that's a sick mask. I want to rock that Storybook mask. I reached out to Dom. He hooked me up with some swag and said, hey, if you're ever looking for work, we want you. All the stuff that you're doing, we want you to do it here.

00:02:37 - Michael Chan

So now it's kind of fun. What I'm doing at Chromatic right now is working on some of our external marketing programs, which is kind of the bucket that we've put all this stuff into. What that includes is a new YouTube series called Storytime with Fantastic. Once a month, I interview someone who is kind of related to Storybook or Chromatic at a company utilizing those things to build out teams or design systems. So once a month, I'll interview somebody in that space. I've talked with Brad Frost about Atomic Design, talked with Ryan Bohan from Shopify about how they're building their team and workflows around that for their design systems. I just recently talked with Tom Preston-Werner, who you know, obviously, from Redwood.

00:03:22 - Anthony Campolo

This is what I wanted to get into because people who listen to this podcast are usually at least somewhat familiar with Redwood. Not everyone, but it's a good assumption they've at least heard of it. And Storybook is a really key component of Redwood. We have invested very heavily in making Storybook part of the framework. So when you joined the team, I was like, great. I bet we're going to see Michael Chan now in the Redwood Storybook shared Slack, which has happened. I'd really love to get a description of what Storybook is. Then we can talk about how Chromatic relates to that, because using these two things apart can be a little challenging if people aren't already familiar with it. I would love to first start with a Storybook 101, and then we can talk about how Chromatic relates to that.

00:04:03 - Michael Chan

Oh, for sure. I appreciate you having me on to talk about this stuff. My manager will be extremely happy that we're answering these questions. I think something that I really love about my job is that I was a really bad user of Storybook. I used Storybook and Chromatic, but in the most surface-level possible way you could use both of them. I felt pretty good about myself for just having even done it at all. But literally, every day I'm learning stuff. And because we're such a small team at Chromatic, everybody takes a turn on the support rotation. So once a week, we're hanging out in support and answering questions for people. I swear, I feel like the biggest Storybook and Chromatic noob every day that I have to do that because I'm like, I didn't even know they did this. I didn't know it did that. I can't believe it did this all the time. I wasted so much time trying to do this the other way.

00:04:53 - Michael Chan

So it's a very eye-opening experience. Holy shit. I hope I can say that on this show.

00:04:59 - Anthony Campolo

Oh yeah, let him fly.

00:05:01 - Michael Chan

Let him fly.

00:05:01 - Anthony Campolo

We had kids on not too long ago.

00:05:03 - Michael Chan

So perfect. I was just like, oh man, I'm learning so much. But the separation is interesting. Storybook itself is a way for you to document and test components. Now, I actually think that it's a really great development environment too, and we can talk about that later. But the idea is that you'd be able to develop in an environment, and in so doing, you would also be able to document your components. By developing in this environment, you're also documenting various states that you might be concerned with in that component. And then there are various layers of testing integration that you can choose to opt into after that.

00:05:49 - Michael Chan

Right now, they've actually done a ton of work to introduce a test runner. Now you can actually run your Jest test suite on your UI components inside of Storybook and see a lot of that stuff happen in real time. There's some really cool integrations there, and that's really awesome. So if you're used to using Testing Library or React Testing Library, you now have what we like to call a GUI for React Testing Library.

00:06:09 - Michael Chan

So you can actually see this stuff almost like Cypress, where you can see it play out on your components inside of Storybook. Super cool stuff there. Now, the way that I think about Chromatic, there's a whole bundle of features that Chromatic offers, but I see Chromatic as being another piece of that testing idea. Storybook kind of brings you up to a certain point and drops you off at Chromatic. So Chromatic is this really killer integration that by default, if you were just to install Chromatic, add it to your CI pipeline, and not do anything else, what you get is this really cool visual regression testing on your Storybook.

00:06:51 - Michael Chan

I think a lot of people are really familiar with Netlify branch deploys now. So you put up a branch, open up a PR, it'll deploy that branch. You can preview all the stuff that is different in there. Chromatic does something really similar where every time you open up a pull request or a branch or whatever, it's going to run that version of your Storybook. It's going to create that version of Storybook and deploy it to the cloud somewhere. So you can look at that Storybook, just isolated in time. But then also it's going to compare it to the last Storybook that you actually merged, which is really cool.

00:07:24 - Michael Chan

So you have a Storybook, maybe it's for your design system. That's version one. You want to make sure that nothing changes. You can make additions, but nothing breaks after. That's kind of the public API of those components. You code along, you start adding some features, and then along the way, Chromatic CI is running in the background, running these visual diffs against your Storybooks. For each branch you see green, everything is good. You know that everything's fine. You can merge it, at least for as much as you've tested it. But then you'll get these diffs saying, oh, hey, this story changed. Did you intend to change that? If so, you can update the snapshot and then we can merge it.

00:08:05 - Michael Chan

It's really cool. It's taken so much of that. I know the reason this was such an unlock for me doing front end architecture and design systems was that I didn't have to think about all of those things that were in my brain, like, okay, if we change this API, then this component over here is going to break. If we change this for this app, then this app over here is going to break as well. And so being able to have all that stored away in this thing, I was able to unload so much off my mind and be like, hey, if the test passed, then that's great. If we ship something and the tests said they were green, it means that we haven't tested it thoroughly enough.

00:08:38 - Michael Chan

That kind of stuff is great. And it also took away all that browser testing stuff because we support all the major browsers. Honestly, Chromatic is like a godsend.

00:08:48 - Michael Chan

A lot of people complain about Storybook just being a gallery of components. You're like, oh yeah, why would I do Storybook? I can just make a new route in Astro or whatever, and that's my design system. And it's like, yeah, totally, you can. But that doesn't opt you into Chromatic, which offloads all of the historical UI decisions that we've ever made across all of the browsers.

00:08:59 - Anthony Campolo

Yeah, I want to interject with a couple descriptions. I think that might be useful for people who have never used Storybook because this is one of those things that is a very difficult topic for podcasts. This is a highly visual tool. The first time that I used it, I remember I was in a Redwood app and you run a Redwood command. What it does is, in addition to your front end being run on port 8910, you get a whole separate port running this thing called Storybook. And Storybook is a bit like a code editor in that it has a dropdown on the left with files and components, and you can go see those in their different places.

00:09:39 - Anthony Campolo

And with Redwood, this is great because Redwood has this concept called a cell, which is a way to declaratively state whether your component is loading or empty or has a failure state or a success state. You can click through each of those and just see them. So if you're creating a loading spinner, you can just see that loading spinner. If you want to see what your failure looks like, then you can just go check your error message and things like that.

00:09:59 - Anthony Campolo

I remember the first time I used it, the way I described it is I felt like Wizard of Oz. I was like Dorothy stepping out and all of a sudden everything is in color because I could see all of my components and they were just all there. It was a revelation for me because I'd been doing all these weird hacks to test these components in these different states, and it was such a hassle. And then once I realized, okay, that's why this thing was invented. But then, as you're saying, once you have that, the downstream effect is you also can then build this whole test suite around it. So I think that now has become a really sophisticated system that can do a lot. And I know you've also called Chromatic Storybook for the cloud, so it hosts things as well. Is that true?

00:10:45 - Michael Chan

So that's actually one of the most, if you think about features of Chromatic as a train of things that you would want to unlock, I guess the first thing is that it's actually a really great way to host a Storybook. When you install Storybook, there's that build Storybook command, and you can use that to create a static artifact that you can put anywhere. Netlify, Vercel, throw it on an AWS S3 bucket, wherever you want to put it. You can put it. But you get a lot of cool things when you use Chromatic. The biggest thing is embeds. This is actually one of the coolest unlocks for me.

00:11:20 - Michael Chan

If you're doing a design system, which I think Storybook is used a lot for, like design systems and component libraries, you can now take that. And now every story is embeddable. So if you use something like Zero Height, which is a little bit more for strictly design systems.

00:11:38 - Anthony Campolo

I have no idea what that is.

00:11:39 - Michael Chan

Okay. There's a handful of tools. I think InVision has some. Zero Height has some tools that are designed for creating a design system, but not a component library. If this makes sense, I know that this line is very thin for people.

00:11:53 - Anthony Campolo

Yeah, you're going to have to define those two terms and the difference. I know people have heard both of those terms and I'm sure have a wide range of ideas of what those mean.

00:12:01 - Michael Chan

Yeah. So let's take a second and split those up. Design systems are a little bit more wide-reaching. The whole notion of a design system is that you would have a single language that is adapted to multiple platforms, like a single design language that's adjusted to multiple platforms. So think McDonald's. McDonald's has a wide breadth of things that it needs to consider. It needs to consider billboards. It needs to consider mobile advertisements. It's also going to have some print menus. It's going to have some displayed menus both outdoors and indoors. And all of these have very slightly different disciplines: mobile app, website, all kinds of stuff. They're all over the place. Nike, think about these big brands that are just everywhere.

00:12:48 - Michael Chan

Maybe they have a movie trailer ad. All of these are going to have different constraints, but the design system should be in place to govern the things that don't change and allow for breakages on those various constraints. It's not at all tied to a single medium. It's the whole brand, the brand as a whole. What do business cards look like? It's a much broader thing.

00:13:02 - Michael Chan

Now, we as engineers think that everything relates to exactly the one thing that we care about. So when we hear design systems, we think about components and the components that we're implementing. So we've effectively co-opted design systems on the web to mean component libraries that implement design systems. That's kind of an important separation when you think about some of the tools in this space. A design system is not a component library. A component library is an artifact governed by a design system, typically.

00:13:37 - Michael Chan

And that's going to scale. If you're running a startup, they're probably going to be indistinguishable because what you're focused on is the web or a mobile app. It's just going to be, you know, maybe you're sharing componentry across those two and your design system really is components. But at some point, as you grow, so too does the design system separate from a component library. And it's important to keep those two things separated.

00:13:59 - Michael Chan

Now tools like Zero Height and InVision think about it a little bit more like Notion or Figma where you're making changes visually inside the tool. You're actually making changes. You might change copy or some rules, or you might change a screenshot of this thing, but it's a little bit more screenshot-driven to describe the constraints of your design system. Storybook takes the completely opposite approach, where it focuses specifically on engineers. It's all based on components. If you want to commit a text change, you literally have to commit it in git. There's not a way for a PM to come in and change the things unless they have git access.

00:14:41 - Michael Chan

The benefit you get from that is that it's testable. You have strict versions. You can merge and reverse things. So the two tools kind of live in the same world, but there's not a lot of connective tissue because one set of things you really want to have versions and mergeability and control over how things are managed technically. And then on the other side, you want the freedom of just running in and changing text the way you would in a what-you-see-is-what-you-get type of editor.

00:14:58 - Michael Chan

So the cool thing is that if you have a hosted Chromatic, you can actually embed your stories, which are versioned and from code, into tools like Zero Height, Notion, or InVision where you're communicating the broader concept of your design system.

00:15:21 - Christopher Burns

I think this is actually really interesting because as a developer, sometimes it's so binary, ones and zeros. But I know that I'm from the UK, you're from America, and we could both walk into a McDonald's or a Starbucks in each country and know exactly what to order and have zero problems ordering it because everything is identical. When you're a big corporation, and especially with things like design systems, when you say to somebody, oh, make a PowerPoint, you're not making a PowerPoint from scratch. There's templates, there's documentation, there's certain font choices, certain colors allowed, certain colors not allowed. All these things have been built over a long time to make a visual representation. And I think the biggest way developers see this, and it sounds so bad to say, is when a big corporate company says, we've created our own font.

00:16:07 - Christopher Burns

That's the only way a developer ever goes, why have they created their own font? What's wrong with San Francisco? It's because to the company, it's about that branding, that familiarity built over decades and years and years and years.

00:16:27 - Christopher Burns

As I said, you're in America, I'm in England, and walking into a Starbucks, they literally look exactly the same at this point. You would think, surely they wouldn't. You're thinking, yeah, but America is a very different country. And this is just two Western countries. I'm sure if we walked into a Starbucks in Thailand or Singapore, it would still look exactly the same and work exactly the same down to their technology. This aspect of the world has been built for so long. That underlying brand recognition, down to colors, even environments, and how a Starbucks makes you feel and how Starbucks is different to Dunkin' Donuts. If you remove the logos, you have different feels in both of them without even looking at the logo or the coffee. They just feel differently. That's what design systems have done to the world. But that's what I mean when I think developers, as you were saying, it's very like a design system is just components and some colors, but it's not a lot of the bigger world.

00:17:27 - Christopher Burns

It's like there are people that spend a lot of time and money creating corporate brands. When I say corporate brands, I more mean that corporations normally have the money to invest thousands of dollars in which color of gray is better. You know, which one represents my company better?

00:17:44 - Michael Chan

Yeah, and I think that that's a really interesting point. An example that I like to use a lot of times is an acquisition. Let's say Starbucks, since we're talking about Starbucks, acquires a smaller coffee roaster or something. That coffee roaster has its own brand, its own design language, etc. Ultimately, what Starbucks is going to do is some kind of migration into all of the Starbucks-ification of that brand.

00:18:17 - Michael Chan

One thing that I really like about design systems is that they're almost aspirational. At least when they're done right, they're done aspirationally. The idea is that this is the line and everything should rise up to this line eventually. So if you're a tech company, you do an acquisition. That product should eventually come into adherence with this thing. Now you might have a component library that, in the interim, looks exactly like the other thing. So you have that connective tissue of the components and you're building up your whole library. So eventually you can move it into adherence with this design system.

00:18:37 - Michael Chan

But I do feel like separating the notion of design systems and component libraries for engineers is very valuable. If people take one thing away from this episode, it's that design systems and component libraries are not the same thing, and it's a good thing.

00:18:54 - Christopher Burns

Very much so. And I think one of the biggest things that I find really hard, this is where you may really be able to help, is I'm already spending all of my time trying to just get the code out. How do I have time to start documenting how the colors should look or the fonts we should choose? Surely just getting it out the door is better than spending all day setting up Storybook. So how has Storybook made that easier? How do people get into it easier and not feel like it's a chore and that thing they have to keep updating?

00:19:24 - Michael Chan

Yeah, I love this question so much because I think it is a little bit of a mindset shift for me. I am a strong proponent of progressive enhancement, and there's the web version of progressive enhancement, but just the philosophy of progressive enhancement. We're going to get something out there, and that is the most important thing. Make it work. Make it right. Make it fast. That's kind of the process in which we work in web development. I really like this. For me, getting that page up is the most important thing. If it's messy, if it's all over the place, who gives a shit? What matters is that it's out now.

00:20:06 - Michael Chan

I think that Storybook is actually really well positioned to do this type of workflow. And I think up to this point, the communication around Storybook has really been about design systems and component libraries and working from the bottom up, making sure that you have a strong base foundation of components and then building your app up from there. I actually don't think that's the way that engineers work. I think it's the way the designers work, but it's not the way that engineers work. We get it out there and then we backfill things as we need.

00:20:42 - Michael Chan

So Storybook is really well positioned to do application-first type of development where you might develop a whole page. Then as parts of that page grow in complexity, you start pulling those out and testing them in isolation. I actually really like this breadth-first model of testing in Storybook, where you do a full page separated from data and enforce that really good interface of props, making sure that it all works. You go into the app, you connect it into your GraphQL query or however, and then the page works and then things start getting a little more complicated.

00:21:10 - Michael Chan

So let's say maybe you have something simple like greeting a person by their name. There's a lot of layers of complexity just in putting text on the page. Maybe you truncate first and last name, but the person hasn't put a last name, and you have some stray comma. Maybe they don't have a name at all, and so it just says, hello, comma, space, exclamation point. You didn't account for that. Maybe they used an emoji and you don't actually properly encode the emoji. Or if they have a really long name and it just gets truncated instead of wrapping the way you want on mobile.

00:21:54 - Michael Chan

There's so many issues that you may want to solve specific to a component. Now you can actually have that core view still in Storybook, but then pull out this greeting component and make cases for every single thing that you care about. Long name, short name, emoji, no name, right to left, whatever you want. You can build out these stories for that component as the complexity rises up in your app.

00:22:01 - Michael Chan

Instead of trying to do the design way of thinking about all of the possible things that could happen in the universe up front and then delivering that to an engineer as an artifact that covers everything. Because we know it never does. There's always something to fix. So I actually really like that workflow where you start at a page and then can pull components out into their own component stories as the complexity grows for those individual pieces.

00:22:27 - Christopher Burns

I find that preaching these kind of things, I don't want to come on here and preach like I'm the world's best developer at doing all these things because I am not. If I was to describe my workflow, I'm very lucky to use Redwood that has Storybook, mock tests, and unit tests all built in. How many of my components and web pages and things actually have them? Probably about 10%.

00:23:06 - Christopher Burns

And the simple answer is, well, half the time I've built the component plus the logic plus the styles in the web page and then gone, that's good enough, and moved on. I've never then put it into Storybook or written a proper story. And it's those extra steps that I always think to myself, how could I increase stability of my application? It's not to go start writing loads of new code. It's to start updating your Storybook, start updating your mocks, your unit tests. And the thing that gets me is it's really hard because how often does the golden path happen for web developers? We'd like to think it happens 90% of the time and no one ever sees an error message or a null, or it just completely crashes.

00:24:00 - Christopher Burns

So often. And look, I hold up my hand and say this all the time: I code the golden path and go, that's good enough. I can move on to the next task. I've tested it, it works, good job. And then one of your customers has literally WWE chair-slammed the submit button 20 times and completely broke it. You never wrote any tests, and what they're seeing now is like the Wild West. I always find it a really hard question in my brain: how can I make it easier to say, just write a small test? Because to me, it's like as soon as I go, I need to write a Storybook test, a unit test, a Cypress test, all of these things, it's like, whoa, that's too much. I've got this next task to do. You know what I mean?

00:24:28 - Michael Chan

No, I totally agree. And I think that for me it's about knowing the continuum of these things. I think as engineers we don't like to do things more than once. You want to solve it once and for all. And I think that we have a really good strategy for managing that in terms of unit tests because I think unit tests are the easiest thing to write. It's a way to check the box, but it's not particularly effective. Unit tests are brittle and whatever. We all know that unit tests are not the best way to test software.

00:25:05 - Michael Chan

However, as the world goes more and more into UI, I think that we need to develop better hygiene for testing things and understanding where the various tools begin and end. Just like they have this idea of snapshots, but it's a snapshot of the code, which is hilarious to me.

00:25:15 - Anthony Campolo

Isn't that what version control is for?

00:25:18 - Michael Chan

Right, exactly. I know the code changed. I saw it in the diff already. Well, I guess this is the thing that makes it to the browser, but that's not useful because the thing is that Internet Explorer renders different than Safari, which renders different than Chrome. I need to know that it didn't change in any of those browsers. I need to know that the user sees the same thing. I can't tell from the code if this component actually even legitimately rendered or not.

00:25:52 - Michael Chan

I think that anything that you're doing in snapshots in Jest right now, that's probably something that you should be doing inside of Storybook, in my opinion. And then also, yeah, there's going to be Cypress stuff, testing your happy path, making sure that a user can log in and pay you. That's great stuff to have in an end-to-end test suite like Cypress. Can they log in? Can they pay? Honestly, for me, those are the only two tests that I really care about in Cypress.

00:26:23 - Michael Chan

And I feel like what we're exploring in Storybook is this idea that maybe you can write tests for UI only once. I get this bug, I know the UI is bad, I fix it, but then I put a test case in there so I know I don't have to fix it again. And so when my Chromatic runs in CI, I have the confidence, this wall at my back of tests. I know that I already solved that, so if something else happens, this is kind of a new use case. I've been thinking about this language. I think UI is kind of fun because, unlike various other forms of testing, there's this soft exception that you can have in UI where it works, but it looks bad.

00:27:03 - Michael Chan

And something that I like about Storybook is being able to add tests to things that work but look bad. It breaks up that flow a little bit of, hey, here's an extreme case where this view totally breaks down. I'm going to put it in there because we've had a user report for it. I can't fix it right now, but at some point I'm going to come back to that and make this view look better. I already have all of the criteria set up for it. Those kinds of things are really fascinating, and I really hope to explore some of that as I help teach people that Storybook really isn't just for design systems and component libraries anymore. I think we're missing the boat on pages and flows, and even component libraries. I think there's a lot that we can gain from a Storybook and Chromatic setup.

00:27:25 - Christopher Burns

It's great to know I'm not the only one that finds these things daunting. It's not that we shouldn't do them, it's that it's okay not to do 100%. And it's about incremental. I always like to think that I'm like a pottery person when I write code. What are they called? I have no clue, and I've never made a pot before. But you start with a lump of clay and you're molding it and it takes time. The first mold doesn't look like what it's meant to be, but then as you spend more time, it gets more to the point where now all the logic works, i.e. it looks like a mug, and that's when you paint it. And the painting is making it pretty.

00:28:07 - Christopher Burns

I think the perfect example of this is when you need to build something. How often do you build things? Let's take a form, for example. Every company probably has a button component and an input component, but how much time do you spend actually thinking, I'm just going to use the default button first just to test the onClick. It all works with the default button, the default input, and then you style it to the company's button and the company's way of doing things. You know, I think it's such an interesting way. I feel like nobody talks about this, but I feel like I'm the only person that feels like they're shaping their code as they're going along. It's just not defined at the beginning. You're just working your way up instead of going top-down, UI first and then logic second.

00:28:50 - Michael Chan

Yeah, no, I think that's really important because I think that so many times we get in this mindset of, I want to do it once and I want to get it right the first time, and I feel like that's the wrong way to do it. You actually get a lot of benefit if you just open your mind to doing it twice and saying, okay, I'm going to do it twice right now and know that that's actually the way that I ensure never thinking about this problem again. I'm bad at it too. When I was running React Podcast, every one of the 123 episodes was me doing it once. I had no process in place. I was just running and gunning and getting an episode out every time.

00:29:24 - Michael Chan

And so as I've kind of matured a little bit, I have realized that I need to be okay with everything being a two-step process. I'm going to do it, and I'm going to document it for later. So the next time I can actually run through it and stop running around with, why does it take so long to do every episode? Every one of these 123 episodes has been the same level of pain. And it's because I didn't take that second step of saying, okay, this is the last time I think about this, right? This is the last time I do this without some kind of checklist.

00:29:49 - Michael Chan

And I don't know, it's hard. I don't think we necessarily like to work that way, but man, the benefits. It's ridiculous, I think. Anthony, you were talking about this the other day. It's like spaced repetition. That's the way to learn anything. If you're dedicated to it, you can learn anything that way. Do people do it? No.

00:30:11 - Anthony Campolo

Yeah. I went on a whole rant about spaced repetition. It's the only learning method that there's science behind saying, if you do this, you will learn things. That sounds like a nice deal. But like you said, it takes discipline because it's a technique that involves, it's like flashcards done systematically. This is how I would describe it. But I want to get to some other topics here. So are there any last things about Chromatic or Storybook that you think people should have an eye on?

00:30:37 - Michael Chan

Yeah, so I think 6.5 is a really cool release. There's a lot of cool stuff in the pipeline, but two things are really worth keeping an eye out for. The Test Runner allows you to actually, again, we think about this as a GUI for Testing Library. So if you're doing a lot of this testing, like putting something in the DOM, even if it's like JSDOM, some kind of virtual DOM, and then running tests on it, you can do that in Storybook. Super cool. Just reusing the tests that you already have written.

00:31:09 - Michael Chan

But beyond that is this idea of play functions. Play functions are freaking sick. It's a way that you can compose stories. I'll just use an example. I can write stories now where I have an empty form, and then I have a filled-in form, and then a filled form. With play functions and Component Story Format 3, I can take that empty form and then spread it out over the other tests and just add my async commands to add the input data. It's almost like beforeEach, except I get to spread the beforeEach state into each of them. I love it. It feels so much more like code than beforeEach and creating tests like that. Love it. It's the best.

00:31:38 - Michael Chan

Anyway, that's it. Those are my two things on what to look for in Storybook.

00:31:44 - Anthony Campolo

I would love to talk about React 18. How do you feel about React 18 being out?

00:31:49 - Michael Chan

Honestly, I saw that it was announced yesterday and I was actually kind of surprised. It's been four years that we've been talking about concurrent mode or concurrent features, all that kind of stuff. And I don't mean to laugh. I understand it's hard work. This is a totally new paradigm. I'm just laughing because in JavaScript years, that is eons. It is such a long amount of time. And so it felt surreal to be like, oh wow, 18 is actually out. Not 18 beta, 18 RC. 18 is on npm. That is nuts, just because it took so much work to get here.

00:32:28 - Michael Chan

I'm super excited about that. I think what is going to happen is that, unlike hooks where everyone could just start using hooks on day one, this is not going to be a thing where people can start using this on day one. You can in little ways, but it's really going to depend on a lot of the downstream libraries and integrations adopting this to where you actually see the benefit of this and be able to opt in in your own code.

00:32:46 - Anthony Campolo

Okay. Well, let's say I don't want to take your advice at all. I go upgrade my app right now to React 18. What should I do and how is it going to break?

00:32:54 - Michael Chan

Okay, cool, cool, cool. Great question. Here's the thing. It won't actually. And this is maybe the coolest thing. They have this gradual adoption strategy for React 18, and it's honestly glorious. It's my absolute favorite thing that the React team has ever done. I think that it is why this release took so much time. You can today install React 18, not change any code, and it will run the same. It'll actually run the same way, which is really freaking cool.

00:33:22 - Anthony Campolo

So it's a semver lie then? It's a bump in the major version without actually introducing breaking changes.

00:33:28 - Michael Chan

Okay, I think that I might be wrong. There might be. There are a couple of heuristic changes.

00:33:32 - Anthony Campolo

So I know that there's the difference in how the actual root DOM renders, and there's a slight syntax change. So will it give me a warning if I don't have that syntax change?

00:33:43 - Michael Chan

Yeah. So what you're going to get is, if you run it on 18, you're going to get a warning in the console in development mode that says, hey, you're running this in basically a compatibility mode. Do you remember when maybe IE9 had an IE7 compatibility mode and you could turn it on and it just used the IE7 renderer?

00:34:00 - Anthony Campolo

I've never developed for IE. I used IE as a small child.

00:34:04 - Michael Chan

I think I'm showing my age right now. Chris, do you remember that?

00:34:07 - Christopher Burns

I'm the youngest one here. I'm only 25, so it shows my age even worse.

00:34:15 - Michael Chan

This is old guy web developer stuff.

00:34:16 - Anthony Campolo

I remember using IE plenty of times. I was not a web developer at the time.

00:34:21 - Michael Chan

Effectively, it uses a compatibility mode. So it basically just runs exactly the same as 17, which is great because it means that you can gradually step into this. You can upgrade to 18 without having to think about concurrent features at all, which is great.

00:34:41 - Michael Chan

Now there is this new root API change. There's the legacy root API, which I can't even remember what it's called. Is it createRoot or, no, render? It's just ReactDOM.render, right?

00:34:47 - Anthony Campolo

Yeah. And you can import the render function and then you don't have to write ReactDOM.render. That's the real pro move right there.

00:34:53 - Michael Chan

Yeah, exactly. So as of 18, that's called the legacy root API. That is the way that you effectively use 17-style rendering inside of React 18. So that's why if you don't change anything, everything should work exactly the way that it has in the past. My understanding is that if it doesn't, then it's a bug. Now, if you want to opt in to the React 18 concurrent rendering and all of the things that will break because of that, you change that from ReactDOM.render to the createRoot API, which now splits out the root creation from the DOM element and then the rendering to that. So you do ReactDOM.createRoot, you give it the element that you want, like the DOM element, document.getElementById or whatever.

00:35:40 - Anthony Campolo

And I do have a tutorial for this actually that I wrote when you first dropped the beta, so that'll be linked in the show notes as well if people want to check that out.

00:35:47 - Michael Chan

Cool. Yeah. And I guess if we're talking about tutorials too, I have a little egghead course on migrating a React app to React 18, and it covers pretty much all of the pitfalls. When you actually do enable that new root, all of the APIs that actually did change, the hook heuristics that changed, some of the kind of weird class things that you need to know about, all based on how updates get flushed to the DOM and compensating for some of those new changes.

00:36:16 - Michael Chan

So yeah, I can link to that as well. That's basically it. A couple of state update and DOM flushing heuristics changed, so you do need to compensate for those. I know that the render callback is no longer in existence, so if you use that third argument to ReactDOM.render, you have some other things that you need to do now. And there's a myriad of examples that exist on the internet that you could draw from.

00:36:38 - Michael Chan

Which kind of brings me back to the React Working Group. I feel like the React Working Group represents React learning how to manage an open source project in concentric circles. React core team has kind of always worked in the Facebook ecosystem and then ad hoc, through the React repo, gotten feedback from people or these secret channels that various people have been a part of in the past to be like, hey, we're floating this idea.

00:37:01 - Anthony Campolo

Yeah. There haven't been very clear mechanisms in RFCs and the kind of things you would expect from an actual open source project.

00:37:08 - Michael Chan

Right, exactly. So one of the really cool things about the React Working Group, they've basically developed a format for talking about pretty big changes with the ecosystem. It's about concentric circles. So you have React core and Facebook, and they're building all this stuff. Then they float this idea to the working group and say, hey, these are the APIs that we're super interested in adding. This is the way that we've implemented it, knowing the stuff that we know.

00:37:42 - Michael Chan

But then also there's a gazillion people who use Redux, there's a gazillion people who use Apollo. Do these APIs work for your libraries and map to the way that we need to think about them? And then it's a closed group of people that represent a number of those big open source libraries or education programs and all that kind of stuff.

00:37:54 - Anthony Campolo

Yeah, like Mark from Redux is in there. And are there people from things like Next or Gatsby?

00:38:01 - Michael Chan

Yeah. There's a lot of representation from a lot, particularly Next, because I know they have ongoing meetings with the Next and Google folks around features in Next, because it's the 900-pound gorilla in the front-end React website-building space.

00:38:19 - Anthony Campolo

Is there anyone from Remix in the working group?

00:38:22 - Michael Chan

Good question. I don't have a strong memory of all the people that are in there right now. It's been growing consistently.

00:38:28 - Anthony Campolo

If you want anyone from Redwood to be there, just let us know.

00:38:31 - Michael Chan

Yeah, for sure. I don't have any control over who does that.

00:38:35 - Anthony Campolo

Yeah, I'm totally messing with you. I'm not putting you on the spot, so don't even worry about it.

00:38:40 - Michael Chan

But yeah, it's a really cool program because it limits the surface area of points of connection. So then it's like, okay, these are people who represent these various open source groups, and then they take that messaging and talk with their communities about what this would mean for them, how they adopt it, how they bring it into the library, how they adapt to these new changes. And then from there it goes out into the broader community at large. I think it's just a really cool way to do it. I've been really impressed with the way that they've done it. I think it mitigated a lot of frustration that could have been seen this week. I really appreciate it.

00:39:13 - Christopher Burns

There's tons of questions I have about React 18, and I probably should have read more than one article about React 18 to this point. Every time I've read an article or tried to read an article about React 18, it feels like a snooze fest to me. What's the flashy thing? There's nothing flashy. It's just loads of background things. And everyone's been talking about this concurrent mode for years. What's the update with it, and really, what is it?

00:39:41 - Anthony Campolo

I mean, I'm curious about server components because I feel like server components is the closest thing to a big flashy feature that has supposedly been enabled by all this stuff. So are server components enabled now?

00:39:50 - Christopher Burns

It feels like we're much more just going to see something like Next.js take the flashy component of React 18 and be like, this is our thing. We've worked so hard on doing this.

00:40:02 - Michael Chan

Yeah, I think that is an interesting feeling, and I think that a lot of people feel that way. I think it represents a little bit of a maturity of where we're at as a React community. Our focus now more is in what frameworks are delivering to us, right? Like what Redwood's providing us over Next or what Remix is providing us over Gatsby. We're thinking about it from a layer up. And I think that's actually an interesting place to be.

00:40:33 - Michael Chan

I really like the idea of thinking about, okay, I understand that React is the tool with which I want to author my components. So almost like a language for combining style, interaction, and markup. But really, the thing that I interact with, the thing that actually provides me the most value as a business or a company, is actually the framework level and the integrations that it provides. For me, I think it's actually a good thing that this release of React is boring because I think that it demonstrates a maturity of the distributions of React and an acknowledgment that people are actually getting more value from those frameworks, almost like an intermediary.

00:41:11 - Michael Chan

I almost see it like, and now I'm going to use another old guy analogy, but basically, Rails is the thing that gained a lot of traction in the Ruby community for building websites. But a lot of it was built on this thing called Rack. There's this other tool in the middle that actually makes all of the HTTP stuff easy. And then also there's other stuff. Like ActiveRecord is, in my opinion, really the crown jewel of Rails. That's the thing that makes Rails, Rails. And I think that that is maybe a better analogy. I feel like people will naturally care less about React unless you're a framework author or a component library author. People actually building things are going to identify more as Remix developers or Redwood developers over time, and less as React developers.

00:41:57 - Anthony Campolo

This is such a controversial take, but I completely agree with you. Some people are extremely anti what you just said, but I agree. I think this is absolutely the direction all of this should go.

00:42:06 - Christopher Burns

And I was going to say, no breaking changes? I've got to do something to keep me in a job.

00:42:11 - Michael Chan

That's where the frameworks are at right now, right? If you want to live on the edge, Remix. That's where I'd go if I want the rush of things rapidly changing all the time.

00:42:21 - Anthony Campolo

Well, you'll never run out of things to do. Let me tell you exactly.

00:42:25 - Christopher Burns

You know, working in a big corporation, you think, hmm, how can I keep myself in a job for six months? Maybe it's adding React Suspense to every single component.

00:42:35 - Michael Chan

Yeah, totally. You know, it's so funny. It is controversial from this side. If you come from the side of wanting to diminish people for trying to build things and have some kind of bar, oh, you have to know at least all of these things if you want to be considered a web developer. I think that's bullshit, right? If you look at history, people just don't identify as PHP developers. It's like Laravel or WordPress.

00:43:03 - Anthony Campolo

Yeah. And this is my take and why I think this is a controversial take. People say you should identify as a JavaScript developer or you should identify as a software engineer. You shouldn't have any specialty at all. I think actually when you're boots on the ground and you're trying to get a job, I think that's terrible advice. That's really bad advice to give beginners. I think that if you specialize in React, you're going to get a job a lot faster. And if you're a junior dev who says, I'm a software engineer, and they're like, well, what do you do? Like, oh, I engineer software.

00:43:34 - Michael Chan

Honestly, I feel like it's almost admitting that being a React developer is no longer a specialization. The specialization of being a React developer is going to be either, like, oh, I'm really good with frameworks, or I'm really good at React performance optimization, or I'm really good at React to Canvas, or alternative uses of React, like React Three.js or something like that. Those are specializations. Being a React developer is a generalization at this point, as far as I'm concerned.

00:44:07 - Anthony Campolo

Yeah. We had a Hydrogen episode and running React on the edge is an example of the specialization now.

00:44:13 - Michael Chan

Totally, yeah.

00:44:14 - Christopher Burns

And it's that thing of, like, the front end is now such a weird area because we're seeing React in the back end. That totally just goes to the client. We've seen React in the front end. We're seeing front end being split up into a back end and a front end. I think the biggest thing about it is that there's no one title to truly define what you are because we all like to say our strongest points. Someone's strongest point could be Redux front to back, and they would own me every single time on creating this everything Redux. But that's still technically a React developer, if you really want to use that analogy. Or someone who can make really good UI in React is completely different.

00:44:58 - Christopher Burns

And then it's the thing of like maybe we all should just go back to we're just JavaScript engineers, TypeScript engineers. Everyone likes to use those two words. Are we even engineers? I don't know, but we kind of call ourselves that these days because it's cooler than a developer now.

00:45:13 - Christopher Burns

I think the hard thing about it all is knowing where we sit in our abilities and where we do really well because the floor is forever changing. It's so easy to look at articles about X and think I should be using X instead of Y. What's wrong with Y? Nothing. It's just X is now better.

00:45:35 - Christopher Burns

This is actually a really good example. All three of us are going to Remix Conf. Someone said to me, why are you going to Remix Conf? You don't do Remix. I was like, yet. I'm not dying on any hill here. Redwood, Next.js, Remix, they're all really good at their given use cases. You should never feel shamed for not using one of them or the other. People that use Gatsby today, there are still really good use cases for Gatsby, but now Gatsby is shamed upon. You're a bad developer, you guys. But no, Gatsby is still really, really good. You're going to build a blog? Probably easier to build in Gatsby than even Next.

00:46:09 - Christopher Burns

It's just, you know, we live in these Twitter spheres. It used to be, React is everything. Next.js is currently everything. Oh, why are you even coding React? Everyone's talking about Solid right now. We should all move to Solid tomorrow. And it's that thing of, like, Solid is pretty good, don't get me wrong. But what we got over here is still good enough. And do our end customers really care what it's built in? Can they really even tell? Can they tell a Bootstrap 3 dashboard from the current best Tailwind design that you can find? I think the answer is sadly, no.

00:46:43 - Michael Chan

Yeah. And it's interesting because what we do, especially you talk about Twitter factoring into this, there's an interesting thing happening right now where there's a lot of developer advocacy. The way that you sell stuff is to make the problem seem really big and the solution sound really easy, and for your thing to be the clear solution in any given department. That's it. You make the problem big, you make the solution easy, and whatever.

00:47:15 - Michael Chan

I think that we have a lot of people right now in this space. We have this rapidly developing space of content creation around coding libraries, whether that be someone who's just spitting out memes on a Twitter account or people doing YouTube videos all the time on Svelte. There's this cycle, and it's not really designed to help anyone solve problems. It's just designed to get you to think that you should use this other thing. It's all very attention-grabbing.

00:47:37 - Michael Chan

And I don't know. It is where we're at. I think that for the person who is able to hold on to what they're actually in this industry for, the more the merrier. I want to have people who are excited about this technology that I am moving into and have some path laid out in front of me. But if you are insecure about your own vision for yourself, there are any number of people who want to give you a hit of whatever they're trying to get rid of. I don't know. I definitely think that it takes a level of confidence to operate in this industry right now.

00:48:08 - Michael Chan

I've never used Redux, and it's because I never had an opportunity to. In evaluating it, I knew I didn't need it in the things that I was using, so I've never used it. So that whole hype cycle of, oh yeah, it's the greatest thing ever, like, oh, now we all hate it, and now it finally has some kind of general utility that people loosely understand, I avoided the whole thing just because it didn't serve me.

00:48:31 - Michael Chan

And so I feel like knowing where you're headed makes it a lot easier to pass all of the hawkers trying to get a piece of your wallet.

00:48:47 - Christopher Burns

I think it's really hard to know what to jump on and what to not. For example, you've just said to me, React 18, there's no breaking changes. So you could just stick on what you're doing on 17. So when's the point that you go, yeah, maybe I should start using Suspense? That may not be in some companies until a year or two from now because it just doesn't make sense to spend the time if it is such a barrier that, I don't know, it just may not be the right time.

00:49:19 - Christopher Burns

And I think it's always that thing of, like, we get so caught up on, it's been out a day and someone with 200,000 Twitter followers has said, I converted my whole application in four hours. This is the best thing in the world, and it's like, I need to go do that.

00:49:27 - Michael Chan

Yeah, no, I mean, I don't think you do. If you want to, cool. I don't think it'll be painful for you. But generally in my profession, I go to where the money's at or where I think the money's going to be. There's no value to you to upgrade to React 18 for shits and giggles. Do it when your framework adopts it or when the framework has fully tested it out. That's when you're like, oh, okay, cool. Yeah. I guess it's maybe my time to do it. Or when a library you have has a new feature and it only works on React 18, it's like, okay, cool. I guess that's the thing. Look for the carrots. Chase the carrots and avoid the sticks.

00:50:02 - Christopher Burns

To take your analogy further, do things with the least resistance, and sometimes the least resistance is just waiting. We've seen that with hooks. I remember when hooks first came out, everyone was like, I'm going to build 20,000 hooks myself. Two years later, pretty much hardly anyone builds a hook and they just use someone else's that's on npm.

00:50:23 - Anthony Campolo

I mean, even worse, imagine you used Snowpack. Snowpack doesn't exist anymore. There are people who spent two years building stuff with Snowpack. The tool is dead. It's effectively over. So waiting can definitely be a virtue. I think just experimenting with the tools, like I always say, if there's any tool you've been hearing about for like a year, cordon off a couple hours in a single day to just do a hello world with it. You don't have to migrate your entire app. Be like, all right, I get it. I understand why people are talking about it. I can see why it has these kinds of use cases. That helps you break through the hype cycle and be like, let me just at least understand this myself so I don't have to just keep going by proxy of other people's opinions of this thing.

00:51:07 - Anthony Campolo

That's where we really get into trouble here, is that everyone just says, well, this person said this about this, so it means that this is good for this. It's like, well, okay, have you done that though? And that really goes a long way.

00:51:12 - Michael Chan

Having those types of projects, what you believe is kind of like a hello world for you, I think that's a really important thing. For me, I have this idea that I work with for myself, which is just like, what's the time to first fetch in evaluating a front-end library?

00:51:27 - Anthony Campolo

That's a good one. That's a very good hello world. Yeah.

00:51:30 - Michael Chan

Thank you. How many concepts do I need to know in order to make a fetch request and then spit out a list with also an error state in case that thing goes wrong and then maybe a spinner or two? There's a lot of information just in that tiny thing. I use a free API. Everybody now uses a Pokedex or whatever. You can find something about beer or dogs if you prefer to think about beer or dogs while you're doing this kind of thing.

00:51:59 - Michael Chan

But then there's also things that are a level up. I think Wordle is such a beautiful, isolated little build-it-and-learn-about-a-framework type of thing. If you see a new front end framework you're interested in and build Wordle in it, damn, there's a lot that you can take away from that experience.

00:52:14 - Anthony Campolo

Yeah, or even tic-tac-toe.

00:52:16 - Michael Chan

Tic-tac-toe.

00:52:16 - Anthony Campolo

A game is actually a hello world that goes far beyond a website. Hello world website, hello world can be pretty dang simple. So yeah.

00:52:24 - Christopher Burns

I was just going to say my final joke, and this is why I'm at least waiting five years to learn about Bitcoin. It could all be over by then. We'll see.

00:52:37 - Anthony Campolo

We also didn't get to hit on the inevitable and eventual return of React Podcast, which I'm sure will be a thing at some point, or Launch Dev or any of that kind of stuff. But those are topics for your eventual third appearance. So thank you so much.

00:52:49 - Michael Chan

Michael Chan was all business today.

00:52:50 - Anthony Campolo

This has been a really fantastic conversation. Any final parting words for the listeners?

00:52:57 - Michael Chan

I guess just, yeah. If you want to hang out with some awesome people and not get distracted by all the shiny things and kind of keep on what your goal is, I think our Discord community is a really great place to do that. Discord dev. Yeah, that's it. Find me on Twitter. I hang out there too.

00:53:15 - Anthony Campolo

Awesome. Thank you, man.

00:53:16 - Michael Chan

Yeah. Thank you.

00:53:48 - Christopher Burns

Wow. Next time I speak to you, you'll probably find out if I have legs or not. Yeah, at Remix.

00:53:55 - Anthony Campolo

You had no legs this whole time.

00:53:57 - Michael Chan

No leg. I know that.