dioxus

https://www.ycombinator.com/companies/dioxus-labs https://www.ycombinator.com/launches/JBK-dioxus-labs-web-des... https://github.com/dioxusLabs/dioxus

Yes! There are a few experiments with JS engines going on (all very early stage atm (and many vibe coded) but looking promising enough to justify doing a proper implementation in future). With this you can actually run regular React DOM (so fully compatible with deploying the same codebase to web). There is then the potential to mix in native components, although that's not fully built-out today. Finally, as part of this project we develop Dioxus Native (see https://github.com/DioxusLabs/dioxus and https://dioxuslabs.com). This allows you to write your app in a React-like framework in Rust, which also allows you to write a single codebase and compile to both native (desktop/mobile) using Blitz and to web (compiles to WASM, renders using real DOM nodes).

What's "rust scripting"? I don't see any mention of it in the docs nor dioxus native roadmap and AFAIK https://github.com/DioxusLabs/dioxus/tree/main/packages/inte... is used as the interpreter although I can't for the life of me figure out where the JS engine is actually instantiated.

Yeah. I think you need to render to actual DOM nodes when targeting the web if you want a first class experience. We're betting on this over at https://github.com/DioxusLabs/dioxus where we're building a cross-platform UI solution that enables you to do this by having a web-centric API (we are developing our own custom HTML/CSS renderer for native platforms).

> I don't see what advantage this gives I believe it may "just" be faster link times. Which may seem minor, but link times can often dominate incremental compile times because it's a slow and (at least historically) serial step which is O(total code size) even if the actual compilation is incremental. See mold's linking benchmarks: https://github.com/rui314/mold. It can be the difference between multiple 10s of seconds with traditional linkers vs <2s with newers ones. There are few strategies for dealing with this: 1. Is just to use a faster multi-threaded linker. On Linux, lld, mold, and wild on Linux are all much faster than the traditional ld/gold (and the latter two another step above lld). On macOS, the new built-in ld64 is pretty good. Not sure what the state is on Windows: possibly lld is best? 2. Is dynamic linking as above. This

I don't think GPUI has it integrated yet, but Dioxus's Subsecond tool [0] implements binary hot-patching for Rust apps which can help alieviate this problem. The other thing you can do (which is popular in the Bevy community) is to compiile the "core runtime" into dynamic library. Then you don't need to recompile that set of crates for incremental builds. [0]: https://github.com/DioxusLabs/dioxus/tree/main/packages/subs...

I think it would, modulo that it's not really "ready" yet. We do have a couple of PoC examples of integrating with the Bevy game engine. Both of these use Dioxus Native, which wraps Blitz with Dioxus (which is a React-like framework but in Rust rather than JavaScript - https://github.com/DioxusLabs/dioxus), but you could do DOM tree creation and event handling manually if you wanted to. - This first one includes Bevy inside a window setup by Dioxus Native (using a `<canvas>` element similar to how you might on the web). Here the event loop is controled by Dioxus Native and the Bevy game is rendered to a texture which is then included in Blitz's scene. https://github.com/DioxusLabs/dioxus/tree/main/examples/10-i... - This second one does it the other way around and embeds a Dioxus Native document inside a window setup by Bevy. Here the eve

If you're familiar with JS frameworks, you can think of it like this: Dioxus : React :: Leptos : SolidJS The key for me is that Leptos leans into a JSX-like templating syntax as opposed to Dioxus's H-like function calls. So, Leptos is a bit more readable in my opinion, but that probably stems from my web dev background. The Dioxus README has a whole section comparing them -- https://github.com/DioxusLabs/dioxus#dioxus-vs-leptos

Creator here - haven't had a chance to write up a blog post yet! Stay tuned. The gist of it is that we intercept the Rust linking phase and then drive `rustc` manually. There's some diffing logic that compares assembly between compiles and then a linking phase where we patch symbols against the running process. Works across macOS, Windows, Linux, iOS, Android, and WASM. On my m4 I can get 130ms compile-patch times, quite wicked stuff. We handle the hard parts that the traditional dylib-reloading doesn't including TLS, statics, constructors, etc. I've been posting demos of it to our twitter page (yes twitter, sorry...) - With bevy: https://x.com/dioxuslabs/status/1924762773734511035 - On iOS: https://x.com/dioxuslabs/status/1920184030173278608 - Frontend + backend (axum): https://x.com/dioxuslabs/status/1913353712552251860 - Ratatui (tui a

> Are there any approaches which implement server-side rendered SPAs with Rust? In that case Rust would render the HTML for the first load and server JSON APIs for changes in the SPA Yes, frameworks like Dioxus (https://github.com/dioxuslabs/dioxus) implement next.js-like "fullstack" SPAs in Rust (the client-side code compiles to WASM). > Rendering the HTML is performance-intensive in my experience, using Rust could save up quite some computational resources. The server-side performance is indeed much better than JS alternatives (client-side performance is more or less the same).