Dan Abramov
===

Tejas: [00:00:00] Hi, and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics. Try it free at LogRocket. com. I'm Tejas Kumar, and today we have a very special guest, Dan Avramov, known as the React guy for his exceptional work on the React core team, and now working with the BlueSky team.

Welcome to the show, Dan.

Dan: Hi.

Tejas: It's so good to have you on here and I'd love to, to chat. Maybe for context for all the listeners, it'd be really great to have some type of summary about how you got , to where you are now. You said you discovered programming through making PowerPoints and learning about macros.

You also often talk lovingly about Visual Basic 6 and building UIs that way. So like, how did that then spark the interest in programming and ultimately lead to React?

Dan: Yeah, as I said, I found programming accidentally, I think I had a book about programming, but I didn't understand what it was about. I, yeah, I was just confused. But I love making presentations. like, I used to do a lot of presentations for school, just on random [00:01:00] topics, just because I liked fiddling with PowerPoint.

And, you could have these pretty complex sequences of animations and things triggering each other. Like, You press a button and then something fades in, something moves. And I discovered this place in PowerPoint where you could press a record button and you can do a bunch of stuff and then you could stop and then it would generate a bunch of code.

And again, I didn't really know what code is at that point. And I didn't really even know English much, except for, like video game level, like any like options or like settings. Those were the words that I knew. Yeah, I just started to like, uh, you know, in the code that it generated, I remember I was just like moving some element on the screen and it generated some code that would say something dot left like equals like 30 and then when I changed it to 50, I noticed that this thing has moved like further and I was like, oh, okay, I understand how this works.

And it was pretty cool that you could also press a button and see all the different [00:02:00] uh, you know, you could press the dot and then see all the different properties. So I was just trying everything and trying to see what works. And eventually I bought a couple of books because that was before you'd learn programming from like the internet.

At least like in Russia, it was not really. I guess like I wasn't using the internet much yet. I was like 12. And yeah, I bought a couple of books and that's how I started learning. And I didn't really think about pursuing it as a career or something like this, but it just happened that I enjoyed doing it.

yeah.

Tejas: That's so, interesting. So it's, it started with presentations and if we look at the, Arc of your career. A lot of the I'd say recognition you've got is from these really high quality presentations that you've given

over the years. 

Dan: true. Like, I don't use PowerPoint, but I still like to do presentations. Yeah, it's been a while since I've done one,

Tejas: I, you know what? I think, Dan, I think we need to see another one. So what? Because. There was the React, what was it, React Hot Loader? I believe you presented this at React Europe, right? Way in

Dan: that, that was my [00:03:00] first kind of big talk uh, 2015, I think.

Tejas: And

then there was the JSConf Iceland one with suspense. These talks are so memorable. And, I've always had the question. I'm sure the listeners have always had this question about why, how does he do it? Turns out it's just something you've been doing since you were 12 and it lends itself well to react because react allows you now to make these types of things on the front end.

I'm curious for presentations today. Do you actually use react? There's plenty of react based slide tools nowadays, or is it just Keenum?

Dan: I guess I did for the React Europe one, because that was the point is to show that, oh, actually I'm just, I don't actually remember. This was a while ago. I think my memory has gotten screwed in the last couple of years. For the React Europe one, I think I did use React because I was showing that, Oh, actually this is like an app and I can do a bunch of stuff there.

But since then I've learned about Keynote and Magic Move and you get addicted to Magic Move, like this thing is just, yeah, so it's [00:04:00] so good. So I think that's I've been using Keynote for a while. And then for the last couple of presentations, I think I just used. I didn't really even do slides. I just did like a markdown file that I scroll.

But I think I've given up on making effort. It's not a good thing.

Tejas: I can relate. And I think this is the trajectory of most people who do a lot of presentations. Because I remember a great presentation from Sophie Alpert at ReactConf 2019 where also it was just Visual Studio Code. And here, I'm just going to show you some code. And the slides were just basically comments.

