If you actually read the README.md file, the first few lines say that there are hosted versions available that you can view directly in your browser. I also mentioned this in another comment. I don't know what else you want...
I just see a lot of open source projects fail on the basic "get the message out".
And, I actually would like to use a Rust / Wasm UI.
That's what was frustrating. I'm looking for this. And still, had to wade through site to find some slick demo showing the merits of the speed and responsiveness. You want some snappy demos to show zip. It says 'reactivity', so I was expecting some super fast demo.
Sure. Ok. Now, put those links on the main page with a big bold "Examples Here". Is it that hard. Why make potential users wade through 5 clicks to get to an example, and then see if they are interested enough to persue further.
If you want users, put in bold, splashy, easy to get to.
It isn't that hard.
Viewing on examples.sycamore.dev
All the examples are hosted under examples.sycamore.dev/ with being the name of the example you want to view. For instance, the todomvc example is hosted on examples.sycamore.dev/todomvc.
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 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.
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 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...
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.
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...
75 comments
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.
> Sycamore is a next gen Rust *web* UI library powered by fine-grained reactivity.
This is why open source doesn't gain traction.
"Hey can i see a cool demo of your stuff"
"No, FU, here is some code in a folder somewhere. F'n normals can't even compile. doh."
I just see a lot of open source projects fail on the basic "get the message out".
And, I actually would like to use a Rust / Wasm UI.
That's what was frustrating. I'm looking for this. And still, had to wade through site to find some slick demo showing the merits of the speed and responsiveness. You want some snappy demos to show zip. It says 'reactivity', so I was expecting some super fast demo.
Sure. Ok. Now, put those links on the main page with a big bold "Examples Here". Is it that hard. Why make potential users wade through 5 clicks to get to an example, and then see if they are interested enough to persue further.
If you want users, put in bold, splashy, easy to get to.
It isn't that hard.
Viewing on examples.sycamore.dev All the examples are hosted under examples.sycamore.dev/ with being the name of the example you want to view. For instance, the todomvc example is hosted on examples.sycamore.dev/todomvc.
> 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.
1. https://github.com/yewstack/yew
2. https://github.com/sycamore-rs/sycamore
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 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.
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.
(if the "search implementation" is readable enough, it may perhaps also serve as teaching material :-)
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.
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.