Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

One of the key design choices of Next.js was to enable granularity on the runtime (Node.js or Edge[1]) and the rendering method (static or dynamic[2]) on a per-route basis. If you want a full SSR site, that's okay. If you want a full static site, that's also okay.

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...

[3]: https://vercel.com/blog/vercel-cache-api-nextjs-cache



What I love about Next.js is not having to think about hosting, webpack, hosting, typescript, scss, and so on. It just works.

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?


FWIW, not currently using Next.js, but I'm someone who values everything else but not necessarily SSR. I've been eyeing to use Next.js in SPA mode. There are dozens of us!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: