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.

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.

Basically its a service that automatically crawls your docs and creates a search index and widget that you can include on your website.

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.

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.

I'm also looking for new contributors and maintainers!