Next.js Nailed Developer Experience
Jamund Ferguson, senior engineer at PayPal, on using Jamstack in the enterprise
Next.js won by turning full stack React into a near zero context switch workflow. Instead of making a front end engineer learn servers, templates, deploy pipelines, and separate backend repos, it let the same person keep writing familiar React files while adding server rendering, API routes, and per page deployment choices when needed. That collapsed a messy handoff between frontend and backend into one mental model, which is why adoption spread so quickly.
-
At companies like PayPal and Amazon, the pain was concrete. Updating UI often meant redeploying large Node.js systems, waiting through slow releases, and dealing with crashes or spinner filled pages when static frontends had to fetch personalized data later. Next.js addressed that gap by combining Jamstack simplicity with built in server capabilities.
-
The key product choice was not novel infrastructure, but better defaults. Next.js made static generation, server rendering, and API routes feel like small code level decisions inside one app, instead of separate architecture bets. That is similar to how Vercel packaged AWS primitives into a workflow most teams would not build themselves.
-
This also explains why Gatsby lost momentum. Gatsby was stronger around large scale static generation and plugin heavy workflows, while Next.js looked more like plain React and let developers switch rendering modes with a small API surface. That matched how most React developers already wanted to work.
The next phase is deeper convergence between frontend frameworks and infrastructure. As edge functions, preview deployments, and integrated data services mature, the winning tools will keep hiding operational complexity while giving teams finer control over latency and personalization. That pushes the market toward platforms where building a fast global app feels as simple as shipping a React component.