4 ms·

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.

throwaway519 1y ago
Can't beat physics but can write better copy.
- andersmurphy 1y ago
  Latency doesn't affect server update rate it affects time to first data.
recursive 1y ago
Everyone knows no one can beat physics. That doesn't excuse claiming you can beat physics.
- andersmurphy 1y ago
  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.
  - recursive 1y ago
    I think most people would have a different understanding of what's entailed in an "update".
    - andersmurphy 1y ago
      The original bit from the datastar website that was quoted was talking about polling.
      - recursive 1y ago
        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. [1]: https://krausest.github.io/js-framework-benchmark/2025/table_chrome_135.0.7049.42.html https://krausest.github.io/js-framework-benchmark/2025/table...
zdragnar 1y ago
> 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.

throwaway519 1y ago

Can't beat physics but can write better copy.

andersmurphy 1y ago
Latency doesn't affect server update rate it affects time to first data.

recursive 1y ago

Everyone knows no one can beat physics. That doesn't excuse claiming you can beat physics.

andersmurphy 1y ago
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.
- recursive 1y ago
  I think most people would have a different understanding of what's entailed in an "update".
  - andersmurphy 1y ago
    The original bit from the datastar website that was quoted was talking about polling.
    - recursive 1y ago
      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. [1]: https://krausest.github.io/js-framework-benchmark/2025/table_chrome_135.0.7049.42.html https://krausest.github.io/js-framework-benchmark/2025/table...

zdragnar 1y ago

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