I see this pattern a lot. And yes, I hear that it's this absence of effort, but also it may just be, you know, reprioritized effort to speak react, right? You're prioritizing effort on the code side instead of on like magic move, which may be arguably better but anyway how did that then evolve to vb6?

Gosh, man. I've heard you talk about vb6 a lot just how you can drag and drop buttons and then you add logic to them and so on. PowerPoint, clear. You bought a bunch of books. [00:05:00] When did VB6 enter the picture? And then after that, maybe we can talk about how that moves towards React.

Dan: Yeah, so for me it was like, I started with PowerPoint, and PowerPoint had an embedded programming language in it, which is called VBA, which is Visual Basic for applications. So that, that was in 20 what is it? 2002 maybe if I'm 2003. I think that's when I started. So I was like 11, 12 and. I just bought a book about VBA and it just mentioned that there is a thing, you don't have to program inside PowerPoint, you can also just write programs for Windows, which was what I used at the time. so I, I just I guess I didn't download it.

So like you can, I don't know if you even could buy like a licensed version in Russia. Like I'm not sure. I just bought we used to like, we used to have these kind of pop up stores that were like near the entrance to the subway stations. They were, just like random people selling pirated software on like CD ROMs.

[00:06:00] And that was the way, you could buy like Photoshop for two dollars. Nobody could afford, like buying software. That was like a ridiculous concept at the time in Russia, at least. And Yeah, I think like I, I bought VB6 and so that was like an extended, more fully featured version of the same programming language.

And so that's what I started with. And then it was discontinued. So it was like Microsoft went with, because, it wasn't a very good language. It was very limited. And Microsoft was competing with Java at the time and was pouring resources into NET as a platform.

Which hosted multiple languages, but one of them was Visual Basic NET. It was a different language, but it was like an evolution of Visual Basic that targeted the NET platform and the runtime. But it, it always felt kind of second class.

And the first class language was C sharp, and so I was like, okay, I guess I'm learning C sharp now. So I learned C sharp. I got my first programming job. I did C sharp for maybe three or [00:07:00] four years and did a little bit of native development with C sharp as well for iOS. And eventually I got into JavaScript and web, and I did some JavaScript with Angular and eventually tried React, that was in 2014, I think, so that was, just a year after it was released, I initially like, I didn't really understand, the JavaScript ecosystem at the time, I was pretty new to it so I had a lot of help from my colleagues, and the first time I saw React, I thought, that, that looks kind of silly. And eventually one of my colleagues was like, no you should really try it. And so I tried it for a single Like button. And it sounds simple like a like button, but it was actually pretty dynamic because it needed, to show like you like this, or like you and this person like this, or like you and two people, like this.

And just being able to write this as an if condition and not think about whether this is the first render or an update I, I understood [00:08:00] why and I had the same problem. Like we had kind of a custom homemade diff in for like real DOM. So it was actually like really slow, but I understood what problem it's solving.

And so we ended up like rewriting our product in React at the same time before there was React Router, before like React Ecosystem existed. And so this was. I think like I just got there early and so I had to build a bunch of stuff so that we could actually use it in our product and that's how I got like familiar with React.

Tejas: that's really awesome to see the full story, right? From PowerPoint to VB6 to NET to see, I didn't even know about the NET and C sharp piece and now finally to React. It's interesting. I also picked up React in 2014. And man, like I got laughed out of the room. I was a somewhat early career engineer and quite naive.

And I saw this and I was like, Oh, this makes sense. JSX totally makes sense because I know HTML, we know HTML. And so bringing that. Into JavaScript, it clicked for me, but I showed it to a number of senior engineers on my team [00:09:00] and they just literally, they're like, what is this? This is coupling. You can't do this.

