ok so I actually like this, but the description and documentation in general are terrible
"rust-powered" meaning it uses rolldown to bundle the javascript, that's fine, but it's a weird thing to highlight, it's confusing for people that aren't super familiar with vite and might think this is a rust framework
from the docs "one of rari's superpowers is seamless NPM package integration" this makes me think the docs are LLM-written... npm package integration, like every other javascript library.
now, the good: there's very few simple frameworks for react (react router and tanstack) and I think the simplicity here on going from an empty project to RSCs is absolutely great, and should be the tagline
I was also happily surprised at how mature the codebase is in comparison to the docs, the vite plugin actually supports a lot of the options I would have expected to see, they're just not documented yet
edit: I realised after digging a bit deeper this actually does have a rust runtime that runs the js, that was not very clear... is this separate from the framework or does the framework only run in the rust runtime? eg can it run on node?
You're right about the messaging being confusing, I've been writing everything solo, so I'm definitely open to PRs that help with the copy. To clarify: "Rust-powered" refers to the server runtime itself, not just the bundler. The actual HTTP server, RSC renderer, and routing are all written in Rust (using an embedded V8 engine to execute your React components). It's not just Rolldown doing the bundling.
On the npm integration point: what I should have said is that rari's Rust runtime handles traditional node_modules resolution (require/import from node_modules), which is actually pretty rare for Rust-based JS runtimes. Deno, for example, uses npm specifiers instead of node_modules.
Great feedback on the tagline too. "Zero to RSC in minutes" is way clearer than what we have now. The codebase is definitely ahead of the docs, I've been focused on getting the runtime solid first, but clearly need to catch the documentation up.
Thanks for taking the time to dig in and give constructive feedback. This is exactly the kind of input that helps make it better.
Yeah I wrote my comment initially thinking it was just rolldown being used, so the "rust-powered" was confusing, I think the tagline is actually ok now that I know this, but really you're doing two things here
1/ an alternative framework for RSCs similar to nextjs, tanstack or react router
2/ a rust runtime for javascript, similar to node, deno or bun (except maybe not as general purpose)
The runtime piece is definitely less general-purpose than Node/Deno/Bun. It's optimized specifically for React Server Components with things like streaming, Suspense boundary handling, and server action execution baked in. You wouldn't use it to run arbitrary JS apps.
Technically you could say that, but the entire server runtime is written in Rust. V8 is just the embedded JavaScript engine. By that logic, every Node.js or Deno app would be "C++ powered" since they all use V8.
It's like beating a dead horse. React is the literal worst of all the modern JavaScript frameworks and yet that's what everybody insists on using. Vue is light years ahead of it (and will be even further ahead when the new Vapor mode is released in 3.6). Svelte is ahead. Solid is ahead. Heck, even Marko is ahead.
Reacts added some poor abstractions over the last decade. Looking at you hooks and effects.
But its far from the worst.
It was the first framework to put together JSX, a functional way of defining components and simplifying state. This was a monumental improvement. As a result they earned mass adoption.
As a result its the framework that now has a community moat that is not going to crumble until someone else can break ground in the way they did.
Sure, some of these could be considered "better" but they're all better due to incremental improvements for Frontend Engineering.
None of which are substantial enough to unseat the king
Not like ReasonML, you still write normal React/TypeScript.
The Rust part is the server runtime. Instead of Node.js running your React Server Components, rari uses a Rust server with an embedded V8 engine. Same React code, different server underneath.
You write React → Rust server executes it → better performance than Node-based alternatives.
interesting, but would certainly be good to see an apples to apples benchmark of rari vs node/deno/bun for the same app, I would imagine the goals of the runtime are not to be a general runtime like those others, but it would still be good to see if it performs better
The main difference is that Deno doesn't have React Server Components support. You'd need to build the entire RSC runtime yourself (streaming, Suspense boundaries, server actions, etc.), whereas rari has this built in and optimized. rari also uses Axum for the HTTP layer with opinionated defaults for RSC workloads: streaming responses, proper cache headers, and optimized middleware are all configured out of the box.
While we use Deno's excellent crates (deno_core for V8 bindings, we're big fans of the project!), you're not locked into the Deno ecosystem. rari uses standard node_modules resolution, so your existing Node/npm workflows just work. Think of it like this: Deno gives you a runtime to build on, while rari gives you the full stack with integrated bundler, router, HMR, and dev server all configured to work together for RSC apps.
Nice project, thank you for working on it. I was trying to figure out the architecture, and I understand that it runs a Deno VM to execute JS on the backend?
I was working on something similar, but for JVM backends [1]. And it seems there are a lot to learn from your project. For example, I'm using GraalVM that executes JS on the server. But I have to compile JS to WebAssembly because otherwise it produces a lot integration issues on the backend. Do you do the same?
Thanks for checking it out! rari uses V8 (via deno_core bindings) embedded directly in the Rust runtime, not a full Deno VM. We execute JavaScript directly on V8 without compiling to WebAssembly.
The key is that deno_core provides clean Rust bindings to V8's C++ API, which lets us run JS/TypeScript with minimal overhead. We handle module resolution, imports, and the React rendering pipeline all in Rust, then execute the actual component code in V8. No WASM compilation step needed.
Your JVM project looks cool! The GraalVM → WASM approach makes sense for JVM integration. We avoid those integration issues by keeping everything in the Rust/V8 ecosystem. The tradeoff is we're tied to V8, but we get native performance and direct access to V8's features.
this looks neat and reminds me of "Ferrari" for fast and combines "react" so it's a great name. Was there a specific use case for this that inspired you? I would imagine some massive existing heavy thing that you plugged in to fix to save it? I just put my open source thing out so it's nice to see some traction on yours, rooting for you.
Thank you, that's very kind! The name actually comes from "Runtime Accelerated Rendering Infrastructure" (RARI), but I love the Ferrari connection, it definitely fits the performance theme.
The inspiration was pretty straightforward: I wanted to build something for myself that was as performant as I could make it. I'd been using Rust a lot more in my day-to-day work and wanted to see if I could bring those performance benefits to React development without forcing JS devs to write Rust. The goal was to abstract away the complexity of Rust but still deliver the same benefits.
Congrats on shipping your project! What did you build?
ah gotcha... i was picturing like this massive web page that was dog slow that you just like made mad fast... but that's cool though. I'll run it.
I built autonomo on github, it's this mcp you plugin to your whatever ai editor and it drives the app/web/desktop whatever thing and validates it actually runs and works... keep building homie!
Fair point! To be clear: rari handled the traffic perfectly fine - the issue was an overly defensive rate limiter I had configured (and it was grouping proxy traffic incorrectly). The framework itself was cruising, I just had the safety rails set too tight. Adjusted now and it's handling the load as expected!
ok so I actually like this, but the description and documentation in general are terrible
"rust-powered" meaning it uses rolldown to bundle the javascript, that's fine, but it's a weird thing to highlight, it's confusing for people that aren't super familiar with vite and might think this is a rust framework
from the docs "one of rari's superpowers is seamless NPM package integration" this makes me think the docs are LLM-written... npm package integration, like every other javascript library.
now, the good: there's very few simple frameworks for react (react router and tanstack) and I think the simplicity here on going from an empty project to RSCs is absolutely great, and should be the tagline
I was also happily surprised at how mature the codebase is in comparison to the docs, the vite plugin actually supports a lot of the options I would have expected to see, they're just not documented yet
edit: I realised after digging a bit deeper this actually does have a rust runtime that runs the js, that was not very clear... is this separate from the framework or does the framework only run in the rust runtime? eg can it run on node?
You're right about the messaging being confusing, I've been writing everything solo, so I'm definitely open to PRs that help with the copy. To clarify: "Rust-powered" refers to the server runtime itself, not just the bundler. The actual HTTP server, RSC renderer, and routing are all written in Rust (using an embedded V8 engine to execute your React components). It's not just Rolldown doing the bundling.
On the npm integration point: what I should have said is that rari's Rust runtime handles traditional node_modules resolution (require/import from node_modules), which is actually pretty rare for Rust-based JS runtimes. Deno, for example, uses npm specifiers instead of node_modules.
Great feedback on the tagline too. "Zero to RSC in minutes" is way clearer than what we have now. The codebase is definitely ahead of the docs, I've been focused on getting the runtime solid first, but clearly need to catch the documentation up.
Thanks for taking the time to dig in and give constructive feedback. This is exactly the kind of input that helps make it better.
Yeah I wrote my comment initially thinking it was just rolldown being used, so the "rust-powered" was confusing, I think the tagline is actually ok now that I know this, but really you're doing two things here
1/ an alternative framework for RSCs similar to nextjs, tanstack or react router
2/ a rust runtime for javascript, similar to node, deno or bun (except maybe not as general purpose)
Exactly! Those are the two main layers.
The runtime piece is definitely less general-purpose than Node/Deno/Bun. It's optimized specifically for React Server Components with things like streaming, Suspense boundary handling, and server action execution baked in. You wouldn't use it to run arbitrary JS apps.
V8 is C++, so why isn't it "C++ powered"?
Technically you could say that, but the entire server runtime is written in Rust. V8 is just the embedded JavaScript engine. By that logic, every Node.js or Deno app would be "C++ powered" since they all use V8.
They are using Deno
It's like beating a dead horse. React is the literal worst of all the modern JavaScript frameworks and yet that's what everybody insists on using. Vue is light years ahead of it (and will be even further ahead when the new Vapor mode is released in 3.6). Svelte is ahead. Solid is ahead. Heck, even Marko is ahead.
Reacts added some poor abstractions over the last decade. Looking at you hooks and effects.
But its far from the worst.
It was the first framework to put together JSX, a functional way of defining components and simplifying state. This was a monumental improvement. As a result they earned mass adoption.
As a result its the framework that now has a community moat that is not going to crumble until someone else can break ground in the way they did.
Sure, some of these could be considered "better" but they're all better due to incremental improvements for Frontend Engineering.
None of which are substantial enough to unseat the king
> React is the literal worst of all the modern JavaScript frameworks and yet that's what everybody insists on using.
That's rather amusing. "Am I wrong? No it's the rest of the world!"
How are these other frameworks so far ahead? I've used a couple of frameworks and React has been the easiest from the big ones to wrap my head around.
I am a react developer. For past few months I am working in vue and I Just dont see any benefits
> React Server Components framework powered by a Rust runtime.
If anybody is wondering.
Thank you, came to comments to find out what it is. Now I can go back to site and see what it is about.
Thanks again.
Is this like ReasonML and its React-Reason framework?
I don't really understand how it works, what part is Rust powered, is it reimplementing the JS engine in Rust?
Not like ReasonML, you still write normal React/TypeScript.
The Rust part is the server runtime. Instead of Node.js running your React Server Components, rari uses a Rust server with an embedded V8 engine. Same React code, different server underneath.
You write React → Rust server executes it → better performance than Node-based alternatives.
wait so it actually has a rust runtime? that's not documented in the site so I had assumed the rust part was simply rolldown
it would be interesting to see a performance comparison to node and bun
I can only found this benchmarks
https://github.com/rari-build/benchmarks
interesting, but would certainly be good to see an apples to apples benchmark of rari vs node/deno/bun for the same app, I would imagine the goals of the runtime are not to be a general runtime like those others, but it would still be good to see if it performs better
How is this different than running that same React code in deno whose HTTP server is also written in Rust?
The main difference is that Deno doesn't have React Server Components support. You'd need to build the entire RSC runtime yourself (streaming, Suspense boundaries, server actions, etc.), whereas rari has this built in and optimized. rari also uses Axum for the HTTP layer with opinionated defaults for RSC workloads: streaming responses, proper cache headers, and optimized middleware are all configured out of the box.
While we use Deno's excellent crates (deno_core for V8 bindings, we're big fans of the project!), you're not locked into the Deno ecosystem. rari uses standard node_modules resolution, so your existing Node/npm workflows just work. Think of it like this: Deno gives you a runtime to build on, while rari gives you the full stack with integrated bundler, router, HMR, and dev server all configured to work together for RSC apps.
I forgot all about Reason…
Author here! Should be all good now, turns out the rate limiter was a bit overzealous
Nice project, thank you for working on it. I was trying to figure out the architecture, and I understand that it runs a Deno VM to execute JS on the backend?
I was working on something similar, but for JVM backends [1]. And it seems there are a lot to learn from your project. For example, I'm using GraalVM that executes JS on the server. But I have to compile JS to WebAssembly because otherwise it produces a lot integration issues on the backend. Do you do the same?
[1] https://github.com/emeraldpay/double-view
Thanks for checking it out! rari uses V8 (via deno_core bindings) embedded directly in the Rust runtime, not a full Deno VM. We execute JavaScript directly on V8 without compiling to WebAssembly.
The key is that deno_core provides clean Rust bindings to V8's C++ API, which lets us run JS/TypeScript with minimal overhead. We handle module resolution, imports, and the React rendering pipeline all in Rust, then execute the actual component code in V8. No WASM compilation step needed.
Your JVM project looks cool! The GraalVM → WASM approach makes sense for JVM integration. We avoid those integration issues by keeping everything in the Rust/V8 ecosystem. The tradeoff is we're tied to V8, but we get native performance and direct access to V8's features.
"Rust-Powered Performance
Native speed with Rust compilation for blazing-fast builds and runtime"
It seems only Rust itself compiles slow while helping others brag about it :).
"I guide others to a treasure I cannot possess"
this looks neat and reminds me of "Ferrari" for fast and combines "react" so it's a great name. Was there a specific use case for this that inspired you? I would imagine some massive existing heavy thing that you plugged in to fix to save it? I just put my open source thing out so it's nice to see some traction on yours, rooting for you.
Thank you, that's very kind! The name actually comes from "Runtime Accelerated Rendering Infrastructure" (RARI), but I love the Ferrari connection, it definitely fits the performance theme.
The inspiration was pretty straightforward: I wanted to build something for myself that was as performant as I could make it. I'd been using Rust a lot more in my day-to-day work and wanted to see if I could bring those performance benefits to React development without forcing JS devs to write Rust. The goal was to abstract away the complexity of Rust but still deliver the same benefits.
Congrats on shipping your project! What did you build?
ah gotcha... i was picturing like this massive web page that was dog slow that you just like made mad fast... but that's cool though. I'll run it.
I built autonomo on github, it's this mcp you plugin to your whatever ai editor and it drives the app/web/desktop whatever thing and validates it actually runs and works... keep building homie!
Website has been hugged
Thats not good advertising for raris Performance claims.
Fair point! To be clear: rari handled the traffic perfectly fine - the issue was an overly defensive rate limiter I had configured (and it was grouping proxy traffic incorrectly). The framework itself was cruising, I just had the safety rails set too tight. Adjusted now and it's handling the load as expected!
Naming so lit
Get started but not working
Two cancers combined!