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.

For more details, check out: https://sycamore.dev/book/introduction/adding-state

▲

bickfordb 6 hours ago | parent | next [-]

The Dioxus library seems really similar to me. How is Sycamores model different?

▲

lukechu10 6 hours ago | parent [-]

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.

	▲	josephg 5 hours ago \| parent [-]
		How does it compare to leptos? Leptos is roughly based on Solidjs and uses signals, to enable fine grained reactivity and avoid a vdom. Why sicamore over leptos?

▲

mapcars 5 hours ago | parent | prev [-]

With Tauri you also get the freedom of choosing frontend frameworks and can reuse existing frontend code/skills. Yes React has issues, for example Svelte handles reactivity in a much better way. I don't see real benefits of re-implementing the whole thing in Rust.

▲

truefaxxx 4 hours ago | parent [-]

A word to the wise: similar to how foam is mostly air, Tauri is mostly marketing. Most of those 15MB "lightweight" bundles expand to 2 GB+ RAM in practice. Of course, devs still shamelessly (ignorantly, in all likelihood) call the apps "lightweight", while taking up, say, 6 GB of RAM for a 5 button UI. Tauri have also proven reticent [0] to correct the record. One supposes the sole advantage of sharing memory with other Tauri apps is not a sufficient sell to overcome Electron's single-browser-engine advantage.

A pure Rust app takes up ~60 MB for the same UI, with a large portion of that going towards graphics (wgpu table stakes).

[0] https://github.com/tauri-apps/tauri/issues/5889

	▲	susupro1 4 hours ago \| parent [-]
		[dead]