Shaundai Person:
The overall theme is that it's part of Suspense. And so what Suspense is, it's not a way to fetch data. It's a component that allows you to specify what you want to show in the UI until something's ready.

Paul:
Hi there, and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket combines session replay, error tracking and product analytics to help software teams solve user reported issues, find those issues faster, and improve conversion and adoption.
Today we have Shaundai Person with us, a very special guest and senior software engineer, hailing in from Netflix. Shaundai is a web developer and expert in React, in server-side rendering. And we're going to talk about the latest React 18 release and how it's really changing the game for server-side rendering specifically, and going over some differences between client-side and server-side rendering. Welcome to the podcast.

Shaundai Person:
Thank you for having me. Excited to talk to you, Paul.

Paul:
So you're like a server-side rendering expert. When I was watching some talks, you really get into the weeds on server-side rendering. Did you have your hands in the details at Netflix a lot in that area?

Shaundai Person:
Expert is a big word and a scary word. I don't feel like an expert, I feel like a person who uses and really takes an interest in optimizing apps. My career as an engineer has been on the front end. And as any front end engineer knows, it's not just pixel pushing, like adding border-radius and doing a bunch of CSS, there's a lot of logic that comes in. And Netflix takes a really strong stance in optimizing the experience and optimizing performance to fit a number of use cases and to benefit ... The people who have slow internet connection have the same experience as people who have the highest optimized, whatever, fiber optics. I don't even know what the great internet is nowadays.
And so it's led me down a path to exploring different ways to optimize the front end. And take different use cases and scenarios, and scenarios both for the user and for the product that I'm building, and create the best experience possible. So out of that came this talk and a couple of more talks that I have that are really centered around how to optimize performance, server rendering being one of those ways to do it.

Paul:
You really have your interest in optimizing websites, making them the fastest, the best user experience. That's a can of worms, like user experience could mean a lot of things. What are some other things that you have in your head in this space that you think about, from the user's point of view?

Shaundai Person:
Actually, this is what I consider my strength as an engineer. I switched careers, and I started my career in sales and I was selling software. And as a software seller, I was the first line of contact for the customer. So they would come to me with the exciting news that our tool helped them in such and such a way. In those conversations, as I was trying to sell them or get them to renew their licenses, I would hear from them that, "Okay, this is a tool that we're really putting a lot of engineering resources in that nobody's going to use." Or, "This is something that our customers have been asking for over and over and over, but nobody is prioritizing that."
And so part of the user experience for me is actually looking and seeing how your user uses the tool. You could make the most beautiful graphics, you could make the most seamless animations that are super accessible, but what good is all of that if your users aren't going to use it? I think that's one of the bigger parts of user experience, is just finding out about the different personas that are going to be using your tool, and then how are they going to use it. Release something and then ask for feedback. And accept the fact that sometimes the thing that you think is the coolest isn't necessarily something that applies to your users, and start from there.
And then you can work on optimizing for loading, and data handling, and accessibility, and light mode versus dark mode. And then creating this more customized-seeming experience for your users, where the part that they want to interact with becomes able to be interacted with as soon as they want to do it. There's concepts of prefetching links, and just based on a user hovering over something, can we start the process of fetching a whole bunch of data. So there's a number of ways to optimize, and I could probably write books and books and books on different optimization techniques.

Paul:
Yeah. I think it's interesting though, at a fundamental level, you're like ... The number one user UI, UX thing I would want to suggest to people is you have to build the right thing.

Shaundai Person:
Exactly.

Paul:
We get really enamored with what we're building and you build the wrong thing. And it's really not a hard problem to solve, like you pointed out. It's like, go talk to them and see what they want.

Shaundai Person:
It can be uncomfortable for a lot of reasons. You may not know how to have those conversations, or you may not be in the room with your customers. So you'll have to go out, you have to make customer visits. I'm lucky in my own role where I'm creating internal tools for other Netflix engineers, so I can just send them a Slack message.
But at my previous company, I would go out to our sales teams or go out to my previous customers and ask for their feedback and things. And then just listen out on Twitter or listen out on LinkedIn, where are your customers and what are they saying? What are they complaining about?
And then it can also be uncomfortable because you, as an engineer, you feel like, "Okay, I put all this work into this," or, "I have a really cool idea." From a engineering perspective, "This is going to be super exciting and functional," and all that stuff. But it's hard to hear when you've spent so much emotional and actual physical energy coding something, and nobody else sees it as valuable as you. So when people are calling your baby ugly, I guess it can be hard to solicit that type of feedback and risk having your feelings hurt.

