Comment by hxtk

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.