my blog https://overreacted.io
people get weird about being modest. be less modest
+7
-7
+7
-7
public/rsc-for-lisp-developers/index.md
+7
-7
public/rsc-for-lisp-developers/index.md
···
4
4
spoiler: Quoting for modules.
5
5
---
6
6
7
-
Okay, so I don't *actually* know LISP, so this is gonna be a tough one. If I misunderstand something, please help me understand it.
8
-
9
-
But from what I know, one of the big ideas of LISP is that code is data, and data is code. I mean, that's kind of [generally](https://wiki.c2.com/?DataAndCodeAreTheSameThing) true, but in LISP it's both culturally and syntactically emphasized. For example, let's take this piece of code in LISP:
7
+
One of the big ideas of LISP is that code is data, and data is code. I mean, that's kind of [generally](https://wiki.c2.com/?DataAndCodeAreTheSameThing) true, but in LISP it's both culturally and syntactically emphasized. For example, let's take this piece of code in LISP:
10
8
11
9
```lisp
12
10
(+ 2 2)
···
42
40
43
41
We can't "quote" individual code blocks in JavaScript without losing many benefits of the language. However, what if we could "quote"... an entire module?
44
42
45
-
In React Server Components (RSC), that's what the `'use client'` directive [does](/why-does-rsc-integrate-with-a-bundler/#serializing-modules):
43
+
React Server Components (RSC) is a client-server programming paradigm that uses a similar idea to refer to client code from the server code. The `'use client'` directive lets you [import code designed for the client--but without running it](/why-does-rsc-integrate-with-a-bundler/#serializing-modules):
46
44
47
45
<Client>
48
46
···
56
54
57
55
</Client>
58
56
59
-
It marks a piece of code to be treated as data (to be sent to the client).
57
+
Like quoting, it marks a piece of code to be treated as data. *Unlike* quoting in LISP, the result you get back is opaque--you can't transform or introspect that code.
60
58
61
-
This means that whoever imports `onClick` from the backend code won't get an actual `onClick` function--instead, they'll get `'/js/chunk123.js#onClick'` or something like that identifying *how to load* this module. It gives you code-as-data. Eventually this code will make it to the client (as a `<script>`) and be evaluated there. Then, the `onClick` function will actually exist (and maybe even be called). Unlike with LISP quoting, this is [implemented at the compile time](/why-does-rsc-integrate-with-a-bundler/#rsc-bundler-bindings) using a bundler.
59
+
This means that whoever imports `onClick` from the backend code won't get an actual `onClick` function--instead, they'll get `'/js/chunk123.js#onClick'` or something like that identifying *how to load* this module. It gives you code-as-data. Unlike with LISP quoting, this is [implemented at the compile time](/why-does-rsc-integrate-with-a-bundler/#rsc-bundler-bindings) using a bundler.
60
+
61
+
Eventually this code will make it to the client (as a `<script>`) and be evaluated there. Then, the `onClick` function will actually exist (and maybe even be called).
62
62
63
63
What this gives us is an ability to write a program that composes behaviors that execute at different stages (on the server and the client) in a very modular way. [See here for example.](/impossible-components/#final-code) The parts outside the "quote" deal with server-only resources, while the parts inside the "quote" are stateful and exist on the client--but they are composed. The server stuff can wrap the client stuff, the client stuff can wrap the server stuff, as long as you're doing all composition from the server. And what doing composition on the server enables is a guarantee that all the server stuff runs [within a single request/response roundtrip](/one-roundtrip-per-navigation/). It's also [progressively streamed](/progressive-json/).
64
64
65
65
That's kind of it, really. Of course, this is a lot less powerful than quoting because the evaluation strategies are being prescribed by React, and there's no kind of metaprogramming like transforming the code itself. So maybe it's still a stretch.
66
66
67
-
I know LISP has a rich tradition of solutions that compose code across multiple environments, with some newer approaches like [Electric](https://github.com/hyperfiddle/electric) picking up steam. I don't understand LISP well enough to understand them but I would love to see more explanations targeted at JavaScript developers, both about prior art and new ideas.
67
+
I know LISP has a rich tradition of solutions that compose code across multiple environments, with some newer approaches like [Electric](https://github.com/hyperfiddle/electric) picking up steam. I don't understand LISP well enough to dig deep into them but I would love to see more explanations targeted at JavaScript developers, both about prior art and new ideas.
68
68
69
69
Thank you!
70
70