There's some term confusion. "Static pages" is a different concept -- when there's no code executed on the server, server can only serve static content (no DB naturally), usually from a CDN that can cache responses. We're talking here about dynamic pages.
> a server component that grabs data from the database directly and render it.
Render where?
1. If it renders it to the html content for the browser, it's called "templating", and all the frameworks have been doing it for 20+ years (e.g. ASP, JSP, Jinja).
2. Render to the browser -- it still need to pass that data from server to browser, there's no way around it. And the idea of abstracting that, so the user would not know or care where the code is executed is not new at all. There were multiple attempts, for example see JSF, released on 2001. It burned in flames because you really want and need to know where the code is run.
And there never-ending attempts to at least write in the same language on server and browser, without abstracting the XMLHttpRequest (aka AJAX aka Fetch) layer. For example Node.js -- to use JS on server. Or GWT -- to use Java in browser (died, because you still absolutely want to know how it will be compiled to JS). Now Kotlin compiles to JS. Those are successful to a point. And the ultimate answer to bring all the languages to browser -- WebAssembly.
My point is -- all the attempts aiming to abstract away client-server boundary has been an utterly obvious failure. But if RSC does not aim to abstract it, then it's not different than technologies from 1999, but in Javascript.
There's some term confusion. "Static pages" is a different concept -- when there's no code executed on the server, server can only serve static content (no DB naturally), usually from a CDN that can cache responses. We're talking here about dynamic pages.
> a server component that grabs data from the database directly and render it.
Render where?
1. If it renders it to the html content for the browser, it's called "templating", and all the frameworks have been doing it for 20+ years (e.g. ASP, JSP, Jinja).
2. Render to the browser -- it still need to pass that data from server to browser, there's no way around it. And the idea of abstracting that, so the user would not know or care where the code is executed is not new at all. There were multiple attempts, for example see JSF, released on 2001. It burned in flames because you really want and need to know where the code is run.
And there never-ending attempts to at least write in the same language on server and browser, without abstracting the XMLHttpRequest (aka AJAX aka Fetch) layer. For example Node.js -- to use JS on server. Or GWT -- to use Java in browser (died, because you still absolutely want to know how it will be compiled to JS). Now Kotlin compiles to JS. Those are successful to a point. And the ultimate answer to bring all the languages to browser -- WebAssembly.
My point is -- all the attempts aiming to abstract away client-server boundary has been an utterly obvious failure. But if RSC does not aim to abstract it, then it's not different than technologies from 1999, but in Javascript.