Building RSCs Framework on Rust: Architecture Decisions That Delivered 45x Performance

So, a quick correction before we get started. When I submitted this talk, the performance number was 45x. By the time I finished preparing, it was 67x. That's kind of the story of this whole project. I kept getting things wrong, fixing them, and watching the numbers jump.

So let's talk about that. I'm Ryan Skinner from Toronto, Ontario, Canada, and I've been building for the web for about 25 years now. I started with Perl CGI scripts, went through the PHP era, survived jQuery, and landed in React like most of us. Last year I started building RARI, which is a React Server Components framework that runs on a Rust runtime.

And the reason I'm here today isn't really to talk about Rust. It's to talk about what happens when you get React's architecture wrong and what happens when you get it right. The question that started all of this was simple. What happens if you remove Node.js from the runtime, but keep V8? Not, what if we rewrite everything in Rust? Not, what if we abandon the JavaScript ecosystem? Just, what if the thing sitting between your React components and the network wasn't Node.js? What if it was something thinner? Something without garbage collection pauses? Something that could handle concurrency differently? V8 is an engine that runs your JavaScript. Node.js is a runtime built around it.

What if we kept the engine, but replaced the runtime? Here was the bet: keep React, V8, NPM, components, everything familiar, but eliminate Node.js from the production runtime layer. Replace it with Rust and direct V8 integration. The hypothesis - performance issues in server-side React stem from layers around it: event loop, garbage collector, host concurrency. By stripping these and optimizing V8 with Rust, significant improvements could occur. In July 2025, the first version was released with three distinct layers.

The architecture comprises the Rust core runtime as an HTTP server with embedded V8 engine and Deno core bridge. The build layer utilizes Vite with RscAware transformations for code handling. React server components with streaming support form the third layer, emphasizing independence among the architecture's layers.

Keep your components. Keep everything you know and love about writing React apps. But remove Node.js from the production runtime layer. And replace it with Rust and direct V8 integration. The hypothesis was that the performance overhead in server-side React isn't coming from React itself or from V8, it's coming from the layers around it. The event loop. The garbage collector. And the host concurrency. If you strip those away and let V8 do its job, and set a more efficient host, maybe those numbers change significantly.

So I built it. And in July 2025, I shipped the first version. The architecture has three layers. And they're deliberately independent of each other. Layer one is the Rust core runtime. This is an HTTP server built on Axum with an embedded V8 engine, using Deno core as the bridge, and this handles all the incoming requests and executes your React components. Layer two is the build layer. This is just Vite. Extended with RscAware transformation. It handles code splitting, tree shaking, and the client-server boundary detection. It's nothing exotic here. It's just standard Vite with plugins.

Layer three is React server components with streaming support. Your components, your JSX, running on the server and streaming to the client. The key insight is that these layers don't depend on each other in the way that you might expect. The HTTP server doesn't need Node.js. The build layer is standard JavaScript tooling. And React doesn't care what's hosting V8, as long as V8 is there. Here's how the runtime actually works. There are two sides that operate independently. The HTTP server is Axum.

Running on Tokyo across multiple OS threads. It handles all incoming connections, TLS, routing, compression, pure Rust, no JavaScript involved. The JavaScript runtime is V8, wrapped by Deno core, running on its own dedicated single thread and its own separate Tokyo runtime. The two sides communicate exclusively through a message channel, not shared memory, not function calls, a channel.

Now, I know what you're thinking. A message channel between an HTTP server and a single JS thread probably sounds like it'd be a bottleneck. Hold that thought and we'll come back to that. The important thing for now, the HTTP side has no garbage collection, ever. It's Rust. It handles thousands of concurrent connections without pausing.

Here are the numbers from the first release. Same application built in both frameworks, same components, same data fetching patterns. Tested with 50 concurrent connections for 30 seconds. Four times faster average response time. Nearly four times higher throughput. Almost six times faster builds. These are solid numbers. I was happy about them. I wrote a blog post. People are interested.

And I thought I was done. RSC rendering worked. Components ran on the server. The performance was already impressive. And Rust as fast seemed like a sufficient explanation for why. It wasn't.

