Show HN: Sycamore – next gen Rust web UI library using fine-grained reactivity
sycamore.dev
sycamore.dev
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."
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/<example_name> with <example_name> being the name of the example you want to view. For instance, the todomvc example is hosted on examples.sycamore.dev/todomvc.
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.
Maybe sell it some.
Next Gen UI. Bold sounding, show it.
That was the main point at beginning. They aren't showing, so kind of leaving it up to you to go dig through the manual. Like reading the manual is not a demo.
They aren't giving any incentive to cause someone to waste time on them.
> 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...
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.
A pure Rust app takes up ~60 MB for the same UI, with a large portion of that going towards graphics (wgpu table stakes).
In react when state changes the component functions that depended on that state are rerun to compute what the component should now look like. Then react diffs the new output with the previous to touch only the parts that changed in the DOM.
In solidjs the component function runs only once (when the component is instantiated), when state changes signals will trigger and cause the specific parts of the DOM that depended on them to change. This is generally more efficient.
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.
Also the ecosystem is really not there for XHTML, it never really took off. In practice it is close enough to HTML that it probably mostly works, but you are going to have problems.
The advantage is also very small, your emitter is simpler (you don't have to special case void elements and whatnot) and if you need to consume your own pages the parser is simpler. But that isn't worth much for most people.
It does make me sad, because parsing and even emitting HTML is a nightmare. But it won, so at the end of the day I find it easier to just accept that.
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 :-)
It resembles deepwiki (which I used on several of my projects, see for example https://deepwiki.com/pthom/imgui_bundle).
If algolia is close to deepwiki as I suspect, that does not replace the original doc site: it needs to index an existing doc site before. So adding (even a simple) search to this site would be worth it imho.
Basically its a service that automatically crawls your docs and creates a search index and widget that you can include on your website.
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.
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.
Shows you how good it looks out of the box on the first page.
I agree that it have better showcase of what you can build with it, but components library isn't it.
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"
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.
A general website will likely need a lot more data in the form of images and other media so all in all this is not too bad.
The reason why bundle size for JS is so important is that the browser needs to first download the JS, parse the JS, then JIT compile it before it can start running. For WASM on the other hand, the browser can in fact parse it while downloading in parallel and then run it almost immediately since WASM is much lower level. So for WASM the main bottleneck is downloading whereas JS, it is parsing and compiling.
Disagree. The bytes have to be read and extracted and the bigger it is, the more you are putting onto clients to load your page.
I'd also point out that this doesn't appear to be just simple runtime stuff like I thought. The fact that there's a 2x size difference between a simple webpage and a simple todo blog indicates this might be quiet expensive. That doesn't bode well for more complex applications.
I'd also point out that I just looked at the wasm. The bindings javascript themselves took up 37kb. That's bigger than react just for bindings.
> A general website will likely need a lot more data in the form of images and other media so all in all this is not too bad.
Yes, and a general website can function without those images. The part that makes the webpage functional is what I'm focusing on.
> The reason why bundle size for JS is so important is that the browser needs to first download the JS, parse the JS, then JIT compile it before it can start running. For WASM on the other hand, the browser can in fact parse it while downloading in parallel and then run it almost immediately since WASM is much lower level. So for WASM the main bottleneck is downloading whereas JS, it is parsing and compiling.
Before the browser can run a wasm blob, it has to download the javascript bindings which it has to parse and jit compile. It can be compiling the wasm while it's parsing the javascript, but it's not a free lunch. The wasm cannot start running until after the javascript is finished.
The browser is also free to start parsing the javascript while it's being downloaded. There's nothing special about javascript syntax that stops a browser from starting parsing while it's in flight (other than it might end up being dead).
I used Sycamore tho, it's neat.