DEV Community: Federico Corradi

Next.js isn't the best framework. It's the most reliable bet.

Federico Corradi — Thu, 25 Jun 2026 17:24:44 +0000

Next.js is the most used React meta-framework in the world and one of the most resented. The numbers say both things at once. The State of JavaScript 2025 survey puts its usage leadership beyond argument while noting, in the same breath, that satisfaction has slipped, and it names the culprits: the rising complexity of Server Components and the App Router. Spend any time near the discourse and you'll hear all of it. The framework is bloated. The App Router broke my mental model. RSC shipped half-baked. The whole thing is a funnel into Vercel's hosting. Some of that is fair, and I'll get to the parts that are. A lot of it is people who picked the wrong tool, or used the right one against its grain, and then blamed the tool.

I've built on Next.js for years, including platforms where the wrong decision would have cost real money and real users. So this is my two cents, offered as one practitioner's view rather than a verdict. I don't think Next.js is the best framework available. I think it's the most reliable bet, and those are not the same claim. Understanding the difference is the whole point.

Everyone has an opinion about Next.js, and most of them are about the wrong thing. Here's mine, for what it's worth: the framework is rarely the problem. How you choose it, and what you do to it afterwards, almost always is.

There is no framework that wins on every axis

Let's clear the strawman out of the way first, because it poisons every one of these arguments. There is no universal frontend framework, and anyone selling you one is selling you something. Programming doesn't work like that. One solution does not fit every problem, and the moment you believe it does, you've stopped engineering and started cheerleading.

So when someone says a competitor is "better" than Next.js, the honest question is: better at what? Astro is genuinely brilliant at static generation. For a content site that's mostly read and rarely changes, it's hard to beat. SvelteKit produces leaner output and a development experience a lot of people prefer; it scores consistently higher on developer satisfaction than Next.js does. These are real strengths, and on their chosen axis they often win outright.

The problem is that real projects are never one axis. They're a content site that also needs authenticated dashboards. A marketing platform that also needs preview workflows for editors. A static catalogue that also has to scale to millions of users without falling over. The framework that wins isn't the one that's strongest at any single thing. It's the one that doesn't collapse into a pile of workarounds the moment your requirements get plural.

Reliable isn't a compliment about elegance

This is where Next.js earns its position, and it has little to do with technical purity.

Take the moment your static site needs to stop being purely static. Next.js has Incremental Static Regeneration baked in, update one page after deployment without rebuilding the whole site, and it pioneered the pattern. Astro, for all its static brilliance, has no built-in ISR. By default, when content changes, the entire site rebuilds. You can approximate ISR-like behaviour, but only by reaching for CDN cache headers, a Redis or Cloudflare KV layer, or your hosting platform's own implementation. It's a request that has sat open on Astro's public roadmap for years, with developers in the thread calling the lack of it a dealbreaker for large content sites. None of that makes Astro bad. It makes it a different tool, strongest exactly where Next.js's complexity would be overkill.

The same shape repeats with editorial preview. Next.js ships Draft Mode as a first-class, deeply documented feature: flip into dynamic rendering, fetch unpublished content, see the draft without rebuilding. It's so much the reference implementation that the integration guides for Directus, DatoCMS, and Optimizely all lead with a section titled "Next.js Draft Mode." SvelteKit supports it too, so this isn't exclusive territory, but Next.js is the path of least resistance and the one every CMS documents first.

Beyond content delivery, what Next.js is really offering is a complete server-side platform sitting inside your frontend codebase. The edge runtime lets you run middleware and route handlers geographically close to the user, handling auth, redirects, and A/B flags before a page ever renders. Streaming with Suspense lets you send the static shell of a page immediately and stream in slow data as it resolves, so a single slow database query no longer blocks the entire render. Server Actions let you call server-side logic directly from a component without writing a separate API layer. And the built-in image and font optimisation pipeline handles format conversion, lazy loading, and layout-shift prevention without any configuration. Each of these is a capability you'd otherwise assemble yourself from separate tools, with all the integration surface area that implies. Together they mean the decision to use Next.js is not just a choice of rendering framework; it's a choice of how much application infrastructure you want the framework to own.

