English for Svelte

Svelte’s core pitch is that it’s a compiler, not a framework running in the browser, and its vocabulary — reactivity, stores, no virtual DOM — only makes sense once you separate what happens at compile time from what happens at runtime.

Key Vocabulary

Compiler, not a framework — Svelte’s defining characteristic: it converts component code into efficient vanilla JavaScript at build time, rather than shipping a runtime framework library that interprets components in the browser. “Svelte is a compiler, not a framework, in the sense that matters here — there’s no runtime library shipped to the browser interpreting your components, the compiler already turned them into plain DOM-manipulation code.”

Reactivity ($:) — Svelte’s built-in mechanism for automatically re-running code when referenced variables change, using the $: label syntax, without needing a separate hooks or observable system. “We don’t need a useEffect equivalent here — Svelte’s reactivity with the $: label handles this automatically, re-running that line whenever the variables it depends on change.”

No virtual DOM — the fact that Svelte’s compiled output updates the real DOM directly with targeted operations, rather than diffing a virtual DOM tree against the previous render like React does. “Svelte has no virtual DOM step — the compiler already knows exactly which DOM nodes depend on which variables, so it generates code that updates those specific nodes directly instead of diffing a tree.”

Store — Svelte’s built-in state-sharing primitive, either writable, readable, or derived, used for state that needs to be accessed or updated from multiple components without prop drilling. “Instead of prop-drilling this value through four components, we put it in a writable store — any component can subscribe to it and get updates automatically, without an external state library.”

SvelteKit — the official application framework built on Svelte, providing routing, server-side rendering, and build tooling, roughly analogous to Next.js for React or Nuxt for Vue. “We’re not just using Svelte for components — the whole app is on SvelteKit, so we get file-based routing and server-side rendering out of the box, not just the component layer.”

Common Phrases

• “Does this need a store, or can it stay as local component state?”
• “Is this reactive statement re-running for the reason we expect?”
• “Are we talking about Svelte the component syntax, or SvelteKit the full framework?”
• “Since there’s no virtual DOM, is this update happening at the DOM level we expect?”
• “Should this be a writable store or a derived store?”

Example Sentences

Explaining Svelte’s compile-time model: “When people ask why Svelte’s bundle is smaller, it’s because it’s a compiler, not a framework — there’s no virtual DOM diffing library shipped to the browser, the compiler already generated the minimal DOM update code at build time.”

Describing a state-sharing decision: “This value needs to be read and updated from three unrelated components, so I put it in a writable store rather than prop-drilling it — any component can subscribe without us threading it through intermediate components that don’t use it.”

Clarifying scope in a discussion: “When you say we should evaluate Svelte, do you mean just the component syntax, or the full SvelteKit framework with routing and server-side rendering? That changes what we’re actually comparing against Next.js.”

Professional Tips

• Emphasize that Svelte is a compiler, not a framework when explaining bundle size or performance advantages — the mechanism is fundamentally different from React’s runtime approach.
• Use reactivity with $: for derived values that should automatically update, but keep it simple — overly complex reactive statements can become hard to trace.
• Remember there’s no virtual DOM when debugging update behavior — issues tend to trace to reactivity dependencies, not to a reconciliation algorithm.
• Reach for a store only when state genuinely needs to be shared across components — for purely local state, plain component variables are simpler and sufficient.
• Be precise about SvelteKit versus plain Svelte in comparisons — SvelteKit competes with Next.js and Nuxt, while plain Svelte competes with React or Vue as a component library.

Practice Exercise

1. Explain why Svelte doesn’t need a virtual DOM to update the browser efficiently.
2. Describe when you’d reach for a store instead of local component state.
3. Write a sentence distinguishing Svelte from SvelteKit for someone new to the ecosystem.