Getting Started with Next.js 15 and Turbopack

Why We Chose Next.js 15

Starting the XGen project, we spent a lot of time debating the framework choice. Vue and Svelte were both on the table, but we ultimately went with Next.js 15. The main reasons were the maturity of the App Router and the team's existing React experience.

Turbopack Speed in Practice

Turbopack reached a stable phase in Next.js 15. Running next dev --turbopack makes the speed difference over Webpack immediately noticeable.

// package.json
{
  "scripts": {
    "dev": "next dev --turbopack --port 3000",
    "build": "next build",
    "start": "next start"
  }
}

Measured results:

• Cold Start: Webpack ~8s → Turbopack ~2.5s
• HMR (Hot Module Replacement): Webpack ~1.2s → Turbopack ~0.3s
• Page route transitions: Nearly instant

App Router Configuration

We leaned heavily into file-system-based routing. Nested layouts via layout.tsx turned out to be especially useful for complex UIs like the canvas editor.

// app/workspace/layout.tsx
export default function WorkspaceLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <div className="flex h-screen">
      <Sidebar />
      <main className="flex-1 overflow-hidden">
        {children}
      </main>
    </div>
  );
}

TypeScript Strict Mode

We enabled strict: true from day one. Given the nature of an AI platform, we knew the data structures would get complicated, and the type safety paid off significantly down the line.

// tsconfig.json 핵심 설정
{
  "compilerOptions": {
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "paths": {
      "@/*": ["./src/*"],
      "@/components/*": ["./src/components/*"],
      "@/stores/*": ["./src/stores/*"]
    }
  }
}

Lessons from the Initial Setup

Turbopack still has compatibility gaps with some Webpack plugins, so we set up a branch configuration that falls back to Webpack when needed. A faster DX directly translates to higher productivity, so the upfront investment was well worth it.