Kent C. Dodds: 0:00 Hi, everyone. My name is Kent C. Dodds, and I'm super excited to be joined by my friend, Monica Powell. Say hi, Monica.

Monica Powell: 0:06 Hello, everyone.

Kent: 0:08 Monica and I don't go back super far. I think the first time we ever interacted, actually, was...Was it 2017, Christmastime?

Monica: 0:19 Yeah.

Kent: 0:19 I did this thing where I was gifting some egghead subscriptions to folks, and you picked one up. Now, you're an egghead. You've done a bunch of stuff with egghead now. Why don't you introduce yourself to us a little bit? Let us get to know you and then we can carry on.

Monica: 0:38 OK. Hi, I'm Monica. I'm a software engineer who develops using a lot of React. I actually founded a meetup, React Ladies, for women and non-binary React developers in the New York City area. I try to be involved in the React community, both within New York but also beyond.

0:57 I'm also being active going to conferences, speaking at conferences, as well as being active within different communities. In particular, I am very interested in JAMstack. A lot of the React frameworks like Next and Gatsby are things that are top of mind for me.

Kent: 1:18 That's awesome. I'm always impressed by people who coordinate -- what's the word I'm looking for -- like people coming together, meet-ups or whatever. I think that is just a noble calling. It's something that where the skills required to do it are totally unrelated to the skill set required to do the job, so it's like a whole extra level of stuff that you have to learn how to do.

1:48 What's that been like for you? I mean, there's the pandemic, which probably changed everything.

Monica: 1:53 Yes.

Kent: 1:54 How has it been organizing these meetings and connecting people in an actual real good way?

Monica: 2:07 I would say in terms of organizing React Ladies, I had this idea that I wanted to bring together a group of people who are also interested in React and learning React. For me, I put the idea out there, created a meet-up group, and on meet-up, they announced when you create a group to people who they think are going to be interested in joining.

2:29 As soon as I made that decision, then there were hundreds of people joining my group. I'm thinking in my head, how am I going to execute an event, I don't have any place to host this event. I was able to post some feelers on the meet-up group, and then someone raised their hand and said that their company will be excited to host.

2:52 For me, putting it out there was a big part of getting started, and not getting too wrapped up into the...How do I pick a date if I don't have a venue and just trying to get the ball rolling. In terms of the events that I've hosted, it's been popular to have like, Lightning Talks where people get to hear from a lot of different speakers.

3:16 I feel that can bring in people who have a variety of interests, as opposed to limiting the evening to one or two particular topics.

Kent: 3:28 I think that's a great insight. When you have lots of different topics, then even after the meet-up, I imagine people are...Their interest is piqued on at least one of those things, so they can talk with each other about those different things. You have more speakers who are asked questions and things like that after the meet-up.

3:49 That makes a lot of sense to me, and I like that a lot. I always personally enjoy the shorter, more succinct, I guess, talks. That's cool and really inspiring. I'm sure we could dive in a lot deeper on how you just jumped in, without having everything planned because I think that's fascinating.

4:14 I did want to ask you about some of your expertise on the server-side rendering side of things.

4:20 I can't remember if you said this before after we started recording, but you mentioned to me that you've been doing a lot of Next.js and Gatsby. For those who don't know, you also gave a talk at React Rally this year about server-side rendering. You're steeped into it.

4:39 I'm curious, where does your interest lie on server-side rendering? Why are you so into it? Why do you think that other people should give it some time as well?

Monica: 4:49 Yes. I would say in terms of someone who hosts their own website, I'm interested in Ssrver-side rendering, at least within the static context, because it makes it super cheap for my purposes to host a website. Until recently, I was able to host a lot of different static websites that were being generated within the server for free.

5:13 Now I'm pushing into the tier where I'm starting to have to pay a nominal cost. But for me, it's been made it very accessible to start hosting for a fraction of what you would need to pay if you were hosting, for example, WordPress website, where you need to manage your own database hosting.

5:33 I would say that's been my interest personally. Then professionally, knowing what are the benefits of server-side rendering. There's benefits in terms of SEO and being able to load content to users more quickly.

