Nothing can replace good engineering. Good engineering means using the right methods or tools for the given situation.

If you're fetching 10s of raw models (corresponding to a table) and extract (or even join!) the data needed to display in the view, it's clearly not the best engineering decision. But fetching 2 or 3 well shaped views in your component and doing the last bit of correlation to the view in the component is acceptable.

Same for deciding a render strategy: Traditional SSR (maybe with HTMX) vs. isomorphic (Next and friends) vs. SPA. Same for Redux vs MobX. Or what I think is often neglected by the frontend folks: Running Node on the backend vs. Java vs. Go vs. C# vs. Rust.

If you're already in the spot where React Server Components are a good fit, the ideas in the article are compelling. But IMO not enough to be convincing to switch to or chose React / Next when you're better of with traditional SSR or SPA, which IME are the best fits for the vast majority of apps.

RSC is indeed very cool. It also serves as a superior serialization format compared to JSON. For example, it can roundtrip basic types such as `Date` and `Map` with no extra effort.

One thing I would like to see more focus on in React is returning components from server functions. Right now, using server functions for data fetching is discouraged, but I think it has some compelling use cases. It is especially useful when you have components that need to fetch data dynamically, but you don't want the fetch / data tied to the URL, as it would be with a typical server component. For example, when fetching suggestions for a typeahead text input.

(Self-promotion) I prototyped an API for consuming such components in an idiomatic way: https://github.com/jonathanhefner/next-remote-components. You can see a demo: https://next-remote-components.vercel.app/.

To prove the idea is viable beyond Next.js, I also ported it to the Waku framework (https://github.com/jonathanhefner/twofold-remote-components) and the Twofold framework (https://github.com/jonathanhefner/twofold-remote-components).

I would love to see something like it integrated into React proper.

Hey, thanks for sharing "JSX Over the Wire"! As the creator of ts-liveview, I’m thrilled to see Dan’s ideas on server-side JSX rendering and minimal client updates—they mesh so well with my work.

ts-liveview is a TypeScript framework I built (grab it as a starter project on GitHub[1]) for real-time, server-rendered apps. It uses JSX/TSX to render HTML server-side and, in WebSocket mode, updates the DOM by targeting specific CSS selectors (document.querySelector) over WebSockets or HTTP/2 streaming. This keeps client-side JavaScript light, delivering fast, SEO-friendly pages and reactive UIs, much like Dan’s “JSX over the wire” vision.

What’s your take on this server-driven approach? Could it shake up how we build apps compared to heavy client-side frameworks? Curious if you’ve tried ts-liveview yet—it’s been a fun project to dig into these ideas!

[1] https://github.com/beenotung/ts-liveview

Though provoking article @danabramov, thanks.

I am wondering: What are the gains of RSC over a Fat Resource (with expand, sort, select and filter) where responses for (expand,sort,select) are cached? Most applications are READ-heavy, so even a fat response is easily returned to the client and might not need a refetch that often.

The article briefly mentions that you need $expand and $select then, but why/when is that not a valid approach?

The other point I have is that I really do not like to have JS on my server. If my business logic runs on a better runtime, we have 3 (actually 4) layers to pass:

  Storage layer (DB) 
    -> business logic in C# (server) 
       -> ViewModel layer in TS/JS (server) 
          -> React in TS/JS (client).

Managing changes gets really complex, with each layer needing type safety.

> But putting ViewModels in Resources also doesn’t work very well. ViewModels are not abstract concepts like “a post”; each ViewModel describes a specific piece of UI. As a result, the shape of your “Post” Resource grows to encompass the needs of every screen displaying a post.

I don't see the issue with adding an endpoint per viewmodel. Treating viewmodels as resources seems perfectly fine. Then again, I'm already on the HATEOAS and HTMX bandwagon, so maybe that just seems obvious, as it's no worse than returning HTML or JSX that could be constantly changing. If you actually need stable API endpoints for others to consume for other purposes, that's a separate consideration. This seems to be the direction the rest of the article goes.

Another great post!

I like the abstraction of server components but some of my co-workers seem to prefer HTMX (sending HTML rather than JSON) and can't really see any performance benefit from server components.

Maybe OP could clear up - Whether HTML could be sent instead (depending on platform), there is a brief point about not losing state but if your component does not have input elements or can have it state thrown away then maybe raw HTML could work? - prop size vs markup/component size. If you send a component down with a 1:9 dynamic to static content component. Then wouldn't it be better to have the the 90% static preloaded in the client, then only 10% of the data transmitted? Any good heuristic options here? - "It’s easy to make HTML out of JSON, but not the inverse". What is intrinsic about HTML/XML?

--

Also is Dan the only maintainer on the React team who does these kind of posts? do other members write long form. would be interesting to have a second angle.

Or you can have your "backend for frontend"... on the frontend, so you don't have an additional layer, it's always written in the frontend language and it's always synced to the frontend needs. The lengths we go to reinvent the squared wheel.

This all seems to be relatively simple concepts for an experienced programmer to understand, but it's being communicated in a very complex way due to the React world of JSX and Components

What if we just talked about it only in terms of simple data structures and function composition?

The framework checklist[1] makes me think of Fulcro: https://fulcro.fulcrologic.com/. To a first approximation you could think of it like defining a GraphQL query alongside each of your UI components. When you load data for one component (e.g. a top-level page component), it combines its own query with the queries from its children UI components.

[1] https://overreacted.io/jsx-over-the-wire/#dans-async-ui-fram...