Dear Client, I'm Leaving You

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

With React Server Components and React’s new suspense SSR capabilities, we get an paradigm shift in the world of client/server side rendering. The pendulum that started in plain HTML pages, quickly swinged to all-client-rendering, is now returning to the server side. Emerging frameworks like Next.js and Remix usher a new era of web development, one where SSR is a first class citizen. In this talk we deep dive into those React features, talk about the state of the art practices regarding server rendering, and maybe get a glimpse into the exciting future of front-back-full-stack relationships.

This talk has been presented at React Summit 2022, check out the latest edition of this React Conference.

FAQ

The speaker is Liad Yosef, and the title of the talk is 'Dear Client, I'm Leaving You.'

The main topic of the talk is server-side rendering and its different paradigms and approaches, especially in React.

The three paradigms discussed are classic server-side rendering, client-side rendering, and the new server-side rendering.

In classic server-side rendering, the server generates the display markup and sends it to the client, which then runs the interaction logic. This approach was common about 15-20 years ago.

In client-side rendering, the client is responsible for generating the display markup and interaction logic. The server sends an empty container, and the client uses JavaScript (like React) to render the page.

In the new server-side rendering, the server generates the display markup, and the client handles the interaction logic. This approach has similarities to classic server-side rendering but utilizes modern technologies like React.

Server-side rendering has become important again due to faster networks, higher loading standards, and the need for better performance, SEO, and handling complex code efficiently.

Some of the performance criteria mentioned are Google's Core Web Vitals, including cumulative layout shift and large contentful paint.

Some of the rendering strategies discussed include static rendering, incremental static regeneration, full server rendering, and edge rendering.

React Server Components allow parts of a page to be rendered on the server without sending the rendering code to the client. This can significantly reduce the bundle size, sometimes by up to 90%.

Liad Yosef
Liad Yosef
21 min
21 Jun, 2022

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Liad Yosef discusses the importance and evolution of server-side rendering, highlighting its benefits such as improved performance and SEO. He explores different rendering strategies and the challenges of hydration in React. He introduces SuspenseSSL in React 18 as a solution for fetching data in advance and selectively hydrating components. He also mentions React Server Component as a game changer for reducing bundle size in rendering with React.
Available in Español: Querido cliente, te estoy dejando

1. Introduction to Server-Side Rendering

Short description:

In this part, Liad Yosef introduces himself and the topic of the talk, which is server-side rendering. He mentions the importance of discussing this topic and refers to a quote by Abraham Lincoln. He also mentions that the talk will focus on server-side rendering in React.

Hi. Hi, everyone. Thank you for attending my talk. I'm Liad Yosef. My talk is called Dear Client, I'm Leaving You. We're going to talk a little bit about server-side rendering, server-side rendering, and everything in between.

So I'm Liad Yosef. I'm the lead front-end architect in Douda. I'm a web enthusiast, and in my free time, I'm also an analog astronaut. I have the privilege of going to analog missions around the world, I really like space. So with this in mind, we will turn our talk into somewhat of a dark mode talk, and it will be a space theme.

So you might ask yourself, why do we need to talk about server-side rendering? Abraham Lincoln once said that if I had eight hours to chop down a tree, I'd spend six sharpening my axe, and Rick Sanchez added that the universe is much more complicated than you think. So be prepared for a 20-minute adventure on the rabbit hole of server-side rendering, and how do we approach it in React?

2. Understanding Server-Side Rendering

Short description:

In this part, Liad Yosef discusses the concept of server-side rendering and its evolution over time. He explains the difference between classic server rendering, client-server rendering, and new server-side rendering. Liad highlights the reasons for using server-side rendering, such as improved performance, better SEO, and addressing issues with client-side rendering. He also mentions the importance of considering performance criteria like cumulative layout shift and large contentful paint. Additionally, he references a talk by Rich Harris on the impact of single-page applications on the web.

