[rglover]

Thank you for sharing your talk.

Not on you, but this move (to RSC) looks like an absolute mess. All you're trying to do is render some HTML, CSS, and JavaScript to the browser. This is over-engineering at its finest. Looking at the demo repo gave me the shakes.

[fny]

For time to first paint, it's a strategy that's wildly effective. Github render_async and Rails Turbolinks are two other proven implementations.

[rglover]

Okay, but what problem is that solving? This all looks like a solution chasing a problem. The only concrete case I can come up with is delivering content to users with high latency issues (e.g., closest data center is too far away) or slow network speeds.

In that scenario, reducing bundle size and network requests can achieve a comparable (if not better) result while preserving code ergonomics. Speaking at least to the demo repo linked above, it looks like API ergonomics were an afterthought and pleasing the benchmark was first priority.

[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).

[vittore]

reminded me of https://www.youtube.com/watch?v=bzkRVzciAZg

[fny]

Reducing bundle size and network requests is not always possible in todays package happy world. Someone will figure out ergonomics, maybe not through this package, but someone definitely will.

[rglover]

And the above solution is going to further incentivize package-happy thinking, not remove it.

And yes, you always can but that doesn't mean people will. It requires time, effort, and thought which sadly seems to be absent (or people just don't care enough to do it).

I know that sounds mean but this sort of stuff is driving web dev off a cliff unnecessarily.

[eyelidlessness]

For what it’s worth, 3/4 of the time I interrupt GitHub’s router for a full page load because it’s drastically faster (on my devices, on my network, YMMV of course).