The Rust React Compiler is now native in Vite
blog.master.dev
blog.master.dev
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.
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.
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.
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.
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...
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.
The golden age of scripting languages being used for applications have setted us back a few decades.
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.
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.
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.
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.
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.
No, I'm saying that I, as a single person, couldn't have any idea what the other 99% is doing and what their needs are. This field is ENORMOUS. There are hundreds of thousands of different types of problems being worked on. I don't know what complexity or requirements they're face and neither do you.
I've got 15 years and 6 jobs and I've still probably seen < 1% of the actual development work being done. And thinking that I can extrapolate form that 1% the other 99% is insane to me.
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.
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?