5:49 One of the projects that I was working at at a former company was actually converting an MVP Create React Application to something that had server-side rendering. There were a lot of conversations that were happening about SEO. How can we optimize generating a lot of different versions of the website ahead of time?

6:15 Having to think more strategically about how data is being handled, in order to have a better experience for more users, was something that came up for me as I started learning more about server-side rendering, and how it's important in marketing context, especially.

Kent: 6:36 On the personal aspect of all this, I love how accessible platforms for creating our own content are these days, like Netlify, or Vercel. There's so many places you can just, "I now have something on the World Wide Web."

6:56 That's one of the things that really got me excited about building websites, too. When I was doing Java, I could give my mom this executable or this jar or something, like, "Here, I made this thing for you." She has no idea. I say, "No, no, go to this URL," and boom, there it is. It's very cool.

Monica: 7:16 Yeah, it is nice.

Kent: 7:17 I'm very impressed that you've reached the tier where you actually have to start paying. You're getting a lot of traffic. That's awesome.

Monica: 7:26 Thanks.

Kent: 7:26 Then on the professional side, there are a lot of benefits to server-side rendering. You mentioned SEO. Why is SEO a benefit to server-side rendering? What can you tell us about that aspect?

Monica: 7:40 If you have an application that only has client-side rendering, and you actually looked within the DOM, the HTML is very bare bones, in terms of you pretty much see the ID of the element where the JavaScript and the actual content is going to be injected.

8:00 Whereas when you have a server-side rendered application, you will actually see the majority of the content that an end user would see once the page is fully loaded should appear within the server-side rendered page. There's a lot more actual content that's relevant.

8:18 If you're going to, say, Wikipedia, it's not super relevant if you see this empty div. You want to know, "OK, where can I get more information about a particular person or something within this website?" Making it easy for Google to find that information is a benefit of server-side rendering.

8:42 Google's like Web crawlers. They're looking at the website and seeing all of the content that's there, and seeing which links are there, and navigating to the website that way. Traditionally, Google actually did not support JavaScript further when they're doing Web crawling.

9:01 Now there is JavaScript support, but I do know people who are big on SEO thing, that there's still a penalty to requiring the Google Web crawlers to have JavaScript enabled in order to navigate across your website. Then also, with static websites, you can generate, I don't know, 5,000 pages of data that is going to be a lot more surfaceable within search results.

9:38 If you're looking for the top 10 events in New York, if that is already in a statically-generated page on a website, that's going to come up to Google clearly, versus if you have to go to the website and search for the top 10 events in New York, or wherever, in order to actually see those results.

10:03 It helps if there's certain information that a website wants to definitely be indexed on Google, to have it statically-generated.

10:14 There can be additional content that a user has to actually manually search for that isn't indexed with Google, but definitely takes some strategy to determine what content you want to surface to search engines, versus just having available for users on-demand.

Kent: 10:34 That makes total sense. It's really awesome that we have technologies like React now, where this is very easy. I know that the new Angular can do this now. AngularJS, this was just not a thing that people did. That's awesome.

10:53 I may have put the cart before the horse a little bit. For some people who aren't familiar with the pendulum swing, from everything was server, then now it's all client, and now we're going back to server, do you want to explain, what's the difference between client-side rendering and server-side rendering?

Monica: 11:10 Yes. In terms of the difference between client-side rendering and server-side rendering. Client-side rendering, which I had started to mention earlier, is you will initially render in a browser a HTML document that has very little content. Then you'll have an ID to an element where the actual JavaScript is supposed to append to and hydrate the application.

11:43 If you had a Create React Application, all of the React code would find that specific div and then load. Then as it loads, the actual content in the page becomes visible. When you first see the page, especially depending on your Internet connection, you'll probably see a flash of a white screen.

12:04 If you, for some reason, don't have JavaScript enabled, you'll see a message saying, "You need to have JavaScript enabled to see this page." Even if you have the page open for 10 minutes, if you don't have JavaScript enabled, then nothing is ever going to load.

