Why Svelte Needs to Keep Stores Despite Runes

[hanielu]

In Overwolf apps (gaming overlays/tools), we often need multiple windows:

• A background process window
• An in-game overlay window
• A desktop configuration window

Each window is a separate JavaScript context, which creates a fundamental challenge for reactivity systems.

Why Fine-Grained Reactivity Falls Short Here

While runes provide elegant fine-grained reactivity within a single window, they can't naturally span multiple JavaScript contexts:

// This won't work across windows
const state = $state({ value: 0 });
export const count = getOrCreateStoreAttachedToMainWindow("count", state);

<!-- in-game-window.svelte -->
<!-- here, the count value does get updated, but svelte doesn't automatically track the value change -->
<button onclick={() => count.value++}>Increment: {count.value}</button>

<!-- desktop-window.svelte -->
<!-- same here -->
<button onclick={() => count.value++}>Increment: {count.value}</button>

The fine-grained reactivity that makes runes so elegant works beautifully within a window, but stops at window boundaries.

Why Stores Are Essential

The subscription model that underpins Svelte stores solves this exact problem:

// This works across windows
export const count = getOrCreateStoreAttachedToMainWindow("count", writable(0));

<!-- in-game-window.svelte -->
<!-- here, the count value does get updated,
but since it's a subscription, it's automatically
updated when the store value changes -->
<button onclick={() => $count++}>Increment: {$count}</button>

<!-- desktop-window.svelte -->
<!-- same here -->
<button onclick={() => $count++}>Increment: {$count}</button>

Stores work across windows because:

1. Explicit subscription contract: The .subscribe() method creates a clear API contract
2. Centralized state: The store can live in one window and be accessed from others
3. Manual pub/sub: Changes propagate via explicit mechanisms that cross window boundaries
4. Auto-subscription syntax: The $ prefix makes working with stores almost as convenient as using local state

The Future-Proof Solution

While runes provide an elegant solution for most use cases, subscription-based stores solve problems that fine-grained reactivity fundamentally cannot. Ideally, Svelte would:

1. Keep stores as first-class citizens
2. Maintain the auto-subscription syntax

The Alternative Is Painful

Without stores, developers in cross-window scenarios would need to:

1. Implement custom pub/sub systems
2. Manually track subscribers
3. Handle cleanup
4. Create custom hooks or helpers
5. Lose the elegance of the $ syntax

There's also the option of using shared local storage with storage events for sync but that's a less elegant solution that just using stores

[webJose]

I have also another scenario: Micro-frontends. Since currently the Svelte runtime cannot be easily dedupped across projects, stores remain the champions as they react across MFE's.

I also think that stores should not be deprecated and should continue to be a core feature of Svelte.

[7nik]

But there are no talks about even deprecating them. Stores just became a niche solution.

[hanielu]

No talks yet, but I saw sveltejs/kit#13305 (comment) and decided to start this discussion, just in-case it's something the svelte team ever considers in the future :)

[rmunn]

The question you linked, @hanielu, was about $ reactivity, and I suspect that @brunnerh thought that the questioner meant $: reactivity. (Though I'll let him speak for himself, of course). It has already been announced that $: will go away eventually, as the $derived and $effect runes are meant to replace it. But to the best if my knowledge, nobody from the Svelte team has announced any plans to remove, or even deprecate, stores.

[hanielu]

Ah I see that makes more sense, thanks for the clarification :D

[brunnerh]

I updated my comment in case there was a misunderstanding.

To my knowledge there are no plans for the removal of stores yet, they also serve some interop purpose towards Observables.
Maybe this will change once signals are standardized, given that there are ways to convert between the reactivity formats.

[Antonio-Bennett]

Creating a class with state wouldn't work? Or having a closure over the state? Not sure what that long function is doing internally so maybe I'm misunderstanding

[hanielu]

Having a closure over the state doesn't change anything, it still doesn't work, the fundamental issue is that whatever system svelte uses for tracking signal state doesn't make it across the window boundaries, just the proxy.

So when the state in the proxy changes, svelte can't react to it.

function getOrCreateStoreAttachedToMainWindow(key, state) {
  const mainWindow = overwolf.windows.getMainWindow()
  const store = mainWindow[key] ?? state
  
  // If we're in the main window, assign the store to window for sharing
  if (window) window[key] = mainWindow[key] ?? store
  
  return store
}