Hacker News Reader

Comment by mjlawson | Hacker News Reader

Personally, and I totally recognize that I'm likely arguing a moot point, I don't conflate static-site generation and server-side rendering and I don't think they can or should be used interchangeably as the author indicates. If my site can be hosted by Nginx alone, it's not server-side rendering to me.

On the other hand, if I am paying for the overhead of running a node server to host my site, but it doesn't support this, why not? I'm very suspicious of the argument that it's to save time due to on-the-fly render costs.

It seems that Remix and perhaps React's new server-side components will be solving this problem in a much more coherent way without requiring weird hacks like this.

View on HN

In the Next.js/Vercel world, this hybrid architecture is primarily (I believe) an issue of cost savings (for them and you). For $20/mo Vercel will host your hybrid Next.js side, yet do all of the backend configuration and maintenance on your behalf, configuring not just NPM but Lambda and Cloudflare Workers, along with nginx and caching and CDN mirroring and invalidations, all seamlessly.

So as a dev you can just code against the Next.js docs and not have to play devops. That's a LOT of time savings for $20/mo, and you can afford way more page hits this way than a barebones $20/mo NPM VM would get you. Yes, backend it's super complex and fanned out to different providers, but Vercel manages all of that for you.

I imagine Gatsby and Netlify are similar, but not sure. Next.js was designed around Vercel specifically (sadly) and there's a lot of vendor-specific lock-in features.

I completely get that this ease of configuration is a huge selling point. Yet I don't think that precludes the possibility of pre-loading information and injecting it at runtime. My main qualm here is probably one where the meaning behind terms like "server-side rendering" are drifting to favor artificial limitations imposed by framework providers.

> Next.js was designed around Vercel specifically (sadly) and there's a lot of vendor-specific lock-in features.

I ran into this while playing around with their middleware. It surprised me that native Node APIs weren't supported which significantly diminishes its utility.

> Yet I don't think that precludes the possibility of pre-loading information and injecting it at runtime.

Can you explain?

Reply on news.ycombinator.com