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)
    }

This installs a handler for every single topic, and every time a message is published, the handlers for all topics are called, even though at most one is interested in the change. A more efficient implementation would install a single handler, e.g. (untested):

    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.

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

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