4 ms·

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

by skiniks 8mo ago

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 8mo ago
How is this different than running that same React code in deno whose HTTP server is also written in Rust?
- skiniks 8mo ago
  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.
  - deleted 8mo ago
    [deleted]
mpeg 8mo ago
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
- ErenayDev 8mo ago
  I can only found this benchmarks https://github.com/rari-build/benchmarks https://github.com/rari-build/benchmarks
  - mpeg 8mo ago
    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 8mo ago
      It's still V8 underneath. If it's faster, it's faster because of the parts that serve HTTP.

by skiniks 8mo ago

laurencerowe 8mo ago

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

skiniks 8mo ago
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.
- deleted 8mo ago
  [deleted]

mpeg 8mo ago

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

ErenayDev 8mo ago
I can only found this benchmarks https://github.com/rari-build/benchmarks https://github.com/rari-build/benchmarks
- mpeg 8mo ago
  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 8mo ago
    It's still V8 underneath. If it's faster, it's faster because of the parts that serve HTTP.