8 ms·

Show HN: Sycamore – next gen Rust web UI library using fine-grained reactivity

95 points by lukechu10 6mo ago

conceptme 6mo ago
a UI library needs some demo
- lukechu10 6mo ago
  The website itself is made with Sycamore! There are also a bunch of examples at https://github.com/sycamore-rs/sycamore/tree/main/examples 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/ https://examples.sycamore.dev/todomvc/
  - silon42 6mo ago
    I get: Uncaught (in promise) ReferenceError: WebAssembly is not defined
    - lukechu10 6mo ago
      Umm which browser are you using? Did you disable webassembly somehow?
  - catapart 6mo 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 6mo ago
      Hmm thanks for the feedback. The front page definitely has lots of room for improvement.
      - fnikacevic 6mo ago
        A great example is the shadcn site https://ui.shadcn.com/ https://ui.shadcn.com/ Shows you how good it looks out of the box on the first page.
        0x457 6mo ago
        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 6mo ago
    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 6mo ago
      That's true... but there's also plenty of other examples with more reactive elements.
  - luckydata 6mo ago
    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 6mo ago
      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 6mo 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 6mo ago
  For simple stuff, qml is OK/better (except the JS part)... but for some more complicated views I'd want qwidgets.
embedding-shape 6mo ago
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 6mo 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. For more details, check out: https://sycamore.dev/book/introduction/adding-state https://sycamore.dev/book/introduction/adding-state
  - bickfordb 6mo ago
    The Dioxus library seems really similar to me. How is Sycamores model different?
    - lukechu10 6mo 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.
jtrueb 6mo ago
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 6mo ago
  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 6mo ago
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 6mo ago
  Unless maybe it's headless, then I still expect a component library or something. Still, I see nothing.
  - lukechu10 6mo ago
    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 6mo ago
  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 6mo ago
    The first sentence of this page says it: > Sycamore is a next gen Rust *web* UI library powered by fine-grained reactivity.
    - lukechu10 6mo ago
      That’s because I’ve changed it since posting this!
    - FrustratedMonky 6mo ago
      How does that mean that shouldn't have a demo available?
dewey 6mo ago
In the footer: "This website is also built with Sycamore. Check out the source!" https://github.com/sycamore-rs/website https://github.com/sycamore-rs/website
arpadav 6mo ago
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.html https://krausest.github.io/js-framework-benchmark/current.ht...
cma256 6mo ago
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 6mo ago
  If you're not targetting mobile, why diverge from XHTML at all?
  - cma256 6mo ago
    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 6mo ago
      But what's the benefit of using e.g. <row><cell> over <tr><td> if your only target is the web?
      - cma256 6mo ago
        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".
gwbas1c 6mo ago
> 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 6mo ago
  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 6mo ago
    Once upon a time there was iced_web https://github.com/iced-rs/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 6mo ago
      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...
      - airstrike 6mo ago
        The Elm Pattern is the best part about iced. That verbosity just makes inherent UI complexity visible.
0x3f 6mo ago
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 6mo ago
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 https://github.com/yewstack/yew 2. https://github.com/sycamore-rs/sycamore https://github.com/sycamore-rs/sycamore
- basro 6mo ago
  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 6mo ago
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 6mo ago
  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 6mo ago
Not a single example of an actual application is not a good look for a web ui library
- lukechu10 6mo ago
  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 6mo ago
    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.
    - lukechu10 6mo ago
      Yeah that makes sense. I’ll work on improving the front page
pstomi 6mo ago
I looked at your doc book (https://sycamore.dev/book/guide 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 6mo ago
  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 6mo ago
    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 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 6mo ago
      No I think that's a different product. What I had in mind is what is on, for example, https://tailwindcss.com/ 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 6mo ago
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 6mo ago
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 6mo ago
  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 6mo ago
    > 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).

95 points by lukechu10 6mo ago

conceptme 6mo ago

a UI library needs some demo

lukechu10 6mo ago
The website itself is made with Sycamore! There are also a bunch of examples at https://github.com/sycamore-rs/sycamore/tree/main/examples 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/ https://examples.sycamore.dev/todomvc/
- silon42 6mo ago
  I get: Uncaught (in promise) ReferenceError: WebAssembly is not defined
  - lukechu10 6mo ago
    Umm which browser are you using? Did you disable webassembly somehow?
- catapart 6mo 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 6mo ago
    Hmm thanks for the feedback. The front page definitely has lots of room for improvement.
    - fnikacevic 6mo ago
      A great example is the shadcn site https://ui.shadcn.com/ https://ui.shadcn.com/ Shows you how good it looks out of the box on the first page.
      - 0x457 6mo ago
        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 6mo ago
  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 6mo ago
    That's true... but there's also plenty of other examples with more reactive elements.
- luckydata 6mo ago
  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 6mo ago
    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 6mo 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 6mo ago
For simple stuff, qml is OK/better (except the JS part)... but for some more complicated views I'd want qwidgets.

embedding-shape 6mo ago

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 6mo 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. For more details, check out: https://sycamore.dev/book/introduction/adding-state https://sycamore.dev/book/introduction/adding-state
- bickfordb 6mo ago
  The Dioxus library seems really similar to me. How is Sycamores model different?
  - lukechu10 6mo 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.

jtrueb 6mo ago

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 6mo ago
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 6mo ago

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 6mo ago
Unless maybe it's headless, then I still expect a component library or something. Still, I see nothing.
- lukechu10 6mo ago
  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 6mo ago
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 6mo ago
  The first sentence of this page says it: > Sycamore is a next gen Rust *web* UI library powered by fine-grained reactivity.
  - lukechu10 6mo ago
    That’s because I’ve changed it since posting this!
  - FrustratedMonky 6mo ago
    How does that mean that shouldn't have a demo available?

dewey 6mo ago

In the footer: "This website is also built with Sycamore. Check out the source!" https://github.com/sycamore-rs/website https://github.com/sycamore-rs/website

arpadav 6mo ago

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.html https://krausest.github.io/js-framework-benchmark/current.ht...

cma256 6mo ago

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 6mo ago
If you're not targetting mobile, why diverge from XHTML at all?
- cma256 6mo ago
  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 6mo ago
    But what's the benefit of using e.g. <row><cell> over <tr><td> if your only target is the web?
    - cma256 6mo ago
      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".

gwbas1c 6mo ago

> 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 6mo ago
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 6mo ago
  Once upon a time there was iced_web https://github.com/iced-rs/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 6mo ago
    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...
    - airstrike 6mo ago
      The Elm Pattern is the best part about iced. That verbosity just makes inherent UI complexity visible.

0x3f 6mo ago

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 6mo ago

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 https://github.com/yewstack/yew 2. https://github.com/sycamore-rs/sycamore https://github.com/sycamore-rs/sycamore

basro 6mo ago
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 6mo ago

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 6mo ago
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 6mo ago

Not a single example of an actual application is not a good look for a web ui library

lukechu10 6mo ago
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 6mo ago
  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.
  - lukechu10 6mo ago
    Yeah that makes sense. I’ll work on improving the front page

pstomi 6mo ago

I looked at your doc book (https://sycamore.dev/book/guide 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 6mo ago
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 6mo ago
  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 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 6mo ago
    No I think that's a different product. What I had in mind is what is on, for example, https://tailwindcss.com/ 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 6mo ago

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 6mo ago

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 6mo ago
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 6mo ago
  > 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).