-
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.
-
Puter.js
Puter.js - The Backend for AI-Generated Apps. One-shot full-stack apps with your existing AI coding tool. Puter.js gives you Auth, Storage, DB, AI & more, with up to 90% fewer AI tokens than other backend platforms.
-
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 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.
Related posts
-
How to find a Next.js memory leak in production
-
Next.js 16 proxy.ts Migration: From middleware.ts
-
Scarab Diagnostic Suite Field Test #012: Next.js Source Map Provenance Boundary
-
Scarab Diagnostic Suite Field Test #008: Next.js Image Optimizer Resource Boundary
-
Ops Assist: AI-Powered Manufacturing Troubleshooting with Gemma 4