[colinclerk]

Server Components make server-side rendering wayyyyy easier for React developers.

With SSR today, developers need to take a `request` object and preload all the data necessary to render the page _before_ any component logic runs.

This is a huge pain because React components often have conditional branches inside them. Developers are forced to predict which branches need to have data preloaded, and then non-trivially pass the preloaded data into the component tree.

Look at how useSWR (a popular data fetching library) supports SSR...you preload the data and pass it in as "fallback" data. Notably, the fallback data is loaded BEFORE React starts running in a server-rendered environment. That's because React doesn't allow asynchronous actions during server-rendering - it must be available before React computes the initial HTML:

https://swr.vercel.app/docs/with-nextjs#pre-rendering-with-d...

With React's new <Suspense>, the ugly SSR ergonomics disappear. Suspense allows data to be awaited during rendering, instead of it needing to be preloaded out-of-band.

This means that code for data loading can be contained completely within the relevant component, and not also duplicated within SSR preload functions.

(It also kills the primary use-case for useEffect(), which IMO is the least ergonomic hook.)

What's interesting is that <Suspense> solves ergonomics issues in both server- and client- environments - which muddies the answer to your question a bit...

Server Components are guaranteed to become the standard for developers who need SSR (ecommerce is certainly one use-case, since they want SEO).

Whether Server Components _also_ become the standard over Client Components remains to be seen. But that's purely a question of performance, not ergonomics. The decision may end up completely abstracted away from the developer via something like Next.js.

[rglover]

> Server Components are guaranteed to become the standard for developers who need SSR

I sincerely hope not. This is a serious detour from how web apps inherently work. Not good because it means people who start with React—likely a large number of devs—are not going to understand how the web works (and will potentially create destructive messes themselves later).

I was able to solve this problem in my own framework with way less hoop jumping: https://github.com/cheatcode/joystick.

What you describe seems like a ton of overhead for what is effectively sending some data-populated HTML, CSS, and JavaScript back to a request. Perhaps I'm misunderstanding something (or it's just an idiosyncrasy of React).

[sergiomattei]

> Not good because it means people who start with React—likely a large number of devs—are not going to understand how the web works (and will potentially create destructive messes themselves later).

You could say that about any abstraction. Frameworks, cars, etc. It couldn't be furthest from the truth.

[rglover]

You can design abstractions in a way that doesn't remove the fundamental concept from the workflow. So, no, sorry.

I used to buy this line of thinking but having done the work myself, it's clear there's a serious lack of thinking before doing. Having worked with React since the early days (~2015) and watching its evolution, these ideas stick sheerly out of popularity, not coherence or clarity (read: the changes over the years have been degenerative, not additive—the original React was clear).