Then there's the thing nobody wants to admit matters: the model that's been trained on it. Next.js existed and was widely adopted well before large language models became a development tool. It sits on top of React, which dwarfs every other component ecosystem. Stack Overflow's 2025 survey of more than 49,000 developers puts React at 46.9% of professionals and Next.js at 21.5%, against Vue's 18.4% and Svelte's 6.9%. So when an AI assistant generates Next.js code, it generates good Next.js code, because the training corpus is enormous and the patterns are well established. Pick Nuxt and you inherit Vue's smaller footprint. Pick SvelteKit and you inherit Svelte's. The framework didn't get cleverer. The gravity underneath it is just heavier, and with roughly a third of all new code now AI-generated, that gravity is a delivery advantage you feel every single day.

The tooling has gone further than corpus size too. Next.js 16 ships with an MCP endpoint enabled by default, and Vercel's DevTools MCP server lets a coding agent query a running application directly for its errors, routes, and compiler diagnostics. Whatever you think of Vercel's commercial motives, and the funnel-into-hosting suspicion isn't baseless, the loop between "something's broken" and "the agent can see what's broken" is tighter here than anywhere else. That's not elegance. It's reliability, and reliability is what you actually ship on.

The discontent is real. Here's what it's actually about.

None of the above means the grievances are imaginary. Three of them are legitimate, and you should know what you're signing up for.

The first is that the opinionation cuts both ways. The same strong opinions that carry you when you align with them constrain you when your needs don't map cleanly onto Next's model. If you want half the features and don't need the other half, there's no clean way to take what you want and leave the rest. That's not a bug in the framework's thinking; it's the nature of opinionated tools. But it means Next.js is an all-in decision, and teams that try to use it selectively often end up fighting it on the dimensions they opted out of.

The second is portability, and this one implicates Vercel-the-business more than Next-the-framework. For most of Next.js's life, deploying away from Vercel meant navigating undocumented behaviour. Netlify documented this publicly: Next.js contains undocumented options and code paths, and Vercel's own deployments use an internal flag called minimalMode that disables core framework features Vercel then reimplements inside its closed-source platform. A former Netlify engineer, commenting on Vercel's own RFC thread, said the routing and redirect rules were lightly and sometimes inaccurately documented, and that they had to reverse-engineer the order and logic before eventually resorting to standalone mode with what they called "lots of hacks." On video, Netlify's Next.js runtime engineer was more direct: Vercel doesn't provide an adapter API, so we read the open-source code and made transformations to reach feature parity. That's the vendor lock-in story, and it's not a vibe. It's documented engineering work the ecosystem had to do without Vercel's cooperation. The stable Adapter API that landed in Next.js 16.2 in March 2026 addresses this directly, developed by a working group that included Netlify, Cloudflare, AWS Amplify, Google, and the OpenNext maintainers. But the API arriving in 2026 is also an admission of where the priorities sat for the previous several years.

The third is the App Router transition, which was handled badly regardless of where the feature itself has since landed. The server and client component model represents a genuine shift in how you think about React, and it wasn't explained well at launch. The caching defaults confused teams for years: pages were cached aggressively by default, causing stale-data problems that weren't obvious until production. Version 16's fix, flipping to dynamic-by-default with explicit opt-in caching via the 'use cache' directive, is welcome, but it's also an acknowledgement that the original model caused real pain. The migration path created its own friction: Next.js always supported running both routers side by side, per route, but teams doing that in practice reported a disjointed experience, with inconsistent routing logic, layout handling, and data-fetching patterns living in the same codebase, making onboarding harder rather than easier. And once the compiler bundles everything, attributing a Web Vitals regression to a specific piece of code became genuinely harder. Teams still need strong observability tooling around caching and edge rendering behaviour to catch the things that won't surface on their own.

These are real costs. Accept them knowingly, or pick something else.

So should everyone use it? Absolutely not.

Here's the turn, and it's the part that actually matters.

None of the above means Next.js is the right choice for your project. It means it's the reliable choice, and reliability is only an advantage if you use the framework the way it wants to be used. Because Next.js is, above all, opinionated. Lean into those opinions and it carries you. Fight them and you lose, slowly, in ways that compound.

I know this precisely because I've watched it happen on a real project, and the lesson isn't that anyone made a mistake.

The setup: a Next.js platform built on a pod-per-locale Kubernetes architecture. Each locale gets its own pod. The ingress routes on path prefix (/fr/, /en/), and by the time a request reaches the Next.js pod, the locale prefix has been stripped; the app receives its locale only as an environment variable at boot. The model is paired with artifact promotion: one binary, promoted across environments, configured at runtime rather than at build. This is sound infrastructure thinking. Each locale scales independently on its own request load. The artifact promotion model is clean and operationally correct.