It's not like we're watching Dan Abramov on Netflix. So I'll frame my talk a little bit like Netflix. There are a lot of topics to discuss. You can either choose performance or hooks or money heist, a web three or a grid game, but I will focus about server walls.

Server walls, that's something that we need to learn. We need to understand in order to really understand the client-server relationship. And we will start with a small history one-on-one on the client-server walls. So when we talk about classic server rendering, what are we talking about? So in classic server rendering, the product that was common about 15 or 20 years ago, the server generates a display markup and the client runs the interaction logic. You can think about PHP or JSP or everything else that you are familiar with. So in classic server rendering, the browser asks for the server to assemble the page. The server assembles the page on the server side, sending the flat markup into the client and the client gets the markup. That's the classical server rendering. And if they want to make their markup interactive, they just ask the server to send the milestone, the JavaScript, to make them useful. That's classic server rendering.

In client-server rendering, that's a paradigm we started working with about 10 years ago, the client is in charge of generating the display markup and the interaction logic like in React. So, the client asks to assemble the page and the server just sends an empty container and then it's the client's responsibility to ask for React or the JavaScript code to render it themselves. React renders the markup and if there's something else that the client wants, they can ask for the server for another JavaScript code to render the missing part. That's client side rendering. In the new server side rendering, which is the paradigm that we started to work with about two or three or four years ago the server is in charge to generating the display markup and the client is in charge of running the interaction logic. Wait, what? I mean, we've just come full circle from the PHP of 20 years ago to the server side rendering of today. Well, you need to remember that React is a templating language. So you can use it in the server in order to template as well. You might ask yourself why? What is the reason of doing server side rendering? Well, in the past, when we had slow network speeds and slow devices, we had to do everything on the server, right? Because the client wasn't strong enough or powerful enough to render it. As devices became stronger and the customers wanted more complex apps, we shifted rendering into the client. But now as the networks become really fast and there's a lot of complex code that is being sent to the client and our loading standards have become higher, so we want things to be loaded much faster, we have to shift the rendering back to the server. If we talk about performance, those are two criteria that Google checks in their Core Web Vitals. Then cumulative layout shift actually checks what happens when the client renders the markup, but something pops out in between because the client is rendering it incrementally, and then you click on something that you didn't want to click. Or large contentful paint, how much time does it take the client to fetch the data in order to render something, which is a problem in clients' underrendering world. SEO is also a problem, because when Google tries to index our page, they go into the server, they ask for the page, and if the server returns just an empty container, Google doesn't know how to index our page. There's a really good talk by Rich Harris called, Single Page Application Ruined the Web, and generally there's a really good talk in the Twitter sphere, or in the web, about Single Page Application versus Multipage Application, where some people say that multipage applications fall short because they don't give the experience that we want, and other people say that single-page applications, because they load really slow, don't give the performance that we want.

3. Understanding Rendering Strategies and Spectrum

Short description:

There's a debate about single-page applications versus multipage applications. Rendering involves who builds the markup, how it becomes interactive, when it's built, and where it's served from. Static rendering provides the same page for everyone, easily cached but not personalized. Client-side rendering allows for personalization but can't be cached and has slow first loads. Incremental static regeneration generates some pages on demand. Real-time server-side rendering is used for personal content. React level components are suitable for web apps with static and dynamic parts. Classic static rendering relies on the cache for serving pages. Incremental static rendering generates variations in the cache. The server is still required, and caching can be triggered by the cache itself.

There's a really good talk by Rich Harris called, Single Page Application Ruined the Web, and generally there's a really good talk in the Twitter sphere, or in the web, about Single Page Application versus Multipage Application, where some people say that multipage applications fall short because they don't give the experience that we want, and other people say that single-page applications, because they load really slow, don't give the performance that we want. That's an ongoing debate.

