For me I found it to be the opposite, almost no latency with spam clicking on the iPhone. This framework is ultra fast. Check it out here https://voicer.com/v/z991V

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.

Why is the frontend state stored on the backend?

The state is updated through Python functions that are run on the server, so the state needs to be on the server

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

> front-end is not built statically

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.

Edge computing isn't a universal fix. At the moment I'm on a corp network that routes traffic through a proxy a couple states away (security reasons), I rarely see <200ms latency and occasionally see >500ms latency. The counter and slider example don't feel right at that latency.

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

I also had an irritating amount of delay on that button. Also using Android (GrapheneOS) with the Vanadium browser (Chromium-based).

Same here, but I think it's because that's not really a good use case. If you are going to use it to actually run some computations in the backend (that have to be in the backend, say, GPU-powered ML stuff maybe? Or anything else that you can run easily in Python but not in JS) then it sounds like a good alternative.