JSX Over the Wire With Dan Abramov  ## Metadata - Author: [[PodRocket]] - Full Title: JSX Over the Wire With Dan Abramov - Category: #podcasts - URL: https://share.snipd.com/episode/c42b83d9-fcaf-44dc-9f8d-44ead69aa30d ## Document Notes ## Highlights - **User-Centric UI Over Tech Boundaries** - The challenge in passing state between server and client stems from their distinct technological contexts and evolution. - React Server Components focus on the user's perspective, integrating backend and frontend seamlessly for better UI experience. Transcript: Dan Abramov Yeah, I think it's still an unsolved problem, right? I think part of the post is that, like, I think there is a solution that has very interesting characteristics that is not yet acknowledged in kind of the mainstream area. I don't think it's being recognized for what it deserves to be recognized. So I think there is like a step forward to being proposed there. But I think the reason it's been difficult is partially just like how you approach it really depends on which side you're coming from. And part of it is historical, right? Like in the beginning, there was really no notion of the client side because the client side was severely underpowered. And so we started on the server, we started with a CGI or later like PHP or Ruby or all these kind of server-centric frameworks. And that was a certain strain of evolution where we learned like maybe to make templates or MVC became popular. And there was this whole thing, like how do you do server rendered applications? And I think there were some really good ideas and like good techniques there. But then later client got more powerful and we started approaching it from purely clients. Initially mixed perspective, but it was hard to mix them because these are separate technologies. All of the techniques we use in programming, like lexical scoping or modules, or like, how do you pass data or how do you even represent data? What kind of objects can you pass around and so on? All of that is different between the client and the server. And so naturally, we started thinking, if we start with the client, how much can they gain from this being our frame of reference? And I think that approach culminated with client-side routing, React, the way people were using React in 2016, 2017, especially, purely client-side. But it also has its own drawbacks where some things have gotten really complicated. The way you fetch data is complicated. It has some inefficiencies that are just inherent to the idea that you're looking from the client-centric perspective, but actually the data lives on the server and you always have To cross that bridge to get more of it. And so I think there were some kind of flaws in that perspective as well. But because they're separated by technologies, they're often separated by teams. So sometimes you have these organizational boundaries where there's the backend team and there's the frontend team. And so it becomes like different camps with different rituals, different techniques we use. And I think there wasn't enough of, let's just see this from the user's perspective, right? Like the user doesn't see the server or the client. That's not a concept. The user sees a blog post or an avatar or a comment, a comment section, a filterable table. So what if we try to look at the whole thing from the user's perspective and divided by technology kind of later as different kind of layers of those things that we create on the screen. And so this is the approach taken by React Server Components. But of course, it annoys the backend camp because the client plays a really big role there and it annoys the client camp because the backend plays a really big role there. ([Time 0:02:28](https://share.snipd.com/snip/c17d451a-22ab-4934-9d4e-d7059e8cceda)) - **React Server Components Blend Approaches** - React Server Components blend old server-rendering with modern client interactivity using JSON rather than HTML. - This method treats UI as composable components running on backend and frontend, bridging API and UX needs. Transcript: Dan Abramov The end state that I get to with the React server components, I think the vibe is more like old school server rendering where not in the React sense of a like literally like PHP and XHP, Which was an evolution of PHP at Facebook, but with components, right? Facebook had something like JSX, but in PHP, and that was a precursor to React, actually. And I think there is this very natural way to say, my UI consists of these pieces and these pieces run on the backend. They have full access to backend resources. And that is a little bit before this introduction of the idea of an API. An API is something more generic that many clients can call, whereas this is more kind of hypermedia-focused approach where you say, the only thing I want to return is this UI. So this is an API that specifically exists for this reason. And so in this sense, I think it's more similar to old school and a server approach where you just return an HTML almost, but you can create your own abstractions. But in terms of how it works, I think it's closer to the API JSON. Like we're transferring JSON. We're not really sending HTML. Of course, we can convert JSON to HTML for like first render, but really we can pass rich objects. It's kind of like, what if HTML could express rich applications, not just the first render, but throughout the application's lifetime. So you can pass a JSON, two components, they can run on the client, like a richer version of HTML almost. And so it has this kind of API-ish or rich vibes as well. And then of course, we're not underestimating the client, right? Like the client is not an afterthought. The client is where all the rich, stateful, interactive logic lives. And so that is influenced by the client-side approaches. So that is also very much a part of the picture. So in that sense, it takes things from each of those strands of evolution, but brings them together in a slightly different way than a lot of other solutions. But speaking, you mentioned BFF. There's this pattern that's gaining some popularity over the last few years, I think, called back-end for front-end. That also, and I use it throughout the text quite a bit, because that is a part of how React server components was discovered, is by thinking along those lines. But this pattern is more general, right? It's not specific to React. It's just this idea that it makes sense that the API team or like the backend team might want to separate some of their data logic into these REST API endpoints or like something that's Not UI specific that can serve many clients that doesn't change every time you change the UIs, some kind of interface. But that interface is just, if you really want the backend team to be happy, the interface that they would want to provide is not really the interface that is needed by the front-end part, Because the front-end part wants to collate some of these API endpoints, right? We want to expand some fields. We don't care about some other fields for some other screens. We want to sometimes do some extra computation with those fields, preparing them. And this is also a familiar pattern. It's sometimes called the view model. So it's this idea that it's not the raw model, the way we store it in the database. It's really cooked. It's prepared for a specific piece of UI. And so this idea of backend for frontend is what if frontend had a representative piece of code on the backend? What if frontend was actually not just on the front, but it also had a backend part that prepared raw backend data for consumption by a specific part of the frontend? And so this is the idea of a BFF is just, what if there was a layer that did that? And then server components are like, what if that layer was structured as components, which is beneficial if you want to compose those bits and reuse them. ([Time 0:06:12](https://share.snipd.com/snip/8761296c-1d9c-4713-a876-e3ca7271387c)) - **XHP's Legacy in React** - Facebook used XHP, which made markup a first-class citizen by treating it as an object, precursor to React components. - React inherited this by merging template and view model into composable UI components, killing traditional MVC on frontend and backend. Transcript: Dan Abramov Yeah, so just to give a quick idea of what XHP is, you can imagine it as like in traditional old school PHP, you would just like echo parts of HTML and then use string interpolation to create Functions like, oh, this is my like table header and it goes into database or whatever. And not really composable, hard to scale. And I think as the first generation of web developers learned the pitfalls of this approach and like how it is lacking some order, there was a move towards more structured approaches. And usually what you would do is you would extract templates. So you would write these like template files that don't contain any logic. They're just HTML with holes where you insert data. And then you have some other layer, like a controller or a view model or like something that actually gets the data. And I think this became popular just because it does solve the problems of the previous approach. And as a maybe more like obvious step is let's try to apply the MVC paradigm to it. It's funny that the same thing happened on front end, right? Before React, the way you would do front end is you would usually have something like MVC, like you would, maybe you would use Backbone, but you would also have this, here is my template. It's written in like mustache instead of ginger or whatever, but it's the same idea transplanted. And then I think React killed MVC on the front end. And there is a seminal talk called Rethinking Best Practices by Pete Hunt that really put React on the map, I think, after it was ridiculed for a couple of years. And it made the case that actually this view model logic, this thing that adapts the data to the presentation, it's inseparable from the template. It isn't inherently coupled to the template because that is what it's for. Like the purpose of the view model is to adapt data in a way that can be presented by the template. So what if we merge those concepts into the concept of a component? And then the way we did separation of concerns not by technology, like template versus controller, but instead vertically by here's the button, here's the form, here's the avatar Or the comment and so on. And that was our block, like UI itself was the unit of separation. And so I think for a lot of people like in JavaScript world, it kind of took a while to get used to. But for Facebook, when React came out, nobody at Facebook was expecting that it would be received so poorly initially because they were already bought into the idea of components from Using XHP. ([Time 0:10:30](https://share.snipd.com/snip/e1112ace-c9cf-4060-b58b-a896646c5d47)) - **UI Data Needs Clash with REST APIs** - Backend data and front-end UI data views often mismatch causing inefficiencies and complexity. - REST APIs tend to be either over- or under-powered for UI needs, making screen-specific data shaping essential. Transcript: Dan Abramov The way I kind of like to frame it is data doesn't have any particular shape. You decide what is it for. There's this sequence of transformations that have to happen between the way things are most efficient to store or retain all the information that we want to store. And then the things that we want to present to the user. And the example I'm using in the article is the like button. So in the database, maybe you have like a posts table with different posts. You have a likes table where each like is a separate row. It has the user who like submitted this like. It has the post ID. And maybe that's all it has because a like is a very simple thing. But even with the simplest example that you can think of, actually, if you want to present it to the user, let's say you have this button that says liked by you and 12 others. Like you already, to prepare this, you need to make some queries. Like you need to check, is it liked by the current user? Does there exist a like in the table for the current user? Do there exist likes of the user's friends Because you want to prioritize them. And if you have some friends who liked it, you want to put them first in this message, like by you and like your friend and not some random person. But if not, maybe you're okay with putting like a random person there. And then you want the count as well. So you want how many people did that. And so this information is personalized, it's aggregated. And there's a question, like if you're making a rest endpoint for a post, you don't include all the likes there, right? Because if there's a thousand, you don't want a thousand. And there are questions like, do you embed the information about the likes into that post? Is it just a field like like count 12? But then how do you know the friends' names? Is there liked by friend names? Or is it a separate API endpoint that returns a list of likes by friends? And so you have to make these decisions. If it's a separate API endpoint, does it contain friends' names? And then what if later you want to show their avatars next to the like button? Do you now include it in that endpoint? So there is this tension between the way the data is stored, which I call the model, and the way the data we wanted to present, which I call the view model. And the problem with REST, and I don't mean REST in some theoretical sense that people sometimes like to nitpick, oh, we're not using REST as originally intended. The way I'm describing it by the end is actually closer with this REST as hypermedia. So I'm aware that I'm not describing it initially as it's originally intended. But even if you look at the way people actually use it, I think there's, depending on who has the most say in the company, you see REST endpoints either kind of gravitating towards the Models. So they represent data closer to like its actual shape in the database or something that's derived objectively from it. But that means that when they go to them and say, oh, like I need these avatars or I need this thing sorted by friends should come first, it kind of messes with the data model. It's okay, like this piece of UI needs this, but maybe another piece of UI wants something different. So like, how do you reconcile it? And so in many cases, the backend gives you the thing. And then the front end, you sometimes have to make multiple requests to combine what you actually want, or you do some processing, or you just give up on the feature. You're like, oh, the API doesn't give me this. I guess no avatars are going to be shown. And that is one extreme when the backend runs the show. And then if the front-end team runs the show, you can see it going in the other direction where, okay, the API really needs this. We're going to end at these conventions for expanding arbitrary properties in our REST endpoints. And we're going to have this screen-specific fields, maybe just, okay, post might have a field with liked by friends or whatever that is really UI specific. But then you have a UI redesign. And the things that these things need also change, but they're already locked into like, you're not going to add like my friends v2, or there's some tension between you probably don't Have a good setup for deprecating fields or kind of swapping them out or even different screens might need different information and so some of them will suffer because the responses Are geared towards they're supposed to be this abstract entities like a post right there you go get slash api slash post slash one two three and you're not really saying no i want the representation Of post as needed by this specific screen. And so I think that is the layer that we're missing. It's something that would do this translation. And it is actually tightly coupled to the UI because the view model is the template. The view model cannot be separated from the template. And so we're extending the same argument that Pete Hunt made in his talk across the backend. ([Time 0:15:30](https://share.snipd.com/snip/d12c3409-7a69-43ba-b216-e43220291205)) - **Use BFF to Tailor Data** - Use Backend-for-Frontend (BFF) as an intermediary to bundle API data needed for specific screens. - Co-locate data fetching logic with UI components for efficient, type-safe data management. Transcript: Dan Abramov Yeah. So I think the backend for frontend is like a possible first step towards bridging that divide. It is the least prescriptive kind of step I can think of that is still useful. And it's interestingly, it doesn't even have to be in JS, right? This pattern itself is more general. Funny enough, when I was working with Flask and Python in 2013, and we had this problem, right? Like we had a REST API that sometimes we needed like different things, a different level of granularity. It was not super great that the client had to ask, the client was a spa. So the client kind of had to ask for them. And it was like, after the page loaded, you go to the server, you load the page, it loads the JavaScript's running. And then JavaScript is like, oh, I'm going to need these like three different things for a screen. So one of the first optimizations I actually made was on the Python side, I had a separate piece of logic that understood our routing. And it basically said which API calls should be pre-bundled into the HTML. So that at least when we send the HTML, we want to send some JSON that we know the client is going to request just to avoid this silly kind of round trip and network waterfall, just like at Least have that first response already be there. And you can think of that as a proto BFF, right? It didn't have this, okay, get me all the data from the next screen kind of endpoint. But it was a piece of logic that says, when the user visits a post page, just prepare the post response, post detailed response, post likes response, whatever, bundle them together. And so I think this is the first step. A BFF is just, in my conception, the way I imagine it, is just a part of your API server. It could be a separate server. It could be a part of your API server that is structured with the same routing structure as your application. So if you have slash posts, slash whatever, the user facing API that they type in the address bar, replicate the same structure on the backend, and just include all the JSON that the screen Is going to need. And then what this lets you do is on the client, you gain the ability to, instead of calling this REST API endpoints, you can just say, I'm on this screen. When the screen is loading, grab all the data needed for it, and then I'm going to plumb it down. If you think about frameworks like Remix, they can implement the same exact pattern, right? Like they have this loader function that prepares data for a screen, but you can think of that as a piece of a BFF. It's just co-located with your components, right? And that's the next stage of BFF is like starting to blend it and bring it closer so that you can have like type checking and so on. ([Time 0:20:31](https://share.snipd.com/snip/4d709b6a-60e6-4aa6-a3e0-0f41bbdca58c)) - **Adopt RSCs with Clear Understanding** - Understand the problems React Server Components solve before adoption to avoid confusion and inefficiencies. - Keep BFF close to frontend, with synchronized types and flexible endpoints to align backend with UI. Transcript: Dan Abramov Yeah, I think it's a tricky question because it really depends on the framing. Because, for example, with React server components, I think most people encounter in it in the wild, they don't encounter it with this perspective of here's a set of problems that it's Related to. And it's also not the only way to arrive at this architecture, right? In the article, I also describe a completely separate thread of thought related mostly to native user interfaces, like the way Instagram, Reddit, Airbnb, Uber, and a lot of other builds That are native apps is actually with server-side logic that returns UI views. And that is the same exact concept. It's just you arrive from a different point of view to the same idea. But that is just to say, I think in practice, the way people encounter, for example, React server components in the file today, it's just because they started using Next.js. Next.js is a popular framework, and it uses this approach. But I think the way it's been described doesn't really explain some of the problems that it solves. And so I think the mental model that a lot of people who try Next.js have is just, oh, it's some weird optimization. Like some components render on the server for some reason. And then it doesn't really explain, oh, this is one way to think about it. It's just the BFF that's composable, right? You're really componentizing your API and not so much like optimizing your components. So I think it helps to understand what problems you want to solve. But in terms of risks, I think with, depends on which approach you pick, right? If you're talking just about the BFF, I think there's one of the risks is that the server part will, again, deviate from the needs of the client. So it's very important that if you're committed to this, you should really think of the BFF as almost a part of your front end. It's just a part of the front end that happens to run on the backend. But you need to think about how to do deployment, how to do versioning, how do you make sure that the development team has the flexibility to just delete these endpoints, add more of them As the routing logic changes to change the types. And also you want the types to be synced. You want the type seen by the front end for a particular screen to match the type seen on the back end by a particular screen. And so this is where approaches like Remix with loaders take a step forward where they ensure that the types are synced because it's just one code base and you just check it with TypeScript. And approaches like React Server Components take it yet forward, in my opinion, again, because then they split up that loader into composable pieces that are reusable, and they can Be composed in the same way that the UI itself is composed. And so it's like each component can have its own front-end side and back-end side, and those are all composable. And again, the risks there is misunderstanding the model, I think, not having a good, clear mental picture of what exactly is going on. And also for React server components, like honestly, the tag itself is still a bit raw. I think it's a bit rough around the edges. The Parcel Bundler really is the standalone implementation, which is not tied to a framework. So if you want to get into the nitty-gritty and play with it, I think that's a good place to go. And then Next.js app router kind of offers like a big vision for how you could build big applications with it. But I think it still has a year until it feels like really solid because they're changing some pieces and learning from it. So it's a bit of a work in progress. Obviously, there's many production apps using it, but it's not as seamless and nice to use as it could have been if more time has passed and the edges are evened out. ([Time 0:23:39](https://share.snipd.com/snip/4d6f3763-8f24-47de-a4e9-009445c6a8c4)) - **Advocate BFF As UI Interop Layer** - Advocate BFF as a thin layer translating backend data for UI needs without discarding existing REST APIs. - Write this interop layer close to frontend ownership, possibly in JavaScript, for better flexibility and type safety. Transcript: Dan Abramov Yeah, it's hard. I think it's fun. I think part of the reason why Facebook was able to come up with these constructs is because there is no notion of backend teams at Facebook. That is not how it's organized by products and screens and features, not by these are the people doing this thing and these are the people doing this layer. But of course, like at some point, you do have some competency that is backend specific, right? There are backend people at Facebook, but they work at the layer even above the stack, right? It's like the data layer, the caching layer, like the thing that the product team, the product backend team calls into. And so I think one of the ways you can think about this, like advocating for this kind of layer is it's not really about changing what the backend does. It's more about having an interop layer between the front end and the backend. So it's almost like the front end team is responsible for the UI and UI should have presence on the server, in terms of server rendering necessarily. Like a lot of people are like, I don't need server rendering. This doesn't have anything to do with server rendering. You could, your spa could remain the spa, right? It doesn't have anything to do with generate HTML. It's really about the, how do we prepare the API to be tailored exactly to what the components need? And the answer to this, you just write your API as components. But of course, it doesn't mean killing your existing REST APIs. You could call those, right? So I think it's just about shifting the backend a little bit upwards and then introducing a new thin layer of translation that kind of translate it. And if you have success with this approach, maybe the next step would be, let's write this layer in JavaScript, then we can automatically at least match up the types in a very nice way. And then the next step could be, maybe we try React server components because it lets this piece be composable. It lets us avoid duplicating logic and just compose those pieces together. ([Time 0:27:36](https://share.snipd.com/snip/20af1349-2977-4e8e-9f0f-33431821298a)) - **Composable Layered Caching Advances** - Caching can be layered and composable, caching different UI parts with varied update frequencies. - New caching methods allow caching at syntactic levels letting dynamic UI parts update independently. Transcript: Dan Abramov So I think part of it is just whatever the old school backend layer decides, right? If the backend layer implements some kind of caching strategies like that school that can stay. But I think this approach opens up very interesting possibilities for caching. Next.js is researching. I think, again, I feel like people will think that I'm plugging Next.js, but I don't actually care about Next.js. I just think that the ideas they're working on are important. So there's a blog post called Our Journey with Caching by Sebastian Magbogge, who's the inventor of hooks, by the way, if you like client-side of React, but also one of the inventors Of React Server Components. And he's working on a kind of new caching layer for Next.js with a directive called Use Cache, which uses the same kind of layered approach as the module system in React server components. It's almost like cache is like a separate world. I know I'm hand-waving a lot of it, but the key thing about it is it kind of lets you cache at the syntactic level almost. So you can designate certain functions as cacheable. And the thing is that it kind of caches the end result as well. So you can cache the entire V model or in the React server components, that's just the component output, right? It's just the UI itself. You can cache the layout or the page or an individual API call. But the interesting thing is that it allows holes. So in React, there's this common pattern where a component accepts children as a prop. And it doesn't care what you pass as children, it's essentially like a whole punctured in the component. And then the stuff around it is like the stuff where you like update the state, or have some data or whatever, but it doesn't care what's inside. So with this approach that Next.js is exploring with use cache, this caching happens at this kind of BFF layer. But the thing being cached is the thing just before substituting the kind of dynamic values into it. So it's actually possible to cache just the layout, and then different pieces of UI have their own separate caching kind of exploration time, which to me is like the holy grail of caching Is you want to cache the footer forever, then the shell, like maybe it updates like every 10 minutes, and then some parts maybe completely dynamic, and then everything can be composed Together. ([Time 0:29:49](https://share.snipd.com/snip/0ce3ee4b-15e1-46fd-832a-d10f1d0616fe)) - **Why JSON Beats HTML Transport** - JSON as transport for React Server Components allows passing rich props and interactivity unlike HTML. - This enables partial refetching and updating of UI stateful components without full reload. Transcript: Paige Niedringhaus So why does this distinction matter so much and especially for the future of kind of rich applications? Dan Abramov Yeah. So I think this is so just to make it clear, you can always take JSON and turn it into HTML. But it's hard to take HTML and turn it back into JSON because you have to parse it. HTML parsing rules are quite arcane. Plus, there's no well-defined way to say in HTML, this is the JSON needed for the script. And this is kind of like in single-page apps or in server-rendered single-page apps that later continue. They have some dynamic interactivity. You really want to pass props. Like you want to say, this is a piece of client-side code. It has interactive logic and it accepts these props that are reached JSON. It's not just HTML attributes. And so if you take HTML and then start extending it in a way that you want to express components, you want to pass props to them, you end up with something like JSX maybe, or if you wanted To serialize it, JSON would be a natural format. And so the reason this is important is because, again, I think the mental model of old school server rendered apps, PHP and so on, is very simple. You just return some HTML and you compose it and maybe you have abstractions like your own tags that turn into HTML and so on. So it's a very simple model of just describing what you want to see on the screen. But then this model, you can't really get far with it. I think, sure, there are like PJAX, Turbo, I forgot what it's called, but all these ways, like HTMX has something for it. I think Morphin, DOM, and so on. There are these approaches that try to deal with refetching. What if you want to navigate to another page, but you don't want to refresh the whole HTML? You don't want to blow away the state. You want it to feel like a snappy client-side transition. Maybe you even want to prefetch it so that it's instant when you click. Or even like refreshing, right? If you just sent a comment, you just want to refresh this part. So how do you replace it in place? And it's possible with HTML, but you hit the limits with interactive bits because you don't want to blow away their state. And so the question is, is there a way to keep the HTML mental model where if you want to refetch something, you just refetch that HTML, have it be reconciled on the client, have it be kind Of merged into your existing structure. If there are new props coming from the server, just have those props be received by components already mounted on the client, already stateful, without blowing anything away. And that is really like what using JSON as the transport. It's not exactly JSON in React Server components. It's more like streaming JSON. So it's a bit better. You can always take that and produce HTML of it, but it's strictly a reacher representation. And so it also works for refetches. And that is why this approach is also used in mobile apps. Again, like I mentioned, Uber, Airbnb, Instagram, Reddit, they all use this approach. So they use something that's like React server components, except instead of client components, they just build native stuff in iOS and Android. And instead of like on the server, it's not React, it's their in-house frameworks that do something similar. ([Time 0:32:21](https://share.snipd.com/snip/af1a4603-ff98-46df-a4d6-bca6d7c3551d)) - **Multiple Paths to UI Composition** - There are many ways to approach composing UI with server-driven data fetching. - Collocating data fetching logic with UI components leads to flexible, scalable solutions across frameworks. Transcript: Dan Abramov I think it's just that there's many ways to arrive at the same endpoint. And I think that is partially what makes this technology interesting is you can start with something like GraphQL and then be like, I don't really want to have a different language for Describing data, but I want to collocate the description of how to get it with my components. And then gradually, you might end up with something similar. Or you can start with the rest endpoints and then be like, okay, I need to massage this data for particular screens. So I want to integrate it with my routing. I want to make it composable. And then again, you can end up with something similar. Or you can start with this idea, oh, I'm just going to send HTML over the wire. On the refetches, I'm also going to send HTML. But I want to keep it stateful. I don't want to replace entire component trees. So maybe I send JSON. And then again, you end up with the same idea. Or you can start with Remix and be like, this loaders are very nice, but I wish I could split it apart so that it's more like components, more composable. And then you end up with server components. So there's so many ways to arrive at the same idea. I personally find it pretty fascinating, but it can also be overwhelming or like you just don't know from which angle to explain it. Yeah, I don't know, just read the article, see if anything there resonates. I try to present a few different perspectives there. And if you want to play with it, again, I would suggest the Parcel Bundler released a standalone, not framework specific. It's just the raw stuff. I think it's the most raw, officially supported way to consume them from a spa. You can literally run a spa and you can run a parcel, the server bundle that it generates. You don't have to generate HTML from your components. It can be a spa, but it lets you see this concept of, oh, it's this thing that is being passed over the wire, and then I can just embed it in my render tree, and it just appears there, but it's Actually coming from the server. So that's a way to play with it. And then if you want to see the big picture from the person who designed this idea, I think AppRoute still has a way to go. They're changing some things in response to feedback, mostly about caching actually. But I think that is, here's a vision of how you could build entire applications this way that can scale down to something as similar as my blog, for example, or scale up to something like As complex as some of the Facebook screens, hopefully. ([Time 0:35:54](https://share.snipd.com/snip/7b4cd2ca-5ad9-4323-bb9e-8f9bce7d5cf5)) - **Must-Have: Composable Full-Stack Components** - Prioritize self-contained, composable full-stack components for scalable UI development. - Ensure components encapsulate data loading and interactive logic coherently. Transcript: Dan Abramov Yeah, the key feature is composition. You want to be able to have full stack components that are fully self-encapsulated. I have a post about this. It's called Impossible Components, but it's really the idea that you want to be able to refer a thing on the screen by its name, like a blog post, or like a post preview, and you want that Thing to be able to describe, I'm loading data from this file or like this database or whatever. And I also have some interactive logic, like I'm doing things when you click on me. And then you want to be able to compose these things together as Lego blocks. And they should add up to a cohesive experience that doesn't do a truly unfetches from the client because client is the only thing in terms of which you can think. ([Time 0:38:36](https://share.snipd.com/snip/12d9a3f4-e9bb-471b-ba82-fbdd0437327d)) - **Principles for Bridging Data and UI** - Design systems with a law of composition ensuring combined behaviors are meaningful and efficient. - Enforce type safety and syntactic connections between server and client for robust development. Transcript: Dan Abramov Same, composition. Composition is the most important thing. You want to be able for different people to create the self-isolated abstractions. And then you want to make sure that there is some law of how they compose together, that their behavior when you compose them is meaningful, right? If these two things are doing a fetch, you kind of want to combine those fetches and not have those be like two separate fetches going from the client. So as much as possible, I think you want type safety so that you have a direct connection so that you can control click between the server and the client. ([Time 0:39:28](https://share.snipd.com/snip/5c41058e-947d-4d84-8836-44c18bf14b01)) - **Network Gap As Programming Primitive** - Firm technological boundaries between server and client remain necessary despite blending UI logic. - React Server Components innovate by incorporating network latency and boundaries as first-class programming primitives. Transcript: Dan Abramov I think there will be a, I think we're, I think we're moving towards blending the boundaries a bit more, but blending the boundaries is, it's doing it well is tricky because you actually Want the boundaries to remain firm in the technological sense. So you want to make sure that here's a runtime, here's like a file I'm in, it should behave according to the JavaScript logic, right? It shouldn't be magically split into like pieces that I don't understand where the split point is. So I think like you want to have these like firm boundaries between them, but also you want these compositional properties where I can just import this client bit and pass information From it from the server as if it's just like a function call almost. And so I think we'll see more experiments with what this blending looks like and the firm boundaries versus fluid boundaries where it makes sense which approaches are actually kind Of resonating with developers. Paige Niedringhaus That's a perfect lead into the last question. Do you think we'll ever have fully bridged that gap between the back end and front end, or will there always be boundaries? They'll just shift based on what people learn and find works best. Dan Abramov Yeah, I think there are some approaches that are even more, I think, daring in some way than, for example, we have server components, right? There's this project called, I think, Electric Cl which also blends the server and the client, but more automatically from what I presume. I'm not very good at reading Lisp syntax and understanding fully what's going on. So I may not be the best person to advocate for it. But I think there is a very real gap between the server and the client, right? It's a gap in time and space, right? It's a gap in time because they execute like at different times. One of them is potentially cacheable. The other one potentially runs a lot more times in response to state updates and so on. So it's like, these are different pieces of code. And there is a space gap where it just takes time to move these electrons along the wire and actually, or photons. I don't know how it's implemented under the hood. But let's say the vibrations of the quantum field. But you have to, they're in separate pieces and they can't treat them as code that runs on the same computer, right? Like you need to incorporate that gap into your programming model as the first-class citizen. And so I think that is where it's going. It may take... I think React Server Components is an important innovation there. And I think it's an innovation that has been overlooked, honestly. And I think people will catch up eventually to what it actually does, which is it puts the network gap into your module system as a first-class primitive. I have a post about this. It's called, What Does Use Client Do? Check it out if you want to find out how that's done. But I think we'll see more of this kind of incorporating the network as a first-class citizen into the syntax of our programming languages and programming paradigms. ([Time 0:40:17](https://share.snipd.com/snip/d33d8f70-06a7-45e7-aa8d-2fbbf3f233bb))