But in order to understand a little bit what we are talking about, we need to understand what we are talking about when we talk about rendering. So, rendering 101, we talk about who builds the markup. It can be either the client, the server, or the edge in between. How does it become interactive? Is it the client that makes it interactive? Or is it the JavaScript code that makes it interactive? Is it the native browser functions? Or is it the React that makes it interactive? When is it being built? Is it being built in build time or in runtime? And, of course, where is it served from? Is it being served from some sort of an edge network, or a cache, or the server itself?

So, if we think about a simple blog, for example, which is very static, then we know that it is being built in build time, it is being interactive. We're using JavaScript code. The server is building it, and it's being served from the cache, right? Because you don't need to rebuild it in runtime. But if you have a complex web app, that's something that the client is building, probably using React or some other frameworks, and it requires server. It requires a runtime server in order to operate. So, if we think about those two parts, those two edges of you have server-side rendering for very static, simple pages, on the one hand, and you have client-side rendering for very complex web apps, on the other hand, you can put them on a spectrum, because those are not the only two options that we have. So, in static rendering, which is the server-side rendering in build time, you're getting the same page for everyone, and it can be easily cached, but it cannot be personalized. And you cannot have variants, because you need to build everything in build time, and it requires a build for every update, whereas in the client-side app, which is the most dynamic, it can be easily personalized because you do it on demand in the request, but it cannot be cached, and it has slow first loads and slow data fetches, because you have to go to the server for everything, but it has fast in-app responsiveness. But we need to remember, this is a spectrum, so, if I want to build a listing page, and I want for every page in the listing to be different, because I have 10,000 properties that I want to list, then I can use something that's called incremental static regeneration, which is not just generating everything on build time, but generating some of them in build time, and some on demand. If I want to build something that is more personal, like my bookings, or my account, or things that need my data, need my cookies in order to present, then I would have to go with real-time server-side rendering, because I can't cache anything, and, on the other hand, if I want to build a web app, but most of the parts of the web app are static, and only parts are dynamic, I would go with React level components. We will talk about all these strategies.

So, when we talk about SSL strategies, or the multiverse of madness, we need to remember that when we speak about static rendering, we no longer talk about only the client and the server. We need to put something in between, which is the edge network, or the cache, and then we can discuss about the relations between the client, the edge, and the server. In classic static rendering, which is like we saw, the blog pages, the server generates the page on build time, and it sends the page to the cache, to the edge network, and then it goes out of the picture. We don't need the server anymore. It just generated the page, and that's it. The client asks the cache or the edge for the page, and it gets the page, it gets the blog post, and it's important to understand. It's important to notice that all of the clients will get the same page because they all ask it from the cache. Like we said, the pages are easily cached, and they do not require a server, and they have great performance, but they do need rebuild for every update, and there's a problem with data fetching.

In incremental static rendering, the server builds the page, sends it to the cache to be cached, but it also builds a lot of variations, a lot of other variations in the cache, and when the client asks the cache for a page, they get the page, and another client can ask for another page, and they will get another page, but if a third client asks for a page that does not exist on the cache or in the edge network, then it goes directly to the server. The server generates it in real time and sends it to the cache, caches it, and then the client talks to the cache and gets this page. It is like the best of both worlds, but you do still need a server. It can also be triggered by the cache. You can do an invalidation time. For example, if you have a page that needs to be revalidated or refreshed every couple of minutes, then when the client asks the cache for the page, the cache can say this is the page that you want, and the next client, the cache can say, hey, the page is stale, asking the server to regenerate it, while at the same time serving the stale page to the client, and then the server regenerates a new page, replaces it in the cache, and then the next client will get the updated page, which is pretty nice.

4. Rendering Strategies and Hydration

Short description:

Incremental static rendering allows for caching and reduces build times for multiple pages, but cannot reflect user-specific data. Full server rendering provides highly personalized content and unique pages without a build process, but has a long response time. Edge rendering combines the benefits of rendering and the edge network, allowing for fast and streamed HTML. Hydration, the process of making the markup interactive, is a challenge as it requires sending all the code to the client and cannot be partially hydrated. React is working on solutions such as suspense and other components.

