Why don't you just transpile the frontend Python code to JS at build time and just have normal HMTL/JS/CSS in the final deployed web app with a Python backend?
You've mentioned no-code tools. For a client, I had to work with the no-code tool Bubble a lot. They do something similar, where the front-end is not built statically but dynamically and uses WebSockets to communicate with the back-end. I don't think this is a good idea (and that's why Bubble is also trying to switch to static pages now, but you can imagine what it takes to do that once you reach a certain size).
In fact the Pynecone frontend is built statically. But UI event handlers are run on the backend. The latency scenario is identical to if you used HTMX or Hotwire or a traditional web server. You click, it gets posted to the backend, an output comes back and is rendered.
The click counter thing is contrived and maybe Pynecone should have avoided centering on that, since the users they're targeting for sure don't care about frontend-only click counters.
Is it possible to take the optimistic approach and update the UI before getting response from the back end? Obviously for simple things, like counters, that need an immediate update to the UI.
You could designate some handlers to be “frontend-only” and then compile them to wasm or js and run them in the browser. There might be usability/ergonomics issues with having “special” functions that don’t really work like normal ones.
You've mentioned no-code tools. For a client, I had to work with the no-code tool Bubble a lot. They do something similar, where the front-end is not built statically but dynamically and uses WebSockets to communicate with the back-end. I don't think this is a good idea (and that's why Bubble is also trying to switch to static pages now, but you can imagine what it takes to do that once you reach a certain size).