Home

Tech

What we think

Why Redpapr Shifted from React+Next.js to SvelteKit

Go Back

At Redpapr, we're building the future of edtech—faster, simpler, and more accessible. As our platform evolved and our user base grew, we found ourselves hitting the limits of our original tech stack. That’s when we made a bold decision: migrating from React + Next.js to SvelteKit.

This post explains why we made the switch, how it impacted our team and users, and what we learned along the way.


The Backstory: React + Next.js

When we started Redpapr, React and Next.js made perfect sense. The ecosystem was mature, SSR (Server-Side Rendering) was battle-tested, and the developer tools were rich. We built fast and deployed faster.

But as we scaled, we ran into friction:

  • Too much boilerplate for simple components.
  • State management overhead even for UI interactions.
  • Performance bottlenecks despite optimization.
  • Large JavaScript payloads on the client.
  • Context-switching between JSX, hooks, and CSS-in-JS was hurting dev velocity.

React wasn't broken—it just wasn’t the right fit anymore.


Why SvelteKit?

We explored alternatives: Astro, SolidStart, even sticking with React but tweaking our approach. SvelteKit stood out immediately:

1. Truly Reactive, Minimal Syntax

Svelte removes the need for useState, useEffect, and other boilerplate. Variables are reactive by default. This made our components cleaner and our developers happier.

2. Built-In Transitions and Animations

Edtech thrives on interaction. With Svelte’s built-in transitions, we didn’t have to import animation libraries or write complex logic—things just worked.

3. Smaller Bundle Sizes

Svelte compiles away the framework. This led to smaller client-side bundles, faster load times, and better Core Web Vitals—directly improving user engagement.

4. SvelteKit’s First-Class Routing and SSR

SvelteKit offered everything we liked about Next.js—file-based routing, layouts, SSR/SSG—without the React baggage. It felt leaner and more modern.

5. Simplified State and Stores

Instead of context providers and third-party state libraries, we now use Svelte’s lightweight store system. It’s easier to reason about, and easy to share between components.


The Migration

Migrating a production app isn’t easy. We tackled it incrementally:

  • Migrated one module at a time, using SvelteKit’s adapters for hybrid deployment.
  • Created design system components in Svelte that mirrored our existing UI.
  • Rewrote shared logic in framework-agnostic TypeScript modules.
  • Kept React running alongside for a while using microfrontends.

The transition took about 4 weeks. The payoff came fast.


What Improved?

  • 🚀 Page load time dropped by 35%.
  • 📉 JS payload size reduced by ~45%.
  • Developer productivity increased—more features shipped, less time debugging.
  • 🧠 Cognitive load on devs dropped dramatically—Svelte’s syntax is easier to grok.
  • 📱 Mobile experience felt noticeably smoother.

Lessons Learned

  • Don’t fear change—modern frameworks are designed for smoother transitions.
  • Think in user terms—every millisecond saved adds up.
  • Choose simplicity—Svelte favors clarity, and that pays off.

What’s Next?

We're continuing to double down on performance, accessibility, and delightful interactions. SvelteKit gives us the foundation to iterate fast and stay nimble—just like our learners.

If you're curious about how SvelteKit can transform your dev experience, we say: give it a try. Like we did.


Want to know more about our tech stack, migration strategy, or upcoming features? Drop us a message—Redpapr loves to share and learn.