English for Svelte Developers

Svelte’s pitch to teams is that it moves work from the browser to the compiler, and that framing shows up constantly in how developers talk about it — “compiled away,” “no virtual DOM,” “reactive by default.” Getting comfortable with that vocabulary makes it much easier to explain Svelte’s tradeoffs to a team evaluating it, or to review a Svelte PR precisely instead of vaguely.

Key Vocabulary

Compiler (Svelte compiler) The build-time tool that transforms Svelte component files into optimized, framework-free JavaScript, rather than shipping a runtime library that interprets components in the browser. Example: “Most of what feels like framework magic here actually happens at compile time — the compiler generates plain DOM update code, so there’s very little runtime overhead.”

Reactivity The mechanism by which a UI automatically updates when the underlying data it depends on changes, without the developer manually triggering a re-render. Example: “Assigning to this variable triggers reactivity automatically — you don’t need to call a separate update function like you might in another framework.”

Rune The $state, $derived, and $effect symbols introduced in Svelte 5 that make reactive declarations explicit in the code, replacing the older implicit reactive statement syntax. Example: “We wrapped this value in $state so the rune system tracks it explicitly, instead of relying on the older implicit reactivity that was easy to miss in review.”

Store A Svelte-specific object for holding reactive state that needs to be shared across multiple components, exposing a subscribe method that components can read from reactively. Example: “We moved the user session into a writable store so any component can subscribe to it without prop drilling it through five layers.”

Props Data passed into a Svelte component from its parent, declared explicitly at the top of the component and used the same way regardless of how many layers deep the component sits. Example: “This component is missing a default value for its optional prop, so it throws when a parent forgets to pass it.”

SvelteKit The official application framework built on top of Svelte, providing routing, server-side rendering, and build tooling, comparable to what Next.js provides for React. Example: “We’re moving this route’s data loading into a SvelteKit load function so it runs on the server before the page renders.”

Hydration The process by which a server-rendered page becomes interactive in the browser, attaching event listeners and reactive behavior to the already-rendered HTML. Example: “The button isn’t responding to clicks yet because hydration hasn’t finished — the HTML is there, but the JavaScript hasn’t attached its listeners.”

No virtual DOM A description of Svelte’s approach of generating direct, targeted DOM update instructions at compile time, rather than diffing a virtual representation of the UI at runtime like React does. Example: “Because there’s no virtual DOM here, the compiler already knows exactly which DOM node to update when this value changes — there’s no diffing step involved.”

Common Phrases

In code reviews:

• “This reactive statement has a side effect that isn’t obvious from reading it — can we make the dependency explicit with a rune instead?”
• “We’re mutating this array in place, which won’t trigger reactivity the way you’d expect — let’s reassign it instead.”
• “This store is exported directly and any component can write to it, which makes state changes hard to trace — should we expose a more controlled update function instead?”

In standups:

• “Yesterday I migrated this component’s reactive statements to the new rune syntax; today I’m testing that the derived values still update correctly.”
• “I’m blocked on a hydration mismatch — the server-rendered markup doesn’t match what the client renders on first paint.”
• “I finished moving the shared cart state into a store, so we no longer need to pass it down through four component layers.”

In architecture discussions:

• “Since there’s no virtual DOM overhead here, Svelte tends to produce smaller bundles and faster initial renders for this kind of content-heavy page.”
• “SvelteKit’s load function runs on the server by default, which is exactly what we need to avoid exposing this API key to the client.”
• “The compiler catches a lot of reactivity mistakes at build time that you’d only discover at runtime in some other frameworks.”

Phrases to Avoid

Saying “it’s just faster” without specifying why. Say instead: “the compiler ships less runtime code and skips the virtual DOM diffing step” — this actually explains where the performance difference comes from, which matters when someone asks you to justify the framework choice.

Saying “the reactivity broke” for a mutation bug. Say instead: “we mutated the array in place instead of reassigning it, so reactivity didn’t trigger” — this is a specific, well-known Svelte gotcha, and naming it precisely points straight at the fix.

Saying “the store” as if there’s only one kind. Svelte has writable, readable, and derived stores, each with different intended use. Say instead: “we should use a derived store here since this value is computed from another store, not something we set directly.”

Quick Reference

Term	How to use it
compiler	”Most of the optimization happens at compile time, not runtime.”
reactivity	”Reassigning the variable triggers reactivity automatically.”
rune	”We use $state and $derived runes to make reactivity explicit.”
store	”Shared state lives in a writable store components can subscribe to.”
SvelteKit	”The SvelteKit load function fetches data on the server.”
hydration	”The mismatch happens between server-rendered and client-rendered markup.”

Key Takeaways

• Explain Svelte’s performance story specifically — no virtual DOM, compile-time optimization — rather than a vague “it’s faster.”
• Know the difference between implicit reactive statements and explicit runes, since this is a major migration topic for any team using Svelte 5.
• Distinguish writable, readable, and derived stores by their intended use, not just by name.
• Name in-place mutation bugs precisely as a reactivity trigger issue, since this is one of the most common Svelte-specific mistakes.
• Describe SvelteKit’s load function clearly when discussing where sensitive data fetching should happen — server-side by default.