Reminds me of the joke "hey, check out the website I just made: localhost:8080"

You can have microsecond updated, once the connection is established you can stream. Regardless of your latency.

Say your ping is 100 (units are irrelevant here). It will take you 100 before you see your first byte but if the server is sending updates down that connection you will have data at whatever rate the server can send data. Say the server sends every 10.

Then you will have updates on the client at 100 110 120 130 etc.

That's still 100 irrelevant units later than the server sent the update. This is like saying the first byte of the packet takes 100ms to arrive but the subsequent bytes in the packet are instant!

It's not quite right. You'll never have updates in microseconds even if your ping is, say, 7ms.

At best you can be ~2-4x as fast as long polling on HTTP/1 -- an order of magnitude is a ridiculous statement.

You're right! 200-400% faster is so useless.

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.

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

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

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 think most people would have a different understanding of what's entailed in an "update".

The original bit from the datastar website that was quoted was talking about polling.

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

Can't beat physics but can write better copy.

Latency doesn't affect server update rate it affects time to first data.