Telerik blogs

React Server Components look to be the future of React, and you can already use experimental RSCs in KendoReact. See what this could mean for you!

Even if you haven’t been keeping a close eye on the React world lately, you’ve probably still heard the buzz about React Server Components (RSCs). If you’re looking for a crash course on what they are and why they’re so popular right now, check out our earlier post The Current State of React Server Components: A Guide for the Perplexed.

As a quick summary: RSCs are still in beta, but they’re looking more and more like the future of React—and the Progress KendoReact team is ahead of the curve, already including several experimental Server Components as part of our component library. So what’s the practical impact of that for you: a developer building apps with KendoReact? Let’s take a look.

Server Components or Client Components: Why Not Both?

When we’re talking about the advantages and disadvantages of Client vs. Server Components, it’s important to start by saying that it’s not a “one or the other” kind of thing. The two approaches are meant to be used in tandem, supporting each other and working seamlessly together.

While we’re still figuring out what best practices and common patterns will look like for this new technology, the current suggested approach is a parent-child relationship with Server Components as the parent and Client Components as the child. That’s because the two different component styles have very distinct strengths:

  • Server Components excel at performance—fetching large amounts of data quickly and rendering it with ease, significantly lowering the bundle size. However, because the rendering of the component is done on the server, user interaction options are limited. There are hybrid approaches that can be employed, but for the most part, Server Components really shine when they’re used in situations where a lot of data needs to be rendered or you want to keep a big dependency on the server. That’s part of why the Server DataGrid is one of the first Server Components we added to KendoReact.
  • Client Components, on the other hand, are what you want to reach for when you need to create stateful content and interactive elements within your React app. Because they render on the client side (aka: in the user’s browser), they’re perfect for situations when your application needs to respond to various user inputs. The 100+ beautiful, accessible and highly functional KendoReact components that you already know and love are Client Components.

Because of that, it’s most likely that apps you create will call for a mix of Server and Client Components. Making a choice to use exclusively one or the other would actually limit the functionality of your app.

Of course, that will depend on what you’re building: an application that’s meant to simply show data to users and doesn’t include any interaction might not need Client Components, while an application that’s heavily stateful or doesn’t include any large dependencies might not call for Server Components. Ultimately, you—the developer—will be the one who decides what’s best for your specific application.

Why Add React Server Components to KendoReact?

The short answer is: because we want to make your development process as easy as possible! Ultimately, the goal of any component library is to improve the workflow of the developer using it.

While Server Components are still technically in beta (i.e., not included in the standard, stable release of React), we know that they’ll be included with the stable version of React 19. Furthermore, there are many frameworks that are already starting to embrace them—including, notably, Next.js, a framework that we know many of our developers are already using.

It’s important for us to keep pace with trends in the React world—or, better yet, be the ones blazing a trail, figuring out new and exciting ways to leverage cutting-edge technologies. The development of these new components involved a lot of learning, as well as a lot of trial and error on our side. If you’re interested in hearing more about that process and getting a peek behind the curtain at what our RSC development process looked like, check out our recent stream: Data Decisions: React Server Components and KendoReact!

Screenshot of the experimental disclaimer on the KendoReact Server Components documentation page

We’re proud to be early adopters of RSCs, and we believe that they significantly enhance the value of our library. Our goal is always to broaden the range of use cases that we can address with our components. That being said, it’s important to keep in mind that React Server Components are still in beta—which means they’re experimental in our library as well. We’d love for you to try them out and let us know what you think, but it’s always smart to be thoughtful about using beta technologies in production.

In the meantime, we’ll continue creating and launching new Server Components. Keep an eye on the Server Components section in our documentation to see what’s currently available. We also publicly share our roadmap, so you can always check out that page to see what’s coming in the next release! And, of course, we welcome you to request a feature if there’s something you’d like for us to add or expand within the library—whether that’s Server Component–related or not!

And if you aren’t already using KendoReact, you can try it free for 30 days:

Try KendoReact

About the Author

Kathryn Grayson Nanz

Kathryn Grayson Nanz is a developer advocate at Progress with a passion for React, UI and design and sharing with the community. She started her career as a graphic designer and was told by her Creative Director to never let anyone find out she could code because she’d be stuck doing it forever. She ignored his warning and has never been happier. You can find her writing, blogging, streaming and tweeting about React, design, UI and more. You can find her at @kathryngrayson on Twitter.

Related Posts


Comments are disabled in preview mode.