The architecture had three fundamental gaps, and Rust couldn't save me from any of them. Here's the first thing that I got wrong. I deliberately made components client-side by default. It was an intentional design choice. In my model, you'd mark things with USERVER to opt into server rendering. It seemed like a cleaner mental model. You're explicitly declaring what runs on the server. You're being intentional about it.

But the consequence was that every component without a directive shipped to the client bundle, including components with zero interactivity. A component that just renders a heading and some text? Client bundle. A component that fetches data and displays it? Client bundle, unless you remembered to mark it. I kept experimenting with different approaches to fix this. Better tree shaking, smarter bundling, but the bundle just kept growing. React's actual model is the inverse. Server components are the default. You don't need a directive.

They just run on the server. USE client is how you opt into interactivity. You're saying this component needs to hydrate because it has state or event handlers. And USERVER doesn't mark server components at all. It marks server functions. Actions, mutations, things you call from the client that execute on the server. Three distinct concepts, and my design had merged two of them into one.

So here's why this matters so much for performance. With my model, client-side by default, every component ships to the client. You have to manually opt out. Your bundle grows linearly with your application size. Optimization means fighting the default at every step. With React's model, server by default, only interactive code ships to the client. You have to manually opt out. Or you have to manually opt in. Your bundle only grows with interactivity. Optimization means doing nothing. The default is already optimal.

I kept trying to optimize the bundle when the real problem was the default was backwards. No amount of tree shaking fixes a wrong default. The standard model isn't just a convention. It's genuinely the better architecture. It's genuinely the better architecture for performance. The second gap, we didn't have an app router yet. We shipped with file-based routing, a pages router, and it worked. You could build apps with it. But a pages router just maps URLs to files. What we didn't have was the framework level understanding of application structure that an app router provides. Without it, the framework couldn't do root-level code splitting. It couldn't prefetch intelligently.

It couldn't analyze the dependency graph across your entire application. And it was blind to what the client actually needed for any given page. The app router isn't just a routing feature. It's how the framework sees your application as a whole. And we hadn't built it yet.

The third gap was really a downstream consequence of the client-first default. Because so much was shipping to the client, the server rendering wasn't doing its full job. I'd call it RSC-flavored rendering. Components ran on the server. HTML was generated and it looked like SSR. But the hydration story wasn't complete. The client was still doing way too much work because client-first default meant too much code was hydrating. So three bottlenecks remained.

Client-side hydration overhead because the full tree was re-rendering to become interactive. JavaScript parsing delay because too much code was shipping. And cascading waterfall requests because data depended on the hydration. And the data dependencies weren't resolved server-side. Once the directive model was wrong, these problems cascaded. It smelled like SSR, but it wasn't true SSR.

Here's a lesson. And it's the thesis of this entire talk. Rust didn't save me from architectural mistakes. The performance ceiling wasn't limited by runtime speed. It was limited by incorrect semantics. By diverging from React's design intentions, I created problems that no amount of systems programming could fix.

And the fix wasn't optimization. It was alignment, aligning with how React was designed to work. So I went back and I built the three missing pieces properly. First, correct RSC semantics. Server components are the default. No directive needed. Use client ops into interactivity. This is the same code you'd write in Next.js or any other RSC framework. Nothing special, and that's the point.

The moment I flipped the default, bundle sizes dropped immediately. I didn't touch a single component. I didn't refactor anything. The framework could finally make correct decisions automatically because the default was right. Second, the app router. Build time analysis of every root and component in your application. Now the framework knows what belongs where. It can split code at the route boundaries automatically. It can analyze the dependency graph across the client server boundary. It can render RSC from roots with zero configuration.

With that, bundle size is cut in half, 55% smaller, just from the framework understanding the application structure. Third, true server-side rendering. Everything renders on the Rust runtime by default. The client receives pre-rendered HTML and an RSC payload. It hydrates only the interactive components. No full tree re-render to become interactive. No JavaScript parsing delay for static content. And no cascading waterfall requests.

