Svelte Best Practices and Where to Go Next

Svelte's syntax is small enough to learn quickly, but writing good Svelte is still a matter of habits, not just knowing the runes exist. A few of those habits are worth calling out explicitly now that you've seen the whole toolkit.

Prefer $derived over $effect for computed values

It's easy to reach for $effect out of habit, since it feels like the most general tool:

<script>
  // Works, but the wrong tool
  let total = $state(0);
  $effect(() => {
    total = price * quantity;
  });
</script>

<script>
  // Clearer: total can't drift out of sync, and there's no extra write
  let total = $derived(price * quantity);
</script>

If you find yourself writing $effect purely to set another $state variable, that's almost always a sign the value should be $derived instead — it's fewer moving parts, and the compiler can reason about it more precisely.

Keep components small and focused

A component that's grown past a couple hundred lines, with <script> full of unrelated state, is usually several components wearing a trenchcoat. Splitting by responsibility — a list, a list item, a filter bar — keeps each piece's props and state easy to hold in your head, and makes reuse possible instead of accidental.

Don't reach for shared state by default

Runes-based shared state and stores (covered earlier) are useful, but every piece of state you make global is one more thing every future change has to consider. Default to props and callbacks for anything local to a part of the component tree; promote state to something shared only once two genuinely unrelated components need it.

Accessibility doesn't go away because it's a framework

Everything true about accessible HTML is still true inside a .svelte file: use a real <button> for actions, pair <label> with <input>, keep heading levels in order. The Svelte compiler will even warn you at build time about some common mistakes — like a click handler on a non-interactive element with no keyboard equivalent — so pay attention to those warnings rather than suppressing them.

Where SvelteKit fits in

Everything in this course is plain Svelte — components, reactivity, rendering — the same building blocks regardless of what's around them. SvelteKit is a separate, official meta-framework built on top of Svelte, adding the pieces a full application typically needs beyond components:

• File-based routing (a file at src/routes/about/+page.svelte becomes the /about page)
• Server-side rendering and data loading (+page.server.js functions that run before a page renders)
• A build pipeline that can target static hosting, a Node server, or various edge runtimes

It's the Svelte equivalent of what Next.js is to React — genuinely useful once you're building a real, multi-page application, but a separate layer of concepts on top of what you've learned here. With the fundamentals from this course in hand, picking up SvelteKit is mostly a matter of learning its routing and data-loading conventions — the components themselves work exactly the way you already know.