Paul:
It's one of those scenarios. Having a project manager is really nice, as an engineer, not having to reach out on that front. Aside from the global scope of building the right thing, you were getting into a bunch of specific things that you can do technically to improve on the user experience. Prefetching, loading correctly, hydrating things in the right order.
And it's my understanding that React 18 really brings a whole new toolset available to front end developers of how you can tailor that UI UX to be better. You can really take a needle in the thread and go in. I'm not somebody who has had their fingers in a hybrid rendering or lazy loading and stuff, so I'd love to hear from your perspective why this is a big deal, why it is so profound for a server-side rendering based application.

Shaundai Person:
The best way to start with an explanation for that is to start with the state of things pre React 18. And so even the approach that the React team took to releasing this version actually plays into a lot of the stuff that we were just talking about, where we're having the conversations with our users. And so the React team reached out to me and I want to say maybe 15 to 20 other people, who are at varying stages of their front end careers, and asked them to be part of this working group, React 18 working group.
And so through there they told us about, "Okay, this is our beta version of React. These are the features that we're adding in." They put in all those great documentation. And then they were like, "Okay, basically pick it apart. Just comment." It was just a series of GitHub pages and they were like, "Just tear it apart. Try these examples. Let us know what doesn't make sense in the documentation, but then also what parts of this are the most useful to you and what do you really get excited about." So they had those conversations with us. And one of the big changes, which is what I have built a talk about, and I recently did a talk at JSConf in Santiago, Chile, was about the new streaming server rendering architecture with Suspense.
So in React 18, the issue previously, pre React 18, is that there are a number of steps in the server rendering process, and we'll go into these, but there's a number of steps in the server rendering process. And for each of those steps, pre-Act 18, each step would have to be completed for your entire app at once. And what that means is that if you have a slow moving component, like say you have a grid with a ton of data that is going to take some time for that data request to be fulfilled, until that request is fulfilled, the rest of your app can't move on to the next stages in the server rendering process.
So because of one component, your user is either stuck looking at a blank page, or if you've separated the rendering of your components into different parts, then the part that potentially is the most important to your user, that part with all of this data that they may have come to see, isn't ready when they're ready. So the React team knew that there were ways to optimize it so that we could specify to your user that, "Yes, your app is waiting for something," and gives your users a little bit better of an experience than looking at a blank page or just like a blank piece of your screen.

Paul:
Is it like there's this new API available that you can have some sort of agnostic view about what is loaded, what's not loaded, what's about to come into play, and then your UI can react as needed?

Shaundai Person:
Exactly.

Paul:
To show hide replace ... Okay.

Shaundai Person:
Yeah, that's pretty much it. So the overall theme is that it's part of Suspense. And so what Suspense is, it's not a way to fetch data. It's a component that allows you to specify what you want to show in the UI until something's ready. So it doesn't care whether you're using GraphQL or REST, all it cares is that things have loaded or not loaded. And if they haven't loaded, what am I going to show? There's a prop called fallback, what am I going to show in that place? It might be like a loading spinner for example, that indicates to your user that this piece of the app isn't ready.
Now with the new architecture there's two additional features that will allow you to break the work apart. So Suspense's have been part of React for a while, but still you're faced with that problem where you have to load everything or fetch all the data for the entire app at the same time. Now you are able to split the work apart. Let's say that big data grid that we're talking about, React can continue to move on through all the other steps of the server rendering process for the rest of your app, because your data grid is wrapped in Suspense while Suspense waits for your loader to be ready. And it's just showing that fallback spinner in its place until that data grid is ready. You got it?

Paul:
I understand what it is because I watched Shaundai's talk about this. If you're listening, you want to hear her go over the details. Because you mentioned we can go into the podcast about how the server-side rendering process happens, and there's just no way we can do your talk justice for the time we have in the podcast. And I thought that talk was like, it really outlined what happens in the server for SSR. So if you're new to SSR or you're wondering what is server-side props and Next.ja, definitely check out Shaundai's talk, it's really good.
Just a quick pause here to remind you that PodRocket is brought to you by LogRocket. LogRocket can help you understand exactly how users are experiencing your digital project with session replay, error tracking, product analytics, frustration indicators, performance monitoring, UX analytics, and a bunch more. Machine learning algorithms surface the most impactful issues affecting your users and you can spend your time building a better product, rather than hunting through tools. Solve user-reported issues, find those issues faster, and improve conversion adoption with LogRocket.
What do you say to all the folks, there's this trope coming on the internet where people are like, "Server-side rendering was the first mistake that we made.

Shaundai Person:
Oh gosh. Yeah.

Paul:
Okay, so what do you say to them? Because Astro's, out and Astro is really tickling a lot of people's fancy because you could do SSR and you can not load. It's like, "Oh, this whole SSR problem, forget about it. We're just going to load JavaScript, only and then if you need it, we'll put it in." So where are the limitations in your mind to that and is this an answer to that?

