React for Two Computers

> 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>

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

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
    }
  

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.

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

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?

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"

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

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.

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.

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.

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?)

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]

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

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!