The server does the heavy lifting once and the client's job is minimal. Wire up the event handlers on the bits that need them. Here are the numbers. First release versus after all three fixes. Average latency dropped from 4.2 milliseconds to two milliseconds. Throughput jumped to over 20,000 requests per second. P99 latency dropped from 46 milliseconds to four milliseconds.

By October, correct directives in the app router had cut the bundle from 400 kilobits down to 27.6 kilobits for a minimal benchmark page. Today's production bundle is 285 kilobits versus Next.js' 634 kilobits. 55% smaller. Running a full app with real dependencies. Not because Rust got faster. The Rust code barely changed because the architecture finally matched React's design intentions. Correct semantics, correct directives, correct defaults, correct understanding of the application.

That's where the performance came from. That was October, 2025. Let me show you where we are today. The final piece of the architecture is the response cache. And this is where the message channel finally pays off. When a request comes in, the HTTP server checks a two-level cache. First level, rendered HTML. Second level, pre-compressed response bytes in ZStandard, Rotli, and gzip. On a cache hit, the server does a hash lookup and a mem copy. That's it. V8 never wakes up.

The JavaScript thread could be completely stalled and cache routes would still serve at full speed. On a cache miss, the HTTP thread sends a message to the JS thread. V8 renders the component tree, produces the RSC wire format, sends it back. The HTTP thread converts it to HTML, compresses it with ZStandard, and caches both the raw HTML and the pre-compressed bytes. V8 runs ZStandard, Rotli, and gzip so that when a client sends an except encoding header, the server returns the right bytes without ever touching a compressor again.

After warmup, the server is effectively a Rust HTTP server with an in-memory cache. V8 sits idle until a cache miss or invalidation forces re-render. Remember that message channel that I said sounded like a bottleneck? It only fires on cache misses. Under steady state load, it's completely silent. Same page, same components, warm cache, 50 concurrent connections. Nearly 98,000 requests per second. 67 times higher throughput than Next.js. Half a millisecond average latency versus 34 milliseconds. The 67 times number comes from the response cache.

The 67 times number comes from the response cache. V8's idle on the hot path, so the server's just doing hash lookups and writing pre-compressed bytes to sockets. So I want to be clear, that's the best case. Warm cache, no re-rendering, cold renders are closer to two to three milliseconds server side, but for the majority of production traffic, this is the path requests take.

So I built rari.build with RARI itself. It's serving real production traffic with post-hog analytics and sentry error tracking with session replay. Average response time is about 150 milliseconds, and that includes the full internet round trip, network latency, TLS handshake, and data transfer. But the server side processing is sub-millisecond. Memory sits under 500 megabytes, that's less than Chrome tab. 345 kilobits of total page weight on first load with full sentry and post-hog. Perfect 100 page speed scores on both mobile and desktop.

And in February, it hit the Hacker News front page. I pulled up the metrics dashboard expecting to see memory climbing. Response time stayed flat. Response time stayed consistent. I didn't touch a single config. The server just handled it. So not everything can be cached. For pages with suspense boundaries, RARI switches into streaming mode. The flow is send the shell and synchronous content immediately. The browser starts painting while the server is still working.

Behind the scenes, async components are still resolving as each one completes, and a small inline script that swaps it into the correct position. It uses the same RC pattern that React uses internally. You add a loading.tsx file to a route and the framework changes its entire rendering strategy for that route. Without the file, the route is cached and served as pre-compressed bytes. With it, the route streams. Cold renders take 2 to 3 milliseconds, cache responses take 0.12 milliseconds. You choose per route just based on whether that file exists or not.

Here's the full progression. In July 2025, it was four times faster than Next.js. Rust is fast, but the architecture had gaps. By October 2025, it improved to 10x with correct RSC semantics, app router, true SSR, matching React's design. By 2026, it reached 67x with the response cache eliminating v8 from the hot path. Each improvement stemmed from architectural insights, not micro-optimizations or Rust optimizations. Architecture matters more than language. React's directive model is a performance feature, and v8 with Node.js is viable, removing performance constraints.

