[HN Gopher] Show HN: Sycamore - next gen Rust web UI library usi...
___________________________________________________________________
Show HN: Sycamore - next gen Rust web UI library using fine-grained
reactivity
Author : lukechu10
Score : 94 points
Date : 2026-04-01 12:30 UTC (10 hours ago)
(HTM) web link (sycamore.dev)
(TXT) w3m dump (sycamore.dev)
| conceptme wrote:
| a UI library needs some demo
| lukechu10 wrote:
| The website itself is made with Sycamore!
|
| 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/
| silon42 wrote:
| I get: Uncaught (in promise) ReferenceError: WebAssembly is
| not defined
| lukechu10 wrote:
| Umm which browser are you using? Did you disable
| webassembly somehow?
| catapart wrote:
| 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 wrote:
| Hmm thanks for the feedback. The front page definitely has
| lots of room for improvement.
| fnikacevic wrote:
| A great example is the shadcn site
|
| https://ui.shadcn.com/
|
| Shows you how good it looks out of the box on the first
| page.
| 0x457 wrote:
| That's a component library, Sycamore is no that.
|
| I agree that it have better showcase of what you can
| build with it, but components library isn't it.
| ecshafer wrote:
| The website is an entirely static website, and the frameworks
| main pitch is how good it is with reactive websites. This
| website could be entirely the same with html and css.
| lukechu10 wrote:
| That's true... but there's also plenty of other examples
| with more reactive elements.
| luckydata wrote:
| I will say it bluntly because it needs to be said: that
| website is not enough for anyone to be interested in the
| library.
| lukechu10 wrote:
| There are also plenty of other examples as mentioned in the
| comment above. Also many other projects using Sycamore
| which you can see by looking at GitHub's reverse dependency
| page.
| sourcegrift wrote:
| 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 wrote:
| For simple stuff, qml is OK/better (except the JS part)... but
| for some more complicated views I'd want qwidgets.
| embedding-shape wrote:
| 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 wrote:
| 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 wrote:
| The Dioxus library seems really similar to me. How is
| Sycamores model different?
| lukechu10 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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
| hrmtst93837 wrote:
| You can't fit browser JS ergonomics into Rust and expect
| zero friction, because once you wire up a stateful UI with
| the kind of component churn you get in React, you spend
| more time satisfying the type system, and you also give up
| hot reload plus a decade of npm junk for odd corner cases.
|
| You need a hard reason for that rewrite.
| jtrueb wrote:
| 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.
| lukechu10 wrote:
| 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!
| electrograv wrote:
| 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.
| TechSquidTV wrote:
| Unless maybe it's headless, then I still expect a component
| library or something. Still, I see nothing.
| lukechu10 wrote:
| It's more like ReactJS/SolidJS (but in Rust) rather than a
| component library like Bootstrap. Although I definitely agree
| the home page can do a much better job of explaining this.
| josephg wrote:
| 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.
| simonbw wrote:
| The first sentence of this page says it:
|
| > Sycamore is a next gen Rust *web* UI library powered by
| fine-grained reactivity.
| lukechu10 wrote:
| That's because I've changed it since posting this!
| FrustratedMonky wrote:
| How does that mean that shouldn't have a demo available?
| lukechu10 wrote:
| There are a lot of demos! Check out the examples/ folder
| on GitHub.
| FrustratedMonky wrote:
| Folders on Github is not a demo.
|
| 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."
| lukechu10 wrote:
| 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...
| FrustratedMonky wrote:
| This?
|
| 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.
| Tuna-Fish wrote:
| The landing page is the screenshot. It uses sycamore.
| simlevesque wrote:
| Well, then something's wrong. I click on different pages in
| the documentation and the whole page gets rerendered. Seems
| like it's not delivering what's promised.
| Flavius wrote:
| "Read the Book" button, next gen web UI. That's all you need to
| know about this one.
| FrustratedMonky wrote:
| I'd like to know why i'm bothering to read the book?
|
| Maybe sell it some.
|
| Next Gen UI. Bold sounding, show it.
| ordu wrote:
| You don't need to read, but you may want to look, if you
| want to see web UI in action. It is much better than a
| static screenshot.
| FrustratedMonky wrote:
| Then they should put some links to some demo's.
|
| 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.
| lukechu10 wrote:
| Good feedback. I'll make a demo page showcasing all the
| examples and link to it from the home page.
| dewey wrote:
| In the footer: "This website is also built with Sycamore. Check
| out the source!" https://github.com/sycamore-rs/website
| arpadav wrote:
| 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...
| cma256 wrote:
| 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.
| 0x3f wrote:
| If you're not targetting mobile, why diverge from XHTML at all?
| cma256 wrote:
| Are there native frameworks which use XHTML? Regardless, a
| document language being used to construct complex,
| interactive GUIs is incidental complexity. XHTML can be a
| compilation target but it does not need to be a development
| target.
| 0x3f wrote:
| But what's the benefit of using e.g. <row><cell> over
| <tr><td> if your only target is the web?
| cma256 wrote:
| If your only target is web then there is no benefit other
| than a reduction in complexity.
|
| 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".
| 0x3f wrote:
| I think I much prefer semantic elements like <section>
| over something like <row>. Calling something a row bakes
| in presentational information. Something that's a row on
| one screen size might be a column on another.
| cma256 wrote:
| I agree. For my blog I don't apply CSS and prefer to let
| the browser's reader mode perform the styling for me.
|
| 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.
| kevincox wrote:
| No browsers support streaming parsing of XHTML so you are
| slowing down pageloads. Especially for longer pages.
|
| 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.
| gwbas1c wrote:
| > 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.
| lukechu10 wrote:
| Ok I've modified it slightly.
|
| 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.
| airstrike wrote:
| Once upon a time there was iced_web https://github.com/iced-
| rs/iced_web
|
| 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
| lukechu10 wrote:
| I'm personally not to big of a fan of the Elm pattern for
| UI. Although it can be quite elegant, most of the times, it
| ends up being quite verbose even for simple things.
|
| 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...
| 0x3f wrote:
| 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.
| wsowens wrote:
| 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.
|
| 1. https://github.com/yewstack/yew
|
| 2. https://github.com/sycamore-rs/sycamore
| basro wrote:
| They differ in a similar way to how React differs from SolidJS.
|
| 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.
| eviks wrote:
| 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...
| d0liver wrote:
| My impression was that it's next gen because it's using Rust on
| WASM as opposed to something that compiles to JavaScript.
|
| 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"
| luckydata wrote:
| Not a single example of an actual application is not a good look
| for a web ui library
| lukechu10 wrote:
| What kind of examples were you expecting? There are plenty of
| examples in the examples/ folder on GitHub as well as plenty of
| other projects using Sycamore as can be seen from GitHub's
| reverse dependency page
| 0x457 wrote:
| At very least I'd like to see how easy it is to build a
| simple -/+ counter and click some buttons.
|
| I used Sycamore tho, it's neat.
| pstomi wrote:
| 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 :-)
| lukechu10 wrote:
| Yes I plan on adding doc search. Although I'm not sure if I
| should try to build one from scratch (never tried building full
| text search before) or using something prebuilt like Algolia
| docsearch.
| pstomi wrote:
| Algolia docsearch would host an AI view of the doc, on its
| own website with its own stack, no?
|
| 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.
| lukechu10 wrote:
| No I think that's a different product. What I had in mind
| is what is on, for example, https://tailwindcss.com/ and
| many other open source project websites. If you open the
| search menu, you'll see at the bottom that it's powered by
| Algolia docsearch.
|
| Basically its a service that automatically crawls your docs
| and creates a search index and widget that you can include
| on your website.
| FrustratedMonky wrote:
| 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.
| cogman10 wrote:
| 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.
| lukechu10 wrote:
| It's the gzipped size that matters a lot more. Also wasm is
| significantly faster to parse and run than Javascript so
| although 500kb seems like a lot for JS, for WASM it's not that
| much.
|
| 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.
| cogman10 wrote:
| > It's the gzipped size that matters a lot more.
|
| 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).
___________________________________________________________________
(page generated 2026-04-01 23:01 UTC)