Lee Robinson === [00:00:00] Hello and welcome to Pod Rocket, the podcast brought to you by Log Rocket. Log Rocket helps software teams improve user experience with session replay, air tracking, and product analytics. Try it free@logrocket.com. With us today is VP of Developer experience at Versace Lee Robinson. Lee, welcome to the show. Thank you for having me. I'm excited to be here. Yeah, me too. Me too. Uh, can you tell us about yourself and your current role as VP of developer experience of Versace? Yeah, absolutely. I work at Versace, which is a front and cloud, and we try to make it really easy for people to deploy and get their sites online. And in my role, I. Kind of manage and lead our community of developers for both Versace and n Gs, which is a React framework that we created. That's [00:01:00] pretty much what I spend all of my time thinking about and obsessing over is our community, what they want, how we can make great things for developers to use. Awesome. Ever since like Versace ship, it's been kind of all the buzz for what I could tell. Um, so we have a lot about, a lot of talk about there. Yeah. Uh, so like, it seems like Versaces launched like a suite of products. Last week as part of its front end cloud. Can you kind of explain like why Versace decided to step into the storage industry and what are the problems you aimed to solve with, uh, your three storage solutions? The interesting thing here and kind of why now for getting into this really interesting and exciting part of the market is we feel like there's an opportunity to think about the pairing of some of these tools as if they were designed for the perspective of a front-end developer. So databases, we've previously talked about chron jobs in the past as another product. All these other pieces of the development workflow that historically have been thought kind of. Back in [00:02:00] dev first, or database only first, for example, right? When you start to use these tools and integrate 'em with your front end frameworks, your next GS Yoursel kits of the world, you want tools that pair really well with these. They work wherever you want to deploy them, including new providers like Brice that have primitives, like serverless functions. So really the genesis of us getting into. The storage space was partnering with some really great companies to have a great experience across the entire stack. When you're deploying to Versace now, I think the way that this is the most paramount, I think for people when they use Versace is I can go and deploy. A full stack application, a reactor, spelled application with a database, with Postgres, with Redis, with object storage. It can have chron jobs. CICD set up a global edge network. I can do all of that in about a minute when you deploy it to [00:03:00] Versace. So we're trying to make it as easy as possible for people to get started with the tools they need to build a really powerful site. And this was one of the main things we talked about last week at our Versace ship event, which was really just an opportunity to get our community together and share some of the things we've been working on as a company. So it's like, in my mind it's, as a pro engineer's perspective, it's like I just want a one-stop shop. I don't want to think about pulling in all these tools. And with this solution, I can pretty much just set everything up really fast, like pain free, essentially, especially in my perspective as an educator. I have definitely struggled in the past trying to teach people something where I had to pull a bunch of tools together. From the beginning of my career when I was learning to code and I was using Heroku, there was such a simplicity to having all of those tools, having that toolkit available for me to use that had everything I really needed. And I think they did a fantastic job there. So that's the [00:04:00] type of experience I want to provide to. Developers learning to code for the first time developers who have been coding for a while is a place where I can really easily get all of these powerful tools. Yeah, and I think that makes sense cuz it just allows us as engineers to just be productive and kind of worry about our product versus trying to pull in all these random tools and hitting that pain point. I think that's super awesome. So the next thing I wanna talk about is Versace has also made security a key priority for its front and cloud. Can you kinda elaborate on Versace's secure compute solution and how we'll support enterprise businesses? Yeah, there's kind of two sides to the, the coin of the announcements last week. There's stuff that's for the hobbyists, for the devs who want to build stuff and just start their next side project. And then there's also stuff for the enterprises, the large businesses, and secure compute is a really exciting innovation there. So we of course, just talked about the. Brand new databases, you're starting from scratch. That's gonna work really well for some people. But for a lot of the [00:05:00] larger companies, they have massive databases and lots of existing infrastructure, and they need a way to really securely connect to those products in a way that has the same developer experience of what they've come to love from the rest of Versace's products. So the idea with secure computers, let's do exactly that. Let's have our serverless function and experience. The developers love today while still allowing folks to securely connect to their existing backend infrastructure. And this is something that a lot of our enterprise customers have asked for, and I'm, I'm really excited for this to be available. I know you want to target enterprises. How does the storage approach kind of fit in there? Are you targeting, like, are you expecting enterprises to buy into that or is it more of indie hackers or like smaller startups? We actually started by rolling out our storage offerings to our free tier and our pro tier. We're not actually rolling them out to enterprise right now, and I kind of think that moving forward, [00:06:00] I would expect for our database integrations and our database products to be something that more of the hobbyist and the small to medium businesses want. Because enterprises typically, they have the data layer set up somewhere. Maybe they wanna add some caching on top, and that's something that we could help with. Oftentimes they have large distributed systems already in play. This next feature is something I'm super excited about. It's for sale spaces. Can you tell us more about the features and functionalities that come with it, and how it makes managing for Sale projects easier at scale? I think the best way of summarizing it for me is how do you take the knowledge of some really, really, really incredible engineers who deeply understand the web, deeply understand all of these new frameworks. And kind of bundle that up and put it into something that can be accessible for teams everywhere. That idea also paired with this idea of how do you take the lessons [00:07:00] of companies building software and the largest organizations in the world who historically have built this tooling internally and closed source. How do you combine those two ideas? To have a suite of tools available for the rest of the enterprise teams or the rest of the software teams to get those insights. One way I like to think about this with spaces, which is a suite of tools that allows you to essentially scale software quality. That's the way I like to describe it, and one of those tools is through conformance. So putting checks and balances in place to help your team have fast and efficient code, do the right thing. And we'll talk about approvals in a second. But the interesting thing with conformance, I kind of think about the most common conformance tool that a lot of developers know is yes, lint. I can set up es lin on my repository. It has some rules. It can tell me if I'm doing something incorrectly or it can [00:08:00] gimme suggestions, both warnings and errors. The interesting thing is with our conformance product, there are some limitations of ES lint that typically really large companies end up building their own systems on top of. So Slint isn't available to track changes across multiple files. So for some larger conformance checks, it's a little bit harder to understand the entire module graph essentially, and how things are related more than, oh, actually don't import this thing inside of this file. So going a level deeper on the type of rules and suggestions that you can provide. And also it's. Pretty easy to be able to just slap a ignore on there and move on with your life. And one of the systems with conformance through spaces is trying to make that process a lot more structured. So if I am disabling something that my organization has decided is very critical to the business, I want to have that in a [00:09:00] centralized configuration. Where the proper code reviews and approval happen before that thing gets turned off, so somebody doesn't check in some insecure code into my repository, for example. So the second part of the spaces product is code ownership. And I think that the key thing here is. A lot of software tooling today has been designed for a multi repo approach rather than a monorepo approach. And I'm sure we could talk quite a bit about mono repos and why they're great. But the interesting thing here is just re-imagining some of these existing tools. But in the perspective of aada repo. So for example, a code owner's file is something that's, I think some people are familiar with, uh, with Git. But it is a singular file at the root of your repo. So the idea with code ownership is kind of tying this thread between advanced rules to help you scale software quality. And making sure, deeply nested somewhere in my monorepo that the right teams are reviewing and approving [00:10:00] and understanding all these code changes that go out. Because as you scale from a hundred to a thousand to 5,000 engineers, you really want to have these systems in place to scale that quality. Like in my case, I do have like a turbo repo monorepo, um, at my job, but we don't use njs. Would I still be able. To leverage this product, or do I have to use njs to kind of enforce these kind of consistencies? You know, we've had a few smaller products like analytics that you can use without hosting or deploying to Versace. This is a big step in that direction as well too. You can actually use the space product without deciding to deploy my next GS application to Versace, for example. It will work with any framework actually. So if you wanted to use spelt or nt, um, that would work as well too. And the idea is to be deeply centered around the monorepo. And while the first version that we're launching, uh, of course, is deeply integrated with turbo [00:11:00] repo, that is a platform that can be extended on in the future as well too, if there's a different monorepo tool that you prefer to use. So I'm also very excited about that. That's awesome. Yeah, I'm definitely excited to kind of get my hands on it and kind of play around and see how, like, how my team personally could probably benefit from it. So super, super awesome to see. And the D UI is amazing too, as well. Yeah. Shout out to our design team. I really love the work that they've done to condense some really hard things into a, a UI that's approachable, like trying to tackle how you organize. The relationships across your code base, assigned code ownership rules and the different runs for each of the tasks in your dependencies. It's a challenge, uh, which kind of is a good segue into, um, the next, uh, section, which is for sell's visual editing, and it seems like an offering anyone can use. Can you share how this new feature simplifies the content editing process? I think the best way to [00:12:00] explain it is to work backwards from the pain. So the pain that I've felt many times as an industry removed from a traditional CMS to a headless cms, where we swapped out our front end for something newer like an X GSM Versace. During that process, the content editor still struggled a little bit when trying to understand the relationship between the front end. And the rest of their content in whatever tool they decide to use for their headless c m s. So the idea here is trying to bring those worlds a little bit closer together without going like full square space. That's a different level of abstraction. One level up. We still want developers to be able to pick the best tools for the job, the best headless cms. They want the best front end cloud and and framework that they want. But helping those two work together a little bit better I think is really powerful. So for example, when you go to a Brice deployment, we have this little [00:13:00] toolbar that pops up and you'll be able to click an edit button. And when I'm viewing some content from my cms, I can click that edit button. I can on the screen will highlight the places I can edit. I can type directly in there for simple edits, or I can get deep linked directly into my c m s for where that content is at. So for kind of the basic things, oh, it's just a simple edit typing into an editor on my actual website. And then for the more advanced stuff, I don't have to go dumpster diving through my c m s to figure out exactly where that content is. I can just link. Directly to it. So the whole point is to save, um, both developers and marketers and designers time in the review process of content. So the team has been busy with the launch of next GS 13.4. What are like the biggest highlights in your mind, uh, for this latest release? This was the big launch of the week in my opinion. I mean, I'm biased because I really love Next Js and I, you know, use it all the time. But this was one of the, the things I think [00:14:00] folks were very excited about. So I guess to, to rewind back a little bit, in October last year, we announced next JS 13 at next JS Comp, and we kind of set out this vision. Of, we've been working on this larger update to n gs for some time. About a year ago actually, we initially announced the plans for this new update, which we now call the app router, uh, originally published as the layouts R F C. In October, we released the first version of this for people to actually get their hands on in beta, and then we've been working really hard as a team to get this out and into the community's hands and get feedback and super, super excited that with 13.4, the app rider is now stable. The key thing here is how do you invest years of research and development time into. A new platform for the framework without leaving the community behind. This [00:15:00] is the core challenge. You don't want everyone to feel like, well, 13.4 came out, all my stuff is old. I either gotta update or you know, I'm out of luck. And this was something we really thought super deeply about. Because we didn't want to have a moment where the community felt divided on, oh, I have to move to this new way, or I'm gonna, you know, have some trouble. So a core principle here with the app router is that it's designed to be incrementally adoptable. And we actually recommend people do it this way versus a one large PR to move your entire app over from the pages router to the app router. And because of that, both of the pages and app router can kind of harmoniously live together in your application. This is what we're doing at Versace right now too. It also helps signal this message to the community that I think is really important, which is the page's router isn't going anywhere. There's many, many applications live in production today that are relying on it that will still want updates, and we're still adding new features there as well too. So I'm really excited about that as like the core [00:16:00] framing of getting people on board of like, okay, why would I even consider this? Now the challenge and the interesting part is my goal is to convince folks that the app router is worth checking out and trying out and incrementally adopting to. Because there's some really, really exciting stuff. I think the biggest one for me, Is a simplified programming model. In our keynote video, we basically said it was like bringing the best parts of PHP Rub on rails and react into next js, which is really funny. There's been some fantastic memes about this. Next JS is php. Now, you know, we've, we've came full circle back to Rubion Rails and like, it's actually kind of true in some ways. There were some really fantastic things about those tools that. We want to have that same type of experience. When you get down to the details, that's where you start to see the power of the architecture that React has been building out with server components and suspense. You can kind of think of the app router as one of the first places that is combining. A [00:17:00] lot of the architecture direction that React has laid out into a framework that folks can get their hands on today and start building with. And I say first because I don't believe it will be the last. I think we are helping build out this architecture. With the React community at large. And I'm really hopeful some of the initial work done by frameworks like Gatsby, um, some community members have also started building their own server components, frameworks. I'm sure this is gonna continue to pick up in the future, but the router in the framework is the key of what brings all of these pieces together. So I'm very excited to see the community's reaction to all of this, and hopefully they enjoy the programming model of just writing Async Await. In my component to fetch data and layouts being a primitive, that is just composing react components. There's no specific next JS api. You're just. Passing in the child of a rat component, uh, and more and more and more. And I could go on there, but I think [00:18:00] that's gonna be the thing that's very exciting about the new direction of n gs and the deep integration with not only fetching data, but also mutating data with server actions. This one is one that's been talked about a decent amount, I think, in the developer community right now because it is a feature. That has been designed and layered across the entire part of the ecosystem. There are core foundational pieces that have been developed by some of the React team members who work at Versace in conjunction with the React team at Meta and the independent members of the React core team that work in the community. They've all kind of worked together. On some of these core pieces that work for just every React developer, so whether you use something like Create React app or client side only React, you can still take advantage of this stuff. Then there's also been layering to those features that work for server side rendering, which is kind of how the pages router in next JS worked, where you rendered some HTML [00:19:00] from the server and then you hydrated on the client. And then finally there's also features that layer in for something like the app router that uses server components or other frameworks in the future that could use server components that run only on the server and allow you to have some powerful features for how the server actions integrate with the rest of the router and the cash and just the entire programming model. So I'm really excited about this because we're, while server actions are experimental, They've already allowed me to write a lot less code in the examples I'm building. So to make this really tangible, I think the norm for React developers for some time now is if I want to do data mutations, typically it looks something like this. I fetch in some data, I display it on the page, there's a button where I wanna add something, update, delete something. That has an event handler on click on submit that calls some function. That function, it runs on the client [00:20:00] side, right? So to do something securely, it's gonna need to talk to an api. So there's a use effect, or it calls my API somewhere and next, yes, it would've been an API route in, uh, you know, it could be hosted on a different server as well too. That API actually. Does some crud action on the database and then returns the result back. That result gets stored in state back in the client that updates the UI and rinse and repeat. This has been just how you build React applications for the longest time because for a while React hasn't really had a strong opinion about the layering of the client and the server and how to take advantage of the best parts of both. So with the new architecture and the primitives that they're. Releasing, there's an opportunity for next GS to deeply integrate with some of those and try to provide that seamless transition between both the client and the server. And in the context of server actions, actually, there's a lot of stuff that you can do server side only. So rather than having [00:21:00] the event handler and having the separate API out, wouldn't it be great if. Your code that wanted to mutate or update some data, it just called a function, and that function is going to run on the server. That is the most simplest programming model you could possibly have, and that's really what server actions enable at a high level. I haven't had a chance to mess with the server actions yet, but I've seen a lot of. Examples online of everyone trying it out and seeing what they like, what they don't like. So one thing I do appreciate is the incremental migration that you can do from pages to apps. Right? I think that's like, obviously Yeah, a community juror. I just, it shows that you're thinking of the community first and you don't want it to be painful. Cause otherwise no one will do it. Right? Mm-hmm. Um, but I'm curious, like with this incremental migration path, and you also mentioned you're still adding features to pages, is the future you see like there's always gonna be a pages directory and there's always gonna be an app directory. Is there always gonna be a divide, a hybrid? Like how are you envisioning that? Like are you [00:22:00] always playing to support both or Eventually going to. End up on the app directory. Yeah, I think the hybrid world is going to exist for a while, and I think it's good. I think probably multiple major versions. I think it would not be doing justice to the next GS community to remove something that so many applications depend on today, and it's just not a realistic timeline for adoption, especially for large companies. Um, trying to adopt something that's still pretty new. So yeah, this hybrid world where you can coexist with both will live on for a while. T b d on how long? But probably a decent while. And I think it's overall good for the ecosystem. The less forced churn we can have, the better. I think having stability in the JS ecosystem is really important. As an engineer, like you said, you can feel left behind very fast and then you start thinking you're just doing legacy things, you know? Yeah. It's such a tricky balance from people like myself. [00:23:00] I come on this podcast. I'm, I'm really excited to talk to you. I'm excited about some of this new stuff. I tweet about the stuff that I'm excited about. I can definitely see the perception where people in the community see myself talking about server actions or the greatest thing ever, lead one on this monologue about how great they are. Does that mean that I need to update everything in my app and move from event handlers to server actions? And the answer is no. The answer is, while this stuff is exciting, it's still super new. Server actions are experimental. If there's anything that I would love for people to take away today, it's that the approach that you're doing inside of the Pages router, it's not legacy. It's not bad, it's not deprecated. It's totally okay and encouraged, and hopefully you don't feel pressure to adopt some of these latest things. You should do it on a timeline that makes sense for you. It makes sense for your team. That's incremental, and it's the same thing, even going a step further for server components. When folks are starting to explore [00:24:00] the app router, they see, okay, I have server components and I have client components. Does that mean client components are a bad thing? Should I not be using those and I should only be using server components? And the answer is no. Client components are great and client components are what are allowing you to add interactivity to your application to help bridge that mental model. You can think of client components as everything that exists in the pages router today. So the reason for the distinction, at least the way I like to think about it, is it's just allowing you to be a little bit more intentional about what code runs only on the server and doesn't require hydration, and what code runs on both. I think that that flexibility is really powerful, but during the incremental adoption phase, it's totally okay to say, you know what? These are all client components. To get started, I'm gonna move over to this app router. I'm gonna slowly move and pull pieces to server components and move that data fetching on the server where it makes sense. Maybe I'll remove some event handler, some JavaScript here, and move that to a server action [00:25:00] instead. And effectively what you're doing is you're slowly taking advantage of some of these new paradigms and these new patterns, which hopefully the goal is that that will provide a better end user experience. I really wanted to call it out. Cause I feel like, at least from my perspective, there's like this slight divide, at least from what I can tell, like where people go all in server components, but there's people that are like, I'm not ready. Is that okay? I think it's great that you're kind of reassuring everybody, like, you know, you don't have to do this right now or ever. Yeah. Well to your point, I think it's a natural tendency to not like change. So when. People look at these changes, either kind of glass half full or glass half empty. I think a lot of devs are rightfully pessimistic about really anything that's new. They need to see it work. They need to see it validated. They need to see other people succeed with it. And then they'll consider adopting it. I think sometimes it's a mismatch between the developer advocates, developer relations [00:26:00] people. We're usually like the glass half full. We look at the world and we're excited about all the tech and the possibilities of how you could use these things, um, while still having some healthy skepticism. But we like to see where we're headed towards and it's a little bit different sometimes than. The kind of glass half full approach. So I try to hopefully bring a little balance to to both of those, cuz they're both very valid. So my perspective, it seems like Versace is just constantly coming out releasing new things. Like how does Versace prioritize initiatives? Yeah, I mean, first off, I have to just give the largest kudos and thank you to the entire Versace team. We have some really incredible, smart, kind, hardworking people who. Are the, the folks behind a lot of the things that you see me talking about all the time and I, I wouldn't be on this podcast today talking to you. I wouldn't be in this position if it wasn't for a lot of those people. So I'm, I'm really [00:27:00] indebted to a lot of the work that they do. It's what makes my job really fun, cuz I have the cool tools to go and build stuff with. Now, kind of going back to your question on how we think about what to work on, I'm also super, super fortunate that we have such an incredible community of people. Who are so willing to give us feedback on what's working really well and also places where we can do better too, which is also equally important. And that really helps us kind of right size and prioritize where we want to build, while also having kind of an opinion on how we think is the right way to build software, um, years into the future as well too, and bringing some of those things to. To market and to make it easy for people to use the rest of the tools that we provide. So I think tangibly going back to the storage products that we talked about and having really good, a seamless kind of first party integration into storage. This is something that I've been asked about since day one when [00:28:00] I joined Versace, and I think I, when I talked to Guillermo about it, it's really funny. He's like, he's been hearing about that since he started the company. It's been something that. Customers have wanted for a really long time, and it was finally time to do it in a way that we felt. Was doing right by the front end developer and giving them something that felt like an integrated tool with the rest of the front end toolkits. I personally just try to spend a lot of time talking to customers, both our customers who are on the free tier, our customers who are on our pro tier, so our small and medium businesses, and our enterprise customers as well too, and try to have a rounded worldview. On what improvements and things they would like us to build to make it easier for them to ship quality software at scale. I think, I know we've been talking about for sale, let's kind of pivot this to you. How do you prioritize your time? Like what are you doing day-today? I'm really fortunate to have some great folks on my [00:29:00] team who help us achieve our goal of really growing this fantastic developer community and educating the people in the community along the way. I personally really, really love everything about developer education. It's, it's what gets me up in the morning and teaching concepts that are maybe difficult at first, and trying to present it in a way that finally makes it click for people is something I get a lot of enjoyment about. So that's really where I'm helping steer the direction and the prioritization and the strategy for my teams working on these goals. So I spend a decent amount of time thinking about that. I also think it's really important for Derell developer experience, this umbrella of leader to be hands-on. If I wasn't coding, I would be a phony, right? Like if I'm not actually using the stuff that we're doing, then how can you trust me when I say that this thing is better than another thing? Just because I am leading teams [00:30:00] to help further the goal and the strategy that I want to help achieve. For Versace, I. That doesn't mean that I should completely step away from the craft and understanding the craft at a deep level, being able to talk about our products, especially on a technical sense, on a very deep level, is something that I really aspire to do. And I think it's something I'm constantly challenging myself on too, to try to dive a layer deeper in understanding on how some of this stuff works. And I think the last part would be, Just trying to deal with the communications, regardless of what size of team you're on, what size of company you're on, and what type of org you are, there's always little tweaks that you can be doing to better communicate with your team, with your company, with your community. And that's something I'm always trying to kind of tweak and iterate on. And I think one thing that's super top of mind for me, that I'm spending a lot of time. Thinking about is trying to help [00:31:00] bring the community along for the ride as we're building and iterating on things. Let me give you an example. So for in the past, Sometimes we spend a lot of time really obsessing behind closed doors about we gotta get this thing right. We gotta tweak this part of the product and make this thing and get it all ready and then ship it out to production. Something I'm trying to do a little bit better is kind of bring everyone along for that journey. Here's how we're thinking about this thing. Here are some of the decisions we made around this part of the product. Here are some things that we considered. What do you think about it? Person in the community, and help shape that as we go along the way. A subtle difference, but I think it's been good so far. One thing I I appreciate that you do is you do your Twitch dreams. Yeah. Maybe like once a week sometimes, but I, I do see you like I'll go in there, pop in, watch how you interact with the community if you have any questions. But also just like build, like you said, just you use your products. Right. I think as you build with your products, that will just obviously just deepen your, your understanding of anything. Right. And kind of find what you don't like and maybe find things that you do like. Right. So I think that's like [00:32:00] super awesome and I just love how you kind of put yourself out there. Cuz when I think of a VP, I don't. In my mind, I don't picture VPs on Twitch interacting with the community. I picture them, you know, bigger picture stuff and like yeah, they send their minions out to do that work. Right. So like for me, I take that to heart cause it just kind of shows like the perspective of how Versaces kind of approaching these things. Um. Mm-hmm. Yeah. Thank you. I appreciate that. I think first off, I love Twitch. I can't believe that I haven't been on Twitch for as long as I have been cuz I was always doing just YouTube. But Twitch is just so great. Um, and I, of course still like YouTube too, but the live aspect of Twitch is, uh, fantastic. One thing that I love about doing live streams, interacting with the community in real time is I'm kind of always refining. This message for how I teach the product, whether that's Njs or Versace, and continuing to iterate on the message that makes sense for the audience. And the only way you do that is when you get in the arena and you go on and you do something live and you're put [00:33:00] yourself in that vulnerable position. To mess up because you always mess up when you do it live. There's always gonna be some gotcha. And you gotta feel these questions from people who are curious about something related. They're gonna ask you a layer deeper on the thing that you're talking about. They're gonna point out a bug. It's a really good way to. Battle test, how well you know the technology and how well you can explain it to people who maybe they're joining for the first time and this is the first time they've ever heard about Reactor Njs or Versace and uh, or Knt or felt, and I'm there to try to help with that. What are you most excited about in WebDev in 2023? I'm sure you can list a million things. I'm very optimistic for really the web as a whole and web development right now. I am really excited about. Work that we're doing to make the development workflow faster, faster, not only when you're on your local machine. With tools like Turbo Pack Faster [00:34:00] when you're building your application for production, so you spend less time waiting for a build to complete and also faster to get your site deployed and online around the world faster to make iterations faster, to make updates like every little bit of efficiency that we help speed up that workflow makes a dramatic impact, not only on my personal life as a developer, but on all of the developers in the community and their teams when they use the product. So on the Versace side, I'm super excited about that on the general web dev side and in open source frameworks and in React. I'm actually really excited for the adoption of server components outside of next js, which is kind of an interesting thing for me to say. But I feel so strongly about this architecture in this new direction for React after seeing the patterns kind of validated in next [00:35:00] GS as one of the first places to do it. I'm really excited for what it means for the rest of the community at large, what it means for the ecosystem and the other libraries that can be integrated into this architecture. To give an example of this, in the existing world of React, You can publish reusable packages that can be react hooks and they run on the client side and they can encapsulate something like a React query, which is fantastic. Or you can have reusable packages that have some server side logic through node js that's wrapping some api. You have that kind of alternate ecosystem as well too. So you have these two pieces when you look at this. New architecture with server components and server actions, you get two really powerful primitives. Imagine you had an ecosystem of hundreds of components that you can MPM install that are not only the presentation of your ui, [00:36:00] but they're also the data and logic layer of your ui. So when I go install mpm, Algolia, M P M I, Algolia, it's going to have a table where I pass in my data set and it's able to fetch data on the server and render in the table. It's able to do really advanced. Server side searching and querying. It's able to encapsulate all of this logic into a single component that I can use inside of my application. That's something that previously just was not possible. Uh, another example of this is we published a library called the React Tweet. It's a Twitter embed, but it can be encapsulated and ran as a surfer component. So no client side JavaScript is needed. And it can securely make the fetches on the server. It's just something that wasn't possible before. And it gets really mind blowing when you start thinking about server [00:37:00] actions, because for the first time, you can really encapsulate the entire create, read, update, delete of your application into components, into composable pieces of your application. So the ecosystem here is just going to thrive and grow in the next year. Not only in Njs, but in other frameworks as well too, who start exploring this architecture. So I, I think it's gonna be fun. This is the architecture for the next 10 years of react. So it's, you know, it's day one, but it's really fun to see. Yeah, exactly. I actually didn't even think about it like that with the example you just listed. Um, and now my wheels are turning, like right now I think it's like people are getting confused like, is server components of Versace thing? Like no, it's just a react. Primitive and Versace. It's just like, you know, one of the first to do it and I'm super excited to see like how all these other frameworks are gonna start approaching it cuz it's just gonna unlock so many different patterns. So, we'll, we'll see how that goes, but it's definitely, uh, gonna be an interesting time in 20 23, 20 [00:38:00] 24. Yeah, I think the awesome part about it for me is watching the React core team take the work that they've invested and invested for years and years. Um, learning from how they're using reactive meta, how the community was using the framework, what their opinions are on the way they wanted to structure react for the future, and bringing that reality and bringing that vision to life for something that. Has required so many years of deliberate effort and deliberate intention to, to bring, to actually be something that I can MBM install, react tweet. It's kind of amazing, um, to just write Async Await and just fetch some data and think about the years of investment that have went into that. So major kudos and major shout out to the entire React team at, at Meta and the independent contributors who have just done such a fantastic job of kind of stewarding that community over the years. I agree. They're, they're doing an insane job right now. [00:39:00] But yeah, I mean this pretty much wraps it up and it was a pleasure having you on. Is there any last things you want to call out? Any shout outs? Shameless plugs. Shout out to you. Thanks for doing this. This is, um, really great. Uh, shout out to Log Rocket. It's been fantastic. Thank you for coming to the Versace Ship event. It was great to have you there. And everyone should watch your live streams. Awesome. Thank you so much. Yeah.