Full-Stack Signals in Solid, AI Development, and the Future of Web Frameworks

Speaker A: So I talked to Sunil PI a lot. Um, and we, you know, like, we're both enthusiastic about Durable Objects in general. And one of the things we've been talking about, he's been building a to do list and he's building AI agents and that sort of thing and playing with that space and this idea that you could, you could have something that's like listening to your conversations or listening in on the meeting, but then also has the API keys to linear. So as you discuss it, it's grooming the backlog in the background for you while you talk or, you know, like, based on. Or afterwards or with kind of that, that man in the middle approach, um, where, where you have high context because of, you know, like what you're talking about and what you're doing and then also the, the current projects and that sort of thing. So it can, it can have access and use LINEAR as an active to do list, um, for, for you. And then I think the ultimate goal for our AI overlords is to then just have these coding agents that go out and then do the tasks and you know, like, so you have access to LINEAR and you could like adjust the tasks and do what's needed or add new tasks and they do the same. And so you get that kind of back and forth and you, um. So you end up just supervising robots as your, as your. Feels almost like working in a toll booth to me at that point, like where, you know, you know what I mean? Like, you're just sitting there and like they're just driving through and you're like, yeah, go on, you can go through. That's, that's fine. And occasionally have to do something. Um, yeah, I don't know. I don't like the, the CEO of Anthropic said this week that by 2027, all coding jobs will be automated. I'm not, I don't know, like, I don't know if I buy that like fully. Like, like, I can see, I can see a lot of it just because of the, the nature of it. Um, you know, you can prompt, you can get a long way with cursor just like on pure prompting and, and driving it. But it's a. My favorite analogy is that it's like a, like a, one of these. A robotic vacuum where they get stuck in a corner and just kind of bangs its stupid head in the corner and you got to go like, take the cable out or do whatever, like whatever it's sucked into it's engineer or it's just going in Circles. So you have to have to give it a little guidance. It needs us for that right now.

Speaker B: But yeah, my experience with Cursor has been a uh, little different because like I started using Cursor recently but I was, I'm also like trying to use it for things that's like, probably very different from what everyone else is using it for. Like uh, since I joined the SolidJS core team, I've been looking a lot, a lot more into like the internals of its like reactivity system. And like I'm pretty sure that's way too deep for any AI to help me out with. It's still like decently helpful in trying to like, at least like help me navigate around the code base, figure out what something is doing. But yeah, I don't think it's going to at all help me in those areas. But yeah, it is very helpful when I'm trying to come up with demos for like just very quickly build like, like an entire application so that I can demo like one small concept. Um, but actually going back to the idea of like an LLM, listening into the meeting and grooming the backlog or something, I think like the biggest use case that I've had in my head when I think of uh, that idea is actually like all the non coding, non software engineering, uh, things that I've done like, like especially organizing events, managing communities. Uh, those are like kind of some of the big ones where like oftentimes we hop into a meeting, we talk about everything that we need to do. We need, we take a bunch of notes and then we just go off and like, like it's like trying to maintain a to do list or like a uh, uh, whatever. Trello board, linear board, whatever. Like is like it feels too much of a task. Uh, because there's a lot of things going. Yeah. And it's much easier to like just talk about those things in Slack or Intermedia. But trying to translate all of that into specific tasks on the board is a pretty tedious job. I think that's where like the LLMs could help a lot because uh, we don't need the LLMs to turn those tasks into code. We just need their help to organize uh, like our, our own unorganized thoughts and conversations into structured tasks and lists that we can then operate on.

Speaker A: They're pretty good at that too. Like, generally speaking, like, that's a, like a great use case. You mind if I share my screen?

Speaker B: Yeah, please.