It's bad. And for me, full of imposter syndrome, I was like, Oh my gosh, okay, sorry. I guess I've made a mistake. And, fast forward a few years and it turns out, I guess it wasn't it's interesting to hear you had a similar experience. And so then, okay, you started working with react which sort of puts you at that point in time in a similar place as most people who build with react today, even as the biggest UI library, but then you.

joined the react team, which puts you in a somewhat different place from those of us building on re you went from building with react to building react. What is that? And I asked because I'm somebody who looks at the react open source code base and I go Oh my gosh how can I contribute to this?

So what was that? Like, Was there onboarding? Was there explanations of where things are. I mean, It's a big monorepo was there some type of warning against this? Do not use or you will be fired internal thing. 

Dan: Yeah, at the time it was simpler, right? But it also didn't scale. So I think like we were, like at Facebook, we were hitting the limits of what React completely client side, [00:10:00] completely synchronous, like traditional kind of React approach could do. So I came at a pretty interesting time when I mean the code base was complex.

Like I think that's like in general React's philosophies, we're happy with our code base being complex if that leads to better composability for application code. Because React acts as a coordinator, right? That's what it does. And so if you try to coordinate, things written by different people in a way that still makes sense.

each feature becomes intertwined with all other features because you want all of them to work together. And so that, that is like a very tight concentration of concepts. And you have to really think through, like how the algorithm should work and what kind of instructions are you designing?

So that even if, React can afford to be complex because, We're happy to spend a few weeks thinking like on each kind of small change. But then, the goal is to enable application developers to not have to think about those things. And so I came at an interesting time when [00:11:00] we were.

About the rei rewrite react, but it was not decided yet. So this was 20, 2015 And I think we started our rewrite project in 2017 if I'm not mistaken And so the end result of this was the react 16 release which had Almost no breaking changes despite being rewritten from scratch. So that was like an interesting process and the goal of the rewrite was to just replacing the architecture, the internal architecture of React with something that would scale better and that would enable, like, all of the things you're seeing now from hooks and suspense.

And server components, all of these things were enabled by this rewrite, which Sebastian kind of, Sebastian who was leading the team for a long time and before him, Jordan, the creator of React was leading the effort. So this is like a product of their minds.

But at that point it was interesting because I was just on board in on, and I was trying to figure out how [00:12:00] to add some debug only tooling to react, like some kind of developer. I think something related to debugging performance.

And I just couldn't understand the constraints. Like Sebastian was saying oh, it should be able to work with two versions of the same tree. And I was like what is he talking about? And actually, I shipped a few small changes, but there was like a long period of a month and a half where I was just trying to, figure out like what I need to do.

And it wasn't really going anywhere. And then Sebastian ended up just like flying to London for some other reason, and we just spent eight hours together and then I understood what he wanted. And and I shipped that refactor I think with onboarding on the React team is a bit hard because you have to build up a lot of context so we haven't been, like, super great at onboarding people as a team, but, it's a difficult project to work on.

Tejas: I think that's some really awesome senior engineer energy from Sebastian that Like he didn't fly to London, like explicitly to meet with you, but the fact that he took the [00:13:00] time to really explain it. It's something I feel like a lot of engineers listening can learn from because oftentimes what we see, especially in younger startups is, Oh, you should just know this.

Come on, man, get up to speed, start shipping. And it's so great to see him actually take that time and help you. So it sounds like the onboarding was somewhat involved. But after that. It got way easier, and of course, you ended up contributing quite a bit of code to that. At some point, refactor happened, and this, I'm assuming, had a lot to do with the fiber reconciler, enabling this CPU IO split that you talked about in JSConf Iceland.

And since then, we've seen things like hooks and suspense and so on. , Yeah, that brings us to react server components and recently on X there's been a bunch of people saying RSC is mangoes, RSC is paint, RSC is pudding. And I was away on, on holidays and I came back to this and I was like, what? What's happening? Where did this come from? Could you maybe speak to that?

Dan: Yeah, I think I may have accidentally started it. i'm not sure so I wanted to restart my personal blog because i've been not writing for a couple of years because I did [00:14:00] do a bunch of writing in the past couple of years, but that was for the React official documentation, and I kind of burned out on this.