12:21 Then for server-side rendering in the React context, as a developer, you would write the website code using React. You would have to have some type of logic that is converting your React code into HTML. The React API has a ReactDOMServer API that is actually responsible for converting React into HTML.

12:53 If you look under the hood of frameworks like Next.js or Gatsby, they're using the ReactDOM APIs within a node server to convert your React into HTML. If someone is also doing their own server-side rendering for React, they're probably using ReactDOM server. Potentially, if they feel that they have a better algorithm, they could do it themselves.

13:21 At least within the Gatsby context or with Next, there's two different ways that you can do server-side rendering. If you're doing the static pre-rendering version, you would have it so once you finish writing your React, you would build the website. As the website is built, that's when everything is converted into HTML upfront.

13:50 Then when someone goes to the browser, the initial HTML that is coming back from the server, or potentially from a CDN is as full of an HTML page as possible. For a lot of sites, if you have server-side rendering and JavaScript is disabled, the website should look very similar to if JavaScript was enabled.

14:19 Once we have that initial HTML document that has loaded, then there's another API, the ReactDOM.hydrate API, which actually will start to convert that HTML into React. Then you can start getting the interactivity and the other functionality that you expect within a React application.

Kent: 14:43 Perfect. You have such deep knowledge in all this stuff. This is great.

Monica: 14:46 Thank you.

Kent: 14:47 Thank you for sharing that with us. There are a couple of things that I wanted to ask you about. One is, you mentioned earlier, migrating from create-react-app to server-side rendering. Another thing that I get asked about all the time, and I'd love to hear what your thoughts are, and that is comparing Gatsby and Next.

15:06 Why don't we talk about create-react-app first? Acting under the assumption that OK, so we want the SEO benefits or some of the performance benefits of going server-side with our rendering. We're in a create-react-app right now, or maybe our own finagled webpack thing. What's that process like, of moving from a client-side thing to something like Next or Gatsby?

Monica: 15:35 In my experience, a lot of it was just copying all of the React components and such. In my case, I was using REST APIs with create-react-app. We decided to move over to Gatsby. We also were rewriting everything to GraphQL in order to work with data the way that Gatsby, their philosophy and framework is designed to support best.

16:09 There was some work on that regard, although it wasn't necessarily work that had to be done. The things that did have to be done during the migration, were rethinking how we were handling CSS. We were using, for media queries, there's a JavaScript matchMedia API that you can use to determine whether or not you want to hide or move certain elements.

16:37 If you are doing that within a client-side application, that's fine, because you already know that JavaScript is loaded when the user sees the content. If you have a client-side rendered application, when the page loads, generally, you will want to load your HTML, and then your CSS, and then finally, your JavaScript.

16:56 You can have weird layout shifts if you're relying on JavaScript to position elements and the content on the page appears before the JavaScript loads. That was something that we needed to update. There's libraries like Fresno, or a lot of the different CSS frameworks that are out there now, they'll support server-side rendering with some type of configuration.

17:24 That way, it will inline the CSS before you finish building the static files. That was something that we needed to rethink. Anywhere where we were referencing things like document or window, which are browser-specific API elements, we had to update them so that there wouldn't be errors within the server context.

18:00 There's a few different issues with that. One is that those elements don't exist within the server context. Then there's also the issue of the React hydrate API. It expects that the initial HTML that is generated in the server is going to match the HTML that loads in the browser. You can have weird rendering issues if, for example, you don't show an element if the window isn't defined, and then you have the application load, and the window is defined and something different is happening.

18:38 I would say the best way to avoid those reconciliation errors is to use a useEffect hook. That way, you can check browser-specific elements within that and not have to worry about there being a discrepancy between the initial HTML load and how it loaded within the server, because useEffect refer after React has kicked in, so you don't have to worry about the hydrate API, because that happens before React fully takes over.

Kent: 19:12 Absolutely. Anybody who's dabbled in server-side rendering for not even very long has probably seen some problem with that. It all comes down to, on client side, all of your stuff is running in the user's device. On server side, it's running on a completely different device that doesn't support that DOM. There are complexities there.

