DEV Community: DaniAcu

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

DaniAcu — Tue, 16 Sep 2025 20:15:30 +0000

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)

Using Apollo in Svelte 5

DaniAcu — Tue, 16 Sep 2025 20:13:42 +0000

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

I worked as an engineeer manager in a large e-commerce company in Saudi Arabia. Our frontend architecture was built on Svelte microfrontends, with separate apps handling user management, checkout, marketing, and search exploration.

Our backend was fully powered by GraphQL, and in the beginning, we adopted Houdini as our GraphQL client. Houdini is a great library, but in practice we found that the generated code often felt unclear and rigid, especially for component-driven queries instead of page-driven queries.

This became most noticeable when building smart components—UI elements that need to handle their own API calls, such as:

A header showing user login state
A shopping cart widget with live updates
Shared navigation or marketing components that are reused across apps but still need to be intelligent and data-driven

In these cases, we needed something flexible and reactive, with a clear mental model and strong tooling support.

Why Apollo?

Given the scale of our system, we leaned towards Apollo Client, because it provides:

Robust cache normalization out of the box
Excellent developer tools for debugging and inspecting queries
Rich ecosystem support (links, error handling, pagination strategies, etc.)

Since other parts of our company were already using Apollo in React and Angular projects, aligning on Apollo also reduced the cognitive overhead for new team members.

The Challenge in Svelte 5

At the time of migrating from Svelte 4 → Svelte 5, the only official option for Apollo in Svelte was svelte-apollo. Unfortunately, it had not been updated in several years and was missing modern Svelte 5 features like runes and fine-grained reactivity.

What I wanted was:

The full power of Apollo Client
First-class Svelte 5 integration (no extra boilerplate, reactive by default)
An experience as smooth as React

The Solution

That’s why I built this library—to bring Apollo’s ecosystem and developer experience into the Svelte 5 world.

It provides, reactive queries and mutations that fit naturally with Svelte 5 runes

With this library, you can enjoy Apollo’s power + Svelte’s simplicity without compromises.

Apollo Runes
If you found this useful, consider giving it a ⭐ on GitHub. Thanks!

Answer Dev Questions #1: Demystifying Special Characters in Paths

DaniAcu — Fri, 26 May 2023 01:23:21 +0000

Recently, while engaging in a online discussion, a question caught my attention.

Sometimes i see symbols like “@“ or “*” or “” or “^” or “~”
And I don't know what are they used in ..?!

I wait some time, but I saw that anyone answer the question, I just saw one intention to doit that was a link of a blog post that not track the entire question. So I take the time to answer it, and after doing it I just ask to myself: Why do not create post of this answer?

So here I am, maybe for expert it sounds easy-peasy or like a piece of cake but for the most beginers that try to find some guide in the masive world of things it could be helpful.

All this symbols in the question are for different things.

@

Let start with the at symbol (@). As the question was asked about a js file, so I could say that in JS projects is used to have a convenient way to access to root folder of your app.
Instead of doing ../../../../../../../../../, accesing from the root could be shorted but the most important benefit is that alias is the same for every file. So moving file dont need update imports.
For more information check the rollup alias plugin

*, **, ^