Understanding how pieces fit together is crucial. Four key takeaways: architecture matters more than language, React's directive model is a performance feature, v8 with Node.js is viable, keeping the JavaScript ecosystem, React, and event loop overhead on the server side. Rust didn't save from wrong defaults; slow software can be written in any language with a flawed architecture. Server-first is not just developer experience; it's the optimal bundle strategy designed by the React team. Keeping the event loop overhead on the server side opens up possibilities within the JavaScript ecosystem.

And four things that I want you to take away from this. One, architecture matters more than language. Rust didn't save me from wrong defaults. You can write slow software in any language if the architecture is wrong. Two, React's directive model is a performance feature. Server-first isn't just developer experience, it's the optimal bundle strategy. The React team designed it this way for a reason. Three, v8 with Node.js is viable. It removes an entire class of performance constraints. You keep the JavaScript ecosystem, you keep React, and you keep the event loop overhead on the server side. Four, the fix was alignment, not optimization. The biggest performance gains came from matching React's design intentions, not from fighting them, not from clever tricks, from understanding what the framework was trying to do, and just getting out of its way. You're all shipping React apps, every framework you use today, Next.js, Remix, whatever comes next, made these same decisions about defaults, about where rendering happens, about what ships to the client. The lesson from this whole journey isn't use Rust. It's that the defaults your tools choose shape your performance more than any optimization you'll ever write. Understand the architecture, align with it, and the numbers will follow. RARI is MIT licensed and open source. If you're curious, you can try it now. It downloads the Rust binary for your platform automatically. It's a very complex setup, just npm and go. Thank you. If you want to follow the project, rari.build is the site. I'm ryanskinner.com, I'm bluesky. And we have a Discord. That link is on screen. If you want to go deeper on any of this, talk about the architecture, or just say hi. Thank you. Awesome. Amazing. Great talk, Ryan.

Thanks. How did you get interested in optimization and speed and what started you on this path? One of the early memories I can really think of is using gulp on CSS and that sort of thing back in the day and just obsessing over getting bundle sizes way back then, even as small as possible. I think it's always just been a hyper focus of mine where if you can make it better, why not try. If you have the time you might as well give it an old college try. Definitely, and it seems like it's paying off. It's great.

So this first question is what is the developer experience like for your Rust framework? Can everyday React developers write pure JavaScript or TypeScript or do they need to understand Rust concepts? Yeah, so it's a JavaScript framework. There's no Rust APIs exposed. I mean, the image transformation plugs into the V plugin, but there's no, there's no deep Rust concepts whatsoever. If you're familiar with writing Next.js you can essentially write your app the same way. Amazing, and so would you say the, are you trying to get a one-to-one API service of Next.js or does Rari do things a little bit different? So essentially what happened was I started this project and I didn't intend to use Rust in the beginning. It was essentially, the beginning of the project was to bring in RSC support to V at least when the team got involved. So I was starting to investigate that pretty early and I started experimenting with the Deno crates. And I should clarify that as well. It is package manager agnostic so you don't need to use Deno. Deno is just the Rust kind of backing. It doesn't need NPM specifiers or anything like that. But yeah, so I started out using or trying to build the V plugin and it snowballed from there for sure. I see. Yeah, there was a question about how much of this was from scratch or how much of it was using Deno. I think I can't find it anymore but maybe that's the one. Is it correct that you managed to make NPM and node modules work thanks to the integration of Deno core or is there something done for that in Rust runtime? No, it's Deno core. So Deno core has an amazing extensions protocol and it's got all the node shims so you have most of the support there. So whatever, I can't recall what Deno's compatibility is right now but whatever they're at. I just released the package today so what they're currently at is what Rari supports. It's 70 or 90 or something. I think it's over 90, yeah. And there is a blog post from the Deno team, it's like build a JavaScript engine from scratch. Yeah, that was probably one of the early articles that I saw. It influenced the crates that I saw and definitely influenced kind of the ease of it that I saw.

