I appreciate constructive feedback, but the assumption that the docs were rushed with an LLM isn't accurate. I've spent over a year on this project. That said, I hear you on the messaging and I'm working to improve it. Cheers.
Where did I say they were rushed with an LLM? I've spent countless hours on the framework, and the docs, and have been clear that I'm open to PRs to help with the copy. This isn't something that was rushed in the past few days, I have spent over a year on this project, with it being public for ~6 months. Not sure what your deal is, but respectfully, touch grass.
rari is a React Server Components framework with a Rust-powered runtime. It's not a compiler that converts React to vanilla JavaScript—it's a full framework (like Next.js) that runs React applications.
The Rust part is the runtime engine that executes your React code on the server. Think of it as a faster alternative to Node.js for running React Server Components. You still write normal React code, but the server-side execution happens in Rust instead of Node.js, which gives it massive performance gains (46.5x higher throughput than Next.js).
It handles routing, server-side rendering, and serves both server components (rendered on the server) and client components (interactive JavaScript sent to the browser). The output is still HTML + JavaScript that runs in the browser—just generated much faster.
Thanks for sharing Leptos! I'm actually a fan of it too, it's a great framework for those who want to build full-stack apps in Rust.
That said, rari takes a different approach. It's not a pure Rust framework. It's a React Server Components framework that happens to be powered by a Rust runtime. The goal is to abstract away Rust's complexity entirely so JavaScript/TypeScript developers can build high-performance React apps without needing to learn Rust.
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?
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.
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.
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.
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.
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.
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!
The key insight: when your architecture aligns with React's design philosophy, performance follows naturally. Server components by default, 'use client' when needed, true SSR from the Rust runtime.