English for Svelte 5 Runes

Svelte 5’s runes replaced implicit reactivity (let variables and $: statements) with explicit function calls ($state, $derived, $effect), and the vocabulary shifted accordingly. Teams migrating a codebase need precise language to describe what changed, especially when explaining to reviewers why a component behaves differently than it did in Svelte 4. This guide covers the terms.

Key Vocabulary

Rune — a special compiler-recognized symbol ($state, $derived, $effect, $props) that marks reactive behavior explicitly, replacing Svelte 4’s implicit reactivity. “Runes make reactivity explicit in the code itself, so you don’t have to infer it from a bare let declaration anymore.”

$state — the rune that declares a reactive variable, replacing a plain let at the top level of a Svelte 4 component. “We wrapped the counter in $state(0) so updates to it automatically trigger a re-render, just like a Svelte 4 let count = 0 used to.”

$derived — the rune that declares a value computed from other reactive state, replacing the $: reactive statement for computed values. “Instead of a $: doubled = count * 2 reactive statement, we now write let doubled = $derived(count * 2).”

$effect — the rune that runs a side effect whenever its reactive dependencies change, replacing $: statements used for side effects like logging or DOM manipulation. “We moved the analytics call into an $effect block since it’s a side effect, not a derived value — it shouldn’t return anything.”

Fine-grained reactivity — Svelte 5’s underlying reactivity model, where individual signals update independently rather than the whole component re-rendering on any state change. “Fine-grained reactivity means only the specific text node bound to count updates, not the entire component tree.”

Rune migration — the process of converting a Svelte 4 component’s implicit let/$: reactivity to explicit runes, often assisted by Svelte’s official migration tool. “The rune migration tool converted most of the component automatically, but we had to manually fix a few $: blocks that mixed derived values with side effects.”

Common Phrases

• “Should this be $state or $derived? It looks like you’re computing it from another value, not declaring new state.”
• “This $effect is doing too much — can we split the side effect from the derived calculation?”
• “Did the migration tool convert this correctly, or is it still using the old $: syntax?”
• “Is this reactivity actually fine-grained here, or is the whole component still re-rendering?”
• “Why is this rune not triggering an update — is it being read outside a reactive context?”

Example Sentences

Explaining a migration decision in a PR description: “I converted this component’s $: statements to $derived and $effect separately, since the old code mixed a computed value with a console log in the same reactive statement, which the new runes API doesn’t allow you to conflate.”

Reporting a reactivity bug: “The UI isn’t updating when the prop changes — it turns out the value was destructured outside of $derived, so it’s just a plain snapshot instead of a reactive value.”

Discussing the migration with a teammate: “Most of the migration was mechanical, but the trickiest part was untangling $effect blocks that were secretly also computing derived values — we had to split each one into a $derived plus a much smaller $effect.”

Professional Tips

• Say “rune” as the general term, but name the specific rune ($state, $derived, $effect) when describing a bug — “the reactivity is broken” is far less actionable than “the $effect isn’t re-running.”
• Distinguish derived values (pure computations) from effects (side effects) explicitly in code review — mixing them was a common Svelte 4 anti-pattern that runes are designed to prevent.
• Use “fine-grained reactivity” when explaining performance improvements to stakeholders — it’s the underlying reason Svelte 5 updates can be faster than whole-component re-renders.
• Reference the migration tool by name when discussing upgrade effort, and clarify which parts still needed manual fixes, since automated migration is rarely fully complete.

Practice Exercise

1. Explain in two sentences the difference between $derived and $effect.
2. Write a one-sentence bug report describing a value that isn’t updating because it was read outside a reactive context.
3. Describe, in your own words, what “fine-grained reactivity” means compared to whole-component re-rendering.

In Practice: Navigating Feedback & Collaboration

The beauty of Svelte 5’s runes API – particularly its focus on reactive state and derived values – is amplified when you can articulate your intentions clearly in English. Let’s be honest, a lot of professional communication isn’t about what you’re doing, but why. A simple “fix” might not cut it; explaining the reasoning behind changes dramatically improves code reviews and collaborative development. Consider this scenario: Sarah is reviewing a PR submitted by Mark that updates a component’s data fetching logic. Mark’s commit message simply reads, “Fixed bug.” Sarah’s response in Slack isn’t just “Cool.” It’s, “Mark, could you elaborate on the root cause of the issue? Knowing why the initial fetch was failing will help us ensure this fix doesn’t introduce regressions. Specifically, did we encounter rate limiting with the API, or was it a problem with data transformation after receiving the response?” This level of detail – referencing specific potential problems and demonstrating an understanding of the underlying system – immediately elevates the conversation. Similarly, when writing your PR descriptions, avoid vague statements like “Improved performance.” Instead, frame it as “Optimized data loading by implementing a derived value to debounce API requests, reducing unnecessary network calls and improving initial load times.” The goal is to communicate not just what you changed, but why the change matters within the broader context of the application.

Another crucial area is understanding feedback from code reviews. Often, reviewers will suggest modifications that seem initially confusing. Instead of defensively pushing back with phrases like “That’s not how I intended it,” try responding with something like, “I appreciate your suggestion regarding the derived value. Could you explain your reasoning? Perhaps there’s a more elegant or performant way to achieve the same result.” Actively soliciting clarification demonstrates willingness to learn and adapt, fostering a positive collaborative environment. Don’t be afraid to ask for examples of how you might use that approach in other parts of the codebase. It’s also vital to acknowledge potential drawbacks – “I considered the possibility of increased complexity with this approach but believe the performance gains outweigh the added overhead.” This shows foresight and a commitment to robust solutions. Remember, effective communication is about building shared understanding, not asserting authority.

Furthermore, when discussing reactive state changes within Svelte 5’s runes API, it’s helpful to use precise terminology. Instead of saying “I made this react,” consider “I implemented a derived value that automatically updates whenever the input data changes, ensuring consistent UI behavior.” This level of specificity avoids ambiguity and allows for more targeted feedback and troubleshooting. It’s also useful to think about how your code will feel to another developer reading it – would they immediately understand the intent?

Here’s an example demonstrating a simple SvelteKit command that might be used in a scenario like this:

npm install @sveltejs/kit
npx svelte kit dev

This command, when executed within a development environment, allows you to quickly iterate and test changes to your Svelte 5 application, providing immediate feedback on the impact of your code modifications.