That can also be triggered from the server. So it can be triggered when the server gets new data, it can say, hey, it's been a few minutes since I updated the cache, it can generate a new page or an updated page, replace it in the cache, and then the next client that will ask it from the cache will get the updated version, which is nice.

So in incremental static rendering, it is easily cached, it's very cache heavy, you still rely on cache, it reduces build times for multiple pages, so if you have thousands of blog posts, you don't have to build all of them in advance, but it does require a server, and it cannot reflect user-specific data, because you don't really go to the server and generate a unique page, and the trips to the server are long.

Full server rendering, that's something that's what we call server-side rendering, we have to remember that the cache is no longer in the equation, the client speaks directly to the server, so the client can ask a highly personalized page, for example, account details, my account or my listings, and the server will build it, and it will send to the client something that's very unique to that client. And if another client will ask the server for the page, the server will build something else completely, because that's a different client, a different customer, and they will send it to them.

So, in full server rendering, we get a very highly personalized content and unique pages, and we don't need a build process, which is important, but it does require a server, and we still have the long response time from the server. Why the long response time? Because if we look at the server code, for example, we can see that the line that is relevant here is a render to string, and this line is synchronous, so we need to render everything before we can send the page, and that's a problem. And we will discuss some ways to solve it soon.

And there are voices that say that if your server-side rendering takes more than 200 milliseconds, maybe it's better to do client-side rendering instead.

And now the new thing that everyone is talking about is edge rendering or using the edge network in order to render, and that's like having the best of both worlds, because if we have the edge network that is being spread around the globe, we can use it to render the pages. We don't have to do drifts to the server. So if we just join the rendering and the edge network, we can have something like this. We can have the edge around the world, the client asks for a person-like page from the edge network. The edge network builds it and returns it in real time. But since the edge, it's like a CDN, so it's spread all across the globe, you get the edge point that is closest to the client, which makes it fast. So edge rendering will allow streaming, because now that you have fast times and short times between the edge and the client, you can stream HTML to the client so the client can see parts of the HTML as they are being rendered. It does require an edge network and Next supports it, Remix is going to support it, Netlify has Netlify edge functions, which is pretty awesome. So that's something that you want to take a look at.

And now let's talk about our nemesis, our enemy, hydration. So hydration is actually the process that's happening in the client after they get the markup. And that's a problem, because if you think about it, who is giving life to the markup? It can be either the browser that is using native browser interactions like form submits and drop downs and things that the browser know how to handle. That remix is heavily relying on this. Or it can be JavaScript, right? So the browser can ask for the server to send some JavaScript code in order to make the markup alive or interactive. Or it can be React. But React does hydration, meaning that it builds all the markup in the server and then the server sends it to the client and then the client has to ask React again in order to rebuild the markup, which is pretty wasteful, rebuild the markup. And only then it adds the interaction logic, right? So this is a React based hydration and in React, we need to send to the client both the rendering code and the interaction code, which makes you wonder if the only code that we need is this is the interaction code. Why do we need to send all of this to the client? So hydration is becoming a problem because you have to send all the code to the client and because you can't really partially hydrate. You have to wait for all the code to get to the client until you can hydrate. And you can read the Steve Sower, he has a really good blog post on that. And React is trying to solve it with suspense as a start and React's other components.

5. Using SuspenseSSL for Server-Side Rendering

Short description:

So a short primer about suspense. Our problem with SSR is that we need to fetch all the data in advance in the server, load all the JavaScript before the hydration, and then hydrate everything before you can interact with it. If you want to build a website of mentorship to the Avengers, you have to fetch everything in advance, which is hard. But SuspenseSSL comes to our rescue in React 18. React introduced streaming HTML and SelectiveHydration, allowing us to stream HTML to the client and hydrate selectively. Instead of using render to string in the server and hydrate in the client, we can use rent to pipe of the stream and hydrate root in the client. The same suspense code will be rendered in the server and sent to the client. React will hydrate whatever it can in the client, and when the reviews are ready, the server will push a script to replace them in the markup.