And, when you write documentation, you can't really go on random tangents, which isn't something that I like to do. And so I was just trying to find my personal voice again. And, I also have never blogged about server components. So I thought that is something I do want to get to, because I do feel like there's actually like a lot to say there, but it's also tricky to find, the sequencing, like in which order it's such a broad topic that it's hard, like for us, it started in like, there are pieces of it that have been there since 2015. There are some kind of active work started in like 2018. And it's just, there's such a broad scope of what I could talk about it on that topic that I just don't know where to start. And also because, the reception has been quite mixed, polarized, let's say like a lot of people hate it or think they hate it.

So I think part of it is also like me trying to figure out, okay, how I feel like it's it's [00:15:00] pretty broadly misunderstood, I think, or like underappreciated as a technology and. yeah, I have been thinking about, okay, how would I explain it to somebody new or like how would I explain it from the first principle so that it clicks in the same way that it clicked for me.

And so I was just throwing stuff against the wall and trying different explanations, some of them like maybe nonsensical or silly, but it's just part of my process. And I was also happy that my Twitter account is working again, because my tweets were getting suppressed pretty hard but my new account works.

So I think I just also got overexcited

Tejas: there's so much in there that we can talk about, especially with regards to You mentioned you wanted to find your personal voice again through vlogging. And this voice you have or had on X was being taken from you. So that's a whole tangent we can go down. And maybe we will, but I want to talk a little bit about your takes there on RSU, on server components.

Because You mentioned you were just throwing a bunch of stuff at the wall, and some of it may have been nonsensical. What, in your mind, was the most strange [00:16:00] take from your thought process? And this doesn't have to be something you wrote down, it could still be something you're thinking about that you'd like to share with people.

Dan: I don't know you're, you're trying to, provoke me, because then I'll say it, and then people will

Tejas: Say it! If it's context appropriate. Obviously, I'm not trying to provoke you, but I do think It's worth hearing, right? Because you see, it's such a broad topic, and it can be looked at through many lenses. If anything, it will promote people freely thinking without constraints about this, which I think may be helpful to understand the mental model.

Dan: Yeah, so I'm not speaking for the React team here. I actually I haven't talked to the React team for a little bit. I've been pretty focused on just trying to ramp up and learn React Native for my job. So I was actually pretty detached. So this is just, me screwing around.

But one analogy that I And I'm not saying, that analogies are actually necessarily helpful, like I'm not saying that anybody would understand it. But I think the kind of the key defining thing in the React server components, like the architecture is really that, that it happens in two phases.

So when people think about the, server components and client [00:17:00] components, like you can nest them. So you can put server components into client components. But I think when people look at the code, they often look at it from client centric perspective. So like when you look at a component, you think, Oh, this is a thing that like runs in the browser.

And I think when people see server and client components mixed, their mental model is that when you see a server component, it must be doing some kind of a server call. Like you expect that if you see something, like somebody told you, this is a server component and you see it in JSX, you're probably thinking, Oh, this thing is probably going to the server, but that is a completely wrong mental model.

That's not how server components work.

Tejas: right, That's not a server first The server components are the exception, not the norm, is what you're saying.

Dan: No. So what I'm saying is that in this paradigm, the way to think about server is really it's the past it's like your client, your normal components, which are now called client components, but it's just the same concept as React components you've had before.

they had a past life. If you [00:18:00] think about, any like div in traditional kind of forget about React, right? Like, If you think about just any DOM element, like a div on the page where is it coming from? What was the program that told this div to appear here?

And so maybe it's, maybe it's a script tag. Maybe it was it's some kind of client side script tag. Maybe like it's React, or maybe it's like Angular, or maybe it's your own like DOM manipulation code that just called like document. Wait element that created div, or maybe it's an HTML file, right?

