This isn’t something I’ve found with NextJS, but I also haven’t tried a lot of other, similar frameworks because I’m mostly a backend and SRE person who just learned NextJS so I could throw together pretty UIs to demo my backend ideas, so maybe I’m missing things that are well known among front-end specialists.

My experience is that a basic deployment is very easy—it’s like a ten line Dockerfile to build a distroless nodejs container of the standalone build and if you deploy it, it just works.

Then, as performance demands grow, there’s increasingly more complexity in the efforts that must be taken to squeeze additional performance out of it. An easy win is to host the static resources more efficiently with a static file server or better yet a CDN.

A more complex performance optimization is to implement caching.

At some point you start thinking about how to separate the middleware execution from the app so that it can be hosted in more regions or at the edge.

Vercel provides all of those optimizations for free in terms of operational complexity, and charges a lot for it monetarily, but it’s not all that surprising to me that when I host an application it takes some effort to get performance and feature parity with a dedicated hosting provider for that service, just like how I am not surprised that RDS is a little more complicated, more performant, and more reliable than renting the equivalent EC2 and installing Postgres from the package manager.

Caveat: as a backend dev, I’ve never written anything that relied entirely on NextJS as the server side, so I’m approaching this with a certain amount of baseline complexity already assumed. I’ve not touched NextJS static sites or incremental static regeneration.

Do other frontend frameworks make it much easier to incorporate those performance optimizations? My impression is that it’s not all that hard to deploy NextJS, it’s just hard to manage the complexity of optimizing it to the extent that Vercel’s hosting does.

Next.js is not difficult to deploy on a long-lived server. It’s just a normal Node app.

What’s more painful is deployment to other serverless providers because historically they’ve had to reverse-engineer a few details for more advanced features. This is being fixed now in https://github.com/vercel/next.js/discussions/77740 but that work is ongoing.

The difficulty to deploy Next.js is greatly exaggerated in my opinion. It's mostly if you care about some of the more advanced features, like image optimization and hosting static assets on a different origin it can become difficult, but these are features no Next.js alternative generally provide anyway.

Deploying next is difficult, but IMO that's because deploying anything substantial is difficult. I've had my share of nasty deployment debugging that took days and none of it was due to next. (the biggest offenders I've seen are (1) random open source software no one on my team is an expert on, (2) docker / kubernetes, (3) databases, and (4) integration hell)

It's what v0 and similar tools choose as default.

It’s as easy as deploying any other app that can be Dockerized. Deploying to something like Fargate isn’t _super_ trivial but can be done in <2 hours

Maybe it's difficult to deploy to your platform of choice. Deploying to AWS amplify or deploying using sst is matter of minutes or hour.

I have deployed several next.js projects within an hour (not hours) that were created by different teams. The hour includes settings up DNS, CI/CD using github and deploying to AWS Amplify.

Edit: Why are you down voting it? Is this unbelievable? I have deployed 5/6 next.js projects and none of them are on vercel.