19:40 What you're saying is that going server-side rendering increases the amount of complexity. There's a bit of a cost in your application, some more things you need to think about. Then very often, the benefit exceeds that cost. Would you say that's true?

Monica: 19:59 Yes. I would definitely say the benefit outweighs the cost, in terms of being able to load your content more quickly and having more visibility within search engines, which is something that you often will get with statically or server-side rendered applications.

20:18 I definitely think that that outweighs the benefits. It does add this extra layer of you have to design how you build the application for this server context, which people are only hopefully going to see for two seconds. It's definitely worth it.

20:35 Over time, if you're not migrating the application, hopefully, this is something that's like, OK, you see how you do CFS, and in the back of your mind, you remember to use the browser API references within a useEffect, and then don't have to constantly have this additional cost of making these considerations.

20:58 There are also design considerations in terms of designing, how do you want the page to load? If there is user-specific information, like what should the default state be that you're logged out, even if maybe you are logged in, but you have to get that flash from logged out to logged in? Should there be a stateless environment as soon as the application loads?

21:25 There definitely are ongoing design considerations if you are concerned about how the application is loading and what it looks like as it enhances with the JavaScript.

Kent: 21:38 Sure. That makes sense. There are various competing methods for doing server-side rendering. I'll mention before we get into the common ones, I'm looking forward to Remix, which is upcoming by Ryan Florence and Michael Jackson. I've seen demos and it looks amazing. It's not out yet, so we can't compare it.

22:06 We've got pretty much the main players are Next.js and Gatsby. You've had experience with both, right?

Monica: 22:14 Yes.

Kent: 22:15 Cool. Can you give us an idea of how you make the decision between Next.js and Gatsby?

Monica: 22:22 I would say Gatsby is great if you have a blog or something of that effect. I know they're trying to push in terms of they don't want to be limited to a certain type of statically-generated website. A lot of people associate Gatsby with blogs. Then Next, you might associate with more complex applications.

22:49 One of the areas that Next shines in is that you have more granular control over how the application renders. It supports the pre-rendering, which is the static generation upfront, a compile or a build time. If you want it to on-demand generate pages from the server, they also support that, which is something that Gatsby doesn't support.

23:17 For Gatsby, if you wanted to have a page generated on demand, then you would have to do client-side rendering. I definitely think that a benefit of that is that they allow you to pick and choose how you want to render pages within the same application to a deeper level.

23:39 I feel like, in terms of my experience, I've done a lot within the Gatsby ecosystem, but I do feel like there's still a lot that I haven't fully explored within the Next ecosystem.

23:55 That's something that I'm excited about. They're having a conference coming up. They did a cool thing, where if you go on their website and get a ticket, as soon as you create your ticket and you share the link telling your friends to sign up, that link is customized to you. It has your GitHub avatar, your name, which attendee number are you. It is very rich.

24:24 That's something that they're able to do with their on demand data generation. I definitely think there's cool things that Next is doing that I scratched the surface with. If you have a client-side rendering, you're not going to get the rich metadata that you see on social media.

24:49 If you're doing regular pre-rendering, then you would have to rebuild the whole entire application in order to be able to have that ticket link that was unique to me with my metadata.

25:03 I definitely would say I'm excited about the things that Next is doing. I'm looking forward to diving into it more. Most of my experience has been with Gatsby. I definitely feel like there's a lot of cool things that are within the Next ecosystem that I think are combining different approaches to static site generation than what I've seen before.

Kent: 25:26 That sums it up well for my perspective as well. I'm also a little bit limited on the Next thing. When I was at PayPal, we were trying to decide between using Next and Gatsby for PayPal.me. If you go to PayPal.me slash your username, then people can send you money.

25:49 We needed to have the same dynamic aspects to it for social media stuff, basically. That was a ship stopper for Gatsby. Unless you only have a couple thousand, you'll spend all week building all of those pages. Even with incremental builds and everything, there's got to be a first build. That makes me a little bit more excited about Next.

