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?
lukechu10 15 minutes ago [-]
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.
The Dioxus library seems really similar to me. How is Sycamores model different?
lukechu10 6 minutes ago [-]
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.
I get: Uncaught (in promise) ReferenceError: WebAssembly is not defined
lukechu10 14 minutes ago [-]
Umm which browser are you using? Did you disable webassembly somehow?
catapart 11 minutes ago [-]
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.
lukechu10 4 minutes ago [-]
Hmm thanks for the feedback. The front page definitely has lots of room for improvement.
sourcegrift 24 minutes ago [-]
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.
silon42 16 minutes ago [-]
For simple stuff, qml is OK/better (except the JS part)... but for some more complicated views I'd want qwidgets.
Rendered at 13:28:39 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
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.
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.