So a short primer about suspense. If we want to render something lazily, like here, we want to render mouse only if Elon Musk is present. We wrap it in suspense and then we get a nice spinner if you want. And only when Elon Musk arrives, we can render mouse. So this is the idea of suspense.

And our problem with SSR, like we said, is that we need to fetch all the data in advance in the server, load all the JavaScript before the hydration and then hydrate everything before you can interact with it. So it's like a waterfall. Server fetches all data, then the server renders the entire HTML and sends it to the client. Then the client loads the entire JavaScript code, then it needs to hydrate the entire app. So that's a problem.

So if you want to build a website of mentorship to the Avengers and you call it mentor and for example, everyone can select a mentor of their choosing, and you have the mentor page, which is that you have the image and the reviews on the mentor and the name of the mentor, right? So you build it in React. It's pretty simple. You have the name, the image, the description, and the reviews. And let's say that you want—so if the server renders it, it's really simple. So the server just renders it into markup, sending it to the client, and then React does its magic in the client and it becomes interactive and that's amazing. But let's say that you want the mentor image and the mentor reviews to be lazily loaded. Maybe it takes a lot of time to pull the reviews from the third-party data source. So you want to wrap it, let's say, in suspense, right? You would wrap it in suspense with a fallback. But then you have a problem with the SSL, because React will render it in the server, but it doesn't know what to do with the suspense part. It doesn't know, because it's not there, so it will send it to the client, but React in the client doesn't really know what to do. So that's a problem, because you have to fetch everything in advance. And this is the part where SSL is becoming hard. That's why we didn't really utilize SSL in large scale until a few years ago, because it's hard. But SuspenseSSL comes to our rescue in React 18. React introduced streaming HTML, the ability to stream HTML to the client, and SelectiveHydration, the ability to hydrate selectively parts of the clients. So instead of using render to string in the server and hydrate in the client, we can just do rent to pipe of the stream and hydrate root in the client. And then the same suspense code will be rendered in the server with the loading with the spinner and being sent to the client. Then React will hydrate whatever it can in the client. And only when the reviews will be ready, the server will push to the client some sort of a script that said, hey, the reviews are ready. Just replace them in the markup, which is pretty amazing.

6. React Server Component and Bundle Reduction

Short description:

React Server Component is a game changer for rendering with React. It allows you to define parts of a page as server components, which can go to the database and bundle dependencies without being shipped to the client. By defining only the interactive part as a client component, the bundle size can be reduced by 90%. Check out Dana Bramov's talk and the server component RFC for more information.

