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