The Rust React Compiler is now native in Vite

Posted by acusti 4 days ago

Counter178Comment55OpenOriginal

Comments

Comment by pjmlp 3 days ago

Eventually we will be back to pre-node days, when compiled languages were the majority for JS tooling (C, C++, Java, C#,...), the yin yang of cool technology cycles.

Comment by adzm 4 days ago

No more babel in my compilation pipeline, yay!

Comment by adzm 4 days ago

Update: changed a pet project to use this instead of the babel approach. Literally just did the config changes in the article, no issues. Time from `npm run dev` to ready went from 6 to 2 seconds.

Comment by Waterluvian 4 days ago

It’s just the best thing ever. Compiling at work took a minute for full builds with babel, and with rsbuild it now takes about 0.9 seconds.

Comment by fishfasell 3 days ago

Rust is such an awesome language. The execution times are blazing fast.

Comment by echelon 3 days ago

I just wish Rust itself compiled faster. Serde, proc macros, it's all so slow.

I'm going to start prototyping systems in Go, then porting them to Rust when they're more concrete.

I feel as though the Rust code LLMs emit is generally higher quality than most other languages, perhaps due to the error handling being a chief concern of the language, but the iteration on making changes and running tests is so slow.

Rust could grow into "the final language" if it wasn't so slow to compile. Assuming the WASM bridge also continues to improve.

Comment by throw-the-towel 3 days ago

LLMs being good with Rust makes sense, because the language itself gives you more safeguards than many others. What's good for the (human) gander is good for the (agent) goose.

Comment by echelon 3 days ago

LLMs are ungodly good at Rust, and I say this as a 10-year veteran of the language.

My problem is that now iteration with LLMs is so quick when prototyping new things that I now spend an inordinate amount of time waiting on agents to compile Rust and run tests. It's a huge slow down.

I still want to serialize production logic to Rust (and TypeScript for the frontend as the WASM for frontend ecosystem isn't there yet), but it's really slow to iterate. I'm starting to build prototypes in Golang now and then convert them to Rust when I'm done.

Hopefully the Rust team makes strides over the coming years to address this. I know they have a lot of irons in the fire for many speedups.

Comment by umpalumpaaa 3 days ago

But once you start to close the loop (as in allowing the LLM to build and run its changes) what’s good turns suddenly bad again. Long build times also increase LLM turnaround times. Especially bad when you have a fast model.

Comment by pjmlp 2 days ago

Quite surprising for an ahead of time compiled language. /s

Comment by koito17 3 days ago

Finally got rid of Webpack in 2022, and now I'll be able to get rid of Babel, too.

It's a bit mesmerizing to think that Vite at the time was still "that newish tool the Vue folk use", and now it's pretty much the standard bundler for web frontend. Also the easiest one to configure and use (in my experience).

Similarly, I'm glad I don't have to deal with karma, jest, etc. anymore.

Comment by torginus 3 days ago

I really haven't invested heavily in understanding new tooling, but I did try to move to TS 7.0 and found that a lot of the tooling actually relies on parsing TS not just stripping the types. And the only tool that can do that reliably is `tsc`.

I even had to revert from TS 7.0 (the go rewrite) to 6, because 7 doesn't support plugins and code analysis stuff (which I guess are js) in the way the tooling requires.

Comment by vmsp 4 days ago

OXC Transformers are amazingly faster than Babel. I'm building a framework (https://github.com/vmsp/flypath) for web, iOS and Android native development that's fully backed by OXC and Vite. Instead of transforming styles using Babel like StyleX, I just use OXC. Instead of Metro (React Native's bundler), which also uses Babel, it's just Vite. It's still very early but it's plenty, plenty fast.

Comment by nwienert 4 days ago

Cool stuff. I'm moving One[stack.dev] onto pure rust now, and Tamagui v3 compiler will also is moving from Babel to Yuku which is quite interesting - from my testing it's more flexible and quite a bit faster than OXC.

Comment by BretonForearm 4 days ago

What's a react compiler? Not JS or TS?

Comment by throw_m239339 3 days ago

Hand written React code is relatively slow when running so the React team made a React compiler to make it run faster. You might not see the difference with a toy app, but with a fairly large app, with a lot of IO it's a catastrophe if not compiled and optimized.

It's the definition of overengineering IMHO. The problem is React at first place. Some other frameworks have in theory no compilation or optimization step while delivering constant performance as the app grows, like SolidJS. Since writing a compiler in JS also make compilation itself slow, then the React compiler was re-written in Rust...

At the end of the day, React has a larger community and ecosystem so it's the industry "standard" for JS applications...

Comment by pzmarzly 3 days ago

Why do people say SolidJS has no compilation? SolidJS 1.0 was already doing much more at transpilation time than just changing <h1> to h("h1"), and SolidJS 2.0 has a package called @solidjs/compiler: https://npmx.dev/package/@solidjs/compiler

Comment by 3 days ago

Comment by syspec 4 days ago

Does this work with reacts fancy new compiler that is meant to optimize away various hooks?

Comment by ownagefool 4 days ago

If it wasn't obvious from the article, this is an implementation in the same thing in rust, ergo significantly faster. This was enabled, I presume, by the upstream react introducing code a rust version in source ( but they don't produce a standard binary last I checked )

Comment by dzonga 3 days ago

rewrite it in rust might be a joke -- but damn most the massive improvements in dynamic language toolchains have come from the toolchains being rewritten in rust - Python, JS

Comment by pjmlp 2 days ago

They are only surprising for anyone that never used any ahead of time compiled language since FORTRAN was introduced.

The golden age of scripting languages being used for applications have setted us back a few decades.

Comment by thephyber 3 days ago

Now we rewrite the web in Rust WASM. /s

But seriously, Python and JavaScript have reflection/introspection features. Once the investment was made to transcribe the entire language into a compiled language, the speed gains were obviously going to happen.

Comment by pjmlp 2 days ago

They also exist in compiled languages without the performance impact of scripting languages.

Comment by shikck200 3 days ago

Webdev is the pinnacle of over engineering. And now with AI, it will get even worse. I think the web truly needs a reset.

Comment by onion2k 3 days ago

Webdev is the pinnacle of over engineering.

Imagine you wanted to make a native desktop app that runs on Windows (going back to Windows 95), and OSX, and Linux, and have it use the end users choice of native components, QT, or GTK. It also has to load fast, be accessible, and work on desktop, laptop, and phones. Also, you're only allowed to ship a single binary but you can load in assets based on the device when it runs.

The app could be anything from a single page that renders one image up to a complete 3D game. Users want 60FPS regardless of what it is.

I reckon you'd end up with a relatively complicated build pipeline.

That's what webdev is today.

Comment by shakna 3 days ago

I think you'd just end up with WxWidgets. Because it can do all of that.

Most of the jank of the modern platform doesn't come from JavaScript - it comes frame dependency hell, framework layered over framework, and over abstraction. It is a _cultural_ problem, rather than a technical one.

Comment by 3 days ago

Comment by _bent 3 days ago

not only does it have to load fast, it has to _stream_ the content from the server to the client

Comment by shikck200 3 days ago

Thats not a true comparison, MAYBE that was sort of a thing back in the IE6 era. Today the web is capable of "a good enough" UX for most things. But how we do interactive apps on the web today is just madness. Most sites dont need anything close to React, and those who do could have just used something more simple without the madness what is the react ecosystem / bundlers / packages etc.

Comment by onion2k 3 days ago

The best non-web analogy I can think of is when someone builds a 2D platformer in Unreal Engine. The complexity of the tooling is necessary because someone else is making Witcher 4 in it. The fact the 2D platformer is using a vastly more complicated tool than necessary is on the dev, not the tool.

It's not React's fault that some devs don't know how to make a form in HTML. There is an argument that React doesn't spend much time telling people they might not need it, but that's not really their responsibility, plus there are some things (reactivity to other things on the page) that are common enough that seeing the boundary where you do or don't need it is actually quite hard.

Comment by slopinthebag 3 days ago

in defence of using ue5 for a 2d platformer, you still get a ton of features to help you build out the platformer, cross platform support, and you can reuse your knowledge across projects.

it's kind of the same for react. yes you could build one thing in vanilla js, another thing with htmx, and then a third in react. or just build all three in react and be done with it.

modern web dev is actually pretty simple now, there is still a stigma around webdev from the olden days but spinning up vite + react is trivial, doesn't pull a ton of dependencies, and makes it easy to build anything you want. yes you can still overcomplicate it massively but that's on the dev at that point.

Comment by mexicocitinluez 3 days ago

Its 2026. You thinking you know more about other people's requirements in an absolutely enormous field is just plain naive and its embarrassing reading this stuff on HN.

Comment by shikck200 1 day ago

Not sure what your point is? Are you saying that this mountain of complexity is somehow justified for the 99% of stuff out there? Complex stuff can and should be as simple as possible, and that something a good software developer strive to do.

But now we have abstractions upon abstraction, slow ands heavy solutions for almost every thing.

Software is slower than ever, not because of hardware, but because of the endless bloat and abstraction every framework brings.

Comment by satvikpendem 3 days ago

Improving speed is now overengineering apparently, but the same people would complain about how horrible web dev is if it weren't improved. Damned if you do, damned if you don't.

Comment by rjzzleep 1 day ago

It's layers upon layers of indirection and then massive layers of optimization on top of it.

What should happen is that we take the lessons that we learned from this current iteration of the web and desktop and turn it into a new generation while cutting out the crap we don't need.

Comment by satvikpendem 1 day ago

People are doing this already. Flutter is one example where it's compiled to Wasm. Other languages have Wasm web GUIs as well.

Comment by throw_m239339 3 days ago

But bad performances stems from non compiler optimized React to begin with, its execution model when handwritten. Other frameworks don't necessarily take more effort to use and have better performances from the get go.

Comment by satvikpendem 3 days ago

A lot of them do have compilers too, like a couple of the most commonly cited React alternatives, Svelte and Solid, so I'm not sure why React specifically is singled out.

Comment by throw_m239339 3 days ago

*React. Nobody is forced to use React to write web UI though. Actually, in theory, AI helps getting rid of all these web frameworks, they are tools for made developers, LLM don't need React to code a web UI, they can use Vanilla DOM or faster frameworks, like SolidJS.

Comment by yugoslavia4ever 3 days ago

There's lots of overengineered bollocks in webdev, but this is not one of those pieces.

Comment by slopinthebag 3 days ago

it's not really. you have javascript, you have a library like react which has a code transformer written in rust, you have vite which orchestrates the build process, and...?

if anything the migration of all these tools to rust makes things way less complicated. you have a binary for compiling your react code (totally optional btw, it's a performance optimisation), a cli for building your app (vite, built on a rust binary basically), and react itself which is virtually dependency free. where is the over engineering here?

Comment by 3 days ago

Comment by Onavo 4 days ago

Why does the Nextjs version of React compiler require a babel plugin when the vite version doesn't need it? Next.js is on SWC, not sure why they need a babel plugin.

Comment by crypto137 4 days ago

Because next is the worsttttt

Comment by mexicocitinluez 4 days ago

Because it isn't supported by SWC yet.

Comment by Buoylog 4 days ago

[flagged]

Comment by prettycool 4 days ago

[dead]

Comment by glouwbug 4 days ago

[flagged]

Comment by VertanaNinjai 4 days ago

As funny as this is I sometimes wonder about that crowd. Assuming the ecosystem at large flips and most software is now written in Rust what will the “rewrite it in Rust” crowd move to? Will they be satisfied for the most part or does it morph into “now rewrite in $latest_rust”?

Comment by chmod775 4 days ago

You will always have someone say "you should rewrite it in x", but it's rare that something carves out so much ground on the Pareto front you'll get a crowd.

Comment by ablob 4 days ago

I think the crowd will split into those who just cared about it being rust and those who wanted some kind of leverage to tempt others into doing something. The former crowd will cease being, while the latter looks for something new to push.

I believe that one does not need to be overly concerned here. As with most things you will never satisfy zealots so it is sufficient to reconsider every once in a while when the status quo changed enough to warrant the effort (i.e. the actual arguments change).

It is always a choice to participate in these "culture wars" or whatever you want to call this. If you can stick to a decision you can limit the impact quite a bit, I've come to realize.

Comment by anp 4 days ago

I've never been someone to tell others to rewrite in Rust but I am a huge fan of the language and have in fact rewritten a lot of things in Rust. I'd be happy for another programming language to excite me as much as Rust has for the last 10 years, and then maybe I'd join that evangelism club instead :). Not sure how PL evolution is going to go in an era of coding agents though, very curious how that'll play out.

Comment by MBCook 4 days ago

Maybe they’ll go back to “year of the Linux desktop”

Comment by steveklabnik 4 days ago

Because it became a meme virtually everyone who says this are actually joking and not serious.

They'll move on to whatever the next meme is.

Comment by wldcordeiro 4 days ago

I think once you have it in Rust the next ask is using no "unsafe" code from that crowd.

Comment by twistedpalm 3 days ago

As funny as it is, it was removed by this miserable community :/

Comment by dhbradshaw 4 days ago

I'd argue for moonbit -- faster compile times, almost as fast, smaller wasm artifacts and like lean can have proof of correctness built in.

Comment by Svoka 4 days ago

what the point? Rewriting in Rust is not just a language change. Rust enforces designing systems in secure way to start with, not just memory safety.

For me last nail into becoming part of the crowd was Embassy. Whole my life I wrote some ad-hoc C microcontroller stuff. But just learning Embassy I realized that it could've been done much more elegantly and securely. If you have a spare moment, I would watch videos in this channel, old to new:

https://www.youtube.com/@therustybits/videos

Comment by dhbradshaw 4 days ago

I've been using rust since 2017 and still code in it professionally and am a fan.

Moonbit is pretty cool too so I thought I'd mention it for other people who like cool things.