So maybe like HTML is also a programming language. And maybe you could say that this div is part of the HTML program, right? That That's sent to the browser. But the thing is where is that? Program coming from like , there was a program that sent that script to you.

There was a program that served that the contents of that script, there was a program that served the contents of the HTML file. So unless you like literally wrote all of HTML, all of your JavaScript like all of your bundles [00:19:00] by hand, at some point, some computer, like at the very least, this code has moved from your machine to the deployed.

Web hosting to somebody's computer. So there was an opportunity to run code in the meantime. And so server components are really just the code that kind of writes the code, like that's one way to think about them. It's this is the origin of where your components are coming from.

And essentially the idea is when I usually think of that affection, you think about here's my component, I'm going to like. Talk to another server and , that's how I'm going to get a, you know, that's kind of how I'm going to get the data. But with the server components model, you're thinking of, if I want this data in my component, I just pass it from the server.

So it's not think of like fetching data, but more like just getting it by props. It's just your props are coming from the past because that's when your server components have already ran. And it's really like the framing that I'm, maybe I'll write a post with this title, but [00:20:00] the framing I'm thinking of is just React for two computers.

It's a programming model where. You have components, on the side where stuff is being written and you have components on this, like two gears that are, touching and spinning together and you have an opportunity to run some code on this side and some code on this side. And so the weird analogy that like people were making fun of, which, it's probably not helpful, but I can, I love to think of this as like , phase transitions.

Like you have ice that turns into water that turns into air. And like previously we had just one transition like this, so you had components, which you could think of, like water, and then you heat them up, which is like rendering, and they turn into air, which is like DOM nodes. It's it's turning, your JSX is turning from this like capital letter components to lowercase, and the end result is always just the DOM nodes.

And here it's just adding another phase before it, which is like ice melting into And so by the time the components reach your machine, it's all normal [00:21:00] react, but before that there was like another kind of components could run and those components could access your database or file system or whatever it's like on your computer or on the computer that, that you control, such as your server or your host or your boot process or whatever.

Tejas: I don't even find that confusing or problematic, I think that's a really great way of thinking about it. React that runs on two separate environments, and each component that is scoped to a specific environment plays a specific role. I, yeah, I don't this sort of just reaffirms the thought in my mind that social media does what social media will do.

Which will just take something and run with it, maybe in sometimes the wrong direction, but that's a really great way to think about it. And at least for me, it definitely solves that, that mental model piece. And it, frankly, it tracks with all the content you've put out on server components previously.

Like you and I talked a lot about Server components from scratch, this thing you wrote part one of on GitHub and tremendous. I think it just supports that instead of contradicts it, right? And what I've been hearing on social media is, oh, it keeps changing every [00:22:00] year. But I don't know, from what I can see now, it doesn't.

Dan: I think if you forget about react for a second and they think of it as PHP components and jQuery components. It also kind of makes sense. People say, Oh, it's so weird that you can't import the server components from a client.

But it's the same, it's like, of course you can't import PHP code from jQuery code because jQuery code is already, it's like, are you inside the script or are you the thing outside the script? And it's really that's, I think that's the weird, we didn't have. a programming model before, where you could not only have functions inside functions or something like this, but where you could step outside the matrix and now you're not the code inside the script.

You're the code That kind of writes the script and you can just pass data to that code through the boundary.

Tejas: The multiverse is unlocked to you, I see exactly what you mean. That's super, super useful to, to help, I think, me and all the other listeners understand server components. I do want to acknowledge, though you [00:23:00] mentioned this yourself as well, when you were onboarding, React was much simpler, right?

Because it didn't have all this, the multiverse wasn't open to you, so to speak. 

Dan: I,

I would say it's it's actually I do want to contradict that because like server components, for example, doesn't actually it's not even in React. So the React that you see, you know, that is also the part of the point is that by the time something gets through the browser, it's just the React so server components is like a layer before it. That just executes some components early, and then the output of that is the normal React tree

