Svelte’s Growing Pains: Runes, Stores, and the Quest for Standards

I’ve had this thought in my mind for a while. I don’t want to sound pretentious or anything, but I feel like the Svelte development experience was ruined for me when runes were introduced.
I know that stores are still around, and I can use them without issue. However, more and more, the ecosystem seems to be moving away from them.

Why I loved stores?

There are great articles about observables and stores in Svelte. Here’s why I think they’re so valuable:
Stores are an excellent way to structure a site and ensure that everything works consistently.
I worked for more than a year on a very large Svelte project. The main problem I saw was the misuse of stores. Why? Because the mental shift wasn’t happening — developers were still thinking in terms of values, not observables.
But we’re building a UI, and when we work with stores, we need to think of everything as an observable — from user actions to API calls.

It’s actually quite easy once you get used to it: identify where you need the value, and otherwise avoid touching it. Using stores inside components can feel tricky at first, but once you apply the pattern consistently, it becomes very clear.
It’s similar to using RxJS in NestJS — in the end, you can just return an observable in the controller, so the whole flow can stay observable.
Of course, observables can sometimes be painful to manage. But even in those cases, we can isolate the complexity with a specific solution, while keeping the standard approach for the rest of the system. This makes the code easier to deal with in the future.
One of my key rules for observables is: never manually subscribe unless you really know what you’re doing and you’re sure you’ll clean it up. And even then, it’s worth asking if there’s another way to avoid subscribing directly.
I also started using stores as component state. I created a kind of controller that exposes a store and is only managed in the view. This made things feel consistent — both inside components and globally we ended up using the same tool.
And one of the biggest wins was that in Svelte, RxJS worked without an extra library. Observables were first-class citizens thanks to stores. When you’re already thinking in terms of observables, RxJS is fantastic because it gives you everything you need.

Runes, the problem of 0 standard

When runes were introduced, every standard in Svelte was disrupted. To be fair, this isn’t exactly a Svelte problem. It’s the natural result of needing backward compatibility during such a big shift.
We’ve seen something similar with Angular, where signals and observables coexist. The difference is that Angular isn’t trying to replace one with the other, while Svelte is positioning runes as the new standard.
There’s nothing inherently wrong with that. But it creates challenges:
Libraries, community practices, and mental models all need to shift.
Even if no library has to be rewritten, developers outside the Svelte community who want their libraries to work with the latest version will likely target runes.
Companies often push to stay on the latest versions. Sometimes because of contracts, security policies, or just a manager googling and deciding based on what they find first.
All of this makes it hard to maintain standardized code in an ecosystem that itself doesn’t feel standardized right now.
At some point, everyone will want to upgrade to the latest Svelte version, from runes to attachments, to new slot patterns. But that will require codebase changes, even for open source projects.
I loved observables in Svelte, and I still want to use the framework because it feels natural and simple. But moving into this new era will take time, and until then we’ll be surfing waves of “no standard” in our codebases.

I know the Svelte team is doing a great job navigating these changes and trying to keep a clear direction for the framework.

What’s next

I want to keep coding in Svelte, so I’ll try to help the community by creating two libraries that can bring back some standardization to projects especially around observables and services.

Here are the projects I’m working on:

• Apollo Graphql - Finally the right abstraction for Svelte
• RxJS for Svelte 5 (In progress)

Comments

[Spike McLarty]

I could not understand many of the sentences here, the number of grammar problems is extraordinarily high. Please, to the author: submit this to an LLM for review and editing or write in your native language then Google Translate, then translate the English back to double-check. Your efforts deserve a good representation.