Shaundai Person:
I'm the type of person who is like, "Oh, I respect you for that." And you know what, I appreciate your view on this as well. And I can see the two different sides and not really have a strong stance with anything. When it comes to coding, engineering, there are trade-offs for both.
I do think that server rendering is an optimization above client rendering. So in the talk I talk about the differences, but the main difference that I see in my head when I'm thinking of how to optimize my app, if I'm going to use client versus server rendering, is that we talked about the different stages of the server rendering process. Your app goes through similar stages but from a different kind of perspective.
And so one thing that is an advantage when you're server rendering is that you're fetching the data from the server, versus initiating that request on the client. And then going back to the client to make a round trip and bring that data back to the client for the user to see. So if you have a lot of data that you're going to be loading for this app, if your only choices are either client rendering or server rendering, without knowing anything else about your app, I would lean towards server rendering. Because fetching large amounts of data will happen a lot more quickly on the server rendering side.

Paul:
Is this because we can't make an assumption about the client? Because otherwise it has to happen on the client, right? We're not sure how fast they are.

Shaundai Person:
Yes. In order for the data to be displayed in the client, that request, if you're just doing client rendering and you haven't optimized for server rendering, the request is going to be made from the client. And the data would be on the backend, would be on the server. So once that request is initiated, you go to the server to get the data and then have to bring it back over the wire. So if you have slow internet connection or there's a lot of data, it's a heavy amount of information that has to get sent in a round trip so it slows down the process.
With server rendering, the request is initiated from the server, the logic is initiated on the client to the button that you push. But we're getting the information right from the server, so it's just a one-way kind of trip for the information.

Paul:
It's also like a controlled environment, I guess. On the server you can control the resources, you can control what domains you are or are not reaching out to. You can really have a congruent environment between your deployments.

Shaundai Person:
That's 100%. The other thing, from just a UI UX perspective, is that if your user has slow internet or you have a lot of JavaScript, which most apps these days come bundled with a lot of JavaScript and then I'll address your Astro comment, it's going to take some time for that JavaScript to be loaded. If your app is just client rendered, it's just like a script tag. Say, if you're using Create React App, like that App.js or App.tsx, your uppermost parent has this little script tag that tells your browser, this is what your page is going to look like. It takes a long time to load if your app has heavy amounts of JavaScript.
And so, until that JavaScript is loaded on a client rendered app, all your users are going to see is a blank screen. So you've probably gone to a website that's not optimized and just sat there for several painful seconds, just either refreshing or just staring and waiting because the JavaScript hasn't loaded for that page yet.
What server rendering actually is, is it on the server, we're going to walk the component tree and we'll render your app to HTML. So even before that JavaScript loads, we'll render all of your app as just static HTML. I'll be able to see here where the login button's going to go. I might see some alt text for some photos. And we'll send that to the browser for the users to see, while that JavaScript loads. So the JavaScript can take a long time, but your user is actually able to start seeing content on your screen.

Paul:
It's like it loads the guardrails.

Shaundai Person:
Yeah, so it's just going to be a static HTML version of your site. Then when there's tools, like Remix is a fun one that I've used, and Astro I think has similar value prop, is that their ... Let's just not put as much JavaScript in things. We don't need all of this JavaScript. We don't need to by default load JavaScript. Let's just add it incrementally.
I'm not sure about Astro's position on how data is fetched, but I know with Remix they've scaled things back and they call it progressive enhancement. They've scaled it all back. We're like, we're going to just give you the fundamentals of the web, or leaning into HTML, all the stuff that you would see that's statically rendered from your server-side app. Let's just start with that and then you can add in little bits of JavaScript as you need it. So those load times are not as significant as an app that's built in like Create React App already.

Paul:
I think one thing that's compelling about Astro is ... And correct me if I'm wrong here because I'm not sure in React, like if we do server-side rendering ... You have some sense about the app is a server-side rendered app, and we're going to hydrate it incrementally in whatever strategy we choose. And there's things like Astro or Remix, where Astro has this opinion of, "We're not going to have any server-side rendering or any JavaScript at all." It's no JavaScript by default. But if you want it you can add it in, and then you can run a server and we'll hook it up and do that thing.
And I wonder if you see Suspense as an answer to that? Is that React's way of saying, "Okay, we see the web moving in this direction of no SSR by default, less things by default, but 98% of the world's on React. So let's give Suspense, let's build out this API so that they can be nimble, they can be quick." But I wonder if that's an answer to this, versus a whole holistic change on how React is structuring applications.

