What Next.js Users Really Want (According to GitHub)

## Executive Summary We looked at 57,793 GitHub issues from Next.js to find out what developers really struggle with. Instead of relying on survey answers, we focused on the problems that actually lead people to file issues. **Key Findings:** - Server-side rendering complexity: 19,277 issues (33% of total) - Configuration and integration pain: 14,450 issues (25% of total) - Resolution rate: Only 29% of issues get resolved; 52% of discussed issues remain unresolved - Build performance concerns: 8,511 issues (15% of total) despite being a core promise … ## The Three Big Pain Points ### 1. Server-Side Rendering (19,277 issues) SSR is here to stay, but it’s tough to get right in production. Developers face challenges like error handling, server components, hydration bugs, and the ongoing struggle to manage server and client boundaries. Here’s what your workflow tools miss: Your sprint velocity might look fine, but if developers spend hours debugging hydration issues that never become tickets, they aren’t building new features. Instead, they’re dealing with architectural debt. ### 2. Configuration Hell (14,450 issues) React version conflicts, webpack configs, and TypeScript integration issues. When your framework touches the entire ecosystem, every version bump is a potential minefield. There’s a hidden cost: Developers often solve problems on their own without creating tickets. Your Jira board shows closed stories, but it doesn’t show the 40 hours spent last quarter fixing webpack configurations. ### 3. Build Performance (8,511 issues) Turbopack, babel, webpack, optimization – the word cloud screams it. Developers are obsessed with build speed, but they’re also frustrated by experimental features that break existing setups. Here’s the problem: Slow builds affect every feature delivery. Your CI metrics show longer build times, and your sprint board shows completed points, but neither tells you the true cost. … **What they don’t show:** ... **The planning problem:** You can’t account for what you can’t measure. When engineering says “this will take longer than expected,” is it because they’re being conservative, there’s legitimate technical complexity, or framework debt is compounding? Without visibility into where complexity accumulates, every planning conversation becomes a negotiation instead of a data-driven discussion.