alt.hn

2/12/2026 at 7:15:47 PM

Rari – Rust-powered React framework

 https://rari.build/

by bvanvugt

2/12/2026 at 8:03:47 PM

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?

by mpeg

2/12/2026 at 8:22:09 PM

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.

by skiniks

2/12/2026 at 8:40:02 PM

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)

by mpeg

2/12/2026 at 9:27:05 PM

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.

by skiniks

2/12/2026 at 9:04:37 PM

V8 is C++, so why isn't it "C++ powered"?

by lionkor

2/12/2026 at 9:22:27 PM

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.

by skiniks

2/13/2026 at 9:08:40 AM

How big is the server runtime compared to v8 under the hood?

Yes, every one of those apps is c++ powered.

by tubs

2/12/2026 at 9:09:04 PM

They are using Deno

by koakuma-chan

2/13/2026 at 2:30:10 AM

[flagged]

by refulgentis

2/13/2026 at 2:36:43 AM

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.

by skiniks

2/13/2026 at 3:16:40 AM

What's with this 'touch grass'. Is this the new valley jargon?

by rjzzleep

2/13/2026 at 4:17:54 AM

[flagged]

by refulgentis

2/13/2026 at 4:21:19 AM

I'm not a zoomer, and you literally posted "I am person who rushes". Take a second after touching grass, then proofread your posts.

by skiniks

2/13/2026 at 4:30:24 AM

[flagged]

by refulgentis

2/13/2026 at 4:39:36 AM

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.

by skiniks

2/13/2026 at 5:58:44 AM

Sigh, people these days just assuming any coherent response must have been generated by an LLM is tiring.

by satvikpendem

2/12/2026 at 10:55:45 PM

[flagged]

by renato_shira

2/12/2026 at 9:39:14 PM

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.

by uriahlight

2/12/2026 at 9:55:34 PM

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

by bnchrch

2/12/2026 at 9:58:42 PM

> 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.

by mden

2/12/2026 at 10:10:46 PM

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.

by written-beyond

2/13/2026 at 6:01:11 AM

Use Vite. It was a misstep by the React team to continue to recommend create-react-app long after it was deprecated, but Vite is what's commonly used today.

by satvikpendem

2/12/2026 at 9:45:54 PM

I am a react developer. For past few months I am working in vue and I Just dont see any benefits

by profstasiak

2/13/2026 at 1:34:20 PM

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.

by TonyStr

2/13/2026 at 8:17:24 PM

That’s because you’re a “React developer”.

by 0xblinq

2/13/2026 at 1:41:12 AM

Thou art living under a rock.

by uriahlight

2/13/2026 at 6:02:15 AM

Ironic.

by satvikpendem

2/12/2026 at 10:24:47 PM

Totally agree.

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.

by apatheticonion

2/13/2026 at 12:43:58 AM

How is a viewmodel better? It's way more skipping around in the codebase to find the parts you actually care about

by h4x0rr

2/13/2026 at 1:05:20 AM

- Allows you to use async/await and generators (useful for pagination/infinite scroll)

- You can test the view model independently of the rendering logic

