Dioxus originally was more like ReactJS and used hooks. However, they have since migrated to using signals as well which makes Dioxus and Sycamore much more similar.

One remaining major difference is that Dioxus uses a VDOM (Virtual DOM) as an intermediary layer. This has a few advantages such as more flexible rendering backends (they also support native rendering for desktop apps), at the cost of an extra layer of indirection.

Creating native GUI apps should also be possible in Sycamore, and something I'm interested in although there is currently no official support. However, I think one of the big differences with Dioxus would be that Dioxus supports "one codebase, many platforms" whereas I think that is a non-goal with Sycamore. Web apps should have one codebase, native apps should have another. Of course, it would still be possible to share business logic but the actual UI code will be separate.

A word to the wise: similar to how foam is mostly air, Tauri is mostly marketing. Most of those 15MB "lightweight" bundles expand to 2 GB+ RAM in practice. Of course, devs still shamelessly (ignorantly, in all likelihood) call the apps "lightweight", while taking up, say, 6 GB of RAM for a 5 button UI. Tauri have also proven reticent [0] to correct the record. One supposes the sole advantage of sharing memory with other Tauri apps is not a sufficient sell to overcome Electron's single-browser-engine advantage.

A pure Rust app takes up ~60 MB for the same UI, with a large portion of that going towards graphics (wgpu table stakes).

[0] https://github.com/tauri-apps/tauri/issues/5889

You can't fit browser JS ergonomics into Rust and expect zero friction, because once you wire up a stateful UI with the kind of component churn you get in React, you spend more time satisfying the type system, and you also give up hot reload plus a decade of npm junk for odd corner cases.

You need a hard reason for that rewrite.