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.
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).
Gasp0de|3 years ago
picklelo|3 years ago
8organicbits|3 years ago
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).
unknown|3 years ago
[deleted]