For desktop, I'm very happy with qmetaobject-rs. Qt is time tested and highly reliable. And gui is, frankly, serious business.
Also, Generally speaking, UI itself is best done declaratively rather than imperatively. There's a reason quick is adopted more than qwidgets.
In sycamore, the component function only ever runs a single time. Instead, Sycamore uses a reactive graph to automatically keep track of dependencies. This graph ensures that state is always kept up to date. Many other libraries also have similar systems but only a few of them ensure that it is _impossible_ to read inconsistent state. Finally, any updates propagate eagerly so it is very clear at any time when any expensive computation might be happening.
For more details, check out: https://sycamore.dev/book/introduction/adding-state
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.
I'm also looking for new contributors and maintainers!
I can’t find a screenshot of it anywhere, let alone the landing page.
I wish they said that on the homepage. I assumed it could render to the desktop or something, and I had to read tea leaves to figure that out.
In other words, elm-ui but for these WASM Rust apps. Building a mobile app, a desktop app, and a web app, in my mind, should be accomplish-able given the right primitives (without requiring a JavaScript runtime be bundled). Rust's multi-crate workspaces make it a really great candidate for solving these cross-platform problems. IMO of course.
For example, a "row" is not just a "<div>" tag. Its a div which horizontally fills its container. Centering contents with a "center" style attribute abstracts flex-box, browser compatibility, version compatibility, and the cascading behavior of CSS.
You move the incidental complexity of the web platform into the compiler which will always do the right thing. And in exchange you get the option to compile to a native or mobile app for "free".
But there are categories of application where that is not acceptable. The presentation is a tightly controlled aspect of the application's functionality. If you're designing an application with leptos or sycamore my suspicion is you would fall into the latter category rather than the former.
> Sycamore is a next generation Rust UI library powered by fine-grained reactivity.
It's not clear on the landing page that this is for in-browser UI, as opposed to desktop UI and/or mobile UI.
I would make it completely unambiguous that Sycamore is for web applications.
But Sycamore does have ambitions to have native GUI support as well. I'm currently looking at GTK, Iced, and GPUI and see if it would be possible to add Sycamore support. This would make it possible to create GTK, Iced, or GPUI apps using building blocks from Sycamore.
FWIW, as an iced user, personally I'd prefer to write iced and use something like sycamore to build for the web rather than the other way around
I feel like combining the drawing layer from one of these existing native UI frameworks with Sycamore could be interesting in reducing some of the boilerplate with GTK, Iced, GPUI, etc...
I wouldn't recommend e2e Rust generally yet though. I think server/API + web could work, but mobile is just boiling the ocean and will never be as good as native. You might think you can just use it for server/API + web, then do native mobile apps, but actually the escape hatches in all the frameworks I've used are not great.
Sad to say but "just use React" remains the good advice.
However, I could be wrong. There's a small semantic difference between "next gen Rust web UI library" and "next gen web UI library written in Rust"
conceptme•2h ago
lukechu10•2h ago
There are also a bunch of examples at https://github.com/sycamore-rs/sycamore/tree/main/examples
You can see the deployed versions at https://examples.sycamore.dev/<example name>/ for instance: https://examples.sycamore.dev/todomvc/
silon42•2h ago
lukechu10•2h ago
catapart•2h ago
To be more succinct: you don't even have an image of your UI running on your websites landing page. Not one single image of the library which is, again, a UI library. People have an interest in knowing "does this look and feel like I want it to?" as well as "can I use this in the projects I'm working on?". Both of those questions should be answered by your landing page. For me, at least, it doesn't do that.
lukechu10•1h ago
fnikacevic•1h ago
https://ui.shadcn.com/
Shows you how good it looks out of the box on the first page.
ecshafer•55m ago
lukechu10•29m ago