React for Two Computers

https://overreacted.io/react-for-two-computers/

by abraham • 1 year ago

67 54 1 year ago

halflife8• 1 year ago

This is very long, I’ve skimmed over the article. In the end, what I’m trying to understand, is what server components solve? Faster performance? Serving compiled app html on refresh? Why is it so much better than the old school hydration?

mike1o1• 1 year ago

It might be a contrived example, but I found the example of syntax highlighting a blog post to be a good example of the benefits of RSC.

If you hydrate on the client, you need to run the same exact code on the server and again on the client - however, that means you now might need to bring in a big syntax highlighting library to the client.

With RSC all of that is done server side, so you don't need to ship the syntax highlighting library.

halflife8• 1 year ago

That may be fine for static rendering libraries, but chart libraries for example would have to be pushed to the client as well. So it seems to me that the benefits are so small and network speeds today are so fast, that switching your entire backend stack for that is over complicated to the point of absurdity…

halflife8• 1 year ago

@danabramov, would love to hear your stance on that

danabramov12• 1 year ago

I didn't really attempt to motivate it from the practical standpoint in the article. The article aims to be more of "reinvent some old ideas from first principles, while explaining some novel parts" kind of thing.

In particular, the callback to Miguel's article about async/await (https://tirania.org/blog/archive/2013/Aug-15.html) is intentional. I'd like to see some parts of my article as making a similar argument for 'use client' / 'use server' and the concept of first-class cross-environment references module system.

And as for practical benefits, I think the main benefit is composition--ability to compose and weave Server/Client building blocks together. Of course there's been myriads of approaches to server/client apps but I've never seen anything with the same compositional properties as RSC. I think Sam's talk (https://www.youtube.com/watch?app=desktop&v=9CN9RCzznZc) makes an amazing argument in favor of that viewpoint so I'll defer to him.

dhucerbin3• 1 year ago

Value proposition is “components for server”. But it’s worth to take a step back first.

What is value proposition of react component in comparison to older “mvc-inspired” frameworks? That you can drop a component in your code and call it a day. Don’t need to wire up separate controllers, models and views. Just one thing.

Now, if you want to add “auth” to your app (in react meta framework like next) you need to add component and probably add some routes and inject some middleware. With server components, you just add one component somewhere in the root of your app. Just one thing.

All that over the wire format, suspended data fetching etc, are a result of solving that problem and keeping in mind that those components are slightly different. It takes more work, but in return we can interleave both types of components nearly freely.

halflife8• 1 year ago

Sorry, having trouble understanding the nuance of the auth example (FYI in react I have experience only in small scale projects). What’s the difference in classic client components having a root component validation auth?

the_gipsy• 1 year ago

This reads like trying to find meaning where there is none.

danabramov12• 1 year ago