Speaker A: This is an app I'm working on and like it's called Joel fit. Um, so it looks like this. I was doing uh, this rehab for my shoulder. I'm doing pt and he gave me um, uh, a Google sheet with the exercises. And I'm like, man, I really don't want to do that. I want to like, just make a page. And so I started, I found the domain Joel Fit, um, is. Is the one. And I was just going to make a quick page for my shoulder rehab that I could reference that would just be nice to look at. And then I've been doing this meal prep stuff and I've been doing kind of uh, like exercise and training and all this thing. And I was like, well, what could I do with all of this? And um, um, I wanted to combine that with the idea of fully prompting something like from scratch, right? Like, like starting with nothing and then building an app where I know what I want. Like I want a Turbo repo and I'm going to use next JS and kind of build it in the same way that I actually build apps, but do it like purely from prompts. And that starts like after I say create Turbo or whatever, right? And do that. So if you. It escalated and this entire application has been built that way, um, over a few days, basically where I go in and I prompt it and do that kind of back and forth prompting through building an actual application. And uh, we're up to like a database and authentication now. So all the way through that. Everything in there is static currently. But that's kind of the next step. And it was interesting to me. And the reason I bring it up specifically is because the way that I did that, um, it starts out with a system prompt, um, that I gave it and I brought in this initial build prompt and I used um, Claude I think at the time to build a prompt for Cursor that gave it kind of here's what we're doing and here's all the things that we want to add to this and kind of make, you know, the general idea of, of what it is we're creating and then through each step, um, because like you said, like managing a to do list is difficult. And one of the big problems with these things is you run out of space over here in the composer. It'll be like, oh, we've run too many commands and now you've lost all your context and you're like, well, what do we do? So I was like, well, part of the way that we work and we being me and the LLM, um, are we're going to build a, build a Plan. So every single time you're going to create a plan document and we're going to, you're going to write out what we're going to do, I'm going to tell you what's wrong or what's good and then we're going to go through step by step. And that's what we did. It's like keeping a to do list, keeping a little mini Jira in here. And I'm like, okay, we'll add all the, you know, the file structure and add all this stuff so that when we come back like it's not like oh, I don't know where because they're just dumb, right? Like it's like I don't know where I am, I don't know what's going on. You know, like we do look at this, this is, this is where we're, what we're doing and you know there's a bunch of them in here. Um, because as we go through it it's like different projects basically doing um, this, this sort of prompting document and keeping a to do list up to date. And to me the next step for that would be like, well instead of that like you have access to you know like a little, you can make a script or do whatever, like give it a little API for linear. Um, they have a, they have a um API in general but like give it access to that. And now you're just like you're building through linear. So like pull all the current tasks, see what we're doing, pick the next best task and then execute it and keep, keep linear updated uh, while you go. And what's uh, really interesting to me is these are the best. Wow. This is where I'm dealing with um, kind of a bad time. Me uh, personally not with the LLM involved. This is, this is what it might have looked like before. But like I get you know like the comm commit history is just wild in terms of like detail and stuff because that's part of, part of what we do too. It's uh, commit, commit often and then make sure we're using conventional commits and that sort of thing. This is the farthest I've taken this idea of you know, like pure prompting through an app, which is um, frustrating sometimes. Um, kind of slow. You might notice my little, my little coding buddy. Curses. He's lit.

Speaker B: Mhm.

Speaker A: Yeah, it's been interesting uh, and kind of a fun process especially because I already know exactly what I want and I'm able to mhm. Push it from an architecture perspective. And get what it is I'm looking for.

Speaker B: I don't know, it's really interesting because instead of just going to the LLM and saying that, hey, here's my code, here's what I need to add, or here's what I need to fix, do it. You first come up with like an, like a game plan, an overview of here's all the things that I need to do. Uh, or like come up with a plan of how we're going to do these things over time and then like, do it step by step. Like it's almost like meta prompting.

Speaker A: Yeah. And because I had data, so I had my spreadsheets and uh, I've had my, you know, like what it is I'm up to and I had quite a lot of data. I have like personal. Like I have my DEXA scan metrics are, are up there where I went and got like a full, full body scan for my body composition. And so I have all of this, this information, like good structured data and then knowing what I want and then also knowing how to build an app. So it wasn't like I was like, oh, please help me. It's more like, hey, here's what we're trying to get done. Go ahead and do these things. Um, that's all stuff I can type. I actually have like fairly significant hand pain, uh, for most of my life. And, and what I like is that I'm typing less. Um, but then obviously the AI overlords feeding me gruel and um, putting. Putting compute as my universal basic income kind uh, of makes me. Yeah, like that, that, that is. That's bleak. Uh, but I like the future as it is currently, so that's pretty cool.

Speaker B: Yeah. I'm really curious to see how far you can go with this. Like, how long until like the AI starts cropping itself. I'm like, okay, I don't know what you're talking about anymore.

