(I didn't find disabling SSR straightforward.)
I wonder if Vercel is underestimating the size of the market that just wants a "Heroku for React".
We often see folks wanting a mix of both. For example, maybe the /about page is static, but the home page is dynamic and personalized based on the visitor. You can do all of this with Next.js. Our future direction is adding even further granularity, enabling this decision at the data fetch level, allowing you to cache results across deployments[3].
[1]: https://beta.nextjs.org/docs/rendering/edge-and-nodejs-runti...
[2]: https://beta.nextjs.org/docs/rendering/static-and-dynamic-re...
I initially fought to get SSR working, fixing hydration errors and making sure our code was isomorphic.
I later realized that I can just use the parts of Next.js we need and turned off SSR. It wasn't a big value add for our particular product.
But doing this wasn't straightforward. I hadn't even realized it was a possibility until I stumbled across a blog post.
I had to copy a NoSSR implementation of the internet. It wasn't just some flag I could toggle for a page.
I've also found myself recommending Next to folks saying "Use Next.js, but btw you don't need use SSR. Make sure the trade-offs make sense."
I'm curious if I'm in the minority of Next.js users. What percentage of them don't need SSR but value everything else?
I feel like Next.js is in a similar position. While their main vision is SSR, I wonder if they are missing out on a chunk of the market that simply doesn't want to think about infra. We use them because we just don't have to worry about webpack or fiddling with deployment and hosting. We could care less about SSR and in fact we disabled it app-wide.