If I understand this correctly, the `BroadcastChannel` API solves a similar purpose.

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

The subscribe() implementation seems suboptimal in the case where there are many different topics:

    subscribe(topic, callback) {
        if (this.listeners[topic] == undefined) {
            // Not yet any listener for this topic
            this.listeners[topic] = [];

            window.addEventListener('storage', (e) => {
                const dataKey = topic + "_data";
                if (e.key === dataKey) {
                    const data =  JSON.parse(e.newValue)[0];
                    this.listeners[topic].forEach((v, k) => {
                        v(data);
                    });
                }
            }, false);
        }
        this.listeners[topic].push(callback)
    }

    window.addEventListener('storage', (e) => {
        if (e.key.endsWith('_data')) {
            const topic = e.key.substring(0, e.key.length - 5);
            const data = JSON.parse(e.newValue)[0];
            this.listeners[topic]?.forEach(v => v(data));
       }
    }, false);

I built a ComfyUi node that let you run a little paint program in another tab. (Sorry about the lack of updates if you use it. I intend to get back to it)

Negotiating the communication between tabs was by far the hardest part. In the end I ended up using local storage for signaling to establish a dedicated messsageport channel.

It was such a fight to make something that re-established the connection when either page reloaded.

There are still some connection issues that I haven't been able to resolve. It seems some browsers on some systems reject messages between tabs if they were loaded hours apart.

It might be worth benchmarking a pure local storage fallback, but I'm guessing it would suffer with high traffic.

A generalised implementation that allowed switching multiple paint programs and multiple ComfyUi pages would be ideal. A PubSub might be the way to go.

There's also the issue of other parts of the app also using local storage. Need to not step on toes.

It's nice that the 'storage' event also gives you event.newValue to spare you the race condition of reading from localStorage.

The audio demo makes me think of Bandcamp which will pause music that you're playing if another Bandcamp tab starts playing a song separately. Must be a similar mechanism under the hood

Related recently discussed:

Show HN: JavaScript PubSub in 163 Bytes (31.03.2025)

https://news.ycombinator.com/item?id=43529774

Isn't this a security hole waiting to be exploited?

How does the browser handle access control to the local storage, especially offline when they aren't loaded from the same site?

[Yes, I really don't know. Yes, I'm asking. Not everyone is a web dev.]

Very cool, I love seeing pubsubs in the wild. We built an ssh based pubsub that we have been using in production for awhile now: https://pipe.pico.sh/

I love it, the code is so simple: https://github.com/simonfrey/tabsub/blob/master/tabsub.v1.js

I wonder how one does this on nodejs across instances gracefully.

I remember implementing the same thing in our framework like a decade ago, but eventually taking it out. We wanted to use it for caching data between tabs, so as not to hit the server again per tab:

https://github.com/Qbix/Platform/blob/main/platform/plugins/...

It had the concept of a “main frame” that they would route all requests to the server through.

I remember now — I did it not so much for tabs as for our solution of having tons of little iframes on a page: https://qbix.com/ecosystem