Speaker A: Oh, like a lot like it. It gets confused and it'll be. So the git commits are interesting because we can go pretty far. And you'll be like, if you let it push once, it's like it's on now. It's going to push literally every time, you know, like you give it a little bit of permission and I have it on. They have. It's called YOLO mode. It's is what they call it in cursor, where it stops asking for permission to do anything. And it's like, basically it has full access to your entire system and can run terminal commands and do all this sort of thing. Um, and it'll go down wacky and it'll just get confused and weird and start going in loops and that sort of thing. Um, quite often actually. So it's just like, okay, we need to reset back to this commit, force, push and now we're going to start again. Right. Like, and then. But then you erase it and it's like it has no idea obviously. Um, because you know, it only knows what you show it. So it's. Now you just start back over and kind of rethink about the approach. Um, it's interesting way to like try out different ideas too. And then also things like adding tests. Um, um, even. Even like end to end tests or whatever. It's like. Cause it can run those things also. So it can run the tests and just sit there and beat its little face against the wall until the tests work while I go. Like I'd literally set a prompt and then go. And I'll be making a matcha or whatever and just kind of watching it from across the room and just kind of seeing it run and get my tea and go sit back down and it'll be finished and then either say yes or no and kind of move on. Um, I don't know. It's kind of fun and satisfying in its own way. Um, I don't know. It's a weird.

Speaker B: Yeah, it's like AI does test driven development.

Speaker A: Yeah.

Speaker B: AI is probably better at that than us.

Speaker A: Uh, well, the interesting thing is at that point because it's another input. So now you have tests and if the tests are good and tests, like I can review the test and okay, well these are covering what we want it to cover, then that's more context that it has. So the more tests that are there and the more tests that it can run, it can be like, well, be sure you run the tests every time. So it'll run those tests and if they start failing, it'll be like, oh, um, mine will be like, oh shit, we got a broken test. Uh, and then go back and fix it. And that to me that's pretty cool. And just the idea of getting more tests out of it. Or even like you said, test driven. Like, hey, this is the functionality that we want. Let's get a good set of, let's get a good suite of failing tests before we even start. Um, which is stuff that like, I'm like, oh, I would love to do that as a human. Right. I rarely do. Like, some of my best days as a developer in my career have been when I was test driving something but then like, uh, yeah, how about we just code?

Speaker B: Uncle Bob would be proud.

Speaker A: Yeah, Woody,

Speaker B: I don't think I disappoint

Speaker A: him on many levels.

Speaker B: Yeah, that's true.

Speaker A: I'd hope so, to be honest.

Speaker B: Yeah. Random question. Why do you have that context and those prompts in an XML file? I haven't seen an XML file in forever. Why XML?

Speaker A: Because it's structured. Um, and LLMs like structured data. So it's like put it in.

Speaker B: JSON is structured.

Speaker A: I don't think it's even valid XML. JSON is structured. I Don't know. Like Claude likes XML. Um, just in general. And there's just, it's just kind of a prompt trick to give it, to give it structure and it understands it really well.

Speaker B: Because I feel like JSON would be a lot less tokens.

Speaker A: It's for the machine.

Speaker B: Would it be because you don't have closing tags? So like every time you have a closing tag you have like a whole word. That's not a lot less tokens.

Speaker A: That's marginally less tokens.

Speaker B: It's like almost double. I feel I'm not optimizing. I don't think that's fair. Yeah, you're definitely not at this stage where that optimization matters. But yeah.

Speaker A: Yeah. So this all started as a project in the cloud web API that I was working on. Like that was where it did. Cause I have a, like this. The whole thing started as meal prep and I was building that up and I built up a lot of context in there. Um, and then I kind of. Because you can add documents to it. So I'd be like, okay, well we need to refresh the core principles document. Um, so I can make a new one based on all the new data. So take all that and make a new one. Then I'd push it out and um, it uses a very machine like format when it like for the data that you put into your project. And I can't think of a more machine. Yeah, I can think of lots of formats that are more machine than xml but like, I don't know.

Speaker B: Fair. Yeah. Cursor is good.

Speaker A: Yeah.

Speaker B: So are you going to turn that into like a course on egg prompting your way to victory with cursor?

