lukechu10

Hmm that's pretty cool. Thanks for sharing!

What does it mean to have a distributed quantum computer? Because if these distributed quantum computers are connected by classical communication channels (e.g. the internet), then it has been proven that this cannot provide any quantum speedup over just a single quantum computer.

See Jozsa & Linden 2003: https://arxiv.org/abs/quant-ph/0201143

So to actually get a quantum speedup, these quantum computers will need to be connected with quantum channels, which are possible IRC with fiber optic links (eg. by using the quantum state of the photons). But that is not the case.

Well what makes you think the VPN providers are not tracking?

You would have to either self-host your own VPN server somewhere (maybe on a public cloud provider) or if you are truly paranoid, use something like Tor.

Good feedback. I'll make a demo page showcasing all the examples and link to it from the home page.

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...

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.

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.

There are a lot of demos! Check out the examples/ folder on GitHub.

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.

Yeah that makes sense. I’ll work on improving the front page

That’s because I’ve changed it since posting this!

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

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.

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...

That's true... but there's also plenty of other examples with more reactive elements.

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.

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!

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.

Hmm thanks for the feedback. The front page definitely has lots of room for improvement.

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.

Umm which browser are you using? Did you disable webassembly somehow?

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

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/

Thanks!

I made this a while ago but never shared it before. Figured some of you might find this interesting. Based on a presentation that I gave a while ago and then re-adapted into the current format.

Full source code for the simulations and animations is available here: https://github.com/lukechu10/interplanetary-transport-networ...

Simulations were written in Rust and animations were created in Python using the great Manim library!

Hi, author of Sycamore here. What kind of ergonomic improvements are you thinking about? If this is something actionable, it would be great if you could open a new issue on our repo.

After discovering solid js, I wondered how feasible it would be to write such a framework in Rust. After two days of hacking around, here is the result!

It allows fine-grained reactivity to the DOM with no virtual DOM layer whatsoever! The reactivity system is based on signals and subscribes/dependents. For ergonomics, dependencies on signals are automatically detected. Here is an example:

let (state, set_state) = create_signal(0);

create_effect(move || {

    println!("The state changed. New value: {}", state());

}); // prints "The state changed. New value: 0" (note that the effect is always executed at least 1 regardless of state changes)

set_state(1); // prints "The state changed. New value: 1"

set_state(2); // prints "The state changed. New value: 2"

set_state(3); // prints "The state changed. New value: 3"

Creating DOM nodes is accomplished with the template! proc-macro. When a signal is used inside the template! macro, create_effect is implicitly called and the is DOM updated whenever the value changes.

If you look at some of the examples in the README, you will find that the API is quite similar to that of React hooks. Unlike React hooks, however, the actual function is only executed once and it is the effects that are executed multiple times. This means that the template! macro can generate real DOM nodes and it is the code inside create_effect that is executed multiple times to update the DOM.

Disclaimer:

The library is currently very WIP and very feature incomplete. For instance, it is not possible to get references to DOM nodes without manually creating them outside of the template! macro.

If you are willing to help out, please head over to the GitHub repository. Feedback, issues and PRs are greatly appreciated!