The asterisks (* or **), carret(^), is more a OS thing or to be specific is part of glob (https://en.wikipedia.org/wiki/Glob_(programming)).
In general it means the following:

* (any file)
** (any folder)
^ (exclude this, but I think that you need some extension of glob or something like that. check this discussion about it)

~

The tilde symbol (~) is for user directory. In linux you could go to your user directory using "cd ~" any time. Some any path written with than means that is searching the path starting form user directory, it an alias already provided by the OS. Check this link

I hope this explanation was helpful to you, because I really enjoy wrinting this answer.

See you in the next one.

Here my links.
Twitter
Github

Observations about Svelte

DaniAcu — Wed, 24 Aug 2022 01:50:00 +0000

In the last couple of months, I worked on an Indoor Map solution where we used Svelte to develop the user interface. It was a surprising decision because I had never worked with this tool, so I dedicated some time to learning about it and starting to set up the environment to work above it.

Intro

For people how are not familiarized with Svelte, this is a new kind of framework in the frontend world. But it's more a language than a framework. There is a lot of confusion on the Internet about what Svelte really is and whatnot. Some people mention that Svelte is a compiler that compiles your code into plain Javascript, which is not entirely true. Because like other frameworks Svelte is adding an internal package to do that everything works correctly.

Svelte is an extension of the Javascript language which helps you to create reactive sites. This means that there is some Svelte code that only works in a Svelte environment, not as a normal Javascript. But all this code is compiled to be able to run in any browser.

How svelte works?

One of the main thing that svelte does is syncing the template with the code. Let see an example:

<!--- Home.svelte --->
<script>
   let name = "Dani";
</script>

<h1>Hello {name}</h1>

As you could see this svelte file has two sections. First, the script where we declare the variables that we want to use and next to an HTML text where we could use curly brackets to map the variables into the template.

But how this magic works? Well, one of the things that Svelte doesn't do is use a VDOM algorithm. They don't have a representation of the DOM, they just process the updates directly to the DOM, which in most cases, improves the performance.

<!--- Home.svelte --->
<script>
    let name = 'Dani';

    function onChange (e) {
        name = e.target.value
    }
</script>

<h1>Hello {name}</h1>

<input type="text" on:change={onChange} />

Let see what Svelte is doing in this simple case:

When the h1 renders, they detect the name variable as a dependency, so h1 will subscribe to all updates that the name will have.
When onChange modify the value, the compiler adds an update method below your assignment

// pseudo code
function onChange (e) {
    name = e.target.value
    $$update("name")
}

This method will get all the subscribers to the variable name and run the updates.

Pay attention to the word that I used before, assignment. This is important especially when you work with complex data types like arrays, objects, or others.

function updateComplexValue () {
    arr.push(2);
}

The previous code will not trigger any render update, because the compiler doesn't see any assignment. So, it's so simple as adding what the compiler is expected to trigger the render.

function updateComplexValue () {
    arr.push(2);

    // This doesn't do anything. Just tell the compiler that we need a new render
    arr = arr; 
}

So in terms of logic, this doesn't change anything. But now the compiler identify an assignment and they could add the update method below that.

// pseudo code
function updateComplexValue () {
    arr.push(2);
    arr = arr; 
    $$update("arr");
}

How does reactivity work?

The reason why I think that svelte is more than a simple framework is for this reason. Svelte add reactive declaration which allows you to create a new type of variable, a computed variable (as Vue called 😉). Variables or blocks will be updated every time based on their dependencies.

For example:

let firstName = "Daniel"
let lastName = "Acuña"

let name = `${firstName} ${lastName}`;

The name will always be "Daniel Acuña" because there is no mechanism that said that each time that firstName or lastName change we need to regenerate the variable. But but but, Svelte extends the language to do it possible.

let firstName = "Daniel"
let lastName = "Acuña"

$: name = `${firstName} ${lastName}`;

Now you will have name variable, which is reactive and is dependent on firstName and lastName, each time when these updates name will be calculated again.

Also, you could use it as a block that runs in every update.

let firstName = "Daniel"
let lastName = "Acuña"

$: {
    console.log(`${firstName} ${lastName}`)
}

How empower reactivity?

Reactive programming is not just about magic things going on. It's about events, subscriptions, and streams. Svelte create their own stores that allow you to use streams to share info between components.

// count.store.js
import { writable } from 'svelte/store';

export const count = writable(0);

// Counter.svelte
<script>
import { count } from './count.store';

let value = 0;

count.subscribe(newValue => {
    value = newValue;
})
</script>

<span>Count: {value}</span>

// Increment.svelte
<script>
import { count } from './count.store';

function onClick () {
    count.update(n => n + 1);
}
</script>

<button on:click={onClick}>
    +
</button>

We are just sharing a structure to two different files, and as you could see we are subscribing in a component to be able to read the current value, but we also need to unsubscribe. However, all the subscription management could be annoying if we are using a lot of stores. So svelte, again, create a syntaxis to do it more easily to everyone.Reactive programming is not just about magic things going on. It's about events, subscriptions, and streams. Svelte create their own stores that allow you to use streams to share info between components.

// Counter.svelte
<script>
import { count } from './count.store';
</script>

<span>Count: {$count}</span>

Using the $ symbol, we are let that Svelte managed the subscriptions. So when the component mounts it will be subscribed and when the component unmount it will trigger an unsubscription. We just need to use it in this way to show the value.

The interface that svelte proposes to the subscription is completely common, so you could change it with any library that uses the same contract. The famous stream library RxJS is one of the cases for example.

If you want to empower the reactivity into Svelte, Rxjs is a good choice to take. Because you open the door to new possibilities to manage the streams.

If you are really interested in learning more about how to integrate RxJS with Svelte, I highly recommend this post by Tim Deschryver. https://timdeschryver.dev/blog/unlocking-reactivity-with-svelte-and-rxjs

Some consideration

Svelte is a open source framework but the community doesn't dedicate time to develop useful libraries to work abov it.

For example, if you try to find UI libraries to work with a Desing System you could find some libraries for Material Design with a lot of accesibility issues. Maybe one of the best options is Carbon Desing but all this depend of what do you want kind of app you want to develop. In addition to that, the integration of this libraries needs a extra set some extra configuration in your project to do that everything works.

Some UI libraries recommendation:

Also, svelte has a tech dep for some useful functions and components that they not provide yet. For example, they provide a way to render components dynamically (<svelte:component />) but not a way to use dynamic element (I imagine, something like <svelte:element/>). You could check the current status of this feature in this issue #2324.

Althought, this is a framework in development with a lot of improvements to do. Currently, Rich Harris the creator of svelte is moving to Vercel, so we should wait for new and cool things comming. Check the news

Conclusion

Svelte is so free that you could create whatever kind of code that you could imagine. This comes with pros and cons, but it all depends on your experience working with the reactive site.

If you are building something small like a micro app, svelte could be a good fit to choose. If you would like to learn about reactive programming maybe is a good place to start learning by doing so stuff.

Svelte has a really good future and also is putting in discussion a lot of pre-conceptions that other frameworks have. So I feel that it will help in the next generation of front-end technologies.

Tips and Tricks for Typescript to daily use

DaniAcu — Wed, 08 Sep 2021 20:03:19 +0000

I often see that JS devs struggle to create good types in Typescript. Some people use the famous any and other use unspecific types.

First of all, I'd like to remark that good typing helps you to think less and reduce to time to check the implementation. In Functional Programming, the function definition is so important for the same reason. Your types should be thrust and strictly define which is the structure of your data.

Today, we'll explore some tips about how to use some utils types and some extra cases that will help you on a daily basis.

Pick and Omit

These two utils are part of the utils that comes with Typescript. These are helpful for preventing rewrite interfaces every time that we need something similar. Let's see in action in a real example.

Imagine that we are creating a store to be used in some components.

interface Stores {
  user: User,
  theme: Theme
  // ... some others
}

If we want to define the props of our component that also comes with some of these stores we don't need to replicate it like that:

interface AvatarProps {
  user: User,
  rounded: boolean
  // ... some others
}

Instead, we could use these utils types to prevent repeat these types, and reduce some mistakes like add another type for the user prop.

interface AvatarProps extends Pick<Stores, "user">{
  rounded: boolean
  // ... some others
}

Pick util just create a new type only with the keys that match with the second type that we passed. Imagine this like a function with 2 parameters, the first one is the whole type and the second one is a union with the names that we need to "pick". Remember a union is a conjunction of 2 or more types, in this case, we use a fixed string to match with each key.

interface Foo {
  key1: number,
  key2: number,
  key3: number
}

type FooPicked = Pick<Foo , "key1" | "key2">

/*

This will result in a type like that:

interface FooPicked {
  key1: number,
  key2: number
}

*/

Omit util does the same thing but in inverse order. I mean instead of taking every key that matches with the union it'll "omit" every key that matches with the union.

interface Foo {
  key1: number,
  key2: number,
  key3: number
}

type FooOmited = Omit<Foo , "key1" | "key2">

/*

This will result in a type like that:

interface FooOmited {
  key3: number
}

*/

Partial

We were talking about the store so let continue with that. In this case let think about action, mutation, or anything that will do an update. For example, let use the old setState that React uses in classes as an example.

// state
this.state = {
  foo: "foo",
  bar: "bar"
}

// mutation
this.setState({
  foo: "foo"
})

The method setState needs to receive just a part of the whole state, but we can't use Pick or Omit, because we don't know which will be the key that will be omitted. So, for these cases, we need to send a "partial interface" that will be merged with the whole interface.

// state
interface State {
  foo: string,
  bar: string
}

// mutation
type SetState = (value: Partial<State>) => State;

But what is doing this Partial behind the scene, well it's not so complicated. It's just adding optional to each first-level property.

// state

interface State {
  foo: string,
  bar: string
}

type PartialState = Partial<State>;

/*

This will result in a type like that:

interface PatialState {
  foo?: string,
  bar?: string
}

*/

You could find another case where you need to use it. Just remember that only put optional to first level properties, if you have nested object the child properties will not be impacted by this util.

readonly

If you like to work with immutable data maybe you'll love this keyword. Typescript allows you to determine which properties of your object could modify or not. Continue with the stores, if you will use the Flux architecture you don't want to allow that the state to be modified, you just want to recreate the state in each action.

So for these cases are helpful to put these properties as readonly because it will throw an error if anyone tries to modify it.

interface Stores {
  readonly user: User,
  readonly theme: Theme
  // ... some others
}

Also, you could use the Readonly util

type ReadonlyStores = Readonly<Stores>

When you try to modify any value, you will see an error message.

const store: ReadonlyStores = {
  user: new User(),
  theme: new Theme(),
  // ... some others
}

stores.user = new User()
// Error: Cannot assign to 'user' because it is a read-only property.

IMPORTANT

This check will throw an error in compile-time but not during runtime as const does. It means that if you have a code that typescript is not tracking, it will easily modify your property in runtime. Just prevent skipping typescript rules from your files.

Smart use of infer typing

Typescript has a really powerful inference algorithm. This means that sometimes we don't need to be explicit with the type of a variable because it will directly be typed for you.

let a = "a" // Typescript infer that it will be a "string"
a = 3 // It'll throw an error

// Just need to specify the type if you are not passing a value to the variable
let a: string;
a = "a"

// In another way it will be typed as any
let a; // typescript typed as any (some config will prevent this automatic any type)
a = "a"
a = 3 // it will NOT throw an error

We could use this superpower for our benefit. Continue with our store, instead of creating the interface like that...

interface Stores {
  user: User,
  theme: Theme
  // ... some others
}

const stores: Stores = {
  user: new User(),
  theme: new Theme()
}

... we could give the responsability to typescript to create it automatically.

const stores = {
  user: new User(),
  theme: new Theme()
}

type Stores = typeof stores;

The common typeof keyword takes a new power in typescript. It will return the type that typescript infers of the declaration of the variable. So both codes are doing the same thing.

I love this feature because in these cases the type is completely dependent on the declaration. If you add a new field you just need to add it in the declaration and it will propagate to type immediately. Instead in the manual interface creation, you need to propagate this by your self which could come with some mistakes.

Conclusion

Typescript is fabulous, but as you could see with the difference between readonly and const, typescript just creates a layer for the developer to make the code more secure for all. But the JS code that is generated will not follow the rules. So it could modify the readonly property or have access to private attributes because it just a layer while you are coding.

Also if you are using classes to privatize some methods or attributes, it will be just "private" before compilation. If you really want to use a private value you could use a closure factory, also this could reduce just a little bit the bundle size of your compiled code because there now any necesity to compile anything like when you are using a class. If you are looking for a example of that let check this rewrite that Mark Erikson did in the Subscription of react-redux.

Remember this when you are working with typescript it will help you understand what is happening behind the scenes.

Thank you for reading this post. I hope this helps you in your daily work.

If you would like to learn more, I highly recommend the Typescript documentation for utils.

https://www.typescriptlang.org/docs/handbook/utility-types.html

My Road to Isomorphic Apps

DaniAcu — Tue, 07 Jan 2020 23:03:50 +0000

The web app world changed a lot in the last years

When I started coding, we were creating the pages in a static way. Maybe you remember that. We created a little app with our HTML, CSS and (if you were little crazy) Javascript.

Static Pages

At that moment we only created pages with a simple structure and only reused little things. The scalability of these projects was very heavy. All file work alone, for sample on a simple landing page to one company, we had one HTML by page. At that time, the developers started loving jQuery. Many developers knew jQuery but he didn't know Javascript, that was crazy times.

For sample, if you went to /about .html, you received an about page. This page has its own style and JavaScript code. Something similar to that.

Server Pages (PHP)

In my experience, I used PHP and his frameworks before to use a Javascript framework. To reuse many parts of one page, we have includes functions on our server. This a sample on PHP but it's the same or similar to other languages and templates, like Java using something like JSP.

We came to the PHP frameworks like Laravel, Symfony and others. This way to reused page takes a superpower. On these frameworks, we could create layouts and extends that to only add the content that we need to use it.

Single Page Application (SPA)

With BackboneJS comes the idea to SPA, an HTML creates dynamic pages by JavaScript. But the most relevant framework that all developers remember that it starts with the SPA is AngularJS.
On Angular, you create a simple mapper from route to template, and this template uses a controller with the JavaScript logic.
The concept of SPA is to create a friendly experience to the user with a flow very similar to a desktop application.
This type of apps creates a lot of work on the UI side and creates a boom to JavaScript. So many developers started to learn JavaScript with AngularJS. And now we have pages created just with javascript.

Some issues on SPA

The best thing on this type of app is the experience because you don't need to request the page to the server and you could create an animation between a route to route because it is the same HTML page. But not all is great...

Not a friendly integration with SEO
Friendly SEO is very hard, because when you or a bot try to get the code. You received something like that...

Currently, SEO understands those pages but I think that it's not common behavior. If you request a page you wait to that page return structured information about what is it. Which brings me to the next point...
It's not normal behavior to the browser
If you, sometimes, had set up manually an SPA you discovered the 404 issues on AngularJS. If you want to remove the '#' of the URL to simulate the real URL, you need a node server that on all cases send the main HTML file.
All browsers expect that when the user uses a URL, that loads content. So if browsers received falsy empty content, it's so weird.
Memory leaks
Having the same page loaded for a long time can cause considerable problems with your computer memory (browser crash, issues with the power battery, etc)
Tricky browser loading indicators
If the browser indicator says that the page completes the load, you would be sure that the page is ready. But is not the case to SPA pages.

Server-Side Rendering (SSR)

With Node appears the possibility to run JavaScript from the server.

So, we could use it to create better web apps. But.. could we run our beautiful UI frameworks form the server? Yep, we can.

Only Server Side

If you want to render React from the server you have to use react-dom/server with a utils function, renderToString. Check this sample:

Easy right? Well, not.

This is only the first part, if you need to handle an event or change the DOM, this doesn't work. The function name says all that you need to know, this creates a string with the HTML and sends the initial view to the client, despite using React this app is not reactive.

Server Side World

If you want to be this App reactive, you need to use hydrate React function. Instead of using render, that creates a DOM, you should use hydrate, that matches a DOM with VDOM on React.

For more information, you could check on React documentation.

All SSR frameworks use a similar behavior. For sample on this code lines on Next

Isomorphic Apps

With all this knowledge on your head, let me explain what is isomorphic apps. If we see the app wrapper on a SPA we should see something like that:

We only change the common render function by a hydrate function. This code will run on the client. We create a little server with the following code...

In this case, the app will render on first time by the location that the server received on the request. This creates an isomorphic router, the first rendering populates the request URL as a router URL. But when the app is loaded, the route is managed by the client.

The Future

When you need to propagate the state from the server to the client. You could implement something like the image.

In these cases and others, re-hydration has a considerable cost. Because we need to propagate the data from all the VDOM.

Some people propose some solutions to solve these issues.

These ideas are about reducing the scope to hydrate the app. We could hydrate by events or only hydrate the visible part on the browser, like lazy-hydration (check that GitHub repo).

That's all folks, thanks for reading.