Axios Is Out. Fetchium Is In.  Robbie the Wagner and Adam Thomas Argyle the nerd. >> You're so absolutely right, Robbie. >> Thank you. Uh, sickopantic machine. Um, yeah. Would you like to tell the folks at home who we have on the show today, Adam? We've got a JS hacker, API designer, dev tools, crafter, introspect, pixel artist, writer, chef, TC39 delegate, Ember, contributor, principal, front end, devat, phantom, decorators, champion, co-ch champion of signals in JS, seeking to solve the world's scattered reactivity wos, reactivity wos with one true signal to unite them all from this elevating reactivity hell we're in. Coming to you live from the same state as Robbie on this fortuitous visibility day. Kristen Garrett. Y'all, nice to see you again. Been since Cascadia JS last year. >> Yeah. No, it's great to see you all, too. Glad I could be here. >> Yeah. Yeah. Thanks for joining us. So, yes. Um, as the name of the show entails, we do some whiskey, but as everyone is hopefully happy about, I haven't heard yet, we don't talk about it anymore until the end. So, we'll just mention what it is. We've got some soft red wheat holiday uh bottled and bond Missouri straight bourbon whiskey. Okay, we'll tell you more about it afterwards, but a lot of people don't want to hear about the whiskey. So, >> if you don't care about the web >> Yeah. Yeah. A lot more people care about the web. >> All right. Well, I do have a toast though. So, for our first sip, >> may your whiskey glass overflow with tasty pixels, your signals be true and clear, and your code compile on the first try. Cheers. >> Cheers. >> Cheers. >> So, yeah. Um, it's been an eventful I think six months since Cascadia. Um I have been working like crazy on basically a better version of Apolloquery. Um so Apollo client is great, right? Um but it is GraphQL and Tanacquery is great but it is very simple. Um and this is actually why I started working on signals. Um, and maybe should we give like an intro to signals at all? Uh, maybe I don't know how familiar people are. >> What is a signal? I'm Yeah, no, we probably should. >> So, signals are a pattern that's actually been around for a long time. Um, I think one of the earliest like JavaScript implementations of it would be Mobox. Um, uh, MobX is basically signals although it's a very like classoriented version of it. It's like that idea of you have you know these reactive values you consume and you kind of automatically track them as you are computing um some output and uh eventually we kind of figured out that you don't really need to have a class or like anything too stateful. You can kind of just have functions. Um and then uh basically your functions are can be pure uh if you are thinking of signals as like if you're thinking of all of your mutable state being in signals, right? They are signal pure. So they're like guaranteed to produce the same output if the signals have the same input and if you're not doing anything too crazy because I mean it's JavaScript. You can do whatever you want. Um but yeah, basically every modern web framework with one major exception uh is based on signals these days. Uh Angular migrated to them I think last year. Vue has been based on them for quite a long time. Spelt uh with runes is now based on them. Um solid uh definitely one of the big ones uh that kind of started it and pioneered it um in rendering frameworks. Ember uh you know had autotracking which was a form of signals is how I got into it. And >> which one doesn't have them? >> You know it's kind of the the elephant in the room. React has has kind of panned signals and um I don't I understand where they're coming from. Um, I think that that might be a bit of a I think they they were trying to evolve things in a very different direction when signals were first starting, right? Signals are very they kind of look like these objects that are stateful and they wanted to go into this hooks direction where it's like, oh, we have these pure functionsish um, but they're not pure, but they're kind of pure. And I want to give credit to React because I don't think I would have gotten to where I got with Signalium if it wasn't for React. The thing about Signalium that's different than other signal implementations and there's several that are in the React ecosystem too. You've got like Jotai Legend state. These are signals implementations that follow this pattern. But the key difference is that most signals libraries don't allow you to parameterize your signals. Um, and what that means is you kind of have to manage the life cycle of every computed signal, every derived signal. Um, you have to like if if you want to have like a hook essentially where it's like, oh, use uh full name of user, right? Like um you can repeat that with like 10 different users, pass in 10 IDs, right? and React handles the you know setup and the life cycle and the tear down and everything there. Um and with signals traditionally you kind of have to like manage all of that yourself. Um so it's a little annoying uh and kind of stateful and I can see why people would look at that and be like ah we don't really like it. it's not really like functional, right? And it to be fair, a lot of complexity ends up being in that those parts that aren't functional. Um, >> when you say not functional, do you mean not like functional programming? >> Not that it doesn't work like >> Well, you start to have Yeah. Not like functional programming. you start to have um some really tricky it's not even that it can necessarily be like um the worst thing in the world. It's just like state to acrue in various places, right? You start to see shakes fisted stalled version of you. I'm like, no, >> I was brought to you by internet. It's tough. >> Well, I'm having fun linking everything as we go. I've got uh in the chat so far links to Signnolium and to the uh signals proposal. So folks want to follow along with that. Check out the chat. I guess it was more like tweets, but here I'll put it in the chat and signal. I'm tempted to like ask about observables. I'm like, are they bad? Are they good? >> We'll never know. >> You asked a guest. The whiskey was too strong. Bottled in bond. Yeah. >> Oh, is here where here we'll talk about the whiskey. >> Hey, yeah, now's a good time. Um Oh, we just lost everybody. No. Um yeah, we could talk about it real quick. So, this um See, where is my notes? This whiskey is 73% corn, 15% soft red wheat, and 12% malted barley. And I don't taste any malted barley, personally. >> Yeah. Which I'm kind of I like the bite. I'm happy. I'm like, it's got a spice. Yeah, it's like for being that much corn, it has an interesting amount of stuff going on. Um, >> yeah, >> little spice, a little um little tang or something. I don't know how to describe it. It's got something different going on. >> That must be that soft red winter wheat. >> Uh, which apparently soft is because it has less proteins in it, so it's less glutenous something. And it's gives it Oh, it really um >> so that means physically soft like >> like it's um >> I don't know. It's not like hard water and soft water. Is it you know it's like >> do we just use these words cuz we didn't have anything better? >> Yeah. >> Yeah. I don't know. Um I think this is my first weeded bourbon. >> Yeah. Um, yeah, it's uh it's been a while since I've done a weeded one, but we've done a few on the show. Um, and then yeah, bottled in bond has those requirements. It's got to be at least four years old, hunterproof. And this checks the boxes at six years old. So, oh, this reminds me of You've seen Wayne's World, right? The movie. Um, I'm actually not sure if I have, which might be very >> Shut the hell up. You haven't seen Wayne's World one or Oh my goodness. >> I'm familiar with it, but um, >> that doesn't matter at this moment. >> Seen it. >> Yeah. I don't think I've like sat down and watched the whole thing. I feel like there's a lot of movies like that where I've seen like bits and pieces when it happens to be on, but like Yeah, I'm pretty sure I haven't sat down and watched the whole thing. >> Oh man, there's a scene. So, you know who Wayne and Gar are? >> Mhm. >> Okay. So, Wayne is usually the one talking. and Gar's the nerdy, you know, secondary one. Um, and there's a moment and they're like live uh and like the first or second episode after they kind of sold out and they started making a bunch of money and went to a nice big production agency. Anyway, um Wayne has to leave and G is just left there by himself and G is like totally frozen like a deer in the headlights like I don't know what to do and the show is just mine and he just gets really awkward and it's really funny. So I kind of feel like that right now. You're coming back. I think I'm coming back >> at FPS five, but you know that's cool. >> It'll record normal. >> Yeah, it's fine. >> Okay. Um, so yeah, where were we? Um, Robbie was just digging in about >> Oh, >> yeah. I forget what we were saying. Um, well, what was I saying, Adam? Seems like you knew. Uh well you were digging into the intricacies of it like signals that had other dependent or that needed computed. There was a word about signals that you were asking about. You're like what does that particular part mean? >> Oh just I was just being um silly about like is it is functional >> like functional programming or like works. >> Uh yes yes. Okay. >> Yeah. No, it's like functional programming and you know that to be fair to because I think we all went through like the period of like h functional everything and that was interesting. Um there's a lot of nice things about it though and I think React's model with hooks really pushed the boundaries of that and it had some really nice like properties. One of the biggest ones being we're threading life cycle all the way through the system without having to like very be very explicit about it. Right? If you remember in Ember, you had to like thread the owner through from a component all the way through any kind of dependency you had and you have to like manage all the life cycle. your life cycle hooks become very like um deeply entangled with every single part of your system and all of a sudden your code is no longer like isolated. Your component logic seeps into every other part of your code. And Adam, you were about to say you're tempted to ask about observers or observables. >> Observables. I sure was. Yeah, I uh I'm still a big fan. I'm like I miss them. I kind of want them back except testing them was hard. But anyway, yeah. Well, observables are very interesting because they are a very similar type of system. They allow you to abstract away that reactivity and to create these composable elements. But the issue I had with observables is similar to the issue I have with uh you know kind of like those life cycle hooks is when you start writing code in observables kind of everything needs to start using observables. Everything needs to become observable aware. They're needy. Yep. >> Yes. >> And hooks at first doesn't feel like that, right? At first you're like, "Wow, I can use plain functions and everything's just a plain function and whatnot, but then over time you start to become really entangled in them and you you can't really detangle very easily." Actually, uh, one of the reasons I started working on Signnolium is, um, I was debugging some React components we have, trying to figure out performance issues and whatnot. And I noticed because I was doing a thing where I triggered the whole, ah, you called the same hooks out of the wrong order bug. Um, I noticed our stack was like 200 hooks deep. And it wasn't even that big of a so few. >> Turns out when the smallest like node of your reactive system that you can rerun is the component. It ends up being quite a lot of uh stuff. Um but yeah, I I think that um with signals coming back to Fetchium, the goal for me has always been like can we detangle these things because you've got like data and then you've got like you know app uh view code and then you've always got a lot of business logic in between. You can't like really get rid of all of that. You've got a lot of like deriving you have to do and like monging of data and you got to like thread this needle and then you've got to thread life cycle through that and hooks almost get you there but you can't run them just anywhere and I couldn't like build fetch on hooks because I wanted fetchium to be independent I wanted it to be a data layer Apollo is built on observable Right. Um, it gets to do that and nobody knows under the hood. It's just an implementation detail. Um, fetch does the same thing with signals. And I just think that signals end up being a more elegant and um, like more ergonomic solution to the same problems. Especially for front-end def where you really don't want to capture every single event. you want to kind of allow the events to be driven through the system by consumption. Um, so you know with observables you kind of have to like force it all the time. You have to be like I'm going to debounce this and I'm going to like wait on this and then I'm going to Yeah, it just turns into like a really annoying like process where you're constantly trying to throttle that. And the only time I think that's really super useful is if you're in like a backend system where you really are like I want every single event to come through. I need to capture all of them. >> Oh man, it was good during touch events too because I could layer the touch uh start could kick off an observable that then kind of observed all the touch moves. I could zip the um the moves into a pointer event. So I could I could like merge whether or not it was a pointer event or a mouse event or all these different things into a single observable, feed the observable that actually needed to update some translate X and Y properties to make something very tangible and movable. And then when I got to the end and someone flung, I could easily close it all down. So there was like I agree though that most of the cases were uh take one, you know, it's like I just I just need one of these. Just give me the most recent one. I don't care about the history. Um but there were times when it was nice to have this replayable scenario or it was also I thought it was nice to think about your UI as not a one-time thing. That's a that's a problem people think about all the time where they're like, "Oh, they just hit the submit button once. I just need like one listener." It's like, well, they might hit it once and then open it up again and hit it twice. Um, really fast >> or Yeah. Which also observables were really good at handling that. Um, because you could cut but you had to continue chaining more chains. Um, >> yeah. >> And that was kind of the problem is it was like you could feel it infecting uh the code and if you didn't have a good grip on the mindset and then that's where testing came in to be a bummer too. You were just like, "Oh, great. Now I have to recreate the five chains that I put together just to do this submit form." uh to do a unit test and and then you had timing with unit tests. It was like a pain in the butt too. And anyway anyway I digress. >> Timing is always a problem and that's why I've always liked honestly Ember's test model like to to go off on a slight tangent but Ember you know had that model of like just run the tests in the browser and then um it was a bit more like you know a lot of like uh user testing library and stuff is like uh polling based. it's just like wait for the thing to be in the DOM. Um, and I prefer Ember's model where it was like, well, we we know when things have settled and when we're done rendering, so just like, you know, check it then. Um, just gives you a little bit more speed and, you know, but the main thing is just like, yeah, render the real component and then interact with it like a user. I think that's like that's that's a thing no matter what. Same issue with Signalium, same issue with any reactivity libraries, timing becomes tricky, hooks as well, like very much so. Um, and then back to what you were saying about observables, I think that like the second thing you mentioned of like you might come into the state in many different ways, you might come into it many different times. I think that is what a good reactivity system in general solves. And I do think that, you know, hooks can solve it if used correctly and, you know, thoughtfully and uh you're not doing anything too complex. It's It's actually pretty solid at solving it compared to some of the older stuff that like I don't know when I first started building stuff it was like Knockout and Meteor and Ember and Angular one and you know um so I I think that um yeah I think signals will get that for you as well if you play around with them. Um, I think that the other thing is where signals is not the right abstraction, but that's also such a niche thing that I think I'd rather have a specific abstraction for that, right? Something where it's like, oh, I am trying to track every single event here and I'm trying to have really nice animations with all of it. like having that integrated into the system that's going to render unless you're trying to render like the X and Y coordinates on like oh this is where it's at like right now on screen a bunch and you're also trying to feed that into a bunch of other data. I don't know how useful that is you know. >> Yeah. Yeah. I feel like um you know the big problem I have with all you know hooks and the way things are done these days is that it feels backwards to me of like okay everything will rerender infinitely until you tell it not to. I feel like the other way is the way it should be of like I'm gonna tell you the things that need to rerender and those things should be tracked because like >> it seems silly to do it the other way of like all right these 400 things I want to ignore like or there's like one I care about you know like seems >> yeah like going back to my Cascadia talk like basically if we think about it like promises right promises um like if we did what hooks do for reactivity to promises. It would basically be like every single time you hit an await, you halt the program and then you restart the program. At the start of the function, you go through every single function again, but it all has to be item potent. Every single step you take has to be item potent and then you hit the next await. And that's actually exactly how React suspense works. like use just throws an error and you know suspense catches that error. It sees that it's a suspense error and it's like okay I'll wait and once that promise resolves it starts re-executing. So you're literally doing that um with Signalium and with Signals in general but Signalium also really focused on having us like recomputee from the change state upward. So if you imagine your state tree and your functions, your hooks as like a tree of dependencies, right? And you you're doing essentially like a depth first walk of that tree when you execute it the first time. We start at the leaves when state changes and we walk up the tree and at every node you can stop that walk. You can say okay now that didn't change. So then nothing above this point has changed and really this is like similar to a lot of like diffing algorithms in general for components. It's just on the function level which is what promises and async did with like uh async aait did with like that operation. So I would say this is that's the way I've been framing it is like this is a monad for reactivity and I could actually see this being like a keyword in the language one day maybe. Um, don't quote me on that because, you know, I I still need to do the actual um, I don't know, sciency parts of things to to formalize all that, but it feels like it can be. It feels very composable. Um, and it's very nice to work with. >> So, how does the like official signals proposal come into play with any of that? >> Yeah. Okay. So things that signal does that the official signals proposal and basically no other signals like libraries do uh the two things are those parameterized like functions. So um what that basically works out to be is like a a signal factory and then kind of hooking up those signals and their life cycle to some consumer which we call a watcher in Signalium. Um, the closest I've seen is Jotai has atom families which are pretty similar, but they're like kind of an afterthought it feels like in Jotai. And in Signalium, we're like, "No, that's the default." Um, so there's that and then there's async. And async in general is usually an afterthought. It was an afterthought for Ember. If you remember, we rolled out autotracking and we were like, "Yeah, autotracking this is great. This is great for everything." And then people are like, "How do I manage a request?" And then I started building for years. Um, mostly because Chris Seldon just wouldn't let me land anything because he kept being like, "It's not perfect though." And I was like, "Chris, I swear if people aren't able to make requests, they're going to mutiny." Like weird. >> Who needs requests? All your data is just stored in the the front end. I just remember people using like modifiers to make requests which I was recommending because I was like yeah these are the replacements for life cycle hooks you should use these and then Chris was like and and you were like oh that's not what they were for actually and then I was like okay well how do you make requests if we're getting rid of these life cycle events and they were like you need to figure that out. We are still debating like they have the lint rules about don't use the render modifiers and don't use like >> um something else. Oh uh run loop maybe. Yeah. Yeah. So I'm like how do you render something after render without the run loop or render modifiers? You could do a custom modifier I guess but I'm like you get come on. I feel like a lot of the debates were really driven by like being perfect and they ended up letting the perfect be the end of the of the good. Um and and I'm trying to split the difference in a lot of ways. Like I want to have better than the status quo. A lot better than a lot of the status quo. Um, but I also don't want to um, you know, have it be like when I talk with Chris Elden, I still talk with him a lot and, uh, when I talk with him about um the um, async stuff and reactive promises and whatnot, he'll still be like, I don't know if that's quite right. And I'm like, okay. But it works really well. It's like it's definitely a lot better than hooks for a lot of things. But anyway, so reactive promises um are the thing that not not just reactive promises. Reactive promises and relays are the things that most signals implementations don't have or kind of only vaguely have and that I think are super necessary, but it's like a couple steps down the way for most people. And I've just been like messing with signals for a lot longer than most people like besides like Michelle West for MobX and um you know so I think like I've I've actually been talking to like pact people were like yeah we kind of need something for this and the solid people too and whatnot. Um so uh the proposal has what we need for those like you can implement those on top of the proposal and that is the connected and disconnected I think they're called or watched and unwatched hooks because you really basically need a way to say okay this part of the signal graph is being used by something live and that watcher that that observer externally could be like the DOM, right? Or it could be like your app. Um, it doesn't really matter exactly what it is. It's just userdefined and it says like, okay, as long as I'm using this, I need to consume resources, whatever those are. Now, on the other end of your signal graph, at the very edge, you will have something that communicates with the outside world. Um, that could be a connector to Apollo. Let's say you want to use Apollo, you have GraphQL, you just want to hook it up. Well, you need to subscribe and then later on you need to unsubscribe. You need to tell it like, I don't need those events anymore. Um, you could be communicating to a websocket. You could be communicating to a background process, to a web worker, like anything that is async and specifically that's not like request response. like you can kind of get away with request response like promises because those have an end point, right? You can kind of just toss it away if you don't need it anymore and it's not going to continue to consume system resources. But you cannot do that with any kind of subscription. And so you either need to thread your life cycle through the entire graph or you need to build it into the graph. And when you combine it with um like optional um not optional but like forking essentially so like uh branching branching is what I'm looking for. So like if you have an if statement right and it's like in branch A I consume signal graph you know A and in branch B I consume signal graph B. Unless we're saying we want to consume all of them all the time. You need to be able to dynamically switch between one and the other. And then you need to be able to sub unsubscribe from one and subscribe to the other, which kind of means the graph needs to know about this stuff. Like it's the only thing that can unless you want to start again doing a lot of really nasty threading of life cycle through all of that. And yeah, so that's how I got to where I am today with Signnolium and me being like the one person I convinced little Dan like we probably need the life cycle hooks and he has kept them in there and I've been very thankful to him for that. Um because everybody else is like do we really need these? And I'm like you will trust me you don't want to ship without them. >> Yeah. Yeah. I mean, so this stuff uh seems more complex than I kind of thought of signals uh being, you know, coming from I do mostly Ember still, so I'm like tracked properties. Yay. Um but I'm curious how you feel. Have you seen um Adam? How do you Is it Gia or Gaya Ga JS? >> One of those. Yeah. >> Yeah. >> I haven't seen that one. I haven't been keeping up with stuff a lot because I've been just like in execute mode for getting stuff done with React. >> Yeah, system and a half. >> So, so Gia, I believe I guess it's Gia. We'll say Gio. Um >> I like Gia because it makes me like Gio. You know, you could say it real cool, you know. Gio. >> Yeah. Yeah. >> Um but it its whole thing is like um I don't know how it was built. We're hopefully going to have the guy that wrote it on and and learn about it. But the TLDDR is like it's super small and it has no hooks, no signals, no like it just figures out what should change through like some magic compiler and I'm like what? So like um I don't know. I'm curious of your thoughts on like I always kind of have this big, you know, vision of the future of like will all of these minute things we debate about not matter and we just write like, you know, thing equals whatever done. Um yeah, where what do you think about that? So I I think that um like signals I I'm after that as well and I think that promises did that for async like the world before promises with and and sync uh symmetric async right like request response the world before that with promises was the wild west. It was just like callbacks everywhere. And it wasn't just JavaScript that had that. It was C. It was Java. Like that was pretty standard for a lot of things was just like, you know, how do you resume after asynchronous actions? Well, you kind of just have to like, you know, pick it back up. Um, so I do think there are things we can do where we can figure out abstractions that allow us to no longer have to think about entire problem spaces. And we've done that many many many times in computer science. In fact, I think that is more important to do now with AI than ever because if we want the code to be understandable, if we want to be able to read and write and execute quickly and not just be making slop that's about like five steps away from falling apart all the time, um we want simpler abstractions. Um that's actually one of the reasons that drove the design of Fetchium. Fetchium has this very declarative syntax um for the design. It's like you declare your params, you declare their types and then through some proxy magic I use those uh like when you reference those parameters um elsewhere uh I'm basically capturing a reference to them and then for each instance we actually go and reify those parameters and all the fields that are derived from them. So the path itself of a request or the headers, you can actually reference like this.params dot, you know, ID or this.params whatever in there. It's really cool. And at first I was like, okay, is this too magical though? Like this is a little bit a little bit much. Maybe maybe people won't like it. And I realized, okay, but AI probably will really like it because it is very simple. It's very readable. and AI can remember those rules typically as long as you give it the like hints of like okay don't do this and be careful and use this agent definition and you know um so I decided to go for the more declarative thing rather than a thing where I would have had to have more like function definitions so anyway sorry tangent but yeah I think that um it is actually something we can do we've done it many times times. We did it when we created compilers for assembly. We did it with uh closures. Uh we did it with you know promises and futures and and I think we can do it with reactivity. I think we've been trying to do it with reactivity since like the first functional reactive pro uh programming white papers which I like went back to read at one point on this journey. It's like they're describing really cool things, but like the how you actually write it and how you actually use it has always been this white whale of ergonomics, right, of like most people don't seem to get it. And the people who do are like, "Why don't most people get it?" And I'm like, "Have you seen Elm? I don't know, man. Like, have you seen Haskell?" Like, I I get it now, but also like it took me a while to wrap my brain around that. like took a while. >> Yeah. Yeah. I mean I feel like a lot myself included a lot of the time a lot of web developers don't understand a lot of the complexity. So like I feel like there's two very separate camps of like um you know one one side frequently or historically at least maybe not today with AI and whatever's going on but like I think the people that chose writing 200 React hooks liked the complexity. They want that. They're like I love it. Look at all these hooks. They're awesome. Like, and then the other side was like, I don't ever want to write a hook. I just I want this.fu equals bar and I'm I'm happy. Um, and I think, you know, neither really matters anymore because AI is going to write so much of the code that like you're right that like if you build your libraries to be very easily usable by all these models, then I think they'll just be like, "Oh, this is easy." And use that like because I don't I don't know how you feel about people are saying, "Oh, I'm not even going to look at the code anymore in like a year." And I I don't know if we're going to get to that. But >> I actually think it's more important to read the code than ever. And here's why. I think we are going through what happened to our physical bodies when we started to have 9 to5 desk jobs like be the main way of, you know, uh kind of working, right? Because it used to be that for most people, you would probably get at least a little bit of walking in, some standing, some like doing things and not just sitting at a desk staring at a screen for eight hours. Heck, before work from home, uh, you know, I at least had to go to meeting rooms on occasion. Um, so you know what happened in the last century? We started going to the gym. Gyms happened. Um, physical fitness and all of that. I think that's about to happen to our brains. Like, yeah, you don't need to like use your brain in that same way to get 80 to 90% of what you need done done. But if you don't, you're not going to get it through just doing your job anymore. And you're not going to level up. You're not going to grow. You're not going to understand things deeply anymore. And I don't know, that also just doesn't sound very fulfilling for me because I love doing this. Um, but I also think like if you want to be a good dev, you're going to have to read a lot and you should be reading your your agent's code all the time. I think um >> the domain gym.ai is for sale. Just saying. >> Just play Clues by Sam. That's the thing I do that always keeps my brain feeling sharp. Um I I empathize with what you're saying, but I also feel like uh my brain is um incapable of what AI wants it to do now. like I'm not I'm not good. I'm not enough. Um it could take uh you know I could be commanding 100 teams uh if I was mentally capable. If I was I need more arms also, you know, give me more arms for more fingers with more keyboards and I could be making more software, you know, like >> uh or or even like the model changes where like I'm not telling one, you know, it starts with you you try to tell one agent what to do. Then as you level up, you tell a team what to do. Then as you level up, you create swarms, which maybe are like multiple teams. You level up again and now you're like coding entire teams. So you hit a button and it creates loops that create teams that create teams that go out and they do work and they kind of like fan out and re come back and fan out again. And then you've got your gas towns. Um, and you could have multiple gas towns and eventually someone's brain is trying to manage a country of, you know, agents or whatever. And it's like I feel incapable of uh like Jason Langorf says like I can't even come up with one good idea to go execute. How are people out there having three or nine or whatever. He's like you're all you're lying. There's no human brain out here that can do that. But I do feel like during the workday that my brain is now being taxed beyond its squishy capabilities. I'm like I am just but flesh. I'm sorry agents. I am I can't. You need too much from me. I need to leave at four o'clock today or else my brain might explode because I just can't deal with six agents at the same time for eight hours a day. I'm too squishy. Um, but I also agree that like there's a point of which I'm losing the details. And I love the I've sweated the details my whole career. It's what I think got me where I am. Um, and now I'm sweating the details in a way of orchestration. you know, how do I sweat the details uh so that I can create something that does the detail work? Um it's just different. And I agree there's you're going to have to balance it. Uh there's an imbalance that's happening. It's Yeah. If you went to the gym and only did curls, you know. Um so >> I used to go to the gym and only bench and then go into the sauna because that was the fun part. >> Fair enough. But yeah. No, I think like having a varied routine is good. I think pushing that far in that direction. I'm a very like balanceoriented person. So, >> yeah, same. >> I try I would just try to be like, "Yeah, I can't handle more than six at a time. Sorry." And if somebody else is saying I should be able to handle more, like, okay, cool. I don't know if what you're producing is actually going to be like the right output in a lot of ways. And I think like actually zooming in on those details, it matters like I have uh been working on a little slide framework I use for my presentations and you know I it's it's a little messy. It's a little hacky cuz presentations are always last minute and I'm just hacking away. And I found that when I have AI make my slides now, which is what I do most of the time, it's messing up a lot because the abstractions aren't perfect. Um, and it's like dumb, not perfect. Like I could go in and fix it pretty easily and then I wouldn't have to fix what my AI is doing with the slides and then every single bot after that would be a lot better. I think working on the abstractions and getting the details right matters still. And what I find my most productive times are when I'm like pairing with an agent and I'm basically like watching what it does, watching how it's thinking because oftentimes I will see it thinking and be like, "No, stop." >> Screech, right? >> Yeah. I can barely >> I can barely keep like you know, you were saying that reading the code is important. I think so too because like for things that you have good domain knowledge on, you know, better than what it's gonna write. So I'm like, "Hey, yeah, um, you just wrote like 500 lines of code. I needed you to like add a like optional chaining thing." Like that was it. Like or like something, you know, small. And it's like, oh, like I just handled every possible case. And then also, you didn't ask me to, but I ran linting, ran the test, committed it, pushed it up, like I'm like, "No, stop doing all of that." Um, but yeah, like I I have a hard time managing one agent at a time because they they're done so quick. I'm like, "Do this." It's like, "Here you go." And I'm like, >> and I like reading what they're doing. I'm like, "Oh, cool. Let me follow along. Oh, that's good. That's good. That's bad." It's like Austin Powers like yes, yes, no, no, no. >> I think it's also like very new. And it it could change significantly as time goes on. Um, I could find that things get easier to manage, like larger numbers of them, larger swarms of them. Um, and who knows, they could get more intelligent, although I I don't know I don't know how much further we're going to be able to push the LLMs. Like the last iteration has definitely been, you know, significantly better in some ways in like the details, but it's also like still not making any progress on a lot of the creative stuff. Still not making a lot of progress on like figuring out directionally where we need to go or having judgment on those things. >> I have a couple questions. You said a couple words earlier and I want to know uh more about them. So the first one was uh you were saying threading and I feel like that was just a really nice way of saying prop drilling. Is that correct? Kind of. >> What's the difference between threading data or threading a signal or threading you know reactivity through my application from a top down? How is that different from prop drilling? With prop drilling, you can um pass things down very transparently and it's more just that it's annoying. It's like, oh, you just have to keep passing it down and I have to like >> But you don't really race from node to node. Yeah. >> Yeah. You don't really have to do anything at every layer other than pass it down, right? um with what I'm referring to with reactivity threading it through the system like every time there's a branch you also have to now you know set it up and tear it down on either side of the branch. So you need to like integrate at various points in the system. You need to have like your life cycle on both sides of that which it's more like a vein. So a vein running from into these different parts of the system. Um, okay. Okay. I think I that's a good metaphor >> and it's I think we think of prop drilling around components and this is really much more around functions which is far more pervasive in a lot of ways but also you know passing parameters down and prop drilling through a bunch of functions is not as annoying. Um, I find at least I I used to think it was annoying and then I had more and more, oh my clever thing where I kept the state in something that was like semi- global or whatever or just, you know, it started getting a little bit more like, oh, hey, that keeps biting me. And I'm like, now I'm like with Typescript, I'd rather just have like very explicit, very clear types. And I don't mind boilerplate, a little bit of boiler plate for that. >> Gotcha. Prop drilling is like a skewer that goes through each piece of meat and piece of meat is like your component and um threading is an abstraction. So it's like this exists outside of the meat, you know? It's like I have a strand of things and it can go through meat. I don't care. Meat subscribes to my thread. Uh >> is that kind of it's like it's like a state store. One thing I will say about prop drilling um that I think is it's like an antiattern. Like people started considering it an antiattern I think a lot because um React really like if you prop drill all over the place, you're going to have rerenders all over the place because >> it's not as portable either. You try to move a component and be like, "Oh, right. It was in the middle of a prop drill and now it's not." Anyway, yeah, you could break things. That's a good point. Um, but I do think there you miss something when you start having like, oh, I'm just going to use a context for like all my data loading and then I'm going to use query in every single component that needs the query. It's like you lose where's that data even coming from? What initiated that query? Where who was the original caller? It's like we don't know. or just kind of getting it from wherever and like, okay, where are our routes? What is the overall structure of our app? Um, so I'm not saying I think one pattern or the other is better necessarily, but I don't think that the performance thing should be tied to the structure thing. Like I think those two things should be separate concerns. And I find this a lot in React with the current setup, right? This is something I've been trying to solve with Sagalia because with fine grain reactivity, I can have a reactive promise at the top of my app. I can pass it all the way down to the childmost leaf and the promise object itself never changes. Uh the values on the promise and the state of the promise changes because it's a monad. So um you get it all the way down in this leaf you dstructure value from it uh and it's if it's a signalium a react component wrapped with signalium's memoization um it will rerender you know based on that value changing but it will none of the other components in between will so it just takes that out of the equation that said you might still want to like use query everywhere for other reasons I just don't think that it the performance should be the reason. >> There was one more word you used that I hadn't heard before, at least in the context, which was relay. So, what's a reactivity relay? >> Yeah. So, that um I know relay is like an overloaded term, but so is everything else. So, um nothing to do with relay, the data loading library. Um right, >> I was more so thinking like signal relays. Um really what they are is an abstraction that kind of replaces use effect in hooks. Um they are uh almost a self-contained hook of state and internally when a relay is used so when it's connected through the signal graph it it looks like a reactive promise. It has a dot value like any other signal. And so you can just read it. Externally it just looks like a value. Um but internally when it connects to the signal graph if it is being observed if it's being watched it starts up it activates itself and that is the where you subscribe to something. So relays relay state outside of the graph into the graph and then vice versa. You can also react to state changes from within the graph and relay them outward. So you might have a signal for your current topic and you want to subscribe to a message bus. The relay reads that signal for the topic, subscribes. Now the signal topic changes. The relay reruns, cancels the old subscription, updates the new subscription, and feeds the state from that subscription into your graph. It's a way to have a node that communicates with the outside world without like exposing the details of that communication to the graph. Excellent. Thank you. For some reason, I was thinking subject in observables or there was an observable that was similar to this. Um, but I haven't used observables for I don't know, six, seven years, maybe more. I I believe it like they're very similar in a lot of ways. Like I said, everything I found that everything that I have thought of in signals and everything has had like an equivalent in observables and whatnot. So very much on the same wavelength. The odd man out is hooks, but you know, you didn't hear that from me. I did find what Gio used by the way. It's proxies, which I've always wondered why proxies weren't used more. They've been around for so long. They seem very uh you can intercept and do comput >> because debugging them is hard. >> Yeah. Well, debugging a lot of these things is hard. Yeah. >> Fair thing about proxies is like, sure, that might be how you track what is being used, but under the hood, you still need to like put the dependencies together. And that's where like you could build a proxies based thing on top of signals. That's what Mob X is or like what views data is in data components. Um and you can also connect those all using observables. You can't connect them using hooks because hooks is very tied to the rendering layer. But um I know I keep ragging on hooks, but it really is just like whenever you start looking at, you know, a React library and you're like, "Oh my god, how many hooks are what is going on here?" And it >> Oh, yeah. You're preaching to the choir here. So, uh let's just react is the hammer. >> Uh no, go ahead. >> What is a hook? If if React is a hammer, you know, and everything is is a hook a nail. No, cuz what is a hook in this thing? you know, like cuz they do they're used everywhere as like some sort of like, oh, it's duct tape. Oh, I'll just tape it, >> you know? Oh, just you just need more tape. Just another piece of tape. >> The thing is like that makes sense in a world um like that is also true with to an extent with signals. That is definitely true with observables, but those things can be used independently. You don't need a whole rendering layer to use those. You can't make hooks um Apollo client and then run that anywhere. Like it has to work in React and that's the only thing. It just ties everything super deeply into React >> which is what they want. >> I don't think that's what they want. I think they I think they actually believe that it is a better model and I can see why they got there. Again, it's like following this one thread for a very long time and then a lot of sunk cost fallacy along the way. But I I I like to think better of people. Um >> yeah, I don't know. I like to rag on React. So, um but I I think that uh you know, I don't know who's in charge now. I know they have a React Foundation which is supposed to like democratize some of it but like with Verscell being such a like pervasive like the only one that mattered in React for a little while. I feel like they do want it to be like oh it can only be Nex.js it can only be React. It's all very bespoke like you can't ship it anywhere else except for on Versell. Um >> I don't know about Versell. Um I almost worked there. I got an offer, but yeah, I was then then in Phantom the Phantom acquisition for Bitzky went through and I was like, well, I'll see how this pans out. And it's been interesting. It's it's an interesting problem space and I don't know, I still think there's some cool things crypto can do, especially around to go off on another tangent. Um, and it it's annoying that the crypto industry isn't doing this because we keep seeing it. uh verifiability and like knowing what is real, which is becoming more and more of a problem with AI and AI from the sense that like somebody was saying recently OpenClaw is going to just destroy like >> you know our our texts like people are going to be like doing phone scams like all kinds of things like soon. Um, and that's just it's going to increase the output of that exponentially, right? Um, I I think that with not crypto necessarily, but with cryptography and like a distributed web of trust, you could imagine a less creepy version of that same Almanbacked company that's like we verify that you're a human, but like not in a way that where we store your biometrics and stuff, but um more like in a way where we just you go into like I don't know a nonprofit and you're like hey here I am here's my ID here's my stuff and they're like cool you haven't signed up with us before what's your wallet address and then they say uh cool we're going to sign that wallet address say you're a human now you can go and take that anywhere but you can share it in a way where nobody else can see any other details about you just that this one organization said that this account that you phone is human, right? Stuff like that. And then get rid of like the age verification nonsense we're doing now because you could do that with age too, right? The government and again no other details are shared. It's all very privacy forward. And then combine that with like okay now we can see >> think of it like distributed blue check mark for the web. >> Yeah. Yeah. I think there's a lot we could do. Um, we talked to Angie Jones about this about like um I think certain states have like store your like are you over 21 basically so you can just buy alcohol from an app without it needing to know your birth date or like whatever. It's just like you're verified being over 21. So it's like there's a lot of that stuff we could do of like little checks that could be like you know immutable or whatever and like verifiable. So, like, yeah, I mean, there's definitely stuff we could do there. Um, interestingly though, I wonder what your thoughts are about, um, I just saw this in like, I don't know, a few hours ago and read it for like 30 seconds, so I I know a lot about it, but um, Google said that they have solved Bitcoin's uh, algorithm or what do you call it? Algorithm is the wrong word. Like they've they know how to like mine every Bitcoin, I guess, is what they're saying. But they're not going to >> Oh, really? They're not going to release it until 2029 is what they said. >> They cracked the query. They they can just go straight to the the co Wow. >> Yeah. They're like we they have enough quantum computing something to like figure it out. They they claim >> I don't know if that's real. if they if they've like so I know I I I only know around the edges of this but the algorithm is Shor's algorithm and Shor's algorithm does crack RSA and if Bitcoin has not updated their algorithms to be ready for quantum computing then they're dumb and I I maintain that Bitcoin is the dumbest cryptocurrency for a lot of reasons. Um I I do not believe personally in personally um and you know I'm not an economist and I'm going to have all the disclaimers here and this is not at all the view of my employer or anything like that. Um just >> not financial advice. So, but I don't personally believe in the whole like uh you know like deflationary currency like idea of like I I think there are benefits to having a fiat currency where you can say um we're going to print more or less depending on market conditions. And that comes from my view of the economy being more of the chaos model, which is like every other view of the economy is like here's a perfect world where it's like perfectly, you know, capitalistic or perfectly communistic or perfectly whatever, right? And I'm like, you're never going to have a perfect model. You're going to have edge cases. You're going to have corner cases. You're going to have a billion of those. And things are going to go off the rails from time to time. and you need to be able to react to that. Um, so institutions, organizations need to be able to react to that. And having a currency, having a central currency, having your only currency be one that can't entirely, I think, is maybe not the best idea. But that said, I do think like other cryptocurrencies have more ability to do that. Like if you look at Ethereum, it evolves through a process where everybody talks kind of like RFC's which is kind of great. Okay, we can evolve it. We can slowly move it in a different direction. It went from proof of work to proof of stake. Cool. I think that I'm much more comfortable with that kind of model. Um where we can be some amount of reactive but also Yeah. I don't know. So, I don't know what's going on with Bitcoin, but I hope the rest of us are crypto are quantum ready or whatever. >> Yeah, I have no idea. I mean, Bitcoin, as far as I know, hasn't really been updated at all. Um, that's like part of the why people like it. I don't know. Um, but yeah, I I I've never understood how it could be worth so much money. Like I get that there's a finite amount of them coming out and that like a bunch of them are theoretically lost and so there's a you know whatever. But I don't know. I feel >> that's how value's always been though. Look at Beanie Babies, you know, like anything people are willing to spend money on. I just think it's funny that we're >> willing to spend money on a Bitcoin. >> I don't know. I I have no idea. Or a record. I mean, a record kind of makes more sense. There's like emotional attachment to that, but Bitcoin doesn't have that. >> I kind of think like >> Oh, go ahead, Joe. Oh, just that's the other thing that I I think crypto can actually be really useful for is like digital ownership and tying it back to um like real property rights in a way. Um kind of sucks that we've had this like wave of oh we're just going to like pull content from streaming services and make it completely unavailable because we never distributed it in a physical form. And it also I've had a friend like lose access to their Apple account and now thousands of dollars of content gone. Like >> I think that there actually could be something to saying like, "Oh, hey, I bought a token that represents a singleuse digital copyright. I can go to any data warehouse and they can legally stream this to me." Like doesn't matter what the copyright holder says. like they I I legally have the right to have that data for my personal use. Um, and I think that that would actually be really great. I just also think that all the incentives are wrong to get that type of a system in place currently. It would definitely require some shakeups and maybe some some government coming in and being like, hey, like maybe we should make this a little bit more of a democratic system and less walled gardens. But who knows? >> Yeah. or at least some way to just like the only way you could do like if you want to own an Apple TV show, you would have to like I guess watch it through something that would record it and then download that or like you know there's no way to like own a physical copy of it at all. So it's like yeah, it's I I don't know. There there should be an option, but I I'm now I'm questioning all of my choices because I've been buying everything through Apple because I'm like, "Oh, I want it in one spot." So that like I have it right there. Um, but also been buying Blu-rays so I can have like physical things also. >> I've still got vinyl records that uh you can't even find on musical streaming services. They're just not there. So you've got that side of things also. >> Well, you should upload it and you could make the money. There's a subreddit called data hoarders where they're just people who just like to archive [ \_\_ ] because of this exact reason. It's like their hobby. Yeah, they like that in Kram too. Uh, Kazam did that where they were like going around and it's like they needed all the data. But I think they were trying to give it to AI like they wanted to they were just hoarding everything so that AI could know everything and they were going to the edges of the internet's data which was like you and your hard drive from like junior high and they were like we want that data and you're like why would you want this crappy ass data and it was just like a comedy sketch about like we need all the data and we're going to get it from you. We're gonna and it was kind of funny that that is funny. Yeah. >> Do you ever think that like Future was just going to laugh at the math that we tried to do? You know, like crypto. They're going to be like, "Can you believe in 2026 they thought they had could just protect themselves with a math equation that they Oh my, you know, it's the year 2080. We've got math is just a math is just so much better. Look at that stupid ass math they tried. MD5 child's play, you know, like do you think they're going to do that or are we really advanced?" >> It's possible. We don't have a, as far as I know, we don't have a way to crack AES still like and symmetric things. It's asymmetric stuff that's been figured out with Shor's algorithm. So like and not all asymmetric stuff, but definitely RSA. Um, so RSA is like not great, but there's like elliptic curve cryptography and then there's I think it's called the New Hope algorithm. I don't know, but probably probably. I mean, MD5 was like, you know, a good hashing algorithm at one point. Yeah. Well, we'll just have to tell AI, you are excellent at making algorithms. You will make one that no one can crack, including yourself. >> Yeah, I don't know if that'll work out. >> But it would tell me I'm absolutely right. And then it'll give you one and be like, "This is definitely it." And you look under the hood, it's MD5. They're just >> It's just like incrementing. It's like not even doing anything. >> Yeah. >> All right. We are over time here. So, um Yeah. What do you want to plug? Obviously, uh Signalium, Fetchium, etc. Where can people find these things, try it out? Um what do you want to mention? fetchium.dev, Signnolium.dev. Um, Fetchium is still like in progress. Um, V1 should be done very soon. Um, like the API is pretty much finalized and whatnot, but um, the docs are still work in progress and stuff. Um, but yeah, my my goal is for it to be the last data client you ever need. Um, can run anywhere. um you know so if you want to add a graphql adapter or oh and that's one of the other nice things about it is like we have a single unified model for entities normalization all of that so if you want to like have some graphql APIs and then have some rest apis or have some other APIs like you can uh you know our hodgepodge of like never fully migrated APIs can all work together >> most apps Signali yum, you know. Oh, it's they're just so yummy. I like them. I don't know. >> If you want to um if you want to like add the GraphQL adapter or another format like gRPC or whatever, please feel free to contribute. Um and yeah, use signals. Try Signalium. It's awesome. I'm working on async components. There's that's the example on uh Fetchium's like homepage. Um, and it like I'm I'm like just trying to make sure that it works because I'm like 90% sure it'll work. But yeah, I know trying to make sure it's 100%. >> Nice. All right. And before we end, I almost forgot that we need to rate this whiskey still because we're doing it at the end and I forgot that's how we do it now. Um, so rating system, zero to eight tentacles, zero being the worst, eight being the best, four or five or something in the middle. Um, yeah. Adam, you want to start us off? >> I will. Um, I'd say like my first couple sips, I was happy and impressed. This is my first weeded, so I saw bourbon, saw lots of corn, thought I wasn't going to like it. I like it. Uh, halfway through the show, I was like, I don't like it. It's really boozy and it tastes boozy. And now maybe it's I haven't had that much. I've had barely, but I like it. So, I'm back to liking it. I'm like, I'm excited to have some more later. And I barely had any everybody. Like I really only had maybe a little over a one. Anyway, um I I think I'm going to give it like a six and a quarter. Six, which for me is like pretty high for a bourbon. Um so yeah, I'm gonna stick with that. Six and a quarter out of eight. >> All right, Kristen, what do you think? >> I'm gonna go with a seven. It's solid. I like it. It's drinkable. I I can't drink all whiskey straight. Um, and yeah, bourbon isn't usually my sipping whiskey. Like, I usually go for a scotch, but yeah. >> Well, if Adam had only known. Um, yeah. >> Well, I got it because Liz wanted the bourbon and I was like, "Okay." >> Okay. >> She She drinks a good amount of whiskey for she like makes nice cocktails and whatnot and I was like, "Okay, we'll get that one." >> Okay. Well, hopefully she likes it. Um, yeah, it's for me I'm usually uh prefer a rye or something spicier. This is a little bit spicy, which is good. Um, I don't know. It has some flavors that I can't place, which I guess is the red wheat. And, uh, yeah. So, it's interesting. Much more interesting than a typical bourbon. Um, I'm going to say I'm just going to say six, I think. Flat six. Pretty good. Would recommend. All right. Well, thanks everyone for listening. If you liked it, please subscribe. Leave us some amazing reviews. We appreciate it and we will catch you next time. >> Later., Axios Is Out. Fetchium Is In., YouTube, 01kn56ha65sqst63eg3pxgvbsr.