![\"\"](\"http:\/\/redmonk.com\/kholterhoff\/files\/2023\/03\/two-step-scaled.jpeg\")
<\/p>\n<\/p>\n
The future of React is always top of mind for the frontend community, which will inevitably be affected by shifts in this industry-leading JavaScript framework. Indeed, many developers are still reeling from React\u2019s 2019 decision for v16.8<\/a> to migrate from class-based components to hooks in order to introduce state and manage side-effects (although, mercifully for overworked devs, class-based components are still compatible<\/a>). What happens in React has far reaching repercussions.<\/p>\n In light of the ongoing SPA Wars<\/a>, frontend developers are closely following React\u2019s answers to complaints about shipping too much JS and (relatedly) their interest in the rise of compilers, all of which factors into the involved back-and-forth dance I\u2019m calling the server\/client two-step.<\/p>\n Code executed on the client-side has the best interactivity, but server rendered sites are more performant. There are recognized costs and benefits to both approaches, but a growing number of creators and users of JS frameworks argue for a return to the server. The HTML-first<\/a> philosophy, for instance, rejects client-rendered DOM generated by executing JS, and instead favors server-generated HTML. The increased adoption of “Component Islands,” usually shortened to just \u201cIslands\u201d (coined in 2019 by Katie Sylor-Miller<\/a>, frontend architect at Etsy), is another popular response. In the islands pattern, parts of the page are completely static server generated HTML, while other parts are self-contained interactive apps. Astro, 11ty, and Fresh all use islands.<\/p>\n Which brings me to the React Server Component (RSC). A recent episode of JS Party concerning \u201cThe future of React<\/a>\u201d delves deeply into this thorny subject, and is therefore worth discussing for its relevance to the server\/client two-step. In this conversation Dan Abramov<\/a>, creator of Redux, and Joe Savona<\/a>, part of Meta\u2019s React team, outline their vision for the future of React\u2014and, spoiler, it’s all about server components.<\/p>\n RSCs are a new feature in React 18<\/a>, and considered \u201cstill experimental.\u201d However, they have drummed up a significant amount of excitement. Huge names in the space including Vercel\u2019s Next.js<\/a>, Shopify\u2019s Hydrogen<\/a>, and Remix<\/a> have all announced their involvement in polishing this feature in order to ensure its success. And this enthusiasm from the community appears merited owing to its grand promise. According to Next.JS\u2019s documentation<\/a>:<\/p>\n React Server Components allow developers to build applications that span the server and client, combining the rich interactivity of client-side apps with the improved performance of traditional server rendering.<\/p><\/blockquote>\n React\u2019s answer to the server\/client two-step could be groundbreaking for the JS community. But what came across in the JS Party interview was the intractable complexity involved in balancing client with server in the frontend space. In host Jerod Santo<\/a>\u2019s words: \u201cI\u2019m sitting here thinking, all right, this sounds really complicated.\u201d Why this difficulty in communicating RSCs? According to Savona:<\/p>\n It\u2019s almost hard to talk about server components because depending on where you\u2019re coming from I think different pieces might appeal to you.<\/p><\/blockquote>\n Abramov echoes this sentiment:<\/p>\n With server components it is a little difficult to wrap your mind around if you are used to React because the way you add state, it forces you to create kind of a split point, so if you\u2019re used to just creating components and putting state anywhere, built in within JS app router<\/a> (that\u2019s [NextJS\u2019s] new version with server components) it does require you to learn how to compose components a little bit differently.<\/p><\/blockquote>\n Despite difficulties in terms of cognitive load, explaining how<\/i> RSCs work is of less importance than ensuring that<\/i> it works. Recall that server-side rendering (SSR) has long provided the kind of background optimization that work-a-day frontend engineers want, but don\u2019t necessarily need to understand in detail. And Abramov and Savona assure listeners that its server components do work. They explain that RSCs are currently in production in several projects including at Meta.<\/p>\n The complexity of RSCs is largely responsible for the bottlenecks and developer experience sacrifices Hydrogen noted last fall in their Roadmap<\/a>, which resulted in their decision to abandon server components. Although Hydrogen continues to harbor high hopes for this technology:<\/p>\n We\u2019ve found that keeping a clear separation around where your server is doing the work, and worrying less about how your server and client components might mix together, has resulted in a simpler developer experience that\u2019s less prone to mistakes. We also heard from a number of developers that with most of their pages requiring some level of interactivity, the mental model of routes in a .server file, with interactive components in .client components became repetitive and error prone.<\/p><\/blockquote>\n Although Andrew Clark<\/a>, a React core contributor currently working on React and Next.js at Vercel, assures the community that there are no hard feelings, the dream of harnessing the advantages of client and server in a single, well-packaged solution remains elusive.<\/p>\n Happy for my friends at @remix_run<\/a> and Shopify!<\/p>\n Even though Hydrogen is moving away from Server Components I deeply appreciate their work testing and iterating on the original proposal. Remix is great technology, and as RSC matures I hope it\u2019ll find its way into the framework. https:\/\/t.co\/MqhyAQQttn<\/a><\/p>\n — Andrew Clark (@acdlite) October 31, 2022<\/a><\/p><\/blockquote>\n\n