26:24 I'd be curious to hear what you have to say about this yourself, but for me, the drawback to using Next over Gatsby is Gatsby has an enormous amount of community plugins and things. Whereas Next, you have to wire things together a little bit more yourself.

26:43 Has that been your experience, or am I missing something there?

Monica: 26:47 Yeah. I would definitely say I've had a similar experience with Gatsby. There's a plugin for pretty much everything if you have an idea. I'm like, "OK, I want to add webmentions to my website." There's a plugin that I can use to help me add webmentions or to generate the social cards. There's a plugin for everything with Gatsby, which is nice.

27:11 I definitely would say that it's a benefit of Gatsby that they have more templates and themes, as well as plugins in terms of adding additional functionality to your website without having to recreate the wheel.

27:29 I would say, for Next, though, there may not be Next-specific plugins, but a lot of the functionality that I need is I can maybe find something on NPM and tweak it a little bit into the Next context. The benefit of the Gatsby plugins is being able to quickly get things into the GraphQL data layer without having to dive too deep into that.

27:58 I would say definitely appreciate there are a community of plugins and such. Gatsby also has a lot of documentation. There's documentation for pretty much everything. Not everything, but a lot of different use cases, common use cases are covered within the documentation.

28:16 I found for Next that they do have good documentation, but they're definitely, I think, still building it out, in terms of sometimes I'll read something, and I'm like, "OK, this is interesting. I want to learn more," and then they link me to a GitHub repository so I can look at the code, but I would love to get more in the actual documentation.

28:39 I would say that it's definitely been an adjustment for me coming from the Gatsby ecosystem, where there will be a link to repository, but then everything is still spelled out and very clearly within the actual documentation.

Kent: 28:55 That's true. They have worked a lot on that. We're reaching the end of our time here, Monica. Is there anything else that I didn't ask you about, you were hoping I would, or anything that hasn't come up in our conversation?

Monica: 29:08 I can't think of anything.

Kent: 29:11 Good. I'm glad we covered most of that. Monica, if there's anybody who wants to keep up with what you're doing or wants to ask any follow-up questions or anything, what's the best way for them to connect with you?

Monica: 29:28 I'm pretty much always on Twitter. If you ping me @waterproofheart, I'll see your mention at some point. I blog a lot on my website, aboutmonica.com. If you see something interesting there, probably the best way to get in touch with me is still via Twitter. I have webmentions. If you respond to one of my articles or retweet it, you might see your face on my website.

Kent: 29:58 Nice. That's very good. That's a pretty good incentive to get people to talk about it. It's like, "Your face could be here." That's great. Actually, out of curiosity, with webmentions, are those server-rendered or are they client-rendered? Are those dynamic, and they can be updated without a build?

Monica: 30:17 This is the thing that I ran into with webmentions. When I first started them, it was like, "OK, cool, this is fine." I did them server side. I had a webhook that's triggered whenever I got a new webmention and then rebuilt my website. Then that got to a point where it wasn't sustainable. I was eating through my build minutes.

Kent: 30:41 You're too popular, there, Monica. Jeez.

Monica: 30:44 I ended up turning off the webhook. Now, I have on my list to add client-side web mentions so that on the initial load, it'll load them from the server, whatever was available on the server at build time, and then hydrate with the updated data on the client side.

31:08 That's something that's on my backlog of things to do, but it definitely was a case where I'm like, "OK, client-side is better, because this is real-time data or relatively real-time data." Not having to trigger a full rebuild because three people liked my tweet is definitely ideal.

Kent: 31:26 Yeah, yeah. That makes sense. I guess that's another area where going full-on server-rendered rather than server-generated would probably be better as well, so that's interesting.

Monica: 31:35 Definitely.

Kent: 31:37 Thank you so much, Monica. It's been a pleasure to chat with you. Hope everybody knows a little bit more about the process of server-side versus client-side, and some more information to make decisions.

Monica: 31:52 Thank you.

Kent: 31:53 Cool. Thanks, everyone. We'll see you all later.