Leptos vs Dioxus: which should be the main framework?

[max-wells]

RUST-UI currently ships on Leptos. We have been prototyping a Dioxus port in parallel (dioxus-ui) and want the community input before committing to a direction.

Keep Leptos as the primary framework (Dioxus stays secondary/experimental), or make Dioxus the primary framework (Leptos becomes secondary)?

Vote below, comments with your reasoning (SSR needs, mobile/desktop targets, existing Leptos codebase investment, etc.) very welcome.

Poll closes August 22, 2026.

[max-wells]

Small personal take (not trying to push one way, just sharing my experience): I lean toward Dioxus.

A few points that make me prefer Dioxus:

• Compile times / dev loop: hot-reload for RSX is fast and mature, a big win on large component libraries like this one.
• Fewer hydration headaches than Leptos. The classic SSR mismatch/marker node issues show up less.
• Cross-platform by default (web/desktop/mobile) with no extra effort. Leptos is essentially web-first: cross-platform works today, but it wasn't designed for it, so you end up bolting on src-tauri and co, which gets old fast.
• Server functions on par with Leptos, so no compromise there for SSR/fullstack use cases.
• From what I've seen, Dioxus has more traction right now (⭐ ~38.5k GitHub stars vs ⭐ ~21k for Leptos).
• New features seem to be landing at a good pace.
• Worth noting: Leptos is community-run/open source only, while Dioxus Labs is backed by Y Combinator (S23 batch), which means more resources to keep developing it.

Long-run, I think Dioxus has more room to become THE go-to fullstack Rust framework, so that's where my vote goes.

[boondocklabs]

Dioxus isn't really native cross platform.. it's just a WebView. In the context of rust-ui, that may be fine given the focus on web components, but also dx has their own component library. Why compete with that?

Dioxus has some advantages, but cross platform isn't really one of them IMO. In my experience, WebView apps are typically slow and often feel out of place. I use crux specifically for cross platform Rust development that auto generates bindings to WASM for web (leptos here), Swift for macOS/iOS, Kotlin on Android, or native for ratatui or egui.

The shell is essentially a thin wrapper around the core application logic. This requires more upfront work and means Rust UI code applies only to the web target, but the other platforms can use genuinely native components instead of web-based ones.

Personally, I’d prefer not to pull in Dioxus’s heavier dependencies when they aren’t needed. Leptos and rust-ui seem like a great fit for a lightweight web shell.

[sarendipitee]

@boondocklabs That is misleading. Dioxus has pluggable renderers and absolutely supports native cross platform. Blitz, one of said renderers, is being heavily worked on by not only Dioxus maintainers but also Cloudflare as they are using it in their new Kitesurf headless browser. The idea is that you write Dioxus components using CSS and instead of a WebView you get native pixels out.

[max-wells]

@boondocklabs That is a fair point, and I think Crux is very interesting for exactly that reason.

It is more native in a sense, or at least closer to a genuinely platform-specific approach, because the architecture is built around a shared Rust core with platform-targeted shells instead of trying to force the same UI layer everywhere. I can definitely see the appeal in that model.

For RUST-UI though, the original goal was a bit different, and for now it still is: be accessible to the largest number of Rust web developers possible, and feel very close to the React / shadcn way of building UI.

So even if something like Crux may be the more native architectural path in some contexts, I am not sure it matches the main goal of this project as well as a framework that stays closer to that web-first, component-library experience.

---

@sarendipitee That is a fair clarification.

I agree Dioxus should not be reduced to “just WebView apps,” and the renderer is part of what makes it interesting long-term. At the same time, I also do not want to overstate what is promising versus what is already mature today.

For me the useful takeaway is simply that Dioxus has the stronger multi-target direction, while the main project question is still which framework best fits the kind of UI library RUST-UI is trying to be right now.

[boondocklabs]

@sarendipitee That's fair, and I didn't intend to be misleading but I was more referring to what's implemented today as opposed to where it may go in the future. Currently you cannot implement native UI components on iOS, Android, and to my knowledge there is no mature way to use native framework features such as notifications, GPS, bluetooth, etc.