And it also knows to do SelectiveHydration. So if several parts of the page are being hydrated and the user clicks on one of them, then React automatically prioritize this part to be hydrated and they know to replay the clicks on this part, which is pretty awesome. React Server Component is also a game changer. It basically means, I won't dive into it because there was another talk on that, but it basically means that if you have a page, that most of the page is statically rendered, you don't need a lot of interaction code, you don't need React, but you want to render it with React. Let's, for example, just the mentor rating is something that you want to be interactive. Then you can just define some part of the page as server components, and those parts can go to the database and they can bundle a lot of dependencies, but none of them will be shipped to the client. So if you just define parts as server components and only your interactive part you define as client component, then only this client component will be bundled and sent to the browser and that can reduce bundle in 90%, which is pretty amazing. There's a good talk of Dana Bramov on that, I recommend you to read server component RFC, it's very informative.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Simplifying Server Components
React Advanced 2023React Advanced 2023
27 min
Simplifying Server Components
Top Content
Watch video: Simplifying Server Components
React server components simplify server-side rendering and provide a mental model of components as pure functions. Using React as a library for server components allows for building a basic RSC server and connecting it to an SSR server. RSC responses are serialized virtual DOM that offload code from the client and handle interactivity. The client manifest maps serialized placeholders to real components on the client, enabling dynamic rendering. Server components combine the best of classic web development and progressive enhancement, offering the advantage of moving logic from the client to the server.
Exploring React Server Component Fundamentals
React Day Berlin 2023React Day Berlin 2023
21 min
Exploring React Server Component Fundamentals
Top Content
Watch video: Exploring React Server Component Fundamentals
This Talk introduces React Server Components (RSC) and explores their serialization process. It compares RSC to traditional server-side rendering (SSR) and explains how RSC handles promises and integrates client components. The Talk also discusses the RSC manifest and deserialization process. The speaker then introduces the Waku framework, which supports bundling, server, routing, and SSR. The future plans for Waku include integration with client state management libraries.
And Now You Understand React Server Components
React Summit 2024React Summit 2024
27 min
And Now You Understand React Server Components
Top Content
In this Talk, Kent C. Dodds introduces React Server Components (RSCs) and demonstrates how to build them from scratch. He explains the process of integrating RSCs with the UI, switching to RSC and streaming for improved performance, and the benefits of using RSCs with async components. Dodds also discusses enhancements with streaming and server context, client support and loaders, server component rendering and module resolution, handling UI updates and rendering, handling back buttons and caching, and concludes with further resources for diving deeper into the topic.
A Practical Guide for Migrating to Server Components
React Advanced 2023React Advanced 2023
28 min
A Practical Guide for Migrating to Server Components
Top Content
Watch video: A Practical Guide for Migrating to Server Components
React query version five is live and we'll be discussing the migration process to server components using Next.js and React Query. The process involves planning, preparing, and setting up server components, migrating pages, adding layouts, and moving components to the server. We'll also explore the benefits of server components such as reducing JavaScript shipping, enabling powerful caching, and leveraging the features of the app router. Additionally, we'll cover topics like handling authentication, rendering in server components, and the impact on server load and costs.
Server Components: The Epic Tale of Rendering UX
React Summit 2023React Summit 2023
26 min
Server Components: The Epic Tale of Rendering UX
Top Content
Watch video: Server Components: The Epic Tale of Rendering UX
This Talk introduces server components in React, which provide an intermediate format for rendering and offer advantages for both client-side and server-side rendering. Server components reduce bundle size on the client and improve search engine optimization. They abstract the rendering process, allowing for faster rendering and flexibility in choosing where to render components. While server components are still in the experimental stage, Next.js is a good starting point to try them out.
RSCs In Production: 1 Year Later
React Summit 2024React Summit 2024
24 min
RSCs In Production: 1 Year Later
This Talk explores the experience of shipping server components in production and highlights the benefits and challenges of using Server Components in Next.js apps. The Talk discusses the deployment of UploadThing and the use of AppRouter for safe production usage. It delves into the implementation of different layouts, data fetching, and code centralization for improved performance. The Talk also covers the use of server components for performance optimization and latency handling. Additionally, it explores the use of Edge and Lambda for partial pre-rendering and the challenges faced with webpack performance and hydration. Overall, the Talk emphasizes the benefits and challenges of working with Server Components in Next.js applications.

Workshops on related topic

Mastering React Server Components and Server Actions in React 19
React Summit US 2024React Summit US 2024
150 min
Mastering React Server Components and Server Actions in React 19
Featured Workshop
Maurice de Beijer
Maurice de Beijer
Calling all React developers! Join us for an immersive 4-hour workshop diving deep into React Server Components and Server Actions. Discover how these game-changing technologies are revolutionizing web development and learn how to harness their full potential to build lightning-fast, efficient applications.

Explore the world of React Server Components, seamlessly blending server-side rendering with client-side interactivity for unmatched performance and user experience. Dive into React Server Actions to see how they combine client-side interactivity with server-side logic, making it easier to develop interactive applications without traditional API constraints.

