[00:00] So I talk to Sunil Pai a lot. And 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 have something that's like listening to your conversations or listening in on the meeting, but then also has the API keys to linear.
[00:21] 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 man in the middle approach where you have high context because of what you're talking about and what you're doing. And then also the current projects and that sort of thing. So it can have access and use linear as an active to-do list 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 so you have access to linear and you could adjust the tasks and do what's needed or add new tasks and they do the same.
[01:10] And so you get that kind of back and forth. So you end up just supervising robots as you're, it Feels almost like working in a toll booth to me at that point, like where 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 fine.
[01:28] And occasionally you have to do something. Yeah, I don't know. Like the CEO of Anthropic said this week that by 2027 all coding jobs will be automated. I'm not. I don't know.
[01:45] I don't know if I buy that fully. Like I can see a lot of it just because of the nature of it. You can prompt, you can get a long way with cursor just like on pure prompting and driving it. But it's my favorite analogy is that it's like a robotic vacuum where they get stuck in a corner and just kind of bangs, it's stupid head in the corner and you got to go like take the cable out or do whatever, like whatever it's sucked into its engine or it's just going in circles. So you have to have to give it a little guidance.
[02:17] It needs us for that right now, but. Yeah. My experience with cursor has been a little different because like I started using cursor recently, but I was, I'm also like trying to use it for things that, that's like probably very different from what everyone else is using it for. Like, since I joined the SolidJS core team, I've been looking 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.
[02:55] 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 an entire application so that I can demo like one small concept. 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 that idea is actually like all the non-coding, non-software engineering things that I've done, like especially organizing events, managing communities. 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 to we take a bunch of notes.
[03:45] And then we just go off and like like it's like trying to maintain a to-do list or like a whatever Trello board linear board whatever like is like it feels too much of a task because there's a lot of things going yeah And it's much easier to like just talk about those things in Slack or in a meeting. 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 they don't we don't need to. We don't need the LLMs to turn those tasks into code. We just need their help to organize our own unorganized thoughts and conversations into structured tasks and lists that we can then operate on.
[04:37] 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? Yeah, please. This is an app I'm working on and it's called Joel Fit.
[04:50] So it looks like this. I was doing this rehab for my shoulder. I'm doing PT and he gave me a Google sheet with the exercises. I'm like, man, I really don't want to do that. I want to just make a page.
[05:01] And so I started, I found the domain, Joelfit 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 like exercise and training and all this thing. And I was like, well, what could I do with all of this? And I wanted to combine that with the idea of fully prompting something like from scratch, right?
[05:28] 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 it escalated and this entire application has been built that way 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 we're up to a database and authentication now, so all the way through that.
[06:09] 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, it starts out with a system prompt that I gave it. And I brought in this initial build prompt and I used Clawed, I think at the time, to build a prompt for cursor that they 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, you know, the general idea of what it is we're creating.
[06:42] And then through each step, 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 are, we're gonna build a plan.
[07:06] So every single time you're gonna create a plan document and you're gonna write out what we're gonna do. I'm gonna tell you what's wrong or what's good. And then we're gonna 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.
[07:20] 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, cause 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 where we're, what we're doing. And you know, there's a bunch of them in here because as we go through it, it's like different projects basically, doing this sort of prompting document and keeping a to-do list up to date.
[07:46] 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. They have a, they have a 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 linear updated while you go. And what's really interesting to me is these are the best, wow, this is where I'm dealing with kind of a bad time.
[08:24] Me personally, not with the LLM involved. This is what it might've looked like before, but like I get, you know, like the commit history is just wild in terms of like detail and stuff because that's part of what we do too. It's commit often and then make sure we're using conventional commits and that sort of thing. But this is the farthest I've taken this idea of like pure prompting through an app, which is frustrating sometimes, kind of slow. You might notice my little coding buddy curses.
[08:57] He's lit. Yeah, it's been interesting and kind of a fun fun fun process especially because I already know what exactly what I want and I'm able to Like push it from an architecture perspective and yeah Really interesting because instead of like 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 a, like a game plan, an overview of here's all the things that I need to do, 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.
[09:41] Yeah. And, and cause I had data, so I had my spreadsheets and 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 up there where I went and got like a full, full body scan for my body composition. And so I have all of this information, like good structured data and then knowing what I want.
[10:04] 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. And it's all stuff I can type.
[10:13] I actually have like fairly significant hand pain for most of my life. And what I like is that I'm typing less, but then obviously the AI overlords feeding me gruel and putting compute as my universal basic income kind of makes me like that. That is, that's bleak, but I like the future as it is currently. So it's pretty cool. Yeah, I'm really curious to see how far you can go with this.
[10:45] Like how long until like the AI starts cropping itself? I'm like, okay, I don't know what you're talking about anymore. Oh, like a lot. Like 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 gonna push literally every time.
[11:05] You give it a little bit of permission. And I have it on, it's called YOLO mode, is what they call it in Cursor, where it stops asking for permission to do anything. And it basically has full access to your entire system and can run terminal commands and do all this sort of thing. And it'll go down wacky and it'll just get confused and weird and start going in loops and that sort of thing. Quite often, actually.
[11:36] So it's just like, okay, we need to reset back to this commit, force push, and now we're gonna start again, right? But then you erase it, and it's like, it has no idea, obviously. 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. It's an interesting way to try out different ideas, too.
[11:59] And then Also things like adding tests, even like end to end tests or whatever, it's like, because it can run those things also. So it can run the tests and just sit there and be its little face against the wall and tell the tests work while I go. 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. I don't know, It's kind of fun and satisfying in its own way. Yeah, I don't know, it's a weird, weird time.
[12:36] Yeah, it's like AI does test-driven development. Yeah, and- AI is probably better at that than us. 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 wanted to cover. Then that's more context that it has.
[12:58] 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, mine will be like, oh, shit, we got a broken test. And then go back and fix it. And That to me is, that's pretty cool. And just the idea of getting more tests out of it.
[13:20] Or even like you said, test driven. Like hey, this is the functionality that we want. Let's get a good suite of failing tests before we even start. Which is stuff that I'm like, oh, I would love to do that as a human, right? I rarely do.
[13:37] Like some of my best days as a developer in my career have been when I was test driving something, but then I'm like, how about we just code? Uncle Bob would be proud. Yeah, would he? I feel like I disappoint him on many levels. Yeah, that's true.
[13:56] I'd hope so, to be honest. 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? Because it's structured and like LLMs like structured data.
[14:15] So it's like put it in there. JSON is structured. I don't think it's even valid XML. JSON is structured. I don't know.
[14:22] Like I, Claude likes XML just in general and there's just a kind of a prompt trick to give it structure and it understands it really well. So. Because I feel like JSON would be a lot less tokens. It's for the machine. Would it be?
[14:40] Because you don't have closing tags. So like every time you have a closing tag, you have like a whole word. No, that's not a lot less. It's like adds more tokens. That's not a lot less.
[14:48] That's marginally less tokens. It's like almost double, I think. I'm not optimizing that. No, okay, maybe. I don't think.
[14:56] That's fair. Yeah, I mean, you're definitely not at the stage where that Optimization matters, but yeah. Yeah, so this all started as a project in the Cloud Web API that I was working on. Like, that was where it, because I have 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. 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 so I can make a new one based on all the new data.
[15:26] So take all that and make a new one, then I'd push it out. And 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 machiney, I can think of lots of formats that are more machiney than XML, but like I don't know. Fair, yeah. I mean you could.
[15:48] Yeah, cursor's good. Yeah. So are you gonna turn that into like a course? On iCAD? No.
[15:56] Prompting your way to victory with cursor? No. There's interesting ideas in here that I think would actually... So what's interesting to me, and this is the danger of the entire thing, is that it is great, right? Like this is amazing.
[16:13] But I actually know what I'm doing, right? Like I understand what I want, and 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.
[16:35] Good. And those, even from here, building this out, I knew exactly what I wanted from an architecture perspective and how I was going to deploy it and what I wanted to see and some patterns that I wanted to try. It's 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, which is old school. That's like from patterns of enterprise application architecture from Martin Fowler back in the aughts or late 90s I think.
[17:06] You know, but it's great, like they're still great, like these patterns are still cool and yeah I've been doing a lot of object-oriented stuff I feel like since I've been prompting. Because the machine really likes it. The LLM, the object orientation helps it out and it's been able to kind of expand. And also very testable as far as that goes. Yeah, we'll need to do a whole separate episode on object-oriented.
[17:31] We got a lot to talk about there. Yeah, are you a fan or no? Yeah, I'm a fan. It's more like there's like three different things that you could mean when, like someone could mean when they say object-oriented programming, depending on like what's what their perspective has been. So it's like...
[17:51] Whether they're wrong or not. Yeah, I mean you cannot even say if they're wrong or not because 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 they're taught in college and stuff like that. So it's like, wildly different meanings.
[18:19] I have Kent Beck's Small Talk Patterns over here. Like his, 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 language I'll never write. Like I'll never write small talk.
[18:31] Yeah. But just the ideas in there. 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.
[18:40] But the Java C++ thing, that's, that's a very different, like interpretation of object or inter-programming. I think it's one of those things too where people, it's like Agile or whatever where they, Exactly, or microservices. Here's a great idea, here's a very interesting way to approach this work. Now we're gonna ruin it. Now we're gonna like take it to an extreme and we're gonna make it dogma and you know, like everything is gonna be this way or nothing.
[19:07] And then it's ruined and then it's spoiled and now when you say agile, people will be like, they just get that grimace on their face like this is horrible. But also, I will write classes in TypeScript and I think they're good in certain circumstances for sure. I don't want to write class components in React anymore, mostly because that's not what they want. So we kind of follow the patterns that are given to us. So, as a segue, why is Solid cooler than React?
[19:40] Like, why do you prefer it over React? What makes it a better framework at this point in time? 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 ones? Honestly, like, yeah.
[19:58] Like, what's the top things that you like about React that Solid brings, I guess. I like the focus on the component model. I like that by default, there is 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 at some point.
[20:41] But React basically came up with this idea and then everyone else adopted it. But still, like the function style of component is the best way in my opinion to break to be able to break them apart however you want 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 like both combined into one and you pass it down to a different component and that component can both read and write it so like angular has signals now but they have an object with dot get and dot set So if you pass a signal to a child component, they can also mutate it. Things like that. I really like the suspense model. I gave a talk about two weeks ago at CodeMash called Building Asynchronous UIs Without the Hassle.
[21:30] It's on my YouTube. I talked why I love the suspense and transitions model that React has come up with. It's fantastic. Is this the suspense demo with SolidJS, the solid suspense demo v2? Is that related to that?
[21:48] Yes. So those are the two demos that I presented in that talk. The React version is like a full-fledged 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 solid V2 with like a very hacked together JSX renderer that Ryan made especially for the demo. 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.
[22:21] 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've, 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. But even you think people using React aren't aware of it yet?
[22:54] No, because suspense has been a thing forever, but it was meant for- Yeah, I mean it's like announced how many years, like six years, it feels like something somewhere in that range. 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 the XR components. It's a thing that not every, like 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 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. Well, I mean, I think from a consumer perspective for me, and I'm a person who'll ride the canary builds of Next and React.
[24:01] 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. They have a pretty decent slice of the pie. But, like this year that's changing, I would say.
[24:25] On the React side anyway, it feels like we're getting more server component implementations. I think the React router folks are pretty close. And there's a couple other, who else at the parcel? I think, I think Devin, I saw that. Yeah, parcel, Vite, yeah.
[24:44] Yeah, like the server component wave is coming. It's catching up, which will be interesting to see. 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 we really need to, like the preview build that you got is going to show us where to get those advantages in solid v2, is that the idea? 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 like whatever ecosystem exists it they have like always had access to suspense.
[25:34] The reason I was showing the v2 version is because it has some improvements that the current version doesn't. The current version has some minor issues because they never really got fully addressed. It was kind of quickly hacked together. It's still much much like it still has a lot like the current suspense version in the in the current solid version it's still much better than react but the the second the V2 makes it just even better. And I just wanted to show like the best that is possible today.
[26:09] So that's why I showed the next like the bleeding edge version, but current Solid has suspense, the entire ecosystem supports suspense. So it's like in a very opposite realm of React where React came up with suspense, but because they took so long to actually like build support for it or to collaborate with its ecosystem on it, like its ecosystem doesn't really use suspense that much. 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. Maybe that's not true.
[26:53] I don't know. It's like two things. I think scale is definitely part of what's going on there. But the bigger thing in my head, like from what I've seen is just their philosophy 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, Transact Query, anything like that.
[27:21] Or like the preferred version of how React wants you to use suspense for data fetching is server components. 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 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.
[27:56] And that is like indirect conflict with what people kind of like, how people want to use the stuff. So it's interesting because 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 look at how to start a new React app. There's no mention of any client side, like SPA, right? Like traditional single page app. It's all server architecture, like full stack architectures.
[28:31] 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, 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, cause that's what they use.
[29:13] So that was designed for them. Basically, yeah. And you know, like other people did use it, but it was always like you. How do you even use it? And it's like I don't know nobody taught it.
[29:21] Nobody wrote about it. Nobody you know like showed there was no examples. It was just like yeah, it's great if you you know like you're building a relay app. So it's interesting just to see and I was I was winning. I went to read the react docs because I saw all of the commotion on X about being missing and it's absolutely true and but then you also everything is missing in terms of like traditional spot is all, this is how the architecture of React is.
[29:50] We are a full stack client server framework. 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 wanna go be a contributor, that's not probably gonna happen.
[30:09] Yeah, and that's one place where like, I, solid really shines, which is like one of the things that attracted me towards it the most, which is that like suspense for data fetching is like basically built into the framework because signals kind of have the superpower of like you can just create a bunch of things and not block your rendering which is like the biggest problem with suspense and react where as soon as you try to use a promise soon as you try to do something async you just bail out go all the way to the top and then re-render from there and then you have another thing bail out go to the top re-render from there and because all that has signals it has it doesn't have this problem that like That's the exact problem space that signals were invented for, which makes them really nice for suspense and Async. So you joined the Solid core team recently. Congrats on that, I think that's awesome. Thank you. I think that's interesting too to me, and it really speaks to it, right?
[31:10] Like it's, you can make an impact in Solid. I think anybody listening to this could probably be enthusiastic, go participate, go learn about Solid and make an impact and contribute to the future of the framework. That's the feeling I get from the outside. What does joining the core team mean though? Like what does that what does that entail and what what?
[31:35] You know, how did how did you go from just being an enthusiast to now being a core team member? Yeah, so the the core team of solid is very much made of like people 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. For example like the signals implementation that basically every framework is using today it was kind of like pioneered by this milo who again like the he was on the solid core team because he experimented with signals in a way where like you can kind of have this implementation that can work in any any different framework which originally like the solid jest version wasn't like that but he pushed it far enough where you can have like a different signals implementation even to the point where you can build it into the browser and then like any framework can use it. So that's one of the things, what I was doing with signals was trying to make them full stack. So like make them work across the boundary.
[32:43] So you have a stateful server, like something like a durable object, And you can define these reactive signals and derivations on the server, and you just pass them to the client and the client listens to them, which means at any point, someone 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 how we look at reactive state or state that changes over time across the client and server 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 like pass signals around.
[33:36] How's that working out? Pretty good actually. So I actually, I was on Ryan's stream giving a demo about this. This project actually won solid hack, $7, 000, which was very nice. Right now I'm trying to do a lot of improvements to it.
[33:56] 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 like re-rendering the whole thing, sending the entire payload, the server can just update one piece of like 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 its value to this new value. And the entire rendering happens on the server, so kind of like live viewed. There's a few different ideas that are possible. You mentioned durable objects. Are you using durable objects for your experimentation here?
[34:34] Or what's your stack for that sort of, what's your playground, I guess? I mean, right now everything is local. This will definitely be a good use case for durable objects, because I mean, actually, I'm not sure if that's entirely true because the way it works right now is that like either there's like one global server that every user connects to, or every user has its own server, a WebSocket server, like a durable object. And then they have to talk to each other over WebSocket or HTTP. 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.
[35:20] 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, I think there are like additional APIs or something else. I mean, durable objects would make that easier, right? Yeah. Like they're fine because they're, they're basically a chat room. Like it's a little mini server, like a room is the way I kind of think about them.
[35:42] Yeah, exactly. But to like allow the developer to kind of like express that to the framework that, hey, here's a shared piece of state that multiple users can connect to, that requires a different set of APIs that I don't currently have. So that's a future thing that I'll look into. I'm personally, one of my current obsessions is durable objects and Sunil's work in that area. And just like the, just this, 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 like they each get it, each of them can have a SQLite database of their very own.
[36:32] 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 feel misunderstood. Like people think durable object, 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, you know, they can live for milliseconds or till the heat death of the universe, basically.
[37:09] And you get kind of a really interesting thing to play with that you can build all sorts of cool systems with. Yeah, so Nils has been on a campaign on Twitter trying to build random things and explain. Yeah. Trying to explain ways. And then every other day there's someone like, Oh, that's how it works.
[37:28] I had no idea. And he's like, okay, how do I make this happen but a million times? Yeah, that's the hard part. And it's definitely like an education and example space problem to me. And like a lot of developers and people that are building the blocks for the rest of us to use.
[37:52] It's like, how do you do that? How do you do that work of actually building the systems and then also educate and build the examples that people need? Because people crave examples, right? It's really hard to... People want to be kind of shown the way to do a thing, and there's, you know, 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 like practical examples that people can actually implement on the job is a, it's a, it's always hard.
[38:28] Yeah. 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, 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 like it took us it probably took us a solid like three to four years before we could come up with real use cases for Lambda. And, and then probably another year or so before we can build the tool chain to make it easy to work, like to have a workflow that makes it easy to deploy on Lambdas. Like if you go to a console AWS console today, it still is like write your code here or upload a zip file Yeah, it's like yeah I mean, I gotta say one of my one of the things that is impressive with Cloudflare to me in general is that their runtime just runs locally.
[39:34] So like when I'm using durable objects and yeah, like it's all just it just works. And I think that's actually kind of amazing like that they ship that and allow us to have that sort of freedom from their servers and that sort of thing. Yeah, and this was in direct conflict with Vite forever, but thankfully with Vite 6, now, like Vite 6 was a big, big unlocker for a lot of things going on in the ecosystem. Like several components are one of them, like these meta frameworks, one of them, durable objects, 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.
[40:24] Just like fantastic work, Veeam. Yeah, that's awesome. I didn't even know that. That's cool to hear. Yeah, because with Veeam, you run it in SSR mode and it just runs node.
[40:36] So if you have a VEET project that you want to test with MiniFlare, like your local CloudFlare runtime, it was basically impossible to set that up and like there's very long the rance by Sunil Pai on Twitter trying about that But one of their one of the major goals of V6 Was to address this problem and I think they did a pretty good job at that. Yeah, that's awesome. Cool, well, anything else you're excited about? Yeah, have you seen this, have you seen Zero Sync yet? Anything about that?
[41:15] I've seen it and I was actually just thinking this week that I need to build something and give it a try. It looks pretty cool and just the entire concept of local first. I almost did the Joel Fit app with zero sync actually because I felt like it would actually be a good local first candidate. But no, I've heard of it and I'm excited to try it. Have you tried it?
[41:42] I haven't tried it, but I'm familiar with the concept enough to be incredibly excited for it. Yeah. I like an evolution actually. Yeah, yeah, exactly. Yeah.
[41:54] And I mean, there's actually, there's a lot of reasons for me to be excited for it. I met the, the founder of Rosicorp, Aaron and like, and the other person who worked on Zero Sync in React Miami last year, so in April. That's where they were first talking about Zero Sync with people. And ever since then, I've been like, okay, this is a very exciting project. I'm looking forward to it.
[42:19] And there's a lot of projects that, like if I talk about this project I need to build or I should be building for like 20 minutes, I know that this is a perfect use case for Xero Sync and it's going to make it so, so, so much easier to build. So yeah, I've yet to experiment with it though, like actually build something with it. The other reason why I'm very excited about it is that it's kind of a perfect complement to solidjs because zero sync uses something called an incremental view may IVM incremental view maintenance which means the data that you have on the client, like, Xero is basically able to make very small incremental changes to it instead of like 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. Right. XeroSync doesn't do that.
[43:17] It like makes a very small change to that array and then it's done because it has like 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 re-render the entire thing and then it would diff the entire thing. But Solid doesn't have to do that.
[43:56] And for Solid to be completely optimal, it needs this like incremental thing 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 front-end performance thing, front-end performance. It doesn't matter really to most people. Most people are really not going to notice, but like from an architecture or like efficiency standpoint, like this is the end game. When there's some apps that would probably make possible or like performance wise, for sure, yeah.
[44:30] That would just like really, really benefit 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. Yeah, thank you. I actually gave like a virtual talk around this kind of vague idea, but I didn't mention zero sync in it, and I didn't mention solid. I only mentioned like this idea of like the server sending incremental updates and the client doing incremental updates.
[44:55] But I didn't talk about like how you could actually achieve that, like what technology you need to put together. Like the implementation details. Yeah. More of a conceptual idea. Yeah.
[45:04] That's cool. Cool. Well, it was great to catch up. I'll talk to you soon. Yeah.
[45:10] Thank you very much. This was fun.