Speaker A: No, um, there's a, um. There's interesting ideas in here that I think would actually. And so what's, what's interesting to me and this is the danger of the entire thing. Is it, it is great, right? Like this is uh, this is amazing. But I actually know what I'm doing right. Like I understand what I want and I know, you know, I know when it's trapped and I know when what it's making is bad or the ideas are not working. And I think the danger with these is, is always it's like hey, write me a blog post bad. Hey, here is this blog post I'm written. Give me some critical feedback. Good. And those even like from here, like building this out. I knew exactly what I wanted from like an architecture perspective and how I was going to deploy it and you know, like what I wanted to see and some patterns that I wanted to try. So really interesting if you want to try some design patterns and you have some in mind and know that direction. Like I've been enthusiastic about the repository pattern lately. Um, which is old school. That's like from patterns of energy application architecture from Martin Fowler back in the, the aughts or late 90s I think. Um, you know, and, but it's great. Like they're still great. Like these patterns are still cool. And, and uh. Um. Yeah, I've been doing a lot of object oriented stuff I feel like since I've been been prompting because it like the machine really likes it. The, the LLM M, like the object orientation like helps it out and it's able to kind of expand and also very testable as far as that goes.

Speaker B: Uh, yeah, we'll need to do a whole separate episode on object oriented. We got a lot to talk about there.

Speaker A: Yeah. Are you a fan or no?

Speaker B: Yeah, I'm a fan. Uh, it's more like there's like three different things that you could mean. Like someone could mean when they say object oriented programming depending on like what's, what their perspective has been. So it's like whether they're wrong or not. Like you, you. Yeah, it's. I mean you can, you cannot even say if they're wrong or not because the, the original thing that was supposed to be object oriented programming is like lost. And like 2% of people who are familiar with object oriented programming know what it originally was and 98, 99% of people know what, what they're taught in college and stuff like that. So it's like I have Kent Beck

Speaker A: small talk patterns over here. Like. Yeah, if you, I don't know if you've ever seen that book. It's amazing. It's like, it's super thin. But it's like this amazing book about a uh, language I'll never write. Like, I'll never write small talk.

Speaker B: Yeah. But just, but if you know, small talk then. Yeah, yeah. If you know small talk then yeah, that's what, that's the one person thing, like what it originally was. But the Java C thing, that's a very different uh, interpretation of object oriented programming.

Speaker A: I think it's one of those things too where people um, it's like Agile or whatever, where they.

Speaker B: Exactly.

Speaker A: Here's a great idea. Here's a very interesting way to approach this work. Now we're going to ruin it. Now we're going to take it to an extreme and we're going to make it dogma and everything is going to be this way or nothing. And then it's ruined and then it's spoiled. And now when you say Agile, people will be like m. These get that, that you know, like that grimace on their face, like this is horrible.

Speaker B: Mhm.

Speaker A: But I'll still like I, you know, I will write classes and Typescript and I think they're good in certain circumstances for sure.

Speaker B: Yeah.

Speaker A: Um, I don't want to write class components in React anymore. Uh, mostly because that's not what they want. So you know, we kind of follow the patterns that are, that are given to us. So as a segue, why is Solid cooler than React? Like why, why do you prefer it over React? What makes it, what makes it a better framework at this point in time?

Speaker B: It gives me everything that I like about React and eliminates all the things that I didn't like about React. What's the top, honestly, like what's the,

Speaker A: like the, what's the top things that uh, you like about React that Solid brings?

Speaker B: I guess I like the focus on the component model. I like that uh, by default there is uh, no inherent separation between Logic and ui. Like you just write a function and you have logic in there, you have templates like your jsx, your UI in there and you can break them apart however you want. Which is like very different from how a lot of frameworks force you to break templates from Logic. React kind of like caused this shift in basically every framework. Ah. At some point. But React basically came up with this idea and then everyone else adopted it. Um, but still like the function style of component is the best way in my opinion to be able to break them apart however you want. Uh, I really like the one way data flow model where every time you have a piece of state you very explicitly have, okay, here's how I read it, here's how I write it. Instead of both combined into one and you pass it down to a different component and that Component can both read and write it. So Angular has signals now, but they have an object with get and set. So if you pass a signal to a child component, they can also mutate it. Uh, things like that. Uh, I really like the Suspense model I gave a talk about two weeks ago at Codemash called Building Asynchronous UIs without the Hassle. It's on my YouTube. Uh, I talked why I love the Suspense and Transitions model that React has come up with. It's fantastic.

