Well obviously there's a difference between latency and throughput. Of course it's going to be microsecond plus your rtt/2. Sorry, we can't beat physics.
In a way, you can with optimistic updates. That requires having a full front end stack, though, and probably making the app local-first if you really wanted to hammer that nail.
There's always the cost of the round trip to verify, which means planning a solid roll-back user experience, but it can be done.
Latency doesn't affect server update rate it affects time to first data. I can have a ping of 500ms and still get an update from a stock ticker every 5 milliseconds. They will arrive at 500 505 510 etc.
I'll take your word for it, as I can't find the quote in context.
But I'm unfamiliar with any polling pattern where poll requests are expected to overlap. If updates take microseconds, does that mean I can comfortably run 10,000 of these in a second?
I even think datastar looks cool, but I just think that quote is misleading, and I still think that.
I'd like to see some realistic results, like the kind measured by this[1] type of benchmark. "Microsecond" updates sounds like microbenchmarks with very carefully crafted definitions.