that you use. The server components doesn't,

Tejas: But as a developer, you have to think about that. You

You have to think outside the script tag. We used to think inside the script tag before And so to some level there is more complexity there because most of the people who started with client side React are so conditioned to think inside the script tag.

So now to say, hey, there's a whole new world out there. is Is wild. So the question I have to that is, is it, and this is maybe controversial. I hope it isn't. I think [00:24:00] it's a good question, frankly that most people have is it worth it? Now I need to add a caveat. To me, it certainly is because you can just fetch data on your components.

I've always wanted that. I think a lot of us have, but then there's a requirement to Move a lot of your logic that was client side to the server, and you may not have access to a server. You may not, have played in that as a front end developer for a while. It is increased complexity, and I guess the easy answer here is it depends.

But I wonder if there's more we can say about that.

Dan: Yeah, I mean, is it worth it? It's I don't know. It's a very vague question, but I want to argue a little bit again So imagine a completely client side app, so like everything is client side you know, you do like data fetching on the client side and so on. this is also a valid app in the React Server Components model.

It's just the way you would express it is like your entire, you know, you have your like, uh, root component, or like your, like entry point. Yeah. Like your root application component, you add use client [00:25:00] at the top. So what use client does, it's not some kind of de optimization. It's more like a declaration that I can receive props from the past, like I can receive props from something that's already ran and it's like an entry point into this uh, you know, I can be a script tag.

That's essentially what it's saying. And then you're like in this kind of app, you would only have one server component that just renders your application tree. So it's, a completely 100 percent client side app . It still fits into the model. And , there are some practical kind of limitations to that as in like a framework, like next JS might not support the pattern.

Like you can't just take create React app and like stuff it into next JS and then say, okay, this is now I'm, I have one server component that renders this entire app and it probably like. You probably won't get a lot of benefit from it anyway. It's just an opportunity now you have some place where you can write, you can write some logic that runs at the build time if you want, or at the [00:26:00] request time if you want but , that can access local resources in both cases.

And so with time you can move more things to that side move them , out of the script tag into the thing that, that writes the script tag. But I think just like from a theoretical or just program and model perspective, all like client side, completely client side apps are a part of this model.

They are, valid React Server Components apps. So it's really an extension. , it's not a thing that like changes. If you want to take full advantage of it, like you can, right? And in that case, . You can write a full stack app that's spans both worlds. If you use PHP with jQuery, except that, these things actually compose.

So you can put the PHP ish things into jQuery ish things and it still works. But you can also just use like a little bit of it. And I think that's why to me it's worth it is because it's yeah, you do have to learn. More concepts, but also some concepts melt away, right?

Because now instead of coming up with ways to pass data, like [00:27:00] from the server or like from the build pipeline, you just pass props instead of ways to like exposing like APIs things like APIs and write and rest APIs or whatever you have an ability to just pass functions from the server to the client and they will automatically become APIs and that's called server actions.

It's kind of like an extension of the model that lets you think about server and client as two pieces of one hole that have doors inside each other and you can use like as little of it as you like but I think being able to do that is makes it worth it.

Tejas: Yeah thank you for that answer. It's really nuanced and exactly what I was hoping for. I'm glad you acknowledged there may be more things to learn, right? Because fundamentally the way I've heard the core team and the way I also agree that React is defined is as a developer experience tool.

You said it yourself, it's like a coordinator. And React's main claim to fame is DX. Like you declaratively write your JSX and , it just works. That's the promise. I have a hard time reconciling several components into the story for that reason. Because you just mentioned [00:28:00] your entire client only app can totally work even with the RSC model, but you need to have one component on the server.

And this sounds trivial, but that introduces a whole new set of questions for the everyday, like client side only front end developer, right? Oh, I need a server now. How do I go about this?

Dan: Well, No, so when I say server, I don't mean like a physical server you have, if you're shipping a client side app, there is a server, like you're not serving , your app from your own computer. You're serving it from some other computer that's running somewhere. Maybe you want that server to be static.

