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

> Vercel/nextjs are geared towards encouraging you to make everything static so that it does get served that way.

That would mean they have no reason to exist. If they're slower than a regular server for dynamic content and only as fast as a regular CDN for static pages, they're beaten by the old server + CDN combination.

The niche for rendering on the edge is really incredibly narrow. Take one step further and you have client-side rendering, take one step back and you're already on a server. I'm not surprised people have trouble finding use-cases, and when they do it often turns out they would've been better served by one of the two other solutions.



I'll have to disagree.

I use Next because it offers SSR plus the hydration step for a fully-fledged React app on client, and the ease with which you can pass stuff between the two. SSR for paint speed and SEO/bots/meta/whatever, and the rich client side app functionality that people expect these days. A traditional server-side-render-only approach doesn't make that as easy, IMO.

I use Vercel for the DX, mostly. I can copy an old project repo and have a fully functioning new project site up in literally 20 mins. Same reason people use Netlify.

Also, they're not necessarily slower for dynamic content. Only noticeably if you hit a cold start really. But that's just the normal serverless/Lambda caveat: in exchange for interventionless scaling, one request in n is a little slower during scale-up events. You can always put your next app on EC2/EB/etc if it worries you. I'm more pro-nextjs than pro-Vercel.




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

Search: