50 shades of React rendering in Next.js with Ben Ilegbodu === [00:00:00] Hi, and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams to improve user experience with session replay, error tracking, and product analytics. Try it for free at logrocket. com. Hello everyone, I am Paige Niedringhaus, a staff software engineer at the IoT startup Blues, and your host today. And we are joined by Ben Eligbodu, a front end tech lead and people leader, here to talk about 50 Shades of React rendering. Welcome to the show, Ben. Oh, thank you very much. I appreciate the opportunity to be here. Absolutely. So before we talk about 50 Shades of React rendering, can you just introduce yourself a little bit to our audience and tell us a little bit about your background in software engineering? Sure. Yes. ~Um, ~so I am currently a software engineer at Netflix working on the TV UI. So if you ever use Netflix on a TV, which you [00:01:00] likely have,~ uh,~ my team and other teams around me,~ um,~ contribute to that. If it's broken, it wasn't me. If it's awesome, totally was me.~ Um, uh, ~but yes, I've been in software development,~ uh,~ maybe around 20 years or so, so I got started when I was in high school or so, just picking up,~ uh,~ programming languages in the summer, started coding on a TI 83 calculator. You ever heard of one of those and building games and building,~ uh,~ math programs,~ uh,~ in there. Algebra and stuff like that. ~Um, ~went to school, went to Stanford at my computer science,~ uh,~ degrees, and then started working in the industry, focusing on the web because I liked being able to see what I was building and send links to my friends or family. Or have them using the products that I use. So been focused on that for a long while, and then was looking for a new opportunity, a new space to grow my skills. So it was either going to be mobile [00:02:00] or TV, new environments and such. So opportunity work at Netflix came about and I've been there for three months now. That's fantastic. ~I, ~I do use Netflix very often. So good job. The user interface is great. And ~I, ~I say that after having used other,~ uh,~ streaming services interfaces and they are, they're awful by comparison to be completely honest. playing catch up. So Yeah, you set the bar very high. Alright, so let me ask, as you're working on TV interfaces, are you able to use some of the frameworks that we like to use like Next. js and SvelteKit and things like that? Unfortunately not because they are tied to the web and server rendering and stuff like that. So we do use react, but we have our own proprietary, I guess what you would call a browser and server and such. So a lot of the developer ergonomics are still there using react [00:03:00] because, ~you know, ~there's react and then there's the renderer. So normally it's react dom, but it can be server rendering and other things. So we have our own equivalent of that there. So yes and no to your question. So you have just been doing things like this 50 Shades of React rendering in Next talk on the side, just because you are also a Next user, I guess. Yeah. ~Um, ~I started using next maybe two or three years ago,~ um,~ for personal things. And then while I was at stitch fix prior. To Netflix,~ uh,~ we were using next JS as well. So brought it there and started using it to build a lot of the, replace a lot of the web,~ um,~ features that we had there. Alright, so let's start to dive into this talk a little bit more, because in the talk you talk about four rendering methods in Next. js. There's CSR, SSR. SSG, ISR, can you explain, I know there's so After the soup there, can you [00:04:00] explain some of the differences between these and when you might reach for these different rendering methods? ~uh, for sure. Um, uh, ~the easiest way is probably to describe what each one of those are. ~So let me take a little bit to explain that. ~So you mentioned CSR first, which stands for client side rendering. So that's ~kind of ~the original way that web development existed. You would deliver a blank page to the browser, and then everything would render on the client. So if you did things with jQuery, AngularJS, Ember, all of those were like that. React as well, if you used Create React app. So that is really poor for SEO and even performance of the page, because you have to wait until all the JavaScript loads and then you render on the client. But,~ uh,~ it's really good and appropriate for experiences that are. That have heavy user interaction and don't, there's nothing really, you can serve a render. [00:05:00] So if you think of something like Figma, for instance, that,~ uh,~ design tool, like that is client side rendering, because really, what are you going to render on the server? Or any kind of like charting thing that you have, those are typically client side rendered. Or if you're pulling in a. Third party service, like you're pulling in a Stripe widget or PayPal or some order tracking software, that's usually client side rendered there. So ~that's the, ~those are the good candidates for client side rendering. Yeah. And when I say client side rendering, ~I'm saying it's, ~I'm talking about the initial rendering is client side rendered because in the end. Any ~server, ~server rendering strategy you use ultimately will continue to be client side rendered when the user takes actions and you pop up a modal or you replace some UI, that's always going to be client side rendered. ~Right.~ ~Um, ~so that's CSR. And then the next one, let's just talk about SSR. Let's say,~ um,~ [00:06:00] so that stands for server side rendering. So that is like the OG of rendering in the web. So you can think of PHP, Rails, NET. ~Like, ~basically your server rendered everything. And delivers it ~to the, ~to the browser. And then maybe in the past, you'd have some jQuery sprinkled in to do something on the client, but everything,~ um,~ Is rendered for every request on,~ um,~ the server. ~So, uh, ~that's really nice because ~you get, ~you can have unique content for every person who visits, right? So it can be driven by cookie information, ~you know, ~stuff like that. ~And you can have. ~So the content can be dynamic basically. And then ~the server rendering time is really fast, or I'm sorry, ~the browser rendering time is fast because all of the HTML is already there. So you got your CSS, your HTML, you see something. Before you start doing something on the client. And then the last benefit,~ uh,~ which I mentioned before, I think even you did, it was around SEO. So because the [00:07:00] HTML is in the page now, Google crawlers or whomever you use being maybe who knows,~ uh,~ Bye bye. it can read the HTML and pull out all of the meta tags ~and ~And one,~ um,~ other kind of less mentioned benefit is S. M O, which is social media optimization. So you imagine you send a link in Slack or you post the link in Twitter, all of that rich content that it displays with a preview image description, like all of that comes from the HTML as well. And those tools, especially don't parse the page and run JavaScript and such. So it's really good for that, but,~ uh,~ your server rendering times are going to be slower because the server's doing the work. There. So you have to ~kind of, ~it's a cost benefit analysis there. ~Um, ~but pages like your checkout page or search results, those are really good for server side [00:08:00] rendering because they're unique to the person, but also the server has all that information so it can render it there. ~Right. Um, ~what was the third one? Ssg was next. Oh, SSG. There you go. ~So, uh, ~static site generation. So this was made popular by a couple of tools, Gatsby being the main one. So the interesting part about that is that instead of rendering on demand for every request, we render at build time. So before it even reaches the server and your CI environment, all the HTML pages are pre generated. Which is,~ um,~ amazing because now you don't have to, your server doesn't have to render something on demand. So the server response time is super fast. And because ~there's a unique page, well, not a unique page, ~there's one page that everybody gets because it was pre rendered, then you can cache it and it's like super fast there. So that's great for performance. ~Um, ~that way. [00:09:00] But the problem with that is that it's the same version for everybody. So if it needs to be unique for any given person or based on cookies and stuff, then it becomes ~really, ~really difficult,~ um,~ to do that. You end up having to have it pre rendered like a shell pre rendered and then do most of it client side rendered is usually the way that people would get around it. ~There. ~But,~ um,~ that's usually ~what, ~what happens if you have dynamic content, you really don't want to use,~ um,~ static generation. ~Um, ~and of course, if you have ~like, ~let's say you have a e commerce site and you have 10, 000 products because ~you're, ~you're awesome and you're selling a lot of stuff,~ um,~ if you had to pre generate 10, 000 product pages, that's going to take a really long time,~ um,~ for your CI. ~So, ~and every time you make a change. It's going to ~re ~re render all of those things. ~So, uh, ~that's a negative slow build times, but it's awesome for ~like, ~like marketing landing pages that don't change, for instance, like your help topic page [00:10:00] or ~hmm. ~Oh, about your site and stuff like that. All that legalese yeah, the FAQs and terms and conditions and conditions. That's what I was thinking of. Yeah. Like that never changes except, ~you know. ~The one year it changes and you send out an email and no one cares, ~but you know, ~you got to do that page perfectly good for a static site generation and maybe blog posts as well, depending on how often they change. ~So, ~yeah, those are great. ~Um, ~and then the last one, the last acronym is ISR. It has a nice, fancy name, incremental static regeneration. Just wanting us to sound as smart as possible, ~I guess. Uh, ~and it's basically like the combination of SSG rendering statically or pre rendering statically and SSR, which is rendering on demand. So,~ uh, ~you still pre render. ~Um, ~pages, but,~ um,~ we can set [00:11:00] a timeout for it to re render at some point. ~So, ~let's take a blog post page,~ um,~ You can pre render it, but then we can say,~ well,~ every day we want to re render it again, because we might have changed some content, or every five minutes, doesn't matter. ~Um, ~or a product page, for instance, we know it's going to change. It's mostly static, but it may change, so let's re render it every,~ uh,~ Yeah. right? ~Um, ~but now we can have frequent updates. ~Um, ~but it's still challenging if ~you have different, ~you want to have different content for different people. ~So, you know, ~you have your headless CMS page, for instance, that's really good,~ um, ~for it there. So ~kind of, um, you know, ~wrapping it all together now to actually answer your question. Like blog posts, login pages. Those are good for static pages. ~Um, uh,~ server side rendering. I mentioned ~like ~shopping cart, checkout pages, order history, that sort of thing. ~Um, ~client side [00:12:00] rendering, great for like third party widgets, shipping, highly interactive user interfaces, and then ISR for ~like. ~Product details, pages where you want it to rerender CMS pages, that sort of thing. So when you're using Dex. js, is it possible to have all of these different types ~of pre render ~of rendering happening depending on which pages you're working on? ~Yeah. ~Yeah. That's one of my favorite parts of next,~ uh, ~compared to some. ~Um, ~Frameworks that existed at the same time before,~ um, ~a lot of ~kept ~caught up now, but,~ uh, ~the cool part is that any given page can have its own rendering strategy. So your whole app doesn't have to be,~ um, ~SSG, for instance, like Gatsby used to be, or it doesn't have to be all server side rendered like most of the other frameworks, ~you know, ~that exists and such. So you can say,~ well,~ my homepage. It's CMS driven. I want it to be ISR, incrementally rendered. ~Well, ~I have this checkout page. It really needs to be server side [00:13:00] rendered and so on and so forth. ~So, um, ~depending on ~how you want, ~how you are retrieving your data and how the data differs between people, you can pick whatever you want. Strategy you want, which is nice. ~I mean, that, ~that kind of leads really well into our next question is what strategies can developers use so that they optimize their performance of page speeds and their SEO ~for ~for Next. js? ~Right. ~Yeah. So ~kind of ~got into it earlier is that you really need to take inventory of the page itself. It's ~like, well, does, ~does it make sense for Google to catch this for instance, and, or for Google to have a search result for it and if yes, then you really need the content pre rendered in some sort of way, and so that might be server side rendered if it needs to be. Dynamic in some sort or it could be statically generated, which would be, ~you know, ~the ideal ~and ~And decisions like that basically so It's doesn't need to be [00:14:00] server side rendered. How often is it going to change really? And the less frequent it is the more likely statically generated page And if you have something that's going to be hit by millions and millions of people because your site is awesome and you're making millions of dollars, then you really want to be able to cache those pages. Otherwise, You'll be spending millions of dollars to AWS. ~Uh, ~so you need to,~ uh,~ pre rendering is definitely an option. ~So, uh, ~the easiest is just make everything CSR and be done with it like we used to do. But you really have to take inventory of each page to Sure, and yeah, and I've worked on sites that are maybe an internal tool, and client side rendering is just fine for those, because the only users are internal to your company, so they don't need to be indexed by Google. But. For everything else,~ your, ~your personal developer website, or your Shopify site, or whatever, it [00:15:00] probably does need to be indexed at least partially so people can find you. ~yeah, ~yeah, but I would still argue, ~you know, I mean, ~I've done internal sites to it's ~like, uh, ~it's our own employees, ~you know, ~who cares about them? ~Um, ~but, ~you know, you ~still time is money. So whatever they're doing, the faster they can do it. So you could pre render a page. So it loads quicker or,~ um,~ things to that nature or server side rendered it if it's unique and things. So generally yes, SEO doesn't matter. ~So, um, ~what's in the HTML is not as important, but still speed is important. ~So~ ~You're right. ~You're right. When you're doing lots of large calculations, you don't want your client to be, the browser to be frozen while it's working through that. Yeah. But you make a good point. ~A lot of, and I didn't think about that. ~A lot of internal tools. Are good candidates for client side ~rendered ~rendering that just the nature of them. It's usually something that's highly interactive that they have to do filling out forms and Analyzing data things of that nature. All right, so ~let's, ~[00:16:00] let's talk a little bit about some of the big changes that Next has made in the last couple of iterations where it went from the pages router to the app router. ~How, ~how does that differ? How does going from pages to app change things? right So there are ~kind of ~two main things that happened with the app router One was just,~ uh,~ development ergonomics and how you define pages themselves. ~So, uh, ~next is, how do you say it? ~File, ~file based routing, basically. So if you have a page at slash my slash home, In your repo, it'll be source slash pages slash my slash home. tsx or home slash index. tsx, whichever way you want to do it. But the problem with that is that every component file in ~that ~Next would think is a page. So if you wanted to have your tests in there or helpers in there, like it becomes a little [00:17:00] trickier,~ um,~ there, and there are other like sophisticated routing definitions that you would want to do that were tricky. So the app router,~ um,~ introduced like layout files that you can do to encompass,~ uh,~ layouts and things like that, make it easier to define what is actually the route and what are other. ~Um, ~components, helper components you want and such. ~Um, ~so that's one part and that's ~like, uh, ~the non complicated part. I'll say,~ uh,~ the other side of it is the rendering strategies and it uses,~ um,~ react server components to do a lot of that work. And that comes with a lot of,~ uh,~ I don't want to say baggage cause that's ~kind of ~negative, but it comes with a lot of additional understanding. ~Okay.~ Yeah. curve that comes with it there. So the advantage of the outbrowder strategy is that all of those four things I mentioned, client side rendering, ISR, SSG, SSR, it like does that all automatically for you. So that [00:18:00] whole thing about, Oh, you have to take inventory and think of how you want to get the data. You don't have to do that anymore. You just write how you retrieve your data and it'll do it for you. So if you retrieve your data,~ um, and it's, ~and it doesn't have to look at any cookies or query parameters, then it'll pre render that page. But if you look, if you access a cookie or access query parameters that it knows this needs to be server side rendered ~Mm hmm.~ So it's just driven by the data. ~But, um, ~ With react server components comes the concept of server components, because now it can,~ um, ~render a lot more on the server and kind of stream things from the server. So you have to tell it what's a server component, what's a client component. Which is something that you've never really had to do in the react ecosystem. So anything that accesses the window or other browser things, you have to mark it as a client component ~Mm hmm.~ ~and, ~and [00:19:00] set up that was ~kind of ~like client boundaries. ~So. ~That in itself is difficult. And then if you're using a third party library and it doesn't do those things then you have to create wrapper components to make it client,~ um,~ components. It's a little,~ um,~ convoluted right now. Yeah. Depending on your site, and if you're, I feel like anybody starting from scratch, it actually makes sense. ~Mm hmm.~ it can feel pretty complicated. ~That's, ~that's just what I was going to ask, because I work on a Next. js site right now that is,~ uh,~ I think it's maybe Next. 14, but it started out as a Pages,~ uh,~ yeah. and it was extremely painful to even try and start to think of how I could extract state from pretty much every component that has some sort of hook in it and potentially move it over to the app router. ~So. ~Do you have any, I, like you say, if you're starting from scratch, absolutely use app router, but for people who are already using pages, do you either have strategies or would you say just stick [00:20:00] with pages until you can't any longer? ~Mm~ I was in the same situation at Stitch Fix as well. We had started using Next at 13, I believe. ~So, um, ~AppRouter didn't exist when we first started it. ~Um, ~but then obviously it came about. So one thing that's nice is that they can coexist, the AppRouter and PagesRouter. So some of the more simpler pages. You can move over and really it's more of the,~ um,~ the way the routes are set up versus the rendering strategy. So that's fine. ~Um, ~there, and then I think the next one really ~is, ~is getting, is starting to identify the client components. ~Like ~if you can start getting those kind of ducks in a row. ahead of time than it makes the other,~ um,~ conversions of app router pages,~ uh,~ easier. But just ~like ~converting from JavaScript to TypeScript was,~ uh,~ a difficult thing, this is ~kind of ~similar. So at the end, you just have to take a page, [00:21:00] And start,~ um,~ handling all of ~the, ~the fallouts, I guess I'll say about,~ uh,~ making that transition. But one thing I will say though, is that we have this idea to always be using the latest tech, but you also have to take an inventory of who is on your team and what's their appetite for learning something new, what's their capability, right? So if you have a team where three people are really Maintaining the next app itself, like the infrastructure, the framework, no next, no, how things work. And then 25 people are just the ones who ~come in, make a change, go away. And ~come in, make a change, go away. Like having them understand suspense and how it'll,~ uh,~ dynamically show spinners and load things in is asking a lot. So is that overhead of them having to figure all those things out? Worth the gains from, ~you know, ~switching over to the app router. [00:22:00] So just because a tech makes sense, it may not make sense in your environment because of the people who are there. ~Right. ~So ~that's something, ~that's something really to think about that can get lost. That's a really great point,~ uh,~ because ~it, ~it ends up that it probably is not worth it for us to make that transition right now, because a lot of what we do is documentation and we have all of our documents right now in one content folder, and so our writers know exactly where they need ~to go ~to go in and change the markdown. And if we went to the file based routing system that app router provides. Suddenly all of those files would need to change and they would be nested into folders a lot deeper into the project. And we also like to change the content around, ~you know, ~add new folders and rearrange it on the site. So probably is not in our best interest to go to. yeah, it's one of those ~is the ~is the juice works worth the squeeze and ~You know, ~you got to take that [00:23:00] real Inventory, I guess to see if that's really the case there All right. So we've talked a little bit about the advantages. We've talked about some of the challenges. How, in your opinion, how does next enhance that developer experience compared to other frameworks? How does it make it better? There's a little bit of a learning curve, like you said, with app router, but it has a lot of benefits as well. Yeah, so I will say honestly that all of the frameworks if you take in like Astro and Remix ~and And, um, ~next JS, like these are all meta frameworks at this point. They all more or less do the ~same, ~same thing. And that you can accomplish the same thing. It's just like, where is their core focus and ~then, or ~whatnot. So you can't really say next is, ~Oh, it's ~better than. This other thing with a caveat that I'll mention in the first thing, but like I said, with all of them and with next is the ability to be flexible in how [00:24:00] you can render your site and build your site. So you're not pigeonholed into one thing you can,~ um, ~Be really discerning on a given page, what you want to use. So I think that's the huge benefit of next because it can be, ~you know, ~like a PHP symphony app that server side rendered, but it also can be like a Gatsby app that's statically rendered. It can be all of those things,~ um, ~which is nice. However, I'll say the advantage that Next has, depending on how you use it, is that it's built by Vercell. And Vercell, first and foremost, is a hosting company. So you use Next. js with Vercell, you're going to get all kinds of optimizations and benefits and things like that, that they do, sadly, depending on how you feel about it. They only do it for their site. So there's all kinds of optimizations that they can do since they build [00:25:00] Next. ~js. ~So ~that's kind of the, ~the other frameworks don't really have that partnership with a cloud,~ um,~ SAS provider. So ~that would be, so that's seen, ~that could be seen as an advantage, but it also could be seen as a disadvantage as well. ~Yeah,~ Yeah. At the end of the day, Vercel is going to make money one way or another. ~yeah, ~yeah, the main thing. and it's in their best interest to keep Next. js going because it's, let's just say, their cash cow, in a sense,~ um,~ but they could also move into a world where,~ um,~ this thing only works on Vercel or that thing only works on Vercel and ~kind of, you know, Uh, ~make it less of a, of an open source kind of deal. hopefully they will continue to do good in the industry and not. Just go for the jugular. exactly. ~Well, ~it's been great talking to you, Ben. Is there anything that we haven't covered that you'd like to touch on with Next. js and rendering? Yeah. I would say that,~ um,~ you~ know, ~if you're getting started out and you don't have anything [00:26:00] next ~is a, ~is a great choice as well. And like we said, start with,~ uh,~ the app router ~as well ~and really. You can start with everything being static just to start and then start making things ~more complicated or ~more sophisticated, I guess I'll say, optimized~ as you, ~as you move forward with it there. But there's lots of resources on the next site and everywhere else that really helps with,~ um,~ understanding how to do all of the nuances and such. So in our talk right now,~ um,~ we covered. The high level things, but for each rendering strategy, there are nuances and how you can revalidate, unvalidate, do all kinds of,~ uh,~ different things to make it ~really, ~really tailored to the experience. ~So, um, ~really investigating that sort of thing will be helpful. Great advice. So if people want to get in touch with you to either talk about their own problems with Next. js or to learn more about Netflix or [00:27:00] anything else, what's the best way to find you online? Yeah, the best place will be on Twitter or X. ~Um, ~I still call it Twitter,~ uh,~ is Ben MVP. So at Ben MVP is where you can find me. ~Um, ~that's pretty much my handle everywhere. But Twitter is really the only place,~ um,~ that I check. ~Um, ~no one really messages me on GitHub, even though that's, ~you know, ~also been MVP. And I'm on LinkedIn as well, been MVP. So any of those places you choose to reach out, but Twitter's probably again, Oh, and a shameless plug been MVP. com as well. I've got a lot of blog posts there about next JS too. So if you're interested in other things there, feel free to check that out. thank you so much for joining us on the podcast. It's been great having you here today. Again, I appreciate it. ~I've had fun, so~