Server Components were research, and that mattered

On December 21, 2020, the React team shared its research into “zero-bundle-size React Server Components.” The announcement included a talk, a demo, and an RFC. It also said plainly that the work remained in research and development.

The idea was immediately compelling. A component could execute on the server, read data close to its source, use server-only dependencies, and contribute to a React tree without sending its implementation code to the browser. Interactive Client Components could remain in the same experience.

I wanted the result for D4U7: less client JavaScript, fewer data-fetch waterfalls, and one component model across the server–client boundary.

I did not adopt Server Components in D4U7 in 2020. The honest work was to understand which architectural questions the research had exposed and which implementation promises did not exist yet.

“Zero bundle size” applied to server-only code

The headline did not mean a React application would ship zero JavaScript.

Code and dependencies used only by a Server Component would not enter the client bundle. That created a meaningful opportunity. A Markdown renderer, date formatter, or data transformation used only to produce non-interactive output could remain on the server. The browser received the result needed to compose the tree, not the implementation library.

Client Components still required browser JavaScript for state, effects, event handling, and platform APIs. Their dependencies still counted. A product that placed every existing component on the client side would not receive the headline benefit by naming a few server files.

The boundary therefore made bundle cost an ownership question. Which parts of the experience genuinely needed to execute after delivery? Which logic existed only to turn server data into a view?

I wrote an inventory for D4U7 rather than a migration plan. The room brief and immutable decision history were plausible server work. The editor, offline outbox, conflict resolver, focus management, and live updates remained client concerns.

The research offered a sharper question, not free deletion of the bundle.

D4U7 already rendered useful HTML on the server. The browser then loaded React and hydrated the interactive application. Server rendering improved first display and resilience, but the component implementation used for hydration still belonged to the client bundle where interactivity required it.

The RSC proposal introduced a different layer. Server Components executed only on the server and produced a serialized representation React could combine with Client Components. Their code did not need to hydrate in the browser because it never became browser code.

The model could coexist with HTML server rendering. One concerned which components executed where and what representation crossed the boundary. The other concerned producing initial HTML for a navigation.

Conflating them would create false expectations. Rendering a component to HTML on the server did not automatically make it a Server Component. Likewise, a Server Component payload was not simply an HTML fragment to insert without React's component semantics.

In December 2020, these distinctions were part of the research surface. I avoided describing a complete production stack the announcement had not supplied.

Data access moved into rendering

The proposal showed Server Components reading from server-side data sources during rendering. That could remove a familiar sequence:

1. Render a client shell.
2. Download and execute its JavaScript.
3. Start an effect or client data request.
4. Reach an API endpoint.
5. Fetch data again on the server.
6. Return it and render the meaningful view.

For a room overview, server-side component data access could place the query near PostgreSQL and send only the UI result required by the client tree. It might also avoid building one API shape solely to feed one component.

The convenience did not remove architecture. Authorization, query composition, caching, transaction boundaries, failure behavior, and input validation still needed owners. A component reaching a database directly could become a new form of scattered data access if every leaf invented its own query.

I sketched a server data boundary that exposed room projections and immutable revisions through domain functions. A Server Component could call that boundary; it would not contain ad hoc SQL because the transport layer had changed.

Moving data access closer to render reduced one kind of distance and made query discipline more important.

A server–client boundary was a serialization boundary

Values passed from a Server Component to a Client Component had to cross a protocol. They could not be treated like arbitrary in-process objects.

That raised familiar questions:

• Is the value serializable by the current experimental format?
• Does it contain a secret or field the browser should never receive?
• Is its identity stable enough for reconciliation?
• How large is the payload after repeated or nested data?
• Does the client need the value, or only server-rendered output derived from it?
• What happens when the server and client builds disagree about the component reference?

D4U7 had rich objects: database records, Markdown source, authorization context, evidence links, and revision metadata. Passing an object to a Client Component would become data disclosure, not merely a convenient prop.

I wrote boundary types for the thought experiment and found several fields the existing client API already sent unnecessarily. The research improved the current architecture before any RSC code existed.

Component composition did not abolish the need for a deliberate wire contract.

It was easy to imagine a mostly server-rendered room with a few tiny interactive controls. The actual client boundary could spread.

The editor needed draft state, IndexedDB, outbox delivery, conflict recovery, and authentication transitions. The timeline needed live updates and focus-safe announcements. A decision control needed current room revision and authority. Passing all of that through one high-level Client Component could place most of the page back in the client bundle.

