And this is where things get hairy. The Next.js documentation is sparse. So you either get lucky and someone else has done the guesswork to figure out how to do the most basic things in Next.js (for example the transition from 12 to 13, aka pages-router to app router was ROUGH...you could only find SO issues related to 12 and all the libraries and structures you were used to had all changed in subtle ways).
Caching is another one of these things. There are fetch calls in some routes in my app that get cached no matter what. I've tried every which way to get the damn thing to stop them caching (the most obvious one being the no-store header), but to no avail. It caches and I can only get it to stop by redeploying. And no, purging cache from the Vercel dashboard doesn't fix it either. Only a redeploy will get me updated data from the DB. It's bizarre.
And so the story goes on. It's super easy to get up and running. There are many 'aha' moments, where you can see that a ton of work has gone into DX. So much so, that I really try to use Next.js where I can. However, when you run into problems, they are usually more difficult to solve than with React. And they are subtle and not infrequent.
Don't get me started on debugging. Since Next.js is sort of 'backend' to a large degree (which, in Google's and Cloudflare Page's case means edge-functions), trying to tease a meaningful log that isn't severely character-limited out of either service is very difficult. Error messages in the frontend are useless to an astounding degree.
So, it seems there's a lot of work to be done. Tread carefully, as it's very enticing to have this quick-start, but I'd hesitate to use this for anything too serious, as things will break for no reason and there will be issues that are nearly impossible to solve and I wouldn't want clients emailing me while I'm dealing with BS I simply wouldn't have had on any other stack.