It is also, quietly, a decision to opt out of Next.js's routing contract.

Next's native i18n assumes the locale is part of the request the app sees. Here it isn't. So useRouter().locale returns undefined. Using next/link with the locale prefix in the href isn't recognised by the framework, which triggers a full page reload instead of client-side navigation, and broken Web Vitals immediately. Without the prefix, client navigation works but the URL drops the locale, so a hard refresh fails because the ingress has nothing to route on. Automatic hreflang tags, locale-aware sitemaps, locale-aware prefetching: all gone, because all of it assumes the framework owns the locale.

The fix is workable. A rewrite in next.config.js that teaches Next the prefix pattern, a custom next/link wrapper that prepends the locale from the environment variable, a lint rule banning direct next/link imports to enforce the convention. You ship. But hreflang, sitemaps, language switchers, locale-aware analytics, error pages, type safety on locale values: all of that becomes manual work. Each piece is small. The whole compounds into a permanent maintenance overhead and an onboarding tax on every developer who joins the project.

There was a framework-native path: one deployment serving all locales through middleware-based i18n, which would have preserved the artifact-promotion benefit without the workarounds. But the pod-per-locale model was chosen for request-level scaling, a sound reason and an independent engineering decision made before the framework conflict was visible. Nobody was wrong. Two coherent systems simply didn't compose cleanly, and the bill arrived later, in small instalments, across every feature that assumed Next.js owned the locale.

That's what fighting an opinionated framework actually looks like. Not a dramatic failure. A permanent, quiet tax.

Choose the bet, then honour it

That's what most of the Next.js discontent actually is, once you strip away the noise. It's rarely the framework failing on its own terms. It's teams choosing an opinionated tool and then spending months, sometimes years, working around the opinions they didn't want. Even the declining satisfaction numbers fit this reading: the complexity people resent is often the cost of capability they never needed, bolted onto projects that didn't call for it.

The grievances are real. The portability story was genuinely bad for a long time. The App Router transition was handled worse than it needed to be. The opinionation isn't always comfortable. Know all of that going in.

But if you're building something plural, something that has to hold up across a dozen requirements, in a team that will turn over, over several years, Next.js is still the bet that fails least often. Not because it's the most beautiful answer, but because the ecosystem, the tooling, the training data, and the sheer weight of prior art are all on your side.

Honour the contract and it carries you. Break it, even for the best of reasons, even when the infra team is completely right, and you'll spend the project paying for it in places you didn't expect.

The framework is almost never the problem. The fit is. Choose for the fit, and most of the war stories disappear before they start.

Sanity and the case for a CMS that thinks like a developer

Federico Corradi — Thu, 25 Jun 2026 17:17:45 +0000

The first time I pitched Sanity to a client, I lost the room for about ten minutes. There was no WYSIWYG editor. No familiar pages tree. No toolbar that looked like anything they'd seen before. The person across the table kept asking where the content was, and I kept explaining that the content was the point, that what we were building wasn't a website with a CMS bolted on, but a content platform that happened to power a website. That distinction matters more than most teams realise until they've spent two years maintaining the alternative.

I've been using Sanity on client work and my own projects long enough to have formed real opinions about where it earns its place and where it asks something difficult of you. The portfolio you're reading this on is built with Next.js and Sanity as the content layer. That's not a demo setup. It's a production stack, and that's deliberate.

The hidden tax on every other option

For most of its history, the CMS market offered two deals, and both had small print.

Self-hosted platforms like Craft, Umbraco, and old-school WordPress give you control. You own the infrastructure, the database, the upgrade path. In practice, that ownership compounds into a maintenance burden that grows quietly until it's eating a sprint every quarter. Security patches, PHP version incompatibilities, plugin conflicts on upgrade, server costs. The control was always real; the tax was just deferred.

Fully managed SaaS platforms like Contentful and Prismic in its more structured configurations flip the trade. No infrastructure, clean APIs, good documentation. But you're working within their content model, their field types, their pricing curve. The moment your editorial requirements get interesting, you're either bending the content model to fit the platform's constraints or paying for an enterprise tier to unlock the flexibility you needed from the start. The convenience is a rental agreement, and the landlord sets the terms.