Conversely, making every button a separate client boundary could fragment state and repeat serialized data. The number of boundaries mattered less than the ownership they expressed.

I mapped client responsibilities by capability:

• Local durable intent and sync.
• Browser-only accessibility behavior.
• Live update continuity.
• Interactive filtering and navigation state.
• Commands requiring current client context.

Non-interactive room projection and historical rendering could remain server candidates. The map was useful regardless of whether RSC matured. It identified where the browser genuinely contributed rather than treating “frontend” as one location.

Server-only code changed dependency choices

The zero-bundle promise made heavier server-only libraries less costly to browsers. That did not make their server cost irrelevant.

A Markdown pipeline excluded from the client bundle still consumed server CPU and memory. A data library still affected cold start, deployment size, and supply-chain review. Rendering the same result repeatedly could create server load that a cached client asset had avoided.

The cost model shifted:

client JavaScript saved
versus
server execution + serialized output + cache complexity + request latency

For mostly static content, build-time rendering might remain simpler. For personalized current room state, server execution could make sense. For a highly interactive editor, client code remained necessary.

The research did not declare server execution universally cheaper. It allowed a dependency to stay out of the browser when its result, rather than its implementation, was all the client needed.

I kept bundle budgets and added hypothetical server-render budgets to the architecture note. Cost had moved; it had not vanished.

Refetching raised identity and state questions

The proposal aimed to let the server tree update while preserving relevant client state. That was one of its most interesting promises for D4U7. A room projection could change without rebuilding every interactive island from scratch.

The promise depended on stable component and data identity. If a server response changed tree shape or keys carelessly, client state could reset or attach to the wrong conceptual object. If an editor held a local draft while the server sent a newer contribution revision, preservation of React state alone would not resolve the domain conflict.

D4U7 already separated server projection, local draft, and outbox operation. Any future RSC adoption would have to preserve those boundaries. A server refresh could update the current room revision while the client editor retained its draft and entered explicit reconciliation.

“Preserve client state” was a rendering capability, not a collaboration merge strategy.

I added a scenario to the research note: server room moves from revision 31 to 38 while a client draft remains based on proposal revision 4. The correct outcome was still the three-way conflict model, regardless of transport.

New rendering architecture did not get to overwrite local intent.

The RSC research described a representation that could be streamed, allowing parts of the server-rendered tree to arrive as they became ready. Progressive delivery fit the direction React had been exploring.

Streaming can improve time to useful content and can also multiply partial states. A room page with heading, brief, decision summary, evidence, and history needed a stable hierarchy even while later regions loaded.

I identified boundaries by independent value:

• Room identity, title, and access outcome should establish the page.
• Current decision state should not wait for historical search.
• Evidence previews could arrive later without moving active controls.
• Long history could stream or paginate behind a stable landmark.

The interface needed reserved layout, error states, and accessible announcements. A sequence of spinners would not become good streaming merely because the server delivered chunks.

In 2020 I did not claim an RSC implementation of this plan. The exercise left me with a narrower rule for later streaming experiments: reveal meaningful stable structure, not transport progress.

Failure crossed a less familiar protocol

An API request has familiar boundaries: status, headers, body, timeout, retry, and cache policy. Server Components proposed a React-specific payload and bundler integration whose production failure modes were still being explored.

I listed questions the demo could not answer for D4U7 yet:

• How would a partial server render report authorization failure?
• Which parts could retry without repeating expensive data work?
• How would deploys keep server component references compatible with loaded clients?
• What would offline navigation show if no fresh RSC payload was available?
• How would errors map to stable accessible recovery regions?
• Which response could be cached, for whom, and under which revision?
• How would the client inspect or log a malformed payload without leaking content?

These were not objections to the research. They were the work between a compelling model and a maintained personal application.

The explicit research label gave permission to ask them without pretending the answers were already standardized.

The model depended on tooling understanding which modules belonged to the server or client and how client references entered the payload. This was deeper integration than adding a runtime library.

D4U7 used a deliberately simple build and service-worker asset manifest. An experimental RSC stack would change chunk identity, server build output, deployment compatibility, and the worker's update contract.

I would need to know:

• How server-only dependencies were excluded from browser output.
• How client component references mapped to immutable assets.
• How old clients behaved across a new server build.
• Whether a rolling deploy could serve mixed protocol versions.
• How the release manifest represented both sides.

The 2020 demo was a valuable research artifact, not a stable interoperability guarantee. I kept it in a separate experiment rather than threading its build assumptions through D4U7.

