Skip to main content
Booking for 2026Limited consultancy slots available
Sparkwerk

Why We Chose Next.js for (Almost) Everything

A practical breakdown of when Next.js makes sense, when it doesn't, and how we make the call for each project.

Pieter-Jan Scheir
Founder
December 15, 2024
2 min read

Next.js has become our default framework for web projects. Not because it's trendy, but because it solves real problems we face repeatedly. Here's our honest assessment.

The Good Parts

Server Components Changed the Game

React Server Components fundamentally shifted how we think about data fetching. Instead of loading spinners and client-side requests, we can render complete pages on the server. The result? Faster initial loads and better SEO without the complexity of separate API routes.

// This just works. No useEffect. No loading states.
async function ProjectList() {
  const projects = await db.projects.findMany()
  return <ul>{projects.map(p => <li key={p.id}>{p.name}</li>)}</ul>
}

The App Router is Worth the Learning Curve

Yes, the transition from Pages to App Router was painful. Layouts, loading states, and error boundaries took time to internalize. But now that we've built several projects with it, the patterns feel natural. Nested layouts alone save us hours on every project.

Edge Runtime When You Need It

For landing pages and marketing sites, Edge rendering means sub-100ms response times globally. We don't use it everywhere—database-heavy applications stay on Node—but having the option is powerful.

The Honest Trade-offs

Build Times Can Hurt

Large applications with hundreds of pages take time to build. We've had to restructure some projects to use more dynamic rendering to keep deployments reasonable.

The Ecosystem is Fragmented

Not every React library works smoothly with Server Components. We maintain a tested list of compatible packages and occasionally have to write client-only wrappers.

Vercel Lock-in is Real-ish

While Next.js technically runs anywhere, the best experience is on Vercel. We've deployed to other platforms successfully, but it requires more configuration.

Our Decision Framework

We choose Next.js when:

  • SEO matters (marketing sites, blogs, portfolios)
  • The team already knows React
  • We need both static and dynamic pages
  • Performance is a priority

We look elsewhere when:

  • It's a simple static site (Astro is faster)
  • It's a complex dashboard with no SEO needs (might just use Vite + React)
  • The client has strong preferences for another stack

Conclusion

Next.js isn't perfect, but for the work we do—mostly marketing sites, web applications, and product landing pages—it hits the sweet spot between developer experience and end-user performance. The key is knowing when to reach for its advanced features and when to keep things simple.

Share this article

Want to discuss this topic?

We'd love to hear your thoughts or help you apply these ideas.