We use Websockets for state interactions, so the latency may depend on your internet connection + distance to server. We will improve this in the future by leveraging more edge computing and WebAssembly to execute closer to / on the client.
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.
Also, I turned off WiFi and then clicked the counter a couple times. Obviously the clicks didn't render. When I turned it on, then the counter updated one at a time at what felt like 300ms intervals. I often use the web from the train as I commute and data service can be spotty. I expect I'd see input latency in the minutes if I tried.
I think this is only viable if you're certain all your users have ping <100ms, and are on stable connections.
If you have to use this model, try batching user events (10 clicks => increment by 10) and cancelling old events (slider events at 5, 10, 20; only send slider=20 event).