Next.js has long been positioned as the flagship React framework, powering countless production apps across the web. However, growing developer frustration is beginning to expose its limitations.
A recent blog post by developer Dominik Meca, titled ‘Next.js is Infuriating’, struck a chord across the community in Hacker News and Reddit, with many engineers echoing similar pain points. The issues are not isolated bugs; they reflect deeper cracks in how the framework handles middleware, logging and developer feedback.
Meca sets out with what should be a simple task: setting up production-ready logging. Instead, what follows is a spiral of workarounds, broken abstractions and unanswered questions.
Meca’s verdict is unflinching. “How do you f**k this up so bad? We’ve had middlewares since at least the early 2010s when Express came out,” he wrote. From here, the frustrations snowball as middleware refuses to chain, AsyncLocalStorage contexts mysteriously vanish mid-render and logging across client, server, and middleware becomes a split, fragile process.
The Issues in Spotlight
The core complaint largely centres around middleware, which Next.js’s documentation describes as “particularly useful for implementing custom server-side logic like authentication, logging or handling redirects”.
Yet, in practice, Meca found that “you can pass a grand total of four parameters from your middleware” and nothing beyond headers propagates downstream. His workaround was to stuff request IDs into headers just to pass data to pages.
When even that broke, he tried moving to a custom server, only to find the pattern getting repeated there as well, with AsyncLocalStorage still failing to behave as expected.
This isn’t just one engineer’s rant. Other developers have echoed similar concerns.
Utkarsh Kanwat, an engineer at ANZ, told AIM that beyond the chaining issues, the AsyncLocalStorage problems are a dealbreaker for many use cases.
“You can’t share context between middleware and your actual application code, which breaks distributed tracing, any sophisticated auth patterns, etc,” he said.
He also argued that the lack of context propagation makes Next.js unsuitable for advanced real-world requirements.
“The fact that you can’t reliably share context between middleware and your application code in 2025 is pretty frustrating, especially when Express and other frameworks solved this years ago,” he added.
A Framework Falling Behind?
Meca’s post draws a sharp contrast between Next.js and SvelteKit, another framework backed by Vercel.
Where Next.js middleware struggles even with basics, SvelteKit supports chaining, request-scoped data and composability.
As Meca put it bluntly, “This is what real engineering looks like. SvelteKit is a Vercel product. How is the flagship offering worse than what is essentially a side project?”
Kanwat reinforced this point, arguing that Next.js makes developers work against the framework for anything beyond basic use cases. “It’s frustrating because these should be solved problems by now.”
Vishwa Gaurav, software development engineer at Groww, offered a slightly more measured perspective to AIM. He pointed out that Next.js’ middleware is powerful for straightforward, latency-sensitive tasks as it runs before the route handler and supports edge runtime. However, for richer, composable or complex workflows, its limitations make frameworks like SvelteKit more appealing.
Moreover, highlighting a key difference in approach, he said that unlike dedicated middleware systems, SvelteKit employs hooks to intercept and modify requests and responses, while adding that Vercel should provide “built-in utilities or patterns that facilitate the management of request-scoped data, reducing the need for a custom server.”
The Larger Frustration
Underneath the middleware debate lies a deeper cultural frustration: responsiveness. Developers such as Meca describe the Next.js GitHub issue tracker as a “crown jewel of the dumpster fire,” where “hopes and issues come to die”.
“The mean response time for a bug report is never,” Meca claimed, citing multiple issues that received silence despite detailed reproductions.
Kanwat agrees. “Honestly, the GitHub response times are concerning, but haven’t stopped me from using Next.js yet,” he said, adding that the worrying part is the actual performance regressions that keep showing up, such as massive build slowdowns in recent versions that take months to get fixed.
“The issue isn’t just slow responses, it’s that many performance problems seem to get introduced and then take forever to resolve,” he added.
For projects of critical importance, Kanwat advised greater caution. He admitted that it is better to exercise greater caution and consistently pin specific versions instead of relying on automatic updates.
The sentiment is not universal. Gaurav found Vercel engineers responsive on social media and positive in addressing requests. Yet, the larger frustration remains that a framework of this scale leaves developers split between hacks, custom servers or entirely different tools.
What’s Next For Next.js?
“Personally, I don’t want to use Next.js anymore,” Meca admitted. While he admitted he lacks the leverage to move his entire company away, the experience has eroded his trust in the framework.
Many developers may continue to rely on Next.js, but often with caution, workarounds or pinned versions to avoid regressions.
What emerges is less a single bug and more a pattern: middleware that doesn’t propagate context, AsyncLocalStorage that fails where it’s needed most, and an issue tracker seen as unresponsive. Together, these point to a framework caught between its ambitions and a faltering developer experience.
With alternatives like SvelteKit offering greater flexibility, the cracks in Next.js’s dominance are starting to widen.
The post Next.js Has a Middleware Problem appeared first on Analytics India Magazine.
