51–60 of 97 posts
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.
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.
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 {vm.message.value} } Makes it…
Naming so lit
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
Earlier quoted context omitted.
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 {vm.message.value} } Makes it…
How is a viewmodel better? It's way more skipping around in the codebase to find the parts you actually care about
- 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 , ) 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.
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.
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.
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
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.