I recently decided to give my website a major overhaul. The original version was built using Svelte 4, SvelteKit, and Skeleton.dev with TailwindCSS v3. After a few months of tinkering and staying on top of Svelte’s updates, I took the plunge and rewrote everything in Svelte 5.

This post details the motivation behind the rewrite, the process I followed to migrate the project, and some of the new tech and design choices I made along the way.

---

Why Rewrite in Svelte 5?

My main motivation for this upgrade was to utilize the new runes from Svelte 5. Svelte’s been evolving quickly, and the runes concept (a new approach to reactivity, stores, or specialized use-cases) seemed like a significant step forward.

Beyond that:

• I wanted to ensure my codebase could take advantage of the latest improvements in the Svelte ecosystem.
• Upgrading in place might have led to missing out on new features or failing to reconsider existing patterns.
• A clean slate allowed me to rethink UI/UX decisions and adopt best practices around file structure, linting, and tooling.

---

Creating a New Project vs. In-Place Upgrades

One of the first decisions I made was to create a new SvelteKit 5 project from scratch instead of upgrading the existing codebase. This wasn’t just a random whim:

• Fewer Missed Opportunities: By starting fresh, I was forced to review and port each component and page carefully. This exposed areas where I could remove old hacks or simplify the logic.
• Better Tooling: The new SvelteKit scaffolding includes updated defaults, and I could incorporate the newest TailwindCSS v4 without leftover config from the v3 days.
• Cleaner Code: I could adopt consistent naming conventions and better file organization from the beginning.

While an in-place upgrade might have been faster, I suspect I would have carried over old design patterns that no longer made sense. A fresh project freed me from that legacy burden.

---

The Migration Process

1. Initial Setup

I began by generating a new SvelteKit project with Svelte 5:

pnpm create svelte@latest my-new-website

When prompted, I selected the standard app template to start with a basic structure. Next, I installed Skeleton.dev according to their official documentation:

pnpm add -D @skeletonlabs/skeleton @skeletonlabs/skeleton-svelte

I then configured my global stylesheet to include Skeleton’s imports and set up the theme:

@import 'tailwindcss';
@import '@skeletonlabs/skeleton';
@import '@skeletonlabs/skeleton/optional/presets';
@import '@skeletonlabs/skeleton/themes/cerberus';

2. Porting Code One Page at a Time

With the environment ready, I migrated code page by page. This approach meant:

• I could test each page in isolation and ensure it looked and functioned as intended.
• Old code that was no longer relevant got left behind.
• Each piece of functionality benefited from a redesign or refactor.

3. Redesigning the UI

Because I was rewriting all these components anyway, I decided to overhaul the entire look and feel:

• I leveraged Skeleton.dev’s component library for consistent, accessible UI elements
• I utilized modern layout techniques (like responsive grids, flex, and container queries) to ensure a snappier experience on various screen sizes
• I introduced a light/dark mode toggle using Skeleton.dev’s built-in theming system, which made the implementation seamless

4. Leveraging Svelte 5 Runes

One of the show-stoppers in Svelte 5 is the runes feature. While I’m still exploring how best to incorporate them, here’s what I love:

• Runes can simplify reactive contexts that might otherwise require more elaborate store structures or awkward passing of props.
• They make certain logic more self-contained, improving code readability.

I won’t dive too deep into runes examples here, but they’re shaping up to be a big improvement to Svelte’s reactivity model.

Done

Start the dev server using the following command.

Terminal window

pnpm dev

---

New Tooling and Reduced Configuration

In addition to adopting Svelte 5 and TailwindCSS v4, I also made a tooling switch:

Switched From Prettier + ESLint to Biome

• Why Biome? I wanted to reduce the dependency bloat of having multiple linting and formatting tools. Biome combines linting and formatting into one solution, which is simpler and more efficient.
• Result: Fewer config files, fewer devDependencies, and a more unified code standard.

CloudFlare Turnstile for Bot Detection

• I integrated CloudFlare Turnstile for an added layer of security. This helps detect and mitigate spam or bot traffic, reducing unwanted form submissions or login attempts.

Continued Deployment on Vercel

• I’m still a huge fan of Vercel for deployments. The new site deploys in around 25 seconds, which is noticeably faster than before. SvelteKit’s updates and the lighter toolset likely play a role in this speed increase.

---

Lessons Learned

1. Fresh Starts Encourage Reflection: Creating a new project forced me to re-examine old code and weed out outdated patterns.
2. Stay Updated with the Ecosystem: Jumping to SvelteKit 5 and Tailwind v4 gave me access to new features and simplified some of my code.
3. Consolidating Tooling: Swapping Prettier + ESLint for Biome drastically reduced friction in my workflow. Less configuration overhead = more time coding.
4. Focus on User Experience: While rewriting, I put extra effort into UI/UX details—making the site more accessible, responsive, and visually modern.

---

Conclusion

The rewrite from Svelte 4 to Svelte 5, along with the jump from TailwindCSS v3 to v4, has been incredibly rewarding. The new runes in Svelte 5 open up interesting possibilities for more elegant reactivity patterns. Meanwhile, the fresh start let me redesign my site’s UI to be more modern and light/dark mode-friendly.

By dropping Prettier + ESLint in favor of Biome, and by cleaning up my code and configuration files, I’ve ended up with a leaner, faster project that’s easier to maintain. Deploying to Vercel remains simple, and CloudFlare Turnstile helps keep bots at bay.

If you’re considering a big upgrade or complete rewrite, my advice is: don’t be afraid to start from scratch if you can afford it. It’s a chance to adopt new best practices, cut out old cruft, and create something that better reflects the current state of the web—and your own skills.

Thanks for reading, and happy Svelte-hacking!