The marketing promise doesn't really match production reality. In my opinion you wouldn't build a production grade mobile app on Dioxus today. You can with Crux, sharing core business logic with Leptos.

Arguably you could equally do the same with crux+dioxus web only, but just as a matter of preference I prefer the lighter nature of leptos as a shell, without the heavy virtual DOM as the app itself is all managed inside the crux core.

@max-wells I completely appreciate that RUST-UI goals are web first, and project priorities should likely be focused on the leading web frameworks. Crux being completely headless isn't applicable here, just sharing my use case and rationale for the leptos preference.

[FrancisTCE]

off this is a really hard one, there have been some discussion about exactly this topic today and a very passionate one i must say. Here are my 2 cents (and probably not worth much more than this):

First of all, @boondocklabs has a really good point and so do you.

• My preference (if I was the maintainer) would be the lightweight and most recent tech path, if I was not aiming at a broader enterprise insertion.

Also important in my opinion... if the goal would be mainly community use and nerding over tech then Leptos wins for me otherwise Dioxus is a clear winner here since they have corp backing on it. If Leptos maintaner drops the project it will hit harder than Dioxus that has a dev team to continue work if someone leaves.

Thanks!

[ALAWIII]

Hi @max-wells ,
Since all Rust web frameworks use the same reactive system concepts and keywords, I am wondering if it is better to try to make an abstraction rather than duplicating the same components' code to satisfy many frameworks.
Something like one macro structure used by all Rust web frameworks and compiled to framework-specific settings.
for example: rsx!{} and mview!{} shares nearly same structure:
https://github.com/blorbb/leptos-mview

• one language interface dominate them all.

Also, Rust UI web frameworks will gain a competitive advantage against JS frameworks because of compatibility and easy to shift without compromising time, effort, and re-port!
Make this kind of flexibility change once and rest forever.

[max-wells]

Hello @ALAWIII ,

Interesting idea, and I do think shared abstractions between Rust UI frameworks are worth exploring.

I took a closer look at things like leptos-mview, and my impression is that this can be useful at the syntax/authoring level, especially for reducing some duplication in simpler components. But for me the bigger issue is that this is not only a syntax question.

Things like subsecond hot-reloading, compile-time behavior, tooling, and the overall dev loop come from deeper framework internals, not just from the surface macro. That is a large part of the reason I currently lean toward Dioxus: at least from my experience so far, it is leading pretty clearly there.

So my current view is that a shared abstraction could still make sense as a long-term experiment for a limited shared component surface, but probably not as a full replacement for picking one main framework right now.

My concern is that, if we push the abstraction too far too early, we may end up maintaining our own layer on top of multiple evolving frameworks while still not getting the same benefits in tooling and internals that make one framework more attractive in the first place.

[sergiomeneses]

To me leptos is the go-to decision righ now (and near/mid future), dioxus is another kind of promise and right now to me is far way from a real multi-platform framework. Maybe an abstraction is better than choose one over other.

[MentalGear]

While I did vote for leptis previously I would now change it as I have learned more about dioxus and the better a11y and their already highly advanced shadcn style library https://github.com/DioxusLabs/dioxus-components.

I noticed that you have your own port attempt, so I'm curious why you chose it over directly helping on the official upstream repo (maybe you didn't know as it was not that easy to find).

[max-wells]

Thanks everyone for voting and for the really thoughtful discussion in the comments. Final tally was 108/105, essentially a tie, so I'm locking this now and making the call as maintainer rather than treating it as a mandate.

Going with Dioxus as the main framework going forward. Main reasons for me:

• Fast, mature hot-reload for RSX, big win on a large component library like this one
• Fewer hydration/SSR mismatch headaches than Leptos
• Cross-platform by default (web/desktop/mobile), no need to bolt on extra tooling
• Server functions on par with Leptos, no compromise for fullstack use cases
• More traction right now (~38.5k stars vs ~21k for Leptos), and Dioxus Labs is YC-backed, which means dedicated resources long term

The WebView vs native point raised in the comments is fair and worth keeping in mind, but for RUST-UI the priority is staying web-first and close to the React/shadcn authoring experience, which is where Dioxus fits best right now.

Appreciate everyone who weighed in, near-even split or not this was genuinely useful signal.