In which case you can like what you probably are doing is that you're like, there, there is a computer on which you run. For example, JS minification, right? Like somewhere in the pipeline between your computer where you're writing the code and , user's computer. Somewhere there is a computer that minifies JS.

So let's say, what if you could also use that computer's resources? To also write some code in the shape of react components that can [00:29:00] run some stuff ahead of time. And so maybe this is on your own computer. You just press like NPM run build and some components run at the time, maybe it's during the deploy.

Maybe it's on an actual server. So it's not about now you have to run the servers like you already are. We just give you a tool to write things in the shape of React components so that you're able to compose those pieces in the same way you compose them normally in React. And then speaking back about, like you said, React's, important thing was DX developer experience.

I. I don't really think about it like this way. I think the point of React is that it lets you name things. It lets you give names to things, and then it lets you Put them into each other and they still make sense, right? Like it, it works Lego blocks. So you can have like a Heather, you can have a footer, you could have a tab panel or whatever, and you can just put those things together.

And so server components fits into this perfectly because when you, for example, if you have like a [00:30:00] carousel of like article previews, but. like from the user's perspective or from a designer's perspective, this thing that is like an article preview for a post with a certain URL or with a certain slug, but then you can't actually write a react component like this in client only react because well, how is it going to read the content of that post?

, if you're into like 10 of them, are you going to make like 10 fetch requests to like. I don't know, GitHub or like where you store in those posts just to render a carousel of previews. No, like you have to write some code either like you have to expose the API endpoint somewhere or you have to write some code that pre compiles previews so you can stuff them into global variable so you can read them later.

Dan: But what if you could just pass props from one part to the other. And so this is really about being able to give names to things that really reflect what they're doing. So you can have a carousel, which is a client component because , it requires [00:31:00] knowing a state. So it requires knowing something that only The user's machine can know like how many times has the user clicked the next button or like how many seconds have passed.

So that has to be a client component, but then you can put into this carousel, you can put post previews, which are server components, which means that they can do read file from the file system, either on your computer, if that's where you're running this step or on the server, like you have to do this work anyway, at some point, then we just give you an ability to compose those things.

Tejas: that's interesting. I think a lot of the. Like mystery around this comes from people misunderstanding the term server because the way you put it. Yeah, it makes sense servers are everywhere like you get push that goes to github server, and then it probably goes to Netlify or some CI server, so servers are everywhere And I think this narrative of using what already exists is so so useful because I've spoken to as I go to a bunch of conferences and talk to a bunch of people and usually The fear is, oh, I don't know anything about server side code.

I just, write front end.[00:32:00] And so I think that would be tremendously helpful for people. We're almost at time and we have to wrap up. I would be really remiss if I didn't ask you some career questions. And then maybe we'll wrap up with this. You mentioned You know, you'd leave the React team after writing the docs and specifically you saw broadly a usable suspense data fetching integration shipping, and then they both released earlier last year.

And since then, you've joined blue sky. And you mentioned you're now learning react native, which I think is really funny because you don't react. If you could speak a little bit to that experience and then share maybe some closing thoughts About what's next for react and how you see server components and that story evolving.

Dan: Yeah, I've been wanting to leave Meta and try something new for the past maybe three or four years. But it just never felt like the right time. So we were working on the docs with Rachel and a few other people for a long time. And so I wanted to see that completed.

And of course, because, we started at this Architectural rewrite of React in 20 16 or so, and the things that it [00:33:00] unlocked, we were always talking like about what would the first class way to do that affection like what would it look like? And I think I did want to see that, that being completed.

And so a prouder is the first integration that feels like a cohesive of. Like implementation of that vision, even if it's, in the same stage as like iOS 7. So it's very raw right now, but it's also pretty exciting. And so this just felt like the right time for me to try something new.

