React Server Components: A New Way to Build Fast and Interactive Web Apps

React Server Components are a new feature that lets you render React components on the server and stream them to the client. This enables you to build rich user interfaces with minimal client-side code, while still preserving interactivity and performance.

In this talk, you will learn how React Server Components work, how to use them in your web apps, and what benefits they offer over traditional approaches. You will also see some real-world examples of React Server Components in action and get some tips and best practices for adopting them in your projects.

Transcript

1. React Server Components: A New Way to Build Fast and Interactive Web Apps Aurora Walberg Scharff @aurorascharff
2. React Server Components: Why should you care?
3. Introduction > Aurora Walberg Scharff > Consultant at Inmeta > Norway, Oslo > Full-stack, web-focused: active RSC developer
4. Talking points > Rendering strategies > React Server Components > Next.js App Router > RSC in Next.js “the right way” > Demo > Real world experience > The future of RSC
5. Rendering strategies
6. Static website rendering > Pages are pre-assembled and uploaded to a static host > Simple and efficient > Struggles with dynamic data and impractical to maintain
7. Multi-Page Applications (MPAs) > HTML and data are dynamically merged on the server > Serves the merged result on page load > Page reloads per request
8. pros ✓ Optimized for SEO ✓ Unlimited scalability ✓ More website insights Multi-Page Applications (MPAs)
9. pros ✓ Optimized for SEO ✓ Unlimited scalability ✓ More website insights cons × Slower overall performance × More development time × Hard to maintain Multi-Page Applications (MPAs)
10. Single-Page Applications (SPAs)
11. Single-Page Applications, pros ✓ Instantaneous, app-like feel ✓ Easy to debug ✓ Caching capabilities
12. Single-Page Applications, cons × Slow initial load × SEO suffers × Needs JavaScript × Favors modern browsers × Less secure
13. SPA vs. MPA lifecycle
14. Server-side rendering (SSR) > Pre-render the initial HTML on the server > Fully-formed HTML when opening the page > JavaScript is fetched alongside it
15. Static site generation (SSG) > Pages are pre-assembled and uploaded to a static host > Requires site redeployment whenever data changes > JavaScript is fetched alongside it
16. Server-side rendering (SSR) > Included feature in JavaScript “meta-frameworks” > Build time (SSG) and/or request time (SSR) > Pages generated in the build can be cached
17. Hydration
18. Hydration Hydration is like watering the “dry” HTML with the “water” of interactivity and event handlers. - React core team member Dan Abramov https://github.com/reactwg/react-18/discussions/37
19. Server-side rendering
20. The problem
21. The problem 1. You have to fetch everything before you can show anything 2. You have to load everything before you can hydrate anything 3. You have to hydrate everything before you can interact with anything
22. Strategies to improve it > Partial hydration: only attach JS to certain components > Progressive hydration: lazy load JS to certain components > Selective hydration: priority load JS to certain components based on user interactivity
23. Streaming > Split a request into chunks > Send each chunk as a stream to the client > Render each chunk as it is streamed in
24. React Server Components
25. What are they?
26. “The server”
30. Interactive/Client Components
33. How do they work?
34. The RSC Payload
39. Benefits of using RSC
40. Benefits ✓ Data fetching + access to backend resources
41. Benefits ✓ Data fetching + access to backend resources ✓ Security
42. Benefits ✓ Data fetching + access to backend resources ✓ Security ✓ Caching
43. Benefits ✓ Data fetching + access to backend resources ✓ Security ✓ Caching ✓ Bundle size + performance
44. Benefits ✓ Data fetching + access to backend resources ✓ Security ✓ Caching ✓ Bundle size + performance ✓ Streaming + suspense integration
45. Benefits ✓ Data fetching + access to backend resources ✓ Security ✓ Caching ✓ Bundle size + performance ✓ Streaming + suspense integration ✓ Developer experience
46. Drawbacks of using RSC
47. Drawbacks × Require a framework
48. Drawbacks × Require a framework × Increased complexity
49. Drawbacks × Require a framework × Increased complexity × Learning curve
50. Drawbacks × Require a framework × Increased complexity × Learning curve × Early adoption
51. Next.js 13/14 and App Router
53. |
58. RSC in Next.js “the right way”
66. Data management
69. Server Actions
70. Server Actions > Define a function/file with “use server” > Next.js creates a “hidden” API endpoint for you > Use the function in any component > Provides a type-safe RPC-experience
75. Demo
78. Real world experience
79. Requirements > Interactive dashboards > Complex forms > Articles through a CMS, static data > Need for SEO > Mobile friendly and accessible > Multiple language support > Customer’s own UI library
80. cons × Wrappers for custom library × Trial and error i18n × Limited testing resources Experience
81. pros ✓ Performant app that fulfills requirements ✓ Maintainable app code ✓ Enjoyable DX Experience cons × Wrappers for custom library × Trial and error i18n × Limited testing resources
82. The future of RSC
83. Resources My GitHub repo: aurorascharff/next14-remix-jokes-rebuild
84. Resources > Vercel Next.js App Router docs > Vercel template apps and examples > Vercel “Learn Next.js” free course
85. youtube.com/@codewithantonio youtube.com/@bytegrad
86. Thank you Twitter: @aurorascharff GitHub: @aurorascharff Blog: aurorascharff.no
87. Questions?