Speaker A: Um, is this the Suspense demo with solid JS? The solid suspense demo V2, is that related to that?

Speaker B: Yes. So those are the two demos that I presented in that talk. The React version is like a full fledged, um, app that shows like a bunch of different things. The Solid demo is much, much smaller because it's using like a highly experimental version of uh, solid V2 with like a very hacked together JSX renderer that Ryan made especially for the demo. Uh, so it's like it's using a version of Solid that's not available today that you can't really use outside of that demo. But I wanted to use that because I wanted to show how Solid takes React's ideas and removes all of its limitations and kind of like supercharges it almost. Yeah, that's one of my favorite talks that I've given to this date and I got a lot of amazing feedback for it. Mostly because, like, a lot of people using React are not familiar with what Suspense is, why it exists and what it offers.

Speaker A: You think people using React aren't aware of it yet?

Speaker B: No, because Suspense has been a thing forever.

Speaker A: But it was meant for it announced how many years? Like six years feels like something somewhere in that range.

Speaker B: And it was primarily meant for data fetching, but it took them six years to come up with Suspense for data fetching. And then what they came up with was React server components. It's a thing that not every, like, uh, a very, very tiny fraction of people using React can adopt. So it's like it's something that's been promised forever, but now that it's here, no one can really use it. So it's in a very weird spot where if you're using Relay, you can use Suspense, or you probably have been using Suspense. If you've been using Apollo maybe, uh, if you're using React Query, you're probably not using Suspense. So that's the thing that it's. It's there, but almost no one is using it because it's, it's like It's a very weird mismatch between REACT and its ecosystem.

Speaker A: Well, I mean, I think for, from like a consumer perspective for me and I'm, I'm a person though. Ride the canary builds of NEXT and React.

Speaker B: Right.

Speaker A: I haven't even been able to until 2024. Really. Like it wasn't even like a viable option until like you said, server components came into the picture though. And you're right in that server components have only been available to NEXT users. Right? Like that small percentage of folks, um, they have a pretty decent slice of the pie. But like this year that's changing, I would say on the REACT side anyway, it feels like we're getting more server component implementations. I think the REACT router folks are pretty close. Um, and there's a couple other. Who else at the parcel. Um, I think Devin, uh, I saw Parcel vite. Yeah, yeah, like the server component wave is coming. Uh, it's catching up. Um, which will be interesting to see. Um, but even that aside, like what we can get those advantages, the cool stuff of Suspense out of Solid today? Or is that something that uh, we really need to like the preview build that you got is going to show us we're going to get those advantages in solid V2? Is that the idea?

Speaker B: Yeah. So it's like the exact opposite story because Solid has had suspense basically since it's launched like V1 and its entire ecosystem grew up with Suspense. So like Solid router and everything, uh, like whatever ecosystem exists, they have like always had access to suspense. The reason I was showing the V2 version is because it has some improvements that the current version doesn't. That the current version has some minor issues because uh, they never really got fully addressed. It was kind of uh, quickly hacked together. It's still much, much like it still has a lot, uh, like the current Suspense version. In the current Solid version it's still much better than react, but the V2 makes it just even better. And I just wanted to show uh, the best uh, that is possible today. So that's why I showed the next like the Bleeding Edge version. But current Solid has suspends the entire ecosystem support Suspense. So it's like in the very opposite realm of React, where React came up with Suspense but because they took so long to uh, actually like build support for it or to collaborate with its ecosystem on it. Like um, its ecosystem doesn't really use Suspense that much.

Speaker A: You think it's like a scale issue with React. Like it's just like a glacier in terms of its movement versus Solid, where I feel can be more nimble because of the smaller scale of deployment.

Speaker B: I think it's.

Speaker A: Maybe that's not true.

Speaker B: I don't m. Know it's like two things. I think scale is definitely part of uh, what's going on there. But, but the bigger thing in my head, uh, like from what I've seen is just their philosophy of, or like how they want to offer like built in solutions. Like if you want to use Suspense for data fetching, you either have to use a framework like Remix Next js, Relay, Tanstack, Query, anything like that or like the preferred version of how React wants you to use Suspense for data fetching. A server components which, but the server components, like it's an architecture, like it's a multi page app kind of architecture. If you don't want that architecture, if you don't have JavaScript on the server or if you want client side data fetching, you just simply cannot do that. It's like uh, off the table and you have nothing. So it's like. But React wants to offer a solution which is like fully composable because they want everything to be composable. Uh, and that is like in direct conflict with what people kind of like how people want to use the stuff.

