20 comments

[ 2.6 ms ] story [ 42.0 ms ] thread
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.

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?
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.
There has been a few minor releases since. I am planning on making a new release soon with a few bug fixes and working on new major features.

I'm also looking for new contributors and maintainers!

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.

It looks like this is a web UI library, so it would just render using regular html.

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.

The landing page is the screenshot. It uses sycamore.
"Read the Book" button, next gen web UI. That's all you need to know about this one.
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...
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.

> 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.

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.

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...
Not a single example of an actual application is not a good look for a web ui library
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 :-)

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.

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.