I really like these projects but missing from them is genericity. If you're taking the time to build a WASM app in Rust it would be nice if that app could compile to something other than WASM. For example, looking at the sycamore website's source I see p, h1, div, etc. What I'd rather see is "row", "column", "text". In their source I see tailwind what I'd rather see is "center", "align right", etc.
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.
It's more like ReactJS/SolidJS (but in Rust) rather than a component library like Bootstrap. Although I definitely agree the home page can do a much better job of explaining this.
I think if you're going to use Rust on front end you're probably going to use it on back end too. In that case, I would just use Dioxus and get the e2e typing for free. What would be the benefit of Sycamore?
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.
The website mentions "giving you full control over performance", what are those knobs and levers exactly? What does those knobs and levers influence, and what sort of tradeoffs can you make with the provided controls?
Unlike other UI libraries, I would say Sycamore has a very clear execution model. If you've used something like React before, there is all this thing about component lifecycles and hook rules where the component functions run over and over again when anything changes. This can all end up being fairly confusing and has a lot of performance footguns (looking at you useRef and useMemo).
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.
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.
How does it compare to leptos? Leptos is roughly based on Solidjs and uses signals, to enable fine grained reactivity and avoid a vdom. Why sicamore over leptos?
With Tauri you also get the freedom of choosing frontend frameworks and can reuse existing frontend code/skills. Yes React has issues, for example Svelte handles reactivity in a much better way. I don't see real benefits of re-implementing the whole thing in Rust.
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.
i've had my shot at sycamore a number of times. IMO leptos (leptos.dev) has far more fine-grained capabilities, and dioxus (dioxuslabs.com) is overall more hand-holdy but also powerful. comes with tradeoff for speed. wasm still isnt there yet (yet..) but a lot more web frameworks (including smaller rust ones) can be tracked here: https://krausest.github.io/js-framework-benchmark/current.ht...
The website is an entirely static website, and the frameworks main pitch is how good it is with reactive websites. This website could be entirely the same with html and css.
in case you don't understand what GP is suggesting: your website does not actually describe what you're providing. A "next generation Rust UI library powered by fine-grained reactivity." could mean a UI for native apps - something like egui or Dioxys - or it could mean a way to use rust to output HTML, CSS, and javascript. Or a bunch of other things. And, regardless, there's no way to look at your website and determine how to get that output using sycamore. I can inspect and see your HTML or your CSS, but there's no Rust code for me to compare that against without going and looking it up somewhere.
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.
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.
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.
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.
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.
> 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.
I'm also looking for new contributors and maintainers!
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/
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.
https://ui.shadcn.com/
Shows you how good it looks out of the box on the first page.
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.