I wanted to do some product development. So on this guy, I'm working on the client app. It's a universal app. So it targets both web iOS and Android. It's actually using Expo, so , I've learned some React Native, some Reanimated, a bunch of libraries in that ecosystem. it is challenging, it's different because there's just so many layers in the stack.

I feel like with React, it's all working on React, it's, sure it's hard, And I didn't work on the hard parts. So like that was mostly my teammates, but we're going to react as hard because you have to think about concepts and like how to [00:34:00] enable things to compose, like how to enable things you know, you put together arbitrary user code and then it still works, whereas like in the product code, it's more like, This box is like 10 pixels left on like one of the platforms. And the reason for it is like a bug, like five layers of the stack down and good luck figuring out like where the bug is. So it's a completely different type of work. And I enjoy some of it, some of it I don't. But it's nice to try something new and also to gain like a first.

kind of perspective of what it's like to actually use React Native pretty heavily. so that's where I am right now.

Tejas: You're working on BlueSky, and you have this like massive following on X. Do you feel like you've been silenced on X because you work at BlueSky? Or I haven't really used BlueSky in a while. how's it going? What are they trying to, what's the edge, 

Dan: yeah I honestly don't know what happened to my account, on Twitter or X, it just stopped showing up in the For You tab which is actually a perfect pitch for BlueSky, because the whole point is, Like, why is our, following [00:35:00] graphs or like our kind of interests or like our posts why are they locked up in like a database inside some company that might just decide to flip a flag on your profile.

And 

Tejas: But didn't 

didn't they say the algorithm is open source? I saw YouTubers make

Dan: They threw it over the wall like once, but it doesn't, they're not like updating it. And also like, how can you debug? Like I can debug where my account is broken. So I just made a new account. So I have 10 approved too now, which actually works. Initially it was suspended, but also Had some kind of restrictions, but then they were lifted.

So it finally works now. It like a few, a few months later, it finally works. But yeah the point of blue sky, I guess like the way I would explain it to engineers is It's taken all the things that he would, you know, if you were building Twitter, you'd have different databases and like indexing services and so on.

So what if you remove boundary of a company around it and instead anyone can run those services. [00:36:00] And so your data kind of becomes like a Git repo. Essentially, it's like a similar format. It's just a Git repo or something similar to it. It could be moved to a different host.

So your posts, your likes, they're just like records in this repo. So if you're unhappy with your provider, right now there's only BlueSky, but the idea is to open it up so other companies or individuals can run their own nodes. Then it's, like more similar to the web where you can host them like with different providers, you can move your content.

But then there is a layer that aggregates and that is also like, other people can also run, different versions of that layer, but it's like Google indexing content. So what this gives you is that It's decentralized on a technical level, but it feels like a centralized app. So you can like, if you like something, you see the like, it propagates.

So you, it feels similar to Twitter, except that actually like multiple companies can operate it. And it. Like different services can compose. So you can think of like moderation [00:37:00] or content filtering, or there are custom feeds, like you can write your own feed, people can install it, make it their main feed.

So all of these things are open source and they can talk to each other and you're not beholden to one company. So that's the idea. I don't know if it's going to work out, but it makes a lot of sense to me, so we'll see.

Tejas: Awesome. Yeah, that's such a great explanation because it's ultimately liberating data and ownership of that data from one potentially evil for profit company to the owners of the data, the creators of the content. And I think that's so eloquently put. It also sounds like you have a thing for composition, man, whether it's composing components or

Dan: Yeah, it's composable social media. that's, That's really what it is. I don't know if that would resonate with, people broadly, so I don't know if that's a good tagline or not, but it is essentially composable social media.

Tejas: Well, Dan, listen thank you for taking the time to come chat with us. It's been such a, as always, right? Such a pleasure, such an illumination talking to you and hearing about your take on server components, the onboarding process at Meta, BlueSky, all of it from me and the [00:38:00] rest of the podcast.

Thank you. Thank you so much for coming on board.

Dan: Thanks.