Client render by default for non async components.

[clayrisser]

Goals

1. Make it easier to migrate existing code.
2. Keep the api more familiar to existing development patterns.
3. Remove having to put 'use client' everywhere.

Non-Goals

1. build a rocketship
2. the answer to the universe
3. the ultimate question to the answer 42

Background

It is my opinion that the 'use server' and 'use client' pragma's are very annoying. I feel like there should be a more intuitive way to distinguish between server and client components.

There already is a way to distinguish between most of them already. Most server components are asynchronous, so I believe that async components should be server components and non-async components should be client components by default.

If someone really wanted to use a synchronous server components, then the pragma would be required just as the pragma would be required if someone really wants to create an asynchronous client components, but these situations are less common.

This would remove the need for the annoying pragmas for 95% of client components.

Proposal

Really want to hear other people's thoughts on this.

[icyJoseph]

use client and use server are not pragma, as in h would've been, or React.createElement.

These are directives. The use client directive, indicates to a bundler, or compile step, whether or not, a module should be transpiled/transformed to be used on a client.

The use server directive, is meant to "escape hatch", from within a use client umbrella. Specifically, to be able to define code that lives on the server, but can be invoked from the client.

That is because by default, things don't need to be packaged for a browser environment, unless they use so called, interactivity, require client side state, among a few other requirements.

I understand the frustration of having to wrestle with a new paradigm, and feeling like everything accomplished so far is somewhat lost. There's tons of noise from tech-influencers, who have contributed to false expectations, confusion and mis-understanding about RSC.

Most server components are asynchronous, so I believe that async components should be server components and non-async components should be client components by default.

I've now written a whole bunch of apps, where very few things are client components. Since things by default are server components, that means that without putting too much thought into it, my bundles tends to be smaller.

Previously, even a simple <div />, would be shipped to the client. In RSC, you'd need to put the directive to make that happen.

The idea of Server Components being async, or only to fetch data, is quite simply, missing the forest, for the trees.

See this answer I gave before, on going from 0 to 1 in RSC:

• Client Vs Server Components #51914 (comment)

Surely, given an existing React tree, it might be cumbersome to migrate, and if you listen to all of the tech-influencer noise, you might feel overwhelmed.

To migrate existing code, you just need to opt a React tree into the client directive, and for that, you just slap the directive as high up on the React tree as you can. That way, import statements owned by this module, and in turn their import statements, etc... are all client bundles.

After that, should the compiler tell you that use client is missing somewhere, just slap it in.

This would remove the need for the annoying pragmas for 95% of client components.

The goal with Server Components is to reduce the amount of components that need to send their JavaScript to the client, not by 95%, but rather to extend the component spectrum, to a zero JS dimension, where certain components do not need to make the client side code heavier, and even better, have access to server side APIs.

Surely, you have to dust off you React knowledge about composition, and see that things can be slotted, for example using children props, and so, a component can be a parent of certain children, while still not having any knowledge about them. This is a killer pattern, to improve performance. This pattern, allows you to weave together, Server and Client components.

Also, having server side code, potentially interact with client available code, ought to have a security dimension at play, and so there's ways to poison modules, and even taint data, to accommodate security. In other words, it is better to be explicit about code that'll be send to the client.

I wish I could write more, but I am short on time, I am though, always open to answer and keep discussing, it is the only way to make these concepts stick and become proficient at them.

[clayrisser]

Some people don't want to shift to a new paradigm and others can't shift because of universal applications (react native etc . . .). It would be nice if this system was more compatible.

I wish there would be a guarantee that the old paradigm will never be abandoned, but given the history of the JavaScript ecosystem, I'm sure everyone will be left out to dry.