Kind of pushed me in that direction for sure. Awesome. All right, let's get into this next one. Can an external cache like Redis be used with Rari for bigger projects or is the built-in memory cache the optimal solution? So a contributor actually raised this issue I believe it was last week and that's something we're focused on next is getting the integration to support Redis and other caching solutions. So, you know, if you have like a marketing site or a portfolio or something that's not a thousand pages and was well suited for static content I think the in-memory cache would be great. But when you're getting up to thousands of pages we haven't benchmarked that yet so I think that would be a perfect use case for it. I see. If Z-Standard compression is not supported on older browsers how would Rari tackle that? So it does support the other compression algorithms as well so it does Z-Standard but it does broadly in GZIP as well. So I think we probably do need to add some config options to, you know, pick one. Z-Standard was kind of just my headstrong decision so there's definitely room to work on it there. Okay. Sweet. You said we a couple of times. Is Rari a company or are you? No, Rari is me. It's me. I have one core contributor now who started contributing in the past couple of weeks and he's done amazing work so far so I like to think of it as a community. We only have had a few contributors so far but it's something that I kind of want to put out in the world and not just be me. Exactly. Yeah, this question is similar. We kind of talked about this but we can cover it more. So is the mental model similar to Next.js but optimized for Rust? Yeah, so I'm not trying to essentially rewrite Next.js and Rust but like you asked earlier I did want to support a lot of the well-known and liked APIs like AppRouter and the middleware and different feed support and that sort of thing. So if you're familiar with and I sort of related what do you think about TanStack in its comparison to Rari? I haven't really experimented much with TanStack. Obviously they've done an amazing amount of work for the ecosystem so I have the utmost respect for Tanner and the team but like I said I just haven't had enough time to really play around with their implementation yet. Okay. And this next one's about caching. How does caching work with streaming? What can render results to? The final result is cached but it's kind of the streaming caching needs some love. Yeah, that's good. Can you use it with a Rust backend or is it mostly focused on optimizing JS backends? So it already has the Rust backend so you deploy it. It can't be deployed on things like Vercel or Netlify like Edge that sort of thing so you do need to use something like a railway so it does already come with the full backend. It's got the server, it's got everything you need on the backend and the runtime so it's not Rust backend agnostic that's for sure.

I see. Would there be a way to maybe or you can tell me if you would even do this but would you extend or could you extend with Rust code adding custom endpoints like maybe you wanted like high-performance and so some stuff is native Rust, some is custom. At the moment we don't have anything supported like that. I think I do need to do quite a bit of work in terms of modularizing the crate. Right now it's just one core crate so it does need to be split up and I think exposing some of the Rust APIs to be able to be a little bit more expansive and use that side of the performance would be really interesting. So if you can take any one framework and do basically what you did is build a custom runtime for that one framework, it's a fascinating idea because everything we're doing is we're trying to build it on top of Node.js or trying to be generic. So it would be interesting to see if eventually these platforms maybe added RARI support or custom engine support or something like that. Yeah, essentially it needs to be a standard.

What is your opinion on useClient annotations and it's not a standard part of the language? This is what TanStack does differently. I actually like it. So I do a lot of agency work and I do e-commerce and different nonprofit sites and that sort of thing. So a lot of what I do uses the static renderer. It doesn't really use much of a server side. A lot of what I'm rendering is just straight up server work. But when I am doing things like a switcher or something like that, I don't mind using useClient. After going through the headache that I went through with using a client side first defaults at the beginning, I do kind of appreciate it in that everything being server activity and it's going to affect the bundle. Makes sense.

Time for maybe one or two more questions. Let's see this one. Can we say that moving the server layer out of Node.js was the main difference or could Zig or C++ achieve the same result? Well V8 is C, C++. So I would imagine it would probably be the exact same result. Rust is obviously fast, it's native code. So the core kind of result would be the same. Maybe one more question, let's see. If sometime in the future if Next.js gets rewritten in Rust like the React compiler, will it have comparative performance? I think the big boost in performance comes obviously from the response cache. So the response cache is a big reason for the persistent running process. It's not unlike a Vercel at the moment. I think it would have a lot higher performance. It would probably be comparable in certain things like streaming. That would be kind of, there wouldn't be an argument there. But in terms of the static renderer I think it's kind of in its own class at the moment. I see. All right, that's all the time we have. Thank you so much. Thank you, nice to meet you.