Who Is Next.js Built For?
Yesterday (March 22, 2025), a critical vulnerability in Next.js Middleware was publicly disclosed. If you’re unfamiliar with this issue, Rachid Allam offers a comprehensive overview in the article Next.js and the Corrupt Middleware: The Authorizing Artifact.
While reading about the origins of this flaw, an intriguing architectural question emerged: What were the considerations behind Next.js Middleware’s reliance on HTTP headers for managing internal request contexts?
To understand this architectural choice better, it helps to consider what makes a framework effective. David Heinemeier Hansson (DHH), the creator of Ruby on Rails, famously coined the concept of “conceptual compression.” Good frameworks apply conceptual compression by eliminating complexity and providing clear, consistent abstractions, enabling developers to accomplish more with less cognitive overhead.
From this perspective, Next.js’s decision to embed middleware state into client-accessible HTTP headers can appear unnecessarily complex and potentially counterintuitive. In other Node.js frameworks, such as Fastify or Express, middleware are just simple functions. Digging deeper, Next.js documentation clarifies that Middleware runs within Vercel’s “Edge Runtime.” However, this highlights a possible concern: the complexity introduced by Middleware may be more aligned with Vercel’s platform goals than directly addressing developer needs.
Most developers, particularly those building typical websites or simple applications, have little need for edge runtimes or globally-distributed middleware logic. Yet, developers may feel compelled to adopt these architectural choices due to Next.js’s design decisions. Developers find themselves forced to learn new paradigms, handle unfamiliar pitfalls, and spend time migrating away from Vercel.
Unfortunately, this middleware incident isn’t isolated. Over recent years, Next.js has dramatically expanded its feature set, evolving far beyond a simple React server-rendering solution. It now includes multiple routing systems, incremental static regeneration (ISR), React Server Components, image optimization APIs, and numerous other highly specialized features. On the surface, these additions promise convenience. However, beneath the polished developer experience lies a growing level of complexity, with many features closely tied to Vercel’s managed services. Developers choosing to host elsewhere may occasionally encounter unexpected complexities or maintenance challenges, which could unintentionally increase reliance on Vercel’s ecosystem.
This runs counter to the core philosophy DHH advocates — that frameworks should genuinely simplify development, not merely conceal complexity beneath the surface. If architectural choices become overly driven by platform considerations rather than genuine developer benefits, developers may find themselves managing unexpected complexity. Understanding the motivations behind your tools empowers you to make informed decisions aligned with your project’s long-term goals, enhancing your autonomy as a developer.