Speaker A: So it's interesting. There's been a lot of like, there's been a lot of uproar in general because if you go to the React docs and you, you look at, at how to start a new React app, um, there's no mention of, of any client side, you know, like spa, right. Like traditional single page app. It's all server architecture, like full stack um architectures. And Vite is the one that's missing. That's the one that, because that's how you know like a lot of people, you know, if you want to do a spa with React, Vite makes this awesome solution and you can spin it up and it's a treat to work with and it just functions but you don't get any of that. And also the general architectural direction of React as a project has m. You know like is pushed away from that use case in a lot of ways. And like to me React, the React server components is kind of the answer to GraphQL and relay and these other things that have been tried. And like there was no, I think statistically no adoption of Relay like outside of Facebook because that's what they use. So that was designed for them basically.

Speaker B: Yeah.

Speaker A: And you know like other people did use it but it was always like how do you even Use it. And it's like, I don't know, nobody taught it, nobody wrote about it, nobody, you know, like showed. There was no examples. It was just like mhm, yeah, it's great if you, you know, like you're building a relay app. Um, so it's interesting just to see. And I was, I was went and uh, I went to read the React docs because I saw all of the, you know, commotion on X about Vite being missing and it's absolutely true. And, but then you also. Everything's missing and terms of like traditional spot is all. This is how the architecture of React is. We are a full stack client server. Mhm framework. Um, and that's just the way it is and that's the way the docs are. And your pull requests are probably going to be ignored. So I mean there's a bunch of V ones already in there. So if anybody's like, oh, I want to go be a contributor and that's not probably going to happen.

Speaker B: Yeah. And that's one place where like Solid really shines. Which is one of the things that attracted me towards it the most, which is that suspense for data fetching is basically built into the framework because signals kind of have the superpower of uh, you can just create a bunch of things and not block your rendering. Which is the biggest problem with suspense in React, where as soon as you try to use a promise, as soon as you try to do something async, you just bailout, go all the way to the top and then rerender from there. And then you have another thing bail out, go to the top, rerender from there. And because all it has signals, it doesn't have this problem. That's the exact problem, uh, space that signals were invented for, which uh, makes them really nice for suspense and async.

Speaker A: So you joined the Solid core team recently. Congrats on that. I think that's awesome.

Speaker B: Thank you.

Speaker A: I think that's interesting too to me and it really speaks to it. Right. Like it's, you can make an impact and Solid. I think anybody listening to this could probably if, uh, be enthusiastic, go participate, go learn about Solid and make an impact, um, and contribute to like the future of the framework. That's the feeling I get from the outside. Um, like what does joining the core team mean though? Like what does that, what does that entail? And how did you go from just being an enthusiast to now being a core team member?

Speaker B: Yeah, so the core team of Solid is very much made of like

Speaker A: people

Speaker B: uh, who want to do research or people who kind of want to just experiment with the paradigm and see how far they can push it. Uh, for example, the signals implementation that basically every framework is using today, uh, it was kind of pioneered by uh, Milo, who again he was on the solid Core team because he experimented with signals in a way where you can kind of have, uh, this implementation that can work in any different framework, which originally the solid JS version wasn't like that, but he pushed it far enough where you can have a different signals implementation, even to the point where you can build it into the browser, uh, and then any framework can use it. So that's one of the things, uh, what I was doing with signals was trying to make them full stack, so make them work across the boundary. So you have a stateful server, something like a durable object, and you can define these reactive like signals and uh, derivations on the server, and you just pass them to the client and the client listens to them. Which means at any point, uh, someone, uh, else, like some other user can cause an update to that signal and that you immediately receive that value. So it's kind of like unifying how we look at reactive state or state that changes over time across the client and server, uh, to think only in signals. Because right now if you want to do something like WebSockets, you have to translate everything to websocket messages. Okay, Send this message, receive this message. And this is how you have a big switch case statement where you handle every message and decide how that updates your state. So I want to get rid of that and just pass signals around.

Speaker A: How's that working out?