Shaundai Person:
Yeah. And actually I had that same exact question, especially as I started working with the Remix team. I was like, "Well, what's the difference between this and that? Or when would I use one or the other?" And I don't think that either one is trying to replace the other. They solve very similar problems, but you can use both together.
I know Remix more than I know anything else and then I know React. With React, with these changes, think of it as just something that allows you to specify what you want to show and where it needs to go until the loading has happened. But when it comes to how much are we going to load, when are we going to make those requests to load things, when are we going to make those requests to fetch data, and how close is our data to our server. Are we going to do server rendered fetching? Like Remix has this concept of being able to load while you fetch. So it's more about the logic and when to initiate those requests, and then how much is going to be there. Like let's pair down the amount of JavaScript that's in it so that we can have less that we're going to load.
For React, all they need to know is what you want to show, at a bare minimum. What do I want to show and where does it need to go in the component tree. As things are loading, I don't want this whole loading spinner to be at the top-left of the page somewhere and then just pop in, because that's not good for your page performance. Just think of Suspense more as just a ability to specify what you want to show and where. And because of what it does and its ability to break the work apart, it gives your app the appearance of being almost instantaneously interactive.
We didn't talk about this, so there's four steps in the server rendered process at a broad level. Whatever component is wrapped in Suspense can go through its process on its own separately. And then any components that are wrapped in Suspense are going to go through their server rendered process in the order that they appear in the tree. Now, say something that's at the bottom of the component tree, that's inside of a Suspense element, your app is going to prioritize whatever's wrapped in Suspense. So it's going to prioritize speeding up the server rendering process for whatever component your user thinks is the most interesting.
So you're making your app seem like it's custom-tailored to whatever your user is really interested in looking at at the time. Think about it more from a user experience, slash design perspective.

Paul:
Sealing the deal on the topic of, is Suspense an answer to Remix and the others' frameworks that are coming out? Do you see server-side rendering as the default, going away for new projects being built and selectively hydrating things with islands? Or do you see asynchronous loading with server-side rendering continuing to be king in default? And any other comments on how we're developing using these asynchronous loaders?

Shaundai Person:
That's actually a really good question. And there's this tool that I'm working on at Netflix at the very moment that's been giving me all kinds of stress lately.
Based on this particular project, as well as other things that I've worked on, for enterprise organizations I can see moving toward having more flexibility, the ability to just component by component fetch very separately, and then have each component have its own little experience. You have your own fetching logic, you have your own loading logic, different loading states that are completely separate, other than being in the same repo, even as all the other components.

Paul:
Sounds like Web Components a little bit.

Shaundai Person:
Yeah. Actually,

Paul:
It reminds me a little bit of Web Components.

Shaundai Person:
Yeah, you're 100% right. But yeah, I think especially for enterprise-scale applications, having more flexibility, as long as it doesn't negatively impact performance, it doesn't make the whole app super slow, I see that being the way that we go.

Paul:
Everybody has a different opinion about that. So here we have somebody working at Netflix, working on some groundbreaking stuff, telling us, again, up the same alley, that a lot of folks on these bleeding-edge frameworks are saying it's going to be a hybrid future. It's going to be tailoring custom-made experiences. And I guess Suspense is just one piece in that puzzle that we're entering into this next phase of web dev really.

Shaundai Person:
Yeah, it's really exciting to see. It seems like there's a new framework coming out all the time and they have really good value props. Yes, JavaScript is great, but let's use less of it. Or can we still even have even better experiences with less stuff, less code, less JavaScript.

Paul:
Less stuff.

Shaundai Person:
Yeah, it's an exciting time, for sure.

Paul:
If people, Shaundai, want to follow you and your escapades into server-side rendering, because you mentioned you're talking to the React team, you're on these RFCs and stuff. Do you post comments, or what's your GitHub if people want to see what you're [inaudible 00:22:59]?

Shaundai Person:
Yeah, so everything for me is @shaundai. That's the beauty of having a unique name. You can find me anywhere, just look up my first name. S-H-A-U-N-D-A-I. Twitter is where I post the most @shaundai, GitHub, @shaundai, Instagram if you want, @shaundai. Even dev.to, @shaundai. But yeah, I would love to connect with any kindred spirits or people who are very excited about optimizing front end performance.

Paul:
Shaundai, it was a pleasure to have you on and getting into the details about server-side and client-side rendering. I feel like this is going to be a hot topic or over the following years. It's like, frameworks continue to adapt to their own solutions to this. So maybe it'll help some people form their own opinions. Because you said you want to be more opinionated, so maybe you're going to help some people move in that direction if they want the same thing from this podcast.

Shaundai Person:
I hope so. I hope so. Don't come to me looking for a fight, come with ideas. Yeah, but I would love to be that type of change in the world. I'd love to connect with anybody who's interested in just talking shop, talking more. But yeah, come find me, or find me at a conference.

Paul:
Thanks, Shaundai, it was a pleasure.

Shaundai Person:
Thanks, Paul.