Well, it's in a browser. Between trivial mouse move and trivial object coordinate change, there are numerous system and application layers to relay event to your interpreted (or compiled) code, and then to deliver state change to screen.

Even if we move to native world, making two different windows do the same instantly is not always trivial. For example, there have been articles about GUI toolkits making it impossible to have smooth window resizing. If we make everything ourselves (say, immediate drawing in response to WM_PAINT), we can only hope that the system notifies windows quickly, and that performance available is enough to pump bitmaps to screen. Or, better, we can try to use system-wide software or hardware compositor, add layers for individual objects, and only change their coordinates. Then we rely on compositor being good enough to handle 60/120/144/whatever updates per second when it's needed.

Querying window position is laggy unfortunately. It's a browser feature.

I wonder if it would be more instant if they used postMessage api instead of going over network.

Any local network usage should be nearly instantaneous.

My personal theory about the lag is that positioning the window is not synchronized to the JS thread, so the window moves before the JS thread is aware, which means you see the square move after the window has already moved.

Ah, my bad. I didn't read the code and just assumed there was a far away server.

I assume you mean BroadcastChannel?

https://developer.mozilla.org/en-US/docs/Web/API/BroadcastCh...

Going over local network is more or less instant

Background windows/tabs getting a lower priority maybe a factor.

Probably because of websocket network lag and also, in my anecdotal experience, window position updates are sometimes strangely jittery

Why is it over a websocket? Can't it just share local data?

It says so right in the OP

> The original work by Bjorn Staal used localStorage, but I found sockets more fun, because if tweaked a bit, this can be shared with friends.

I might be wrong, but I think the point is to simulate a server-client architecture (to show that it works even for an actual web app).

those were my thoughts too

You can use Broadcast Channels as well as Service Workers, even WebRTC would use a loopback interface!

This ought to work across different browsers though, for what it's worth. But ultimately it's just a fun experiment.