What neither camp questioned was the assumption that the CMS and the frontend lived in different worlds, and that developers had to translate between them. Eurostar's switch away from a legacy PHP stack is a useful data point here: CMS development tasks that previously took two to three weeks dropped to two to three days. That's not a marginal improvement. It's the difference between a platform that moves with the team and one that resists it.

What Sanity actually bets on

Sanity's position is architecturally different, and once you see it, the other options look like they're solving the wrong problem.

The content lake, Sanity's hosted data layer, handles the infrastructure. Your data is stored, versioned, and served through APIs you don't have to build or maintain. That's the managed part. But the Studio, the editorial interface itself, is a React application that lives in your repository, versioned alongside your code, deployable wherever your frontend deploys. There's no hosted admin panel you log into on a subdomain. The CMS is part of your codebase.

That single decision cascades into everything. A frontend developer can build a custom input component for the Studio in an afternoon, using the same tools they use for everything else. Need a colour picker that enforces brand tokens? A rich text editor that knows about your component library? A media field that pulls licensed images directly from Unsplash without the editor leaving the Studio? These aren't feature requests you raise with a SaaS vendor. They're components you write. I've shipped the Unsplash integration on my own portfolio, and it took less time than configuring a comparable workflow in any managed platform I've used.

Then there's GROQ. Most developers encounter it and assume it's a proprietary query language bolted on for differentiation. It's actually a rethink of the query model itself. In SQL and most REST or GraphQL abstractions, you query against a table or a type and shape the response after the fact. GROQ inverts this: you query from the document outward, and projections let you define exactly the shape of the data you need at the point of querying. No over-fetching. No n+1 problems hiding inside a clean-looking abstraction. Independent developers who've used it in production consistently describe it as a productivity multiplier once the team is past the initial ramp — capable of joins, filters, and projections that would require multiple REST requests in other systems. The first time a frontend developer uses GROQ to pull a document with precisely the fields they need, in exactly the structure the component expects, it's one of those quiet moments where tooling stops feeling like a compromise.

The infrastructure underneath all of this is worth a mention, even if it's not the most exciting part. Sanity's API CDN caches content queries at the edge, meaning reads are fast globally without you configuring a caching layer. The asset pipeline handles images and files with the same approach. For teams serving multiple markets or multiple consumers from the same content source, that's meaningful. The performance infrastructure is just there.

One platform, multiple configurations

One thing that took me a while to articulate properly is that Sanity doesn't ask you to commit to an architectural style upfront. That flexibility is genuinely unusual, and it's worth being concrete about what it looks like in practice.

At the simpler end, a marketing website for a single product or brand maps naturally onto a page-based structure. You model pages, sections, reusable components. The schema is straightforward, the editorial experience is familiar, and Sanity performs well without asking anything exotic of the team. Even here, GROQ and the typed schema are already better than most alternatives, but the lift isn't high.

Move up in complexity to a team running both a web product and a mobile app from the same content source, and the content lake model starts earning its name in a different way. You model content once, articles, products, team members, whatever is relevant, and both consumers query it independently, shaping the response to their own needs through GROQ projections. There's no content duplication, no sync jobs, no risk of the app and the website drifting apart. The web team and the app team work from the same source of truth without coordinating on structure.

Push further into multi-brand or multi-market territory, a platform serving several distinct editorial experiences from a single shared content layer, and the architectural decisions made early start to compound visibly. PUMA is a useful example: a global sports brand that replaced independent regional CMSes with a single Sanity instance, shared across markets, with custom-tailored Studios for each team drawing from the same content lake. The result was over 500 landing pages, 55,000 pieces of reusable content, and a content platform that a single developer can deploy to any environment in five minutes. That kind of setup would be a bespoke engineering project on most platforms. In Sanity it becomes a modelling problem.

The point isn't that Sanity is the right choice across all three scenarios. It's that the same platform can accommodate all three without forcing you to choose a lane at the start and penalising you for changing it later.

The Studio is a platform, not a product

Most CMS products give you an interface and let you configure it. Sanity gives you a React application and lets you build with it. The distinction matters more than it might sound.

The custom dashboard is a direct expression of this. You're not choosing from a set of widgets or configuring a layout through a UI. You're composing React components that render whatever is most useful to your editorial team: recent drafts, publishing workflows, content health metrics, a view of what's scheduled for the week. I've built dashboards that surface things no off-the-shelf CMS would let you expose, because the dashboard is just code.

