The author just doesn't get it.<p>> You can't really sell a service around SPAs: once compiled, a SPA is a single JS file that can be hosted for free anywhere. But a server-side rendered app needs a server to run<p>I hate to break it to the author, but if you're going to limit yourself to apps that don't need a server, you're going to limit yourself to only building toys. The real world is messy <i>because</i> you can't pre-compile all your data into your single JS file ahead of time. Real-world apps <i>need</i> data stored in some kind of database, and some kind of server sitting in front of that database to validate access and present it in a format that can be used by the frontend.<p>Now, you can build that out in a different language, in a different repository, by a different team, behind a formal, stable API. At a certain scale, that's even preferable. But when you're building new products, when you're trying to find product-market fit, the truth is, API design is just another distraction that doesn't help you build value and just delays you from getting to market. What React Server Components does is allow developers to avoid API design. Sure, that doesn't scale, but in the beginning, you should be doing things that don't scale. Leaving aside the point that, if we're being honest, most developers don't know good API design anyway.<p>And no, just because Vercel is taking React in a server-first direction, doesn't mean everyone is being forced into using Vercel for hosting. You can self-host NextJS anywhere you can run Node or Docker: <a href="https://nextjs.org/docs/app/building-your-application/deploying#self-hosting" rel="nofollow">https://nextjs.org/docs/app/building-your-application/deploy...</a> . Which you're probably hosting anyway, because again, in the real world, you need to put something between your frontend and your database. That thing just doesn't necessarily need to be an API.