Bilingual

React for Two Computers — overreacted
15 hours ago
- The article explores the conceptual differences between function calls (verbs/recipes) and tags (nouns/blueprints), showing how tags represent potential computations that are passive and open to interpretation.
- It introduces a framework for splitting computations across time and space, using 'Early' and 'Late' worlds to represent distributed computation across two computers, with tags serving as a bridge between them.
- Key concepts include 'Components' (capitalized functions that embed rather than introspect arguments) and 'Primitives' (lowercase functions that require eager evaluation), along with mechanisms like 'import tag' and 'import rpc' for crossing computer boundaries.
- The article demonstrates how to split a React-like program into Early and Late Components, with interpret() dissolving components outside-in and perform() handling primitives inside-out, enabling client-server architecture without traditional network calls.
- It concludes with advanced ideas like 'use client' and 'use server' directives, streaming execution, stateful Late worlds, and caching, showing the practical implications for React Server Components and modern web development.
Impossible Components — overreacted
15 hours ago
- React Server Components allow splitting a component into a backend part (data loading) and a frontend part (interactivity), enabling self-contained ‘impossible components’ that span both computers.
- Data flows from the backend (server) to the frontend (client) as props, preserving React’s top-down data flow and ensuring the backend is the source of truth.
- This pattern supports local state and local data isolation: each component instance manages its own data and state without coordination, enabling independent reuse.
- Props from the backend can be used later on the frontend for interactive behaviors (e.g., event handlers), not just initial HTML rendering.
- Beyond simple values, props can include arrays, objects, or JSX, allowing components like sortable or filterable lists to be composed from backend data and frontend logic.
- The ‘use client’ directive marks frontend components that rely on state or effects, while backend components use server-only APIs (filesystem, ORM, etc.).
- Composing backend and frontend parts into self-contained blocks (e.g., <PostPreview>) lets developers build interactive UIs in a single roundtrip, without extra requests.
- The division between frontend and backend is physical but composable tools enable a unified component model that matches how users perceive UI chunks (sections, cards, lists).
- Future possibilities include adding mutations via ‘use server’, dynamic per-request filtering, or loading placeholders directly from backend resources.
Functional HTML — overreacted
15 hours ago
- This article reimagines HTML as a functional, programmable language by introducing custom tags via JavaScript functions that run on the server during serialization.
- Objects can be passed as first-class values to tags, and the primary output format is a JSON tree instead of traditional HTML, allowing richer data representation.
- Async server tags are supported with await, making data fetching part of the HTML structure.
- Client References (via 'use client' directive) enable sending code to the client, representing a first-class script tag.
- Server References (via 'use server' directive) allow clients to call server functions, acting as a first-class fetch API.
- Client Tags are server-encountered references that defer execution to the client, enabling full-stack components.
- Full-Stack Tags compose server and client tags, creating components that span both environments with encapsulated logic.
- Streaming is supported with placeholders for intentional loading states, avoiding page jumps.
- The JSON output format facilitates efficient caching by separating data from code, enabling cacheable partials with dynamic holes.
- The article concludes that this design effectively reinvents React Server Components as a functional, composable version of HTML.
RSC for Astro Developers — overreacted
15 hours ago
- Astro Components (.astro) run server-side only, cannot be interactive; Client Islands (React, Vue) handle interactivity, but cannot nest Astro Components.
- React Server Components (RSC) use a similar mental model: Server Components and Client Components separated by 'use client' directive, with no syntax distinction between worlds.
- RSC allows components to be imported from either side if they use no server- or client-specific features, making boundaries fluid.
- RSC solves Astro limitations: fractal islands (nested interactivity with context), SPA-like navigation without full page reloads, and refreshable server parts in-place.
- RSC outputs React trees (HTML or JSON), enabling composable server-client interleaving, while Astro outputs HTML with a one-time handoff model.
- RSC is lower-level (Next.js or Parcel RSC implement it), while Astro is a framework; Astro may offer a gentler onramp to similar concepts.
One Roundtrip Per Navigation — overreacted
15 hours ago
- Traditional HTML apps fetch all data in a single roundtrip by embedding data in the HTML itself.
- Client-side REST APIs often require multiple fetches per page, leading to client/server waterfalls and inefficiency.
- Colocating data fetching inside UI components (e.g., via `useEffect` or queries) worsens waterfall problems and makes optimization hard.
- Client loaders (e.g., React Router's `clientLoader`) reduce waterfalls but sacrifice colocation of data requirements with components.
- Server loaders (e.g., `getServerSideProps`) restore single-roundtrip efficiency and server-side optimization levers, but still lack colocation.
- Server Functions (e.g., TanStack or React Server Functions) enable colocation again but reintroduce client/server waterfalls.
- GraphQL Fragments achieve both colocation and single-roundtrip loading by composing data dependencies at build time.
- React Server Components (RSC) combine the efficiency of server loaders with colocation, ensuring one request per navigation and no client/server waterfalls.
Why Does RSC Integrate with a Bundler? — overreacted
15 hours ago
- RSC integrates with bundlers to efficiently serialize and deserialize modules, avoiding code duplication and network waterfalls.
- The RSC implementation consists of two internal packages: react-server for serialization and react-client for deserialization.
- Bundler-specific bindings (e.g., for Parcel, Webpack, Vite) handle 'use client' entry points and module resolution.
- Bundlers enable efficient loading by pre-bundling code into chunks, reducing the need for per-file network requests.
- The process involves serializing server-side output and deserializing it on the client to revive interactive components like JSX.
RSC for LISP Developers — overreacted
15 hours ago
- LISP treats code as data through quoting, allowing code to be unevaluated and manipulated as a first-class primitive.
- React Server Components (RSC) use a 'use client' directive to quote client code from the server, treating it as opaque data similar to LISP quoting.
- RSC enables composing server and client behaviors modularly, with server parts guaranteeing single roundtrip execution and progressive streaming.
- RSC is less powerful than LISP quoting because evaluation is prescribed by React, lacking metaprogramming for transforming code.
- LISP has richer solutions for multi-environment code composition, like Electric, which are less familiar to JavaScript developers.
How Imports Work in RSC — overreacted
15 hours ago
- React Server Components extend the JavaScript module system to manage the client/server split using 'use client' and 'use server' directives.
- JavaScript modules are singletons—each module executes at most once, preventing code duplication and ensuring private state is retained.
- Sharing code between backend and frontend involves two independent module systems; reused code exists separately in each environment.
- Build failures from incompatible code (e.g., using 'fs' on the frontend) are beneficial as they force developers to resolve conflicts early.
- 'server-only' and 'client-only' poison pills act as markers that fail the build if the module is pulled into the wrong environment, propagating transitively.
- The 'use client' directive creates a door to the frontend, allowing backend code to refer to frontend modules without bringing them into the backend.
- The 'use server' directive creates a door to the backend, allowing frontend code to refer to backend modules without bringing them into the frontend.
- Together, these mechanisms let developers treat an RSC application as a single program spanning two computers with independent module systems and controlled data passing.
Introducing RSC Explorer — overreacted
15 hours ago
- RSC Explorer is a browser-based tool that visualizes the React Server Components (RSC) protocol, built using the same packages React uses for reading and writing the protocol.
- The tool demonstrates key RSC concepts like streaming async components, server actions, and router refresh without a framework, helping developers understand the protocol under the hood.
- It includes examples such as a simple Hello World, an async component with Suspense, a counter with client components, a form action using 'use server', and a router refresh that preserves client state.
- RSC Explorer runs entirely client-side (server runs in a worker), simulating RSC communication without network requests, and allows embedding snippets on other pages.
- The increased interest in RSC followed a critical security vulnerability disclosure, prompting the creation of this educational tool.

Hasty Briefsbeta

react server components

React for Two Computers — overreacted

Impossible Components — overreacted

Functional HTML — overreacted

RSC for Astro Developers — overreacted

One Roundtrip Per Navigation — overreacted

Why Does RSC Integrate with a Bundler? — overreacted

RSC for LISP Developers — overreacted

How Imports Work in RSC — overreacted

Introducing RSC Explorer — overreacted