This restraint protected the service-worker boundary I had just simplified. A new rendering model was not worth making update recovery opaque again.

Security improved only if the boundary stayed explicit

Keeping database credentials and server-only libraries out of the browser was an obvious benefit. Direct server data access could also make it easy to pass more data than a client should receive.

Authorization had to occur before sensitive projection. Serialized props needed review as outbound data. Error messages could not include query details or hidden content. Client-triggered server rendering still consumed untrusted parameters.

I treated the hypothetical Server Component like an authenticated read endpoint with a component-shaped output. The same access rules and evidence applied. A stable room URL was not authorization. A server render for one participant could not enter a shared cache under an incomplete key.

The browser should receive only the fields required for its interactive responsibilities. Server-only execution reduced code disclosure; it did not guarantee data minimization.

The narrow component boundary could make security review easier if its contract remained inspectable. Hiding the wire format behind familiar JSX could make it easier to forget that a wire existed.

D4U7 needed provisioned room state, immutable revisions, local drafts, outbox operations, and update-safe code while disconnected. Server Components did not remove that requirement.

A server-rendered tree could provide an efficient online current view. An offline client still needed a versioned local projection and explicit stale state. Client Components still owned drafts and delivery policy. A cached server payload, if supported later, would need room revision, account scope, and application compatibility.

I would not put RSC responses into a generic service-worker stale-while-revalidate cache and call the application offline. That would repeat the mistake from August in a newer format.

The architecture note treated RSC as one online rendering and data-delivery path inside the larger client-replica model. Resume, authentication, conflict, and outbox logic remained.

A new server boundary can reduce JavaScript and waterfalls. It cannot make a disconnected browser current.

I cloned and studied the public demo separately. I traced which code executed on the server, which client components remained interactive, and which dependencies disappeared from browser output. I altered one small data path to see how the serialized tree and client reference behaved.

The experiment established that the model was real enough to learn from. It did not establish operational compatibility with D4U7, stable APIs, performance on the project's workload, or a support timeline.

I wrote findings in three columns:

• Demonstrated: server-only component code and dependencies can stay out of the client bundle in the research stack; server and client components can compose.
• Promising: fewer client fetch waterfalls, closer data access, streamed updates, preserved client interaction.
• Unresolved for this project: bundler and deploy contract, caching, offline behavior, authorization boundaries, error recovery, and API stability.

This prevented interest from becoming retrospective adoption. The archive could say what I understood in December 2020 without claiming I had shipped a later framework.

Research status was information

Software culture often treats an early announcement as a race. The first demo becomes an adoption signal; caution looks like falling behind.

The React team had done something healthier: shared the direction, implementation, and RFC while explicitly saying the work remained research and development. That status described expected change and invited feedback.

For my project, it changed the correct action. I could evaluate concepts, test boundaries, and improve current architecture without taking a dependency whose production contract was unsettled.

I recorded review triggers:

• A framework I already trusted provides a supported integration.
• The server/client module and deployment contracts stabilize.
• Offline and rolling-version behavior can be tested under D4U7 scenarios.
• A measured bundle or data-waterfall problem justifies the migration cost.

Until then, server rendering, route-level code splitting, explicit data loading, and a narrow client application remained maintainable.

Waiting was an engineering decision with evidence, not indifference.

The idea changed my vocabulary immediately

Even without adoption, Server Components sharpened several beliefs.

“Frontend” did not have to mean browser execution. A component could own presentation while running near data. Client JavaScript was a cost to justify by interaction, not the inevitable destination of every view. Server and client boundaries could be expressed through composition rather than duplicating one entire application on each side.

It also reinforced older lessons. Boundaries need identities. Serialized data needs minimization. Deployment versions need compatibility. Cached state needs freshness. Local intent needs protection. A better rendering primitive does not settle product semantics.

Those ideas would return in the 2023 Server Components article after the ecosystem had a production-stable framework path. The later decision would be stronger because the 2020 note had not pretended the destination was already known.

A first look should preserve uncertainty

The December announcement deserved attention. It addressed real costs in React applications and proposed a distinct model, not a cosmetic API. The demo made the direction concrete enough to influence architectural thought.

Its research status deserved equal attention. Tooling, caching, security, deployment, offline behavior, and framework integration were part of the technology, not details to fill in after declaring adoption.

I ended 2020 with a component map and an experiment, not a migration. D4U7 continued using its known server-rendered entry and explicit client data boundaries.

React Server Components looked capable of moving the boundary. Research was the stage at which to understand that movement without claiming the ground had already settled.