From Next.js to Pareto: What Changes and What Stays the Same

You know Next.js. You know file-based routing, layouts, loaders, SSR. You probably also know the pain: server components vs client components, the "use client" dance, mysterious hydration errors, and a 233 KB client bundle before you write a single line of app code.

What you give up

Transparency matters. Here's what Pareto doesn't have:

• 
  Server components — No RSC, no "use client". This is by design: the loader pattern is simpler and covers 95% of use cases.


• 
  Image optimization — No <Image> component with automatic resizing. Use standard <img> with a CDN.


• 
  ISR / Static generation — Pareto is SSR-only. No generateStaticParams(), no build-time rendering. If you need static pages, pair with a static site generator.


• 
  Middleware — No edge middleware concept. Use Express middleware in configureServer() instead.


• 
  Vercel integration — No one-click deploy. You deploy a standard Node.js server.


• 
  Ecosystem size — Smaller community, fewer examples. You're early.

If you're building a content-heavy marketing site with ISR, Next.js is still the right call. If you're building a data-driven app where performance and simplicity matter, Pareto is worth the switch.

Migration checklist

1. 
   npx create-pareto@latest my-app — scaffold a new project


2. Move your routes from app/ — file structure is nearly identical


3. Extract async server components into loader.ts + standard component


4. Replace "use client" directives — they're not needed, just delete them


5. Move generateMetadata to head.tsx components


6. Replace loading.tsx with defer() + <Await> for streaming


7. Replace next/link with Link from @paretojs/core
   


8. Move Webpack config to configureVite() in pareto.config.ts
   


9. Deploy as a standard Node.js server
   

npx create-pareto@latest my-app

cd my-app && npm install && npm run dev