- Dramatically reduces the code that lives directly in the component (it's only TSX)

- Allows for better abstractions and state management (services)

- Clear path to leveraging threads in front end applications

- Simple "visual" components (like <Input />, <Button />) don't need view models, just orchestrating components.

In practice, when writing traditional React, I focus too much on rendering cycles and the nuances of managing component state while spending much less time on making the application look good and feel performant/nice to use.

Having a component be pretty much exclusively TSX gives me a clear separation of "view" and "what the view needs" - so I just think of the html structure and css. I tend to create much better looking and nicer applications this way.

> It's way more skipping around in the codebase to find the parts you actually care about

Not really. You cnt+click to an implementation. Say you have "await someApi.getItems()" - you just click and go directly there. Traditional React apps need to thunk with redux or have a bunch of custom hooks that quickly become a source of confusion.

by apatheticonion

2/13/2026 at 1:52:17 AM

Hi do you have some examples or repos you'd be comfortable with sharing? This looks interesting.

by adithyassekhar

2/13/2026 at 10:53:13 AM

I care about what SaaS SDKs support out of the box, I don't have time to yak shaving or do avocacy to our FE teams.

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.

by pjmlp

2/13/2026 at 1:07:02 AM

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.

by braebo

2/12/2026 at 10:15:28 PM

I hear you my brother. Days i had to write react were the worst i had to endure

by cantalopes

2/12/2026 at 9:51:17 PM

I hate React, but Vue never seemed much better. What is better about it, in your opinion?

by catlover76

2/13/2026 at 7:15:49 AM

no weird rules of hook. automatic dependency tracking. no stale closure gotchas, no running hook 1000 times cause you made a mistake.

Better update performance by default.

definitely better dev tools

by rk06

2/13/2026 at 12:39:18 AM

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.

[1] https://github.com/mblode/react-vello

by mblode

2/13/2026 at 5:27:03 AM

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!

by ChadNauseam

2/13/2026 at 6:03:17 AM

Similar to Dioxus Native I imagine?

by satvikpendem

2/13/2026 at 12:59:20 AM

Very nice, I think a Rust server using a WebSocket to send MorphDOM diffs to the browser would be very well received.

by ipnon

2/13/2026 at 7:11:37 AM

demo does not works on firefox+linux

by pdyc

2/13/2026 at 7:37:11 PM

Is there a way to enable WebGPU flag on Firefox Linux?

by mblode

2/13/2026 at 2:07:14 AM

This is very cool!

by skiniks

2/12/2026 at 7:49:23 PM

> React Server Components framework powered by a Rust runtime.

If anybody is wondering.

by dev_l1x_be

2/12/2026 at 9:28:37 PM

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.

by desireco42

2/13/2026 at 1:21:23 AM

For those looking for an actual Rust web framework, check out Leptos:

- https://leptos.dev/

- https://news.ycombinator.com/item?id=36461660

- https://youtu.be/cp3tnlTZ9IU?si=5H4cAVS8g6CFGwab

by ivanjermakov

2/13/2026 at 1:32:07 AM

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.

by skiniks

2/12/2026 at 8:08:02 PM

"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 :).

by dbacar

2/12/2026 at 9:08:53 PM

"I guide others to a treasure I cannot possess"

by zadikian

2/13/2026 at 6:04:17 AM

runtime != compile time

by satvikpendem

2/12/2026 at 7:54:59 PM

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?

by satvikpendem

2/12/2026 at 8:03:02 PM

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.

by skiniks

2/12/2026 at 8:15:34 PM

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

by mpeg

2/12/2026 at 8:33:01 PM

I can only found this benchmarks

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

by Erenay09

2/12/2026 at 8:42:34 PM

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

by mpeg

2/12/2026 at 8:11:57 PM

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

by laurencerowe

2/12/2026 at 8:41:10 PM

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.

by skiniks

2/12/2026 at 8:02:40 PM

I forgot all about Reason…

by bsimpson

2/12/2026 at 10:17:23 PM

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.

by moritzwarhier

2/12/2026 at 7:34:30 PM

Author here! Should be all good now, turns out the rate limiter was a bit overzealous

by skiniks

2/12/2026 at 8:28:03 PM

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

by splix

2/12/2026 at 9:18:05 PM

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.

by skiniks

2/12/2026 at 11:17:37 PM

That may sound strange, but it turns out I don't use WASM as well. Last time I touched this part was ~8 month ago, and WASM was just one of the experiments, and I forgot about this. Just remember it was hard to find a right approach initially, on how to execute JS without NodeJS environment. But with a right set of polyfills it works now.

Anyway, I see we have a bit different approaches on how to handle JS part, and I could get some ideas from that.

by splix

2/12/2026 at 9:05:36 PM

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.

by sebringj

2/12/2026 at 9:33:54 PM

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?

by skiniks

2/12/2026 at 9:38:11 PM

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!

by sebringj

2/13/2026 at 8:35:57 AM

Pretty cool work! Question: what's the difference in using BUN? I'm currently using buns react frontend/backend system. And afaik it's also written in rust.

The part that I don't see are the 'use server' .

by BrandiATMuhkuh

2/13/2026 at 1:35:56 AM

I've dreamed of someone taking React and making it somehow embeddable to any back-end programming language without a performance hit, so you can blend it with .NET, Go, Django, etc and it would run either natively or alongside said platform. This is impressive.

by giancarlostoro

2/13/2026 at 2:07:41 AM

Thank you!

by skiniks

2/13/2026 at 12:33:39 AM

I understand nothing of frontend, and never even saw what React looks like, what is this supposed to be? Is it compiler--written in Rust--of React whatever to actual Javacript with DOM calls?

by CrociDB

2/13/2026 at 2:06:36 AM

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.

by skiniks

2/13/2026 at 2:50:38 AM

Just a word of caution. According to my buddy there’s a famous rotund corn star named Rari or Rhari so she might come up in the search results.

by thr0waway001

2/12/2026 at 7:44:06 PM

I went through the website. But I do have a one question - it is not immediately clear to me why I'd use rari over Actix or just a plain-old Express server? What is "rust-powered performance"?

by samrith

2/12/2026 at 7:30:55 PM

Website has been hugged

by mattrighetti

2/12/2026 at 7:44:52 PM

Thats not good advertising for raris Performance claims.

by tuhgdetzhh

2/12/2026 at 7:50:21 PM

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!

by skiniks

2/13/2026 at 12:22:28 AM

Would be more interesting to compare this to Bun or Deno + NextJs or Tanstack Start or React Router performance wise.

by re-thc

2/13/2026 at 6:08:59 AM

The author said it achieves ~50x more throughput than Next.

by satvikpendem

2/13/2026 at 7:34:56 AM

On Node, presumably?

by re-thc

2/13/2026 at 3:04:56 PM

Yes

by satvikpendem

2/12/2026 at 7:29:53 PM

Get started but not working

by xlmnxp

2/12/2026 at 9:05:51 PM

Naming so lit

by choiway

2/13/2026 at 12:51:22 AM

Thanks twin!

by skiniks

2/12/2026 at 8:52:53 PM

[flagged]

by rtcode_io