Get hands-on experience with practical exercises, real-world examples, and expert guidance on implementing these technologies into your projects. Learn essential topics such as the differences between Server and Client Components, optimizing data fetching, passing data effectively, and maximizing performance with new React hooks like useActionState, useFormStatus and useOptimistic.

Whether you're new to React or a seasoned pro, this workshop will equip you with the knowledge and tools to elevate your web development skills. Stay ahead of the curve and master the cutting-edge technology of React 19. Don't miss out - sign up now and unleash the full power of React!
Next.js 13: Data Fetching Strategies
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
Workshop
Alice De Mauro
Alice De Mauro
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
The Gateway to Backend: A Frontend Developer's Guide to Full-Stack Development
React Summit US 2023React Summit US 2023
160 min
The Gateway to Backend: A Frontend Developer's Guide to Full-Stack Development
Top Content
WorkshopFree
Amy Dutton
Amy Dutton
This workshop will guide you through the product development life cycle of creating a real-world web application. You will learn about React Server Components, building a design system within Storybook, and using frontend development to approach becoming a full-stack developer. The workshop will cover increasing confidence in your application with unit tests and implementing authentication and authorization. You'll have the opportunity to work through product features and examine a real-world RedwoodJS project, gaining valuable experience in real-world product development. RedwoodJS makes it simple to approach full-stack development, and this workshop will give you the skills you need to create your own real-world web applications.
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
JSNation 2023JSNation 2023
174 min
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
Top Content
WorkshopFree
Alba Silvente Fuentes
Roberto Butti
2 authors
This SvelteKit workshop explores the integration of 3rd party services, such as Storyblok, in a SvelteKit project. Participants will learn how to create a SvelteKit project, leverage Svelte components, and connect to external APIs. The workshop covers important concepts including SSR, CSR, static site generation, and deploying the application using adapters. By the end of the workshop, attendees will have a solid understanding of building SvelteKit applications with API integrations and be prepared for deployment.
Advanced Application Deployment Patterns with React Server Components (feat. a DIY RSC Framework)
React Summit US 2023React Summit US 2023
104 min
Advanced Application Deployment Patterns with React Server Components (feat. a DIY RSC Framework)
Top Content
Workshop
 Greg Brimble
Greg Brimble
The developer ecosystem is always moving fast and this year has proved no exception. React Server Components can offer a significant improvement to developer experience and to application performance. But I think it's fair to say that this new server-first paradigm can be tricky to wrap your head around!In the first half of this workshop, we'll explore React Server Components from the ground-up: building our own mini meta-framework to help us understand how RSCs work. We'll discover exactly what is produced by an RSC build and we'll connect those pieces together to form a full application.Next, we'll deploy it! Cloudflare have also had a busy year too — Smart Placement, in particular, is a new technology that we've developed which fits the RSC model perfectly. We'll explore why that makes sense for our workshop app, and we'll actually deploy it onto the Cloudflare Developer Platform.Finally, we'll build out our app a little further, using D1 (our serverless SQL database) to really show off the React Server Component's power when combined with Smart Placement.You should come away from this workshop with a greater understanding of how React Server Components work (both behind-the-scenes and also how you as a developer can use them day-to-day), as well as insight into some of the new deployment patterns that are now possible after recent innovations in the platform space.
Building Reusable Server Components in NextJS
React Summit US 2023React Summit US 2023
88 min
Building Reusable Server Components in NextJS
Top Content
Workshop
Will Bishop
Mettin Parzinski
2 authors
React continues to evolve their beta capability, React Server Components, and they're continuing to further develop them in partnership with frameworks like NextJS.In this workshop, attendees will learn what React Server Components are, how to effectively build and use them in NextJS, and focus on one of the major advantages of React/NextJS: reusability through components.We will also cover related beta technologies enabled by the `app` directory, such as nested layouts and server actions (alpha/experimental capability).Join us for this hands-on, 120 minute workshop!Technologies:
React, JavaScript/Typescript, NextJS, Miro