sorry :’(

selfmodruntime2• 1 year ago

I really want to try and read this thoroughly, can you perhaps add a clickable table of contents? It's really long and easy to get lost in.

DecoPerson• 1 year ago

Author invents a programming language where the code is server-side JSX tags ("Early World") and the runtime evaluation is divided into as multiple lazily-evaluated stages ("Late World") in the browser.

Author unfortunately fails to justify or provide a demonstration that justifies the increased complexity over current methodology.

Interesting exploration of an unexplored space, but should be more concise (and use either better or no attempts at humour).

In the Early world, you dissolve all the Early Components with interpret. This gives you a string that represents how to finish the computation in the Late world: [code]
In the Late world, you parse that string, load the references, and then dissolve the Late Components with interpret. That leaves you with a tree of Primitives: [code]
Finally, those Primitives are ready to be turned into DOM or some other format: [code]

jasonjmcghee2• 1 year ago

Author isn't inventing a new language. They are "inventing" react server components. It's not unexplored, they are teaching the reader how server side rendering in react works.

wruza• 1 year ago

Even though already implemented, still valid points.

wavemode• 1 year ago

The calls are not yet made—we’re only building a blueprint of those calls:

    <alert>
      <concat>
        Hello,
        <prompt>Who are you?</prompt>
      </concat>
    </alert>

> This blueprint of “potential calls” looks code, but it acts like data. It’s structurally similar to function calls but it is more passive, inert, open to interpretation. We’re yet to send this blueprint to the other computer which will actually interpret it.

You've reinvented Free Monads: https://www.haskellforall.com/2012/06/you-could-have-invente...

That article is a bit dense if you're less familiar with Haskell, but the basic idea is that you can write code that looks like:

    do
      name <- prompt "Who are you?"
      message <- concat "Hello, " name
      alert message

And what actually gets assembled is something resembling a syntax tree of operations, waiting to be interpreted.

You could interpret it locally, or have the interpreter send requests to another computer. And (if such are your desired semantics) the interpreter can short-circuit the whole thing and return an error message if any step fails - similar to how you describe these as being "potential function calls", i.e. calls which as of yet may or may not successfully execute.

Analogously, JavaScript already has a monad-like construct which can achieve something similar:

    async () => {
      const name = await prompt()
      const message = await concat("Hello, ", World)
      const result = await alert(message)
      return result
    }

But this is pure code, rather than data that can be interpreted in a custom way - it will always be "interpreted" by the runtime itself. The Haskell example is somewhat of a blend between data and code (it desugars to a tree of closures calling each other in sequence, which you have a lot of control over the execution of).

Your React-style example attempts to make this concept into pure data. Though in some ways, a DSL becoming pure data wraps around and becomes pure code again. You need to parse it, semantically analyze it, and then execute it - in other words, you've invented a compiler.

alexisread• 1 year ago

Interestingly Wat (https://github.com/manuel/wat-js) handles Dynamic Variables, which fit well with serialized code, in that the serialization boundary can be better partitioned into variables you need to serialize (locals etc.), and environmental (dynamic) variables which are subject to their runtime env.

Wat also happens to have a good concurrency model, and a portable bytecode. Worth looking at in this space.

danabramov12• 1 year ago

Thanks for the context! I give Haskell a one-word shoutout in the article as a hint but I really wanted to take the reader on the journey of inventing some of these things themselves.

Garlef• 1 year ago

What I've gathered from this: It's an explantion of why serializable closures are a way to solve/tackle the problem of hydration, etc. Hence the compiler technology in newer react.

wild_egg2• 1 year ago

The need to wax philosophical really shows how complex and overengineered RSC is compared to solutions from other ecosystems that are just as effective but far simpler to work with and understand.

danabramov12• 1 year ago

And yet the final code is ~150 lines.

https://codesandbox.io/p/sandbox/8dgdz8

What's overengineered here?

danabramov12• 1 year ago

I'll add I think you're mistaking the cause and the effect. I'm not trying to sell you on something; I don't give a damn what you use. Like literally, I don't. I'm not personally invested in that. I'm not being paid to work on this or promote it or whatever. But I've been thinking about this stuff for a while and I wanted to write it down on the page. And my thoughts tend to be longwinded because I prefer that style. I think someone will salvage something valuable from my writing if they find it there.

jasonjmcghee2• 1 year ago

Author is explaining react server components in a colorful style.

They aren't reinventing or proposing anything new.

Most of the complaints in the comments here are probably due to author not saying "hey we're going to pretend to invent RSC so you get how it works, hop in"

randomcatuser• 1 year ago

this is the most brilliant piece of writing i've ever seen -- reminds me of Godel, Escher, Bach.

Would love recommendations for other things like this where the style is one of discovery!! (like math textbooks that make you feel like you invented something?)

revskill• 1 year ago

Why briliant ??

danabramov12• 1 year ago

Haha thanks, I know it's not everyone's cup of tea but I appreciate kind words, and GEB is too obvious of an inspiration. I would highly recommend Terence Tao's Analysis textbook. It's maybe a bit too rigorous/formal (and maybe doesn't quite describe discovery because it develops very standard theory) but it builds in a very pleasant way. If you're interested in Lean, some of Kevin Buzzard's writing at https://xenaproject.wordpress.com/ is similarly pleasant (e.g. https://xenaproject.wordpress.com/2021/04/18/induction-on-eq...).

danielskogly• 1 year ago

I seem to recall what the parent describes when taking your course on redux @ Egghead long, long ago, where I think you went through creating a simplified version of redux? Such a great way to gain a deeper understanding of something that, on the surface, seems very complex. Thank you for making that course free :)

jy14898• 1 year ago

Tiktok has rotted my brain for this length of article

Noumenon72• 1 year ago

If it's this length but about the history of S3, I can easily stay engaged for each new story. When it's a bunch of hypothetical syntaxes that will get thrown away, I'm only staying if I entered the article with the purpose of "I want to understand React Server Components".

myvoiceismypass2• 1 year ago

Really suggested to watch the talk / video that this is for: https://www.youtube.com/watch?v=ozI4V_29fj4

srcreigh• 1 year ago

Haven’t got through the whole article yet. The beginning was slow for me, but it did start to get interesting quickly.

lennoff2• 1 year ago

It seems like that the author by using JSX to express code directly as an AST re-invented LISP? See Greenspun's tenth rule[1].

[1] https://wiki.c2.com/?GreenspunsTenthRuleOfProgramming

danabramov12• 1 year ago

Sort of! My impression is that LISP is a little more powerful than what we're building up in the article. I wanted to focus on a few specific aspects (like first-class cross-environment imports and serializing continuations) but I'd ofc expect all of that to be expressible in LISP.

lennoff2• 1 year ago

It's fun to theorize about an alternate universe where JavaScript has a LISP-like syntax (Brendan Eich originally wanted "Scheme in the browser"[1], so this isn't so far-fetched!). Indeed, `interpret` sounds like a LISP macro that can "partially evaluate" code (so someone else, ie. the browser can continue to evaluate it).

[1] https://brendaneich.com/2008/04/popularity/

OmarIsmail• 1 year ago

This article is amazing. I think any engineer outside of programming language builders would get something incredibly useful for it.

Not enough engineers engage with the concept of code and programming and as an industry we suffer for it. The beginning of this post does a phenomenal job of simplifying very basic but high level concepts as “what is a function” “what is a tag”.

99% or programmers don’t think about these things like this, and so get confused when these building blocks are manipulated and presented in seemingly strange ways like React components or server components or whatever. By breaking down these concepts (functions, blueprints) and having rebuilding them with simple definitions it allows the reader to start their mental model fresh and go from there.

This is a masterclass in technical communication.

Who gives a shit if it’s long. In fact I’m glad it’s long because every sentence is gold. These are deep subjects and foundational to programming and so ya, talking about them like this can take a few words.

99% of people who take the time to really read and process this post will come away as noticeably improved developers. That kind of bang for the buck is rare!

andrewstuart• 1 year ago

This is unusual for Dan he usually writes very well. This time not.

danabramov12• 1 year ago

What do you dislike? I wrote it a bit more like how I like to think about it, so maybe it's a bit more "for myself" than my past writing.

unconed• 1 year ago

(not OP)

After reading the post, and re-reading the opening, it almost seems they are about two different posts. e.g. "Jot down a few notes" vs actually going meta with yourself in the middle about how the post isn't even halfway. That doesn't really make a lot of sense.

That you then expect the reader to want to read all this _after_ already having watched the video seems a bit gratuitous? Perhaps it would've been better built as something interactive or graphical so you wouldn't need to explain as much of the mechanics.

I did find it interesting, but had to lol at `{fn, args}`: I've spent the last few years working on Live, a not-React run-time, which has exactly that type for its deferred calls. It was inspired by the same idea of treating JSX tags as just `fn(...args)` in drag.

I've always been curious to hear your opinion on Use.GPU / Live. There is a keynote video linked here https://usegpu.live/ if you're interested.

tock• 1 year ago

The selling point looks to be this: you get all the advantages of server side rendering but with the flexibility of react client side components as well. Being able to just use react components for composability on the server side is pretty nice.

React for Two Computers

Related Stories