The plugin ecosystem extends this further. It's growing steadily, and the developer community around Sanity has the rare quality of being genuinely useful rather than just large. The Sanity team themselves are visible in it, which tends to keep the signal-to-noise ratio reasonable. Plugins aren't workarounds. They're first-class extensions of the same model the Studio itself is built on.

Then there's the collaboration layer, which in my experience is where editorial teams feel the difference most directly. Multiple editors can work on the same document simultaneously, with each other's presence visible in real time. Revision history is built in. The Presentation tool ties this together in a way that's worth describing precisely: it shows editors a live preview of their content rendered in the actual frontend, updating as they work, but it also surfaces where any given piece of content is used across the site. If you're editing a component that appears on fourteen pages, you can see that. That's content usage visibility, and it's something most CMSs handle badly or not at all. What's notable about how it was built is that it doesn't compromise the underlying architecture to deliver a visual editing experience. It composes on top of it. The foundation didn't change; a new capability was added without requiring a rethink of anything fundamental.

The AI dividend, and why it wasn't an accident

Content that's well-structured in Sanity turns out to be exactly what AI tooling wants to work with.

Most CMS content, even from platforms with good reputations for structure, ends up with fields that contain unstructured HTML, rich text blobs that carry implicit formatting decisions, and references that aren't consistently resolved. Feed that to a language model and you're doing cleanup work before you can do anything useful.

A well-modelled Sanity schema is typed, relational, and portable. Every field has a declared type. References between documents are explicit. There are no HTML blobs unless you deliberately reach for the rich text field, and even then, the portable text format Sanity uses is structured JSON, not serialised HTML. Teams that modelled their content carefully a few years ago got AI readiness largely for free. Teams that didn't are refactoring now. loveholidays built an AI translation pipeline on top of their Sanity content layer that cut their translation costs by 97% and reduced new market launch times from months to days. That outcome isn't available to teams whose content lives in unstructured blobs.

Sanity has also moved quickly on native AI integration. Connectors to the major language models are available directly as Studio plugins, meaning editors can work with AI-assisted content generation, summarisation, or translation inside the editorial environment without bolting on an external workflow. Having tested the AI connectors, the integration is direct enough to be genuinely useful rather than a checkbox feature. The connectors fit naturally because the architecture was always open. Adding them didn't require rethinking anything fundamental.

What it costs you

None of this is free, and it would be a disservice to make it sound like it is.

Schema design is architecture. The flexibility that makes Sanity powerful is the same flexibility that lets a team build a content model that's inconsistent, under-documented, and painful to extend six months in. Without someone treating content modelling as a genuine architectural decision, thinking through document types, reference patterns, naming conventions before the first field is written, you can end up with a schema that's harder to untangle than the constraints of a more rigid CMS would have been. The platform doesn't cause that problem, but it doesn't prevent it either. If there's no one on the team who's going to own that thinking, it's worth naming the risk before you start. And if developer turnover is high, that risk compounds: Sanity's schema-in-code model and GROQ queries carry institutional knowledge that's harder to transfer than a more standardised platform's configuration UI.

Editor experience also needs deliberate investment. Out of the box, Studio is sparse. Non-technical editors used to more polished managed platforms will find it clean but unfinished-feeling. Field groupings, validation messages, custom previews, input components that match the editorial team's actual mental model of the content: these need to be built. It's a consequence of the platform being a foundation rather than a finished product, not a flaw. Budget for it.

On choosing tools with a long view

I've been working with Sanity long enough to have watched it mature through several phases, from a tool that needed explaining to one that increasingly doesn't. That history gives me a perspective on it that I wouldn't have from starting recently, but the reasons I'd recommend it now are the same ones I'd have given in 2019.

The tools worth betting on are the ones with a coherent architectural position, not just a better feature list. Sanity was always explicit about where its responsibility ended and yours began. That clarity is what made the plugin ecosystem possible, what made the AI integrations fit naturally, what made the Presentation tool feel like an extension of the original idea rather than a pivot. A consistent bet, held over time, compounds into capabilities that would have been impossible to retrofit.

The question for any tool you're evaluating isn't whether it solves today's problem. It's whether the decisions baked into it are the kind that age well. Sanity's have.