Speaker B: Uh, pretty good actually. So, uh, I, I actually I was on Ryan's stream giving this, giving a demo about this. This project actually won solid hack, uh, $7,000, uh, which was very nice. Right now I'm trying to do a lot of improvements to it. Uh, I think eventually this will like, I will have my own version of server components here where like instead of being stateless server components like React, these are stateful server components. Which means instead of rerendering the whole thing, sending the entire payload, the server can just update one piece of one node there and the server will send a websocket message to the client saying that, hey, there's one text node right there, go change, uh, its value to this new value. And the entire rendering happens on the server. So kind of like live viewed, uh, there's a few different values.

Speaker A: You mentioned durable objects. Are you using durable objects for your experimentation here or what's? Your, what's your stack for that sort of, uh, what's your playground? I guess.

Speaker B: Uh, I mean right now everything is local. Uh, this will definitely be a good use case for durable objects. Um, because uh, I mean, actually I'm not sure if that's entirely true because the way it works right now is that either there's like one global server that every user connects to or every user has its own server, WebSocket Server, like a durable object and then they have to talk to each other over websocket or HTTP. Uh, the way that you would want to use durable objects is have multiple clients connect to the same object so that you can have like synchronous strong consistency there. Uh, that's something that I don't think is possible in the, at least the current way that I'm approaching this server signals thing. Uh, I think there are like additional APIs or something else.

Speaker A: I mean durable objects would be right. Yeah, durable objects, they're fine because they're basically a chat room. Like it's a little mini server, like a room. Uh, is the way I kind of think about them.

Speaker B: Yeah, exactly. Um, but to allow the developer to kind of uh, express that to the framework that hey, here's a shared piece of state that multiple users can connect to. Uh, that requires a different set of APIs that I don't currently have. That's a future thing that uh, I'll look into personally.

Speaker A: One of my current obsessions is durable objects and Sunil's work in that area. Um, just this idea that you can spin up infinite mini servers to your heart's content and then they can connect to each other and communicate to each other and back to client and um, like they each get it. Each of them can have a SQLite database of their very own. Like the whole thing is just wild to me and unexplored territory and it's like a primitive that I don't think I've seen anywhere else. And one that's very, I think, I feel misunderstood. Like people think durable object, um, like some sort of shared state or something like that. Not little. Each one is a computer, right? Like you can spin up. Each durable object is its own computer. So it is stateful, but it's like you can do anything inside of it and they will stay for. They can live for milliseconds or till the heat death of the universe basically. And you get kind of a really interesting thing to play with that you can build all sorts of cool systems with.

Speaker B: Yeah, Sunil's been on a, uh, campaign on Twitter trying to build, uh, random things and explain. Yeah. Trying to explain ways. And then every other day there's someone like, oh, that's how it works. I had no idea. And he's like, okay, how do I make this happen? But a million times, yeah, that's, that's the hard part.

Speaker A: And it's a, you know, it's a, like a, it's definitely like an education and example space problem to me. And like a lot of, of developers and, and people that are building the blocks for the rest of us to, to use. You know, it's like, how do you do that? How do you do that, that, that work of, of actually building the systems and then also educate and build, uh, the examples that people need. Because people crave examples, right? Like, it's really hard to. People want to be kind of shown the way, um, to do a thing. And there's some people like to explore and do the research and then other people just want to get some work done or whatever. And so it's kind of like bridging that gap between the research aspect and the practical examples that people can actually implement on the job. It's always hard.

Speaker B: And I feel like you can probably draw a lot of parallels to when AWS Lambda first came out, because, like, when it was first released you were like, uh, okay, I need to log into the AWS console, write a little bit of JavaScript code inside AWS console in this editor, or like upload a zip file with a single file that's written in a certain way and then it just runs when I call them, like it was all over the place. It probably took us a solid like three to four years before we could come up with real use cases for Lambda. And then probably another year or so before we can build the tool chain to make it easy to work, to have a workflow that makes it easy to deploy on Lambdas. If you go to AWS console today, it still is like write your code here or upload a zip file.

Speaker A: I gotta say, one of the things that is impressive with Cloudflare to me in general is that their runtime just runs locally. So like when I'm using durable objects and um, yeah, like it's all just, it just works. And I think that's actually kind of amazing, like that they, they ship that and allow us to have that sort of freedom, um, from their servers and that sort of thing.

Speaker B: Yeah. And this was in direct conflict. In conflict, uh, with Vite forever. But thankfully with Vite 6, like now, Vite 6 was a big, big unlocker for a lot of things going on in the ecosystem. Like server components are one of them, uh, like these meta frameworks, one of them durable objects, uh, or like Cloudflare workers trying to run them locally, one of them. And it was like they came up with one API that addresses all of them, which is like, fantastic work. We team.

Speaker A: Yeah, that's awesome. I didn't even know that. Uh, that's cool to hear.

Speaker B: Yeah. Because with Vite, you run it in SSR mode and it just runs node. So if you have a Vite project that you want to test with Miniflare, with like your local, uh, Cloudflare runtime, it was basically impossible to set that up. And like, there's very long rants by Sunilpie on Twitter trying about that. But one of the major goals of Vite 6 was, uh, to address this problem. And I think they did a pretty good job at that.

Speaker A: Yeah, that's awesome. Cool. Well, anything else you're excited about?

Speaker B: Um, yeah. Have you seen this, uh, have you seen Zero Sync yet? Anything about that?

Speaker A: I've seen it and I was actually just thinking this week that I need to build something and give it a try because it looks pretty cool. And just the entire concept of local first. Um, I almost, I almost did the Joel Fit app with, with, with Zero Sync, actually, because I felt like it would actually be a good, um, local first candidate. Um, but no, I've heard of it and I'm excited to try it. Have you tried it?

Speaker B: I haven't tried it. I'm. But I'm familiar with the concept enough to be incredibly excited for it.

Speaker A: Yeah, um, it's like an evolution.

Speaker B: Yeah. Yeah, exactly. Yeah. And I mean, there's actually, there's a lot of reasons for me to be excited for it. Uh, I met the, the founder of rossicorp, Aaron, and like, and the other person who worked on Zero Sync, uh, in React Miami last year. So in April, that's where they first. They were first, like, talking about Zero Sync with people. And ever since then, like, I've been, okay, this is a very exciting project looking. I'm, I'm looking forward to it. And there's a lot of projects that, like, if I talk about this, uh, uh, what, this project, I'm. I need to build, or I should be building for like 20 minutes. I know that this is a perfect use case for Zero Sync and it's going to make it so, so, so much easier to build. So, yeah, I, I've yet To experiment with it though, like actually build something with it. The other reason why I'm very excited about is that it's kind of a perfect uh, complement to Solid js because zero Sync uses something called an incremental view. Uh, uh, ivm incremental view maintenance. Which means uh, the data that you have on the client, uh, like zero is basically able to make very small incremental changes to it. Instead of something that you would do in React where you would do a dot map and you would replace the entire array with a new array, 0 sync doesn't do that. It makes a very small change to that array and then it's done because it has knowledge, it exists both on client and server. So it knows exactly what changed in the data and it can send a tiny message to the client and say that, hey, this is what changed. Solid can take that a step further and see that, okay, this is one tiny piece that has changed in the data. I need to make this one tiny change in the UI and I'm done. What you would do in React is even though you have a tiny change in the data, React would still rerender the entire thing and then it would diff the entire thing. But Solid doesn't have to do that. And for Solid to be completely optimal, it needs this uh, incremental thing across like across client and server that can tell, hey, this is the data that changed. So that combination is like you have kind of the ultimate like front end performance thing. Front end performance. It doesn't matter really to most people. Like most people are not really not going to notice. But like from an uh, like from an architecture or like efficiency standpoint, like this is the end game when there's

Speaker A: some apps that would probably make possible or performance wise for sure. Yeah, that would just really, really benefit m from that sort of thing. I look forward to your demo and your future conference talk on that setup because that sounds like a cool one.

Speaker B: Yeah, thank you. I actually gave uh, a virtual talk around this vague idea, but I didn't mention Zero Sync in it and I didn't mention Solid. I only mentioned this idea of the server sending incremental updates and the client doing incremental updates, but I didn't talk about how you could actually achieve that. Like what technology?

Speaker A: Like the implementation details. More of a conceptual idea.

Speaker B: Yeah, that's cool.

Speaker A: Well, it was great to catch up. Um, I'll talk to you soon.

Speaker B: Yeah, thank you very much. This is fun.