I looked briefly, but is anyone aware of the differences between Yew[1] and Sycamore[2]? Presumably they are both Elm-influenced(?) Rust web UI libraries named after trees, but it's unclear to me why I should use one versus the other.
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?
show comments
cma256
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.
show comments
pstomi
I looked at your doc book (https://sycamore.dev/book/guide). I suppose it uses sycamore itself.
Do you plan to add a search to it?
(if the "search implementation" is readable enough, it may perhaps also serve as teaching material :-)
show comments
0x3f
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.
arpadav
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...
eviks
What is "next gen" about it, is it "just" fine-grained reactivity? Or is this opposed to prev gen of Rust web UI libs, which were...? Couldn't find it in the book quickly, and it seems to not even have search...
show comments
jtrueb
Is there a new version or news related to this? v0.9 was Nov 2024, and Leptos and Dioxus have been a lot more active.
show comments
conceptme
a UI library needs some demo
show comments
FrustratedMonky
Every UI or GUI 'new fancy' package should include a very obvious Demo or link to Demo on the Home Page.
You're trying to sell me on some slick looking stuff -> Then Show It. Make it obvious. The market is crowded, people don't have time to hunt around and download it to try.
Don't make me read a manual before convincing me I should spend time on it.
luckydata
Not a single example of an actual application is not a good look for a web ui library
show comments
sourcegrift
Looks very good and probably will be my library of choice for my next web project.
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.
IMO a UI library landing page should always contain a screenshot example of the UI.
I can’t find a screenshot of it anywhere, let alone the landing page.
> Reactive Apps with Effortless Performance.
> 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.
Why is the deliverable so bulky?
The webpage has a 250kb wasm deliverable. The todo app has a 500kb deliverable.
That's a pretty big chunk of bytes for such simple applications.
In the footer: "This website is also built with Sycamore. Check out the source!" https://github.com/sycamore-rs/website
I looked briefly, but is anyone aware of the differences between Yew[1] and Sycamore[2]? Presumably they are both Elm-influenced(?) Rust web UI libraries named after trees, but it's unclear to me why I should use one versus the other.
1. https://github.com/yewstack/yew
2. https://github.com/sycamore-rs/sycamore
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?
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.
I looked at your doc book (https://sycamore.dev/book/guide). I suppose it uses sycamore itself. Do you plan to add a search to it?
(if the "search implementation" is readable enough, it may perhaps also serve as teaching material :-)
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.
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...
What is "next gen" about it, is it "just" fine-grained reactivity? Or is this opposed to prev gen of Rust web UI libs, which were...? Couldn't find it in the book quickly, and it seems to not even have search...
Is there a new version or news related to this? v0.9 was Nov 2024, and Leptos and Dioxus have been a lot more active.
a UI library needs some demo
Every UI or GUI 'new fancy' package should include a very obvious Demo or link to Demo on the Home Page.
You're trying to sell me on some slick looking stuff -> Then Show It. Make it obvious. The market is crowded, people don't have time to hunt around and download it to try.
Don't make me read a manual before convincing me I should spend time on it.
Not a single example of an actual application is not a good look for a web ui library
Looks very good and probably will be my library of choice for my next web project.
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.