[skiniks]

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.

[laurencerowe]

How is this different than running that same React code in deno whose HTTP server is also written in Rust?

[skiniks]

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.

[mpeg]

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

[Erenay09]

I can only found this benchmarks

https://github.com/rari-build/benchmarks

[mpeg]

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

[yencabulator]

It's still V8 underneath. If it's faster, it's faster because of the parts that serve HTTP.