What happens when you run React Server Components on a custom Rust runtime instead of Node.js? 4x faster rendering, 10k+ req/sec, sub-50ms P99 latency. Same JSX, same component patterns. Zero Rust knowledge needed. The runtime does the heavy lifting, you write the React.
Excellent work on Rari! I don't want to spoil the fun and take away the achievement, but your benchmark is not a fair comparison. Rari is not using SSR. It is fetching the RSC components from the client-side, while the benchmark is measuring load times for the initial HTML.
Ah, thanks for flagging this, Viktor! You're right that we're measuring TTFB, which does appear to favor Rari's architecture. Both applications use RSC, but their delivery approaches differ significantly.
Rari's runtime delivers a smaller initial payload (~6KB vs ~61KB) with a different component streaming strategy, while Next.js provides more complete SSR HTML upfront. The 4x performance numbers accurately reflect server response times, but they don't tell the complete rendering story.
For applications prioritizing fully-rendered initial HTML without additional component fetches, Next.js's approach might be more advantageous. I'll add a note clarifying these architectural distinctions and their performance implications.
That block with the stream_component is just… gorgeous 😍
ahhh thank you! that means a lot 🥲
Cool stuff! Love seeing more frameworks exploring RSCs. How does this example work – I thought it was a fundamental part of the design of RSCs that client components can't import server components?
While it appears that client components are directly importing server components, what's actually happening is a build-time transformation where these imports are converted to component wrappers.
When you write `import ServerTime from './ServerTime'` in a client component, Rari analyzes the `'use server'` directive during the build process and replaces the actual import with a `createServerComponentWrapper()` call that returns a React component proxy.
This maintains the core RSC principle that server components never execute on the client while providing a developer-friendly experience that feels like normal React composition.
I had a feeling it must be something like this – cool stuff! Curious to see how it feels, will have to give it a spin soon :)
Thanks Sam! Huge respect to you and the team, wouldn't have started tinkering with this without the groundwork laid by Next.js
What happens if you conditionally render the RSC based on the client's state value from useState?
Good call, this may be a footgun that'll bite me in the end, but when your useState values change and get passed as props to a server component, they should trigger fresh server execution every time.
How do they get passed as props? Do you automatically send them over from the client in the call to re-render the page? Also does this mean the RSCs re-render every time client components re-render? I honestly am not understanding how this could work haha
Yeah! Client state gets serialized and sent via fetch requests to the server. When useState values change and get passed as props to a server component, the framework detects this via a dependency on JSON.stringify(props).
It then makes a network request with the new props to render the component server-side. RSCs don't re-render on every client render—only when their received props actually change.
I was also under this impression, but it turns out that not even the flagship implementation respects that rule
This is cool! What’s the thinking behind implementing a custom runtime rather than just adapting the RSC stream to HTTP using the built in Deno server? Seems like that would be a fairly thin layer.
That KVM isolation approach sounds really interesting! This was more of an experimentation with the deno_core crate and extensions, to see if I could swing it. The custom runtime approach ended up giving us sub-ms response times under load (~0.6ms) and ~15x concurrent throughput vs Next.js.
I initially reported it as 4x throughput, but I've removed some artificial limits and now it's hitting 15x
The built in Deno.serve is mostly rust and very well optimised (~10 microseconds/req). Might be interesting to try and break out how much of your savings come from your rust bits vs the different architectural approach to next.js.
Would be fascinating to A/B test: same architectural approach but with thin Deno.serve layer vs our custom runtime. Will keep this front of mind to try when I have a chance!
I initially started with building directly on deno_runtime (provides more than deno_core) but abandoned it for the kvmserver approach because I wanted a general request->response pattern and doing that efficiently really requires access to the deno internals. That limitation doesn’t apply to you.
Somewhat orthogonally I’ve been trying to get fast request isolation working JS and have spent the past couple of months working with the TinyKVM author on building KVMServer which runs my React server rendering benchmark with Deno in under a ms. (x86_64 only for now.) github.com/libriscv/kvm...
Cool demo for Rust! But surely in real-world projects, the performance bottleneck is in the user’s browser, not on the server where you can always rent more VMs?
Great work! There is something that is not clear to me. How do you do the math of req/sec and average response? 10.000 req/sec would mean that the average response was 0.1ms. At 4.23 of average response it would be hard to do more than 236 req/sec. So are you doing clustering as well?
No, we're not using clustering. The high req/sec is achieved through connection parallelism in the load testing tool, which uses 50 concurrent connections. This simulates multiple users accessing the server simultaneously, not server-side clustering.
Ok but that is what doesn't add up in my mind. I'm not questioning how you initiate the requests, but how are you counting the responses. If render a page takes 5ms, and a second has 1000ms, then the maximum of req/sec you can do is 200. The question is how you achieve 10.000 req/sec?
We're counting total completed requests across all connections. Your calculation of 200 req/sec would be correct for a single connection processing requests one after another. However, our load test uses 50 concurrent connections, with each handling requests simultaneously.
With 4.23ms average latency, 50 parallel connections can theoretically handle about 11,800 req/sec (1000ms ÷ 4.23ms × 50), which aligns with our measured result of 10,586.4 req/sec.
If you'd like to dig a bit deeper, the benchmarks can be found here:
To achieve 10.000req/sec then the rendering time should be 0.1ms. Nonetheless the results are impressive.
Boy, I'm old.
Nice stuff. Are you using AsyncContext (AsyncLocalStorage) at all? I'm pretty sure that's where a lot of the slowness with Next.js comes from, they're using that heavily and it causes every async fn invocation to have a perf hit
Can you explain more about this? Interested to hear why that’s a bottleneck
Thanks man! We don't use it at all—explicit context passing per component render instead of async propagation. No per-async-call overhead.
Not only for their dynamic IO features like cookies() etc. but they also have the framework code pretty well instrumented with otel traces