Why Layouts Matter in SvelteKit | Build BookIt

The Copy-Paste Trap

At the end of Module 2, we added navigation to each page by copying the same HTML. It worked, but it’s a maintenance disaster waiting to happen. Let’s see why.

What You’ll Learn

Why repeating code across pages is problematic
The real cost of inconsistency
How layouts solve the repetition problem

The Current State of BookIt

Right now, every page in BookIt has navigation manually added:

<!-- src/routes/+page.svelte -->
<nav>
  <a href="/">BookIt</a>
  <a href="/services">Services</a>
  <a href="/about">About</a>
  <a href="/contact">Contact</a>
</nav>

<h1>Welcome to BookIt</h1>
<!-- ... rest of homepage ... -->

<!-- src/routes/services/+page.svelte -->
<nav>
  <a href="/">BookIt</a>
  <a href="/services">Services</a>
  <a href="/about">About</a>
  <a href="/contact">Contact</a>
</nav>

<h1>Our Services</h1>
<!-- ... rest of services page ... -->

<!-- src/routes/about/+page.svelte -->
<nav>
  <a href="/">BookIt</a>
  <a href="/services">Services</a>
  <a href="/about">About</a>
  <a href="/contact">Contact</a>
</nav>

<h1>About BookIt</h1>
<!-- ... rest of about page ... -->

The same navigation block appears in every file.

What Could Go Wrong?

Imagine these scenarios:

Adding a new page. You create a /pricing page. Now you need to add a “Pricing” link to the navigation. That means editing every single page file. Miss one, and that page has outdated navigation.

Fixing a typo. The logo link says “BookIt” but should say “BookIt Pro”. Five pages to update. Or ten. Or fifty.

Changing the design. Marketing wants the navigation in a different order, with icons. You’re updating the same HTML in dozens of files.

Inconsistency creeps in. Different developers make different changes. Page A has the new navigation, Page B has the old one, Page C has a weird hybrid. Users see a broken experience.

The DRY Principle

Software development has a DRY principle - Don’t Repeat Yourself. When the same code appears in multiple places, it should be extracted into a single location.

Benefits of DRY:

One place to make changes
Impossible for copies to get out of sync
Less code to maintain
Fewer bugs from inconsistent updates

The opposite — WET (Write Everything Twice) — leads to the problems we just described.

What We Need

We need a way to define shared UI (like navigation and footer) once and have it automatically appear on every page. When we update it, every page gets the update.

This is exactly what SvelteKit layouts provide.

How Layouts Work (Preview)

Instead of putting navigation in each page, you put it in a special file called +layout.svelte. This file wraps all pages at that route level:

src/routes/
├── +layout.svelte    ← Shared UI goes here
├── +page.svelte      ← Homepage (wrapped by layout)
├── services/
│   └── +page.svelte  ← Services (wrapped by layout)
├── about/
│   └── +page.svelte  ← About (wrapped by layout)
└── contact/
    └── +page.svelte  ← Contact (wrapped by layout)

The layout renders the navigation, then renders the page content where you specify. Change the layout once, every page updates.

Summary

Copying code across files creates maintenance burdens and inconsistency risks. The DRY principle tells us to extract shared code to a single location. SvelteKit layouts are designed exactly for this purpose.

Key takeaways:

Repeated code must be updated in multiple places
Inconsistencies inevitably creep in over time
Layouts let you define shared UI once

Next Steps

Now that you understand the problem, let’s solve it. Continue with Create Your First Layout to build a +layout.svelte file for BookIt.