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)
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
I never "learned" react because the "create react app" would literally never install for me in the early days. There were literally so many dependencies I never got it to build as a novice, I tried svelte everything worked and I got to spend that time building.
I can only speak for Svelte, in Svelte 3/4 it was so dead simple that I built my first basic webapp with 0 javascript, css or html experience in 3 days.
By week 2 I was trying out different UI libraries and css frameworks, that part was super rough though, back then lots of compat issues.
Vue should be a bit faster due to signals (updating state doesn't cause whole components to rerender), or at least require a bit less work to optimize (not as much need for useMemo, useEffect, etc. if everything uses signals). Other than that, it's mostly up to personal preference. SFC, directives, etc. are all just developer ergonomics, and people tend to prefer whatever they're most used to.
Also, vue interops better with webcomponents and non-framework code than React in my experience. Most non-React libraries need a React wrapper to work in a React project.
It can be made better if you write it using non standard patterns - but the community is so dogmatic you'll get laughed out of the room.
All of my personal react projects use the MVC/MVVM architecture and are so much easier to work with
export class AppViewModel {
@rx accessor message = new TextField()
}
export function App() {
const vm = useViewModel(AppViewModel)
return <div>
<p>{vm.message.value}</p>
<input
onChange={vm.message.fromEvent}
value={vm.message.value} />
<div>
}
Makes it vue/angular/svelte-like, but unlike Vue/Angular/Svelte, you pick the version of TypeScript, the tools and don't need brittle plugins for your IDE to work with it.
As a Svelte developer working with React at $DAYJOB I must say it is the most horrific kludge of terrible abstractions I’ve ever had to suffer through in my life. The sheer number of hoops you have to jump through to do literally anything is comically absurd, and even the nicest way of doing things is a dumpster fire of bad programming patterns. The worst part is, React devs are blind to just how much of their day is spent solving problems that are created solely by React itself, unrelated to any business logic or actual value.
One day my dream is to delete 75% of the code, sprinkle some svelte into the business logic, and be left with a strictly superior, more performant version of the platform.
If anyone’s exploring Rust + React, I’ve been building something similar on the rendering side.
react-vello [1] exposes Vello (a Rust GPU renderer) as a React renderer via WASM + WebGPU, so you can draw shapes and text declaratively while Rust handles the rendering in the browser.
Rust + React is a beautiful combination. For my project, I use Rust for the actually complicated logic that needs to be correct and performant. And then I just use React for the UI. It works pretty great. The communication between the two with wasm-bindgen and tsify is just so easy. It's almost as if they're the same language. It's really crazy, honestly. A feat of engineering.
React Vello seems super cool, by the way. Thanks for sharing it!
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.
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.
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.
I once (2022 I think) took a short ReasonML course with hands-on and while it was only superficial, I remember how much it increased the appeal of pattern matching and immutability for me... without being a true FP head or anything.
Readit News
"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?
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.
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)
Deleted Comment
Dead Comment
Deleted Comment
Dead Comment
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
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 can only speak for Svelte, in Svelte 3/4 it was so dead simple that I built my first basic webapp with 0 javascript, css or html experience in 3 days.
By week 2 I was trying out different UI libraries and css frameworks, that part was super rough though, back then lots of compat issues.
Also, vue interops better with webcomponents and non-framework code than React in my experience. Most non-React libraries need a React wrapper to work in a React project.
It can be made better if you write it using non standard patterns - but the community is so dogmatic you'll get laughed out of the room.
All of my personal react projects use the MVC/MVVM architecture and are so much easier to work with
Makes it vue/angular/svelte-like, but unlike Vue/Angular/Svelte, you pick the version of TypeScript, the tools and don't need brittle plugins for your IDE to work with it.One day my dream is to delete 75% of the code, sprinkle some svelte into the business logic, and be left with a strictly superior, more performant version of the platform.
That means it is mostly React/Next.js and in some cases, Angular.
Anything else will get side looks on why are we not using the official SDKs from partners.
Better update performance by default.
definitely better dev tools
react-vello [1] exposes Vello (a Rust GPU renderer) as a React renderer via WASM + WebGPU, so you can draw shapes and text declaratively while Rust handles the rendering in the browser.
[1] https://github.com/mblode/react-vello
React Vello seems super cool, by the way. Thanks for sharing it!
If anybody is wondering.
Thanks again.
- https://leptos.dev/
- https://news.ycombinator.com/item?id=36461660
- https://youtu.be/cp3tnlTZ9IU?si=5H4cAVS8g6CFGwab
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.
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
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.
I don't really understand how it works, what part is Rust powered, is it reimplementing the JS engine in Rust?
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.
it would be interesting to see a performance comparison to node and bun
Native speed with Rust compilation for blazing-fast builds and runtime"
It seems only Rust itself compiles slow while helping others brag about it :).
Deleted Comment