RobbieTheWagner 
Adam Argyle Welcome to Sentat! Welcome to a brand new episode of the front-end happy hour podcast. Welcome to this week's J.S. Party! Live from Ship Shape Studios, this is WhiskeyWeb and whatnot. With your hosts Robbie the Wagner and me, Charles William Carpenter the third. That's right Charles, we drink whiskey and talk about web development. I mean, it's all in the name, it's not that deep. This is WhiskeyWeb and whatnot, do not adjust your set. WhiskeyWeb and whatnot is brought to you by... This episode is brought to you by Warp at Warp.dev. Warp is now open source and warp is built using Ahas publicly for us all to see.
And it feels like a glimpse of how software is going to be built in the future with the agents, except that's also now. But what's Ahas, the cloud agent orchestration platform by the Warp crew, you got to check it out. Warp has also made their cloud integration even better by Ben Holmes and asked about the Rad Codex integration they just added to. You can also publish an agent session from Cloud Codex or OpenCode to the cloud with one click and then monitor or steer that agent from your phone browser or some other computer. It is sick. Alright, go ahead and close CMux because warp tabs are now on the left side.
They look like projects and each pane is visible within that tab project group. I've got four tabs open right now. Each tab has anywhere from one to four terminals in it, keeping sessions organized. And that visibility into the panes without having the tab open is awesome. Warp updated supported models to adding Kimi K2.6, GLM 5.1, Mini Max and Quinn. Check out Warp at Warp.dev or Ahas at Ahas.dev suite back to that episode. Hey, what's up everybody? Welcome to WhiskeyWeb and whatnot with your host Robbie the Wagner and Adam Thomas Argyle, the nerd. You're so absolutely right Robbie. Thank you.
A psychophantic machine. 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 toolscrafter introspector pixel artist writer chef TC 39 delegate, ever contributor principal front end dev ad phantom decorators champion. Co champion of signals and JS seeking to solve the world scattered reactivity woes reactivity woes with one true signal to unite them all from this elevating reactivity. How we're in coming to you live from the same status Robbie on this fortuitous visibility day. Krista Gerichel nice to see you again, Vincent's cascadia JS last year.
Yeah, no, it's great to see you all today. I'm glad I could be here. Yeah, yeah, thanks for joining us. So yes, 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 bottled in bond Missouri straight verb and whiskey. Okay, we'll tell you more about it afterwards. A lot of people don't want to hear about the whiskey. So if you don't care. 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. So yeah. It's been an eventful, I think six months since cascadia. I have been working like crazy on basically a better version of Apollo slash tensak query. So Apollo client is great, right. But it is graph QL and tensak query is great, but it is very simple. And this is actually why I started working on signals. And maybe should we give like an intro to signals at all? Maybe I don't know how familiar people are. What is a signal? I'm.
Yeah. We probably should. Yeah. I think one of the earliest like JavaScript implementations of it would be mob X. Mob X is basically signals, though, it's a very like class oriented version of it. It's like that idea of you have, you know, these reactive values, you can see them. And you kind of automatically track them as you are computing some output. And 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. And then basically your functions are can be pure. 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 peer. 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 as JavaScript, you can do whatever you want. But yeah, basically every modern web framework with one major exception is based on signals these days. Angular migrated to them, I think last year. View has been based on them for quite a long time. Svelts with runes is now based on them. Solid, definitely one of the big ones that kind of started it and pioneered it in rendering frameworks. Remember, you know, had auto tracking, which was a form of signal how I got into it and doesn't have them.
You know, it's going to be open in the room react has kind of hand signals. And I don't I understand where they're coming from. I think that that might be a bit of a. I think 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. They wanted to go into this hooks direction where it's like, oh, we have these pure functions ish. 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 jota legend state, these are like signals implementations that follow the same pattern. But the key difference is that most signals libraries don't allow you to parameterize your signals. And what that means is you kind of have to manage the life cycle of every computed signal every derived signal. You have to like, if you want to have like a hook essentially where it's like, oh, use full name of user right like. 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.
And with signals traditionally you kind of have to like manage all of that yourself. So it's a little annoying and kind of stateful and I can see why people would look at that and be like, 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. 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 some really tricky. It's not even let it can necessarily be like the worst thing in the world. It's just like state starts to accrue in various places right you start to see.
Or complex patterns with things. By the way, I'm sorry my internet connection seems to be really bad right now. It's just a stalled version of you. I'm like, no, I was just brought to you by internet. It's tough. Well, I'm having fun linking everything as we go. Give it a second. In the chat so far, links to signalium and to the 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 signalium. I'm tempted to like ask about observables. I'm like, are they bad? Are they good? We'll never know. The last to guest.
The whiskey was too strong bottled in bond. Oh, yeah. Oh, it's here. We'll talk about the whiskey. Hey, yeah, that was a good time. Oh, we just lost everybody. No, yeah, we could talk about it real quick. So this, let's see, where's my notes? This whiskey is 73% corn, 15% soft red wheat and 12% melted barley. And I don't taste any melted 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. Yeah. Little spice, little, 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, which apparently soft is because it has less proteins in it. So it's less glutinous, something. And it gives it, oh, it really, um, so that hangs on your tongue soft. Like, like it's, um, I don't know. It's not like hot water and soft water. Is it, you know, it's like, do we just use these words because we didn't have anything better? Yeah. Yeah. I don't know. 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, yeah, bottled in bond has those requirements.
It's got to be at least four years old, 100 proof. And this checks the boxes. It's six years old. So. Oh, this reminds me of a, you've seen Wayne's world right the movie. Um, I'm actually not sure if I have, which might be very spicy. It's good. The hell up. You haven't seen Wayne's world one. Oh, my goodness. I'm familiar with it. But um, that doesn't matter at this moment. Yeah. I don't think I was 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 Garth are. Okay. So Wayne is usually the one talking Garth'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, they started making a bunch of money and went to a nice big production agency. Anyway, um, Wayne has to leave. And Garth is just left there by himself. And Garth is like, totally frozen like a deer in the head. And it's like, I don't know what to do in this show is just mine. And he just gets really awkward. And it's really funny. So I kind of feel like that right now.
Okay. I think you're welcome back at FPS 5, but you know, that's cool. It'll record normal on. Yeah. It's fine. Okay. Um, so yeah. Where were we? Rubber was just digging in about. Oh, yeah. 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. It's 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 is that particular part mean? Oh, just I was just being, um, silly. But like, is it functional? Yeah. Like functional programming or like works.
Uh, yes, yes, yes. Okay. Yeah. Now it's like functional programming. And, you know, to be fair to, because I think we all went through like the period of like, uh, functional everything. And that was interesting. Um, there's a lot of nice things about it, though. And I think react model with hooks really pushed the boundaries of that. And it had some really nice like properties. Um, so, um, this one's 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 an 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. deeply entangled with every single part of your system. And all of a sudden, your code is no longer isolated. Your component logic seeps into every other part of your code. And Adam, you were about to say you're tend to task about observers or observables. Observables, I sure was. Yeah, I'm still a big fan of like I missed 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 a way that reactivity
and to create these composable elements. But the issue I had with observables is similar to the issue I have with, you know, kind of like those lifecycle hooks is, when you start writing code and observables, kind of everything needs to start using observables. Everything needs to become observable aware. They're needy, yeah. 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 can't really detangle very easily. Actually, one of the reasons I started working on Signolium
is 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 call this same hooks out of the wrong order bug. I noticed our stack was like 200 hooks deep and it wasn't even that big of a component. Why so few? And now when the smallest like node of your reactive system that you can rerun is the component, it ends up being quite a lot of stuff. But yeah, I think that with Signolium coming back to FedGM, 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, VIEBE 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 munging 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 FedGM on hooks because I wanted FedGM to be independent. I wanted it to be a data layer. Apollo is built on observables, right? It gets to do that and nobody knows under the hood, it's just an implementation detail.
FedGM does the same thing with Signols and I just think that Signols end up being a more elegant and like more ergonomic solution to the same problems. Especially for front and death, 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. 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 back end 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 start, could kick off an observable that then kind of observed all the touch moves. I could zip the moves into a pointer event. So 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 so in flung, I could easily close it all down. So there was like, I agree though that most of the cases were take one, you know, I just need one of these. Just give me the most recent one. I don't care about the history, 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 problem. People think about all the time where they're like, oh, they just hit the smit bone 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. And it's nice to think about things fast. Yeah, which also observables were really good at handling that because you could cut, but you had to continue chaining more chains. Yeah. And that was kind of the problem as though it was like you could feel it infecting 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. It said, do a unit test 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 to go off in a slight tangent. But Ember had that model of just run the test in the browser and then it was a bit more like a lot of like a user testing librarian stuff is like polling based. It's just like wait for the thing to be in the DOM. And I prefer Ember's model where it was like, well, we know when things have settled and when we're done rendering. So just like, check it then. Just gives you a little bit more speed. 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 a thing no matter what. Same issue with Signolium, same issue with any reactivity library. It's timing becomes tricky hooks as well, like very much so. 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 hooks can solve it if used correctly and you know, thoughtfully.
And you're not doing anything to complex. 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 was like knockout and meteor and ember and angular one and you know. So I think that, yeah, I think signals will get that for you as well if you play around with them. 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. 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 gonna 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, 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 things weird. And like, going back to my cascadia talk, like basically if we think about it like promises, right? Promises, like if we did what hooks do for reactivity to promises, it would basically be like every single time you hit in a way, 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 away. And that's actually exactly how react suspense works, like you 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. With signalium and with signals in general, but signalium also really focused on having us like recompute 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'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 about this point has changed. And really this is like similar to a lot of like differing algorithms in general for components. It's just on the function level, which is what promises in Async did with like, Async awaited 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 keyboard in the language one day, maybe. Don't quote me on that because I still need to do the actual, I don't know, science parts of things to formalize all that, but it feels like it can be. It feels very composable 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 signalium does that the official signals proposal and basically no other signals like libraries do. The two things are those parameterized like functions. So what that basically works out to be is like a signal factory
and then kind of hooking up the signals and their life cycle to some consumer, which we call a watcher in signalium. The closest I've seen is, Jota has Adam families, which are pretty similar, but they're like kind of an afterthought, it feels like in Jota and in signalium, we're like, no, that's the default. 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 auto tracking and we were like, yeah, auto tracking, 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. Like as Chris Selden just wouldn't let me land anything because he kept being like, it's not perfect though. And I was like, Chris, I swear people aren't able to make requests. They're going to meet me like, we're getting that out. Who needs requests? All your data is just stored in the front end. I 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. So you should use these. And then Chris was like, and you were like, oh, that's not what they were for actually.
And then I was like, OK, well, how do you make requests if we're getting rid of these life cycle events? And they were like, we 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 something else, oh, a 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 good.
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. But I also don't want to have it be absolutely perfect. When I talk with Chris Eldon, I still talk with him a lot. And when I talk with him about the 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, OK, 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 are the thing that 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 Michelle Westray for Mobyx. And so I think I've actually been talking to like, pre-act people were like, yeah, we kind of need something for this and the solid people to and whatnot. So the proposal has what we need for those. 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, OK, this part of the signal graph is being used by something live. And that watcher, that observer externally could be like the DOM, right? Or it could be like your app. It doesn't really matter exactly what it is. It's just user-defined. And it says like, OK, 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. That could be a connector to Apollo. Let's say you want to use Apollo. You have a GraphQL.
You just want to hook it up. Well, you need to subscribe. And then later on, you need to unsubscribe. You need to sell it like, I don't need those events anymore. You could be communicating to a web socket. You could be communicating to a background process, to a web worker, anything that is async and specifically that's not like request response. 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 like optional, not optional, but like forking essentially. So like 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 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 unsubscribe for 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 so that's how I got to where I am today with signolium 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 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. Yeah, I mean, so this stuff seems more complex
than I kind of thought of signals being, you know, coming from, I do mostly Ember still. So I'm like, trash property, ZA. But I'm curious how you feel. Have you seen Adam? How do you say, is it Gia or Gia, G-E-A-JS? One of those. Yeah, haven't seen how on. 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, which is neat. Yeah, so I think that's because of them in a half. So Gia, I guess it's Gia. We'll say Gia. I like Gia because it makes me feel like Giu. Yeah, you can say it real cool. Giu. Yeah, yeah. But it's whole thing is like, I don't know how it was built.
We're hopefully going to have the guy that wrote it on and learn about it. But the TLDR 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, I don't know. I'm curious of your thoughts on like, I always kind of have this big 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. Yeah, where do you think about that? So I think that like signals, I'm after that as well. And I think that promises did that for async.
Like the world before promises with, and sync 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. It 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. 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, right, and execute quickly and not just be making slot that's about like five steps away from falling apart all the time, we want simpler abstractions. That's actually one of the reasons that drove the design of Fetchium. Fetchium has this very declarative syntax for the design. It's like you declare your params, you declare their types. And then through some proxy magic, I use those, like when you reference those parameters elsewhere, 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.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 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 hints of like, okay, don't do this
and be careful and use this agent definition. And you know, 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 it is actually something we can do. We've done it many times. We did it when we created compilers for assembly. We did it with closures. We did it with, you know, promises and futures. 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 programming and 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 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 get it now, but also like it took me a while to wrap my brain around that. Like, it's like 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, you know, one one side frequently or historically at least, maybe not today with AI and whatever's going on. I think the people that shows writing 200 react hooks like to 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 dot, food equals bar and I'm happy. And I think, you know, neither really matters anymore because AI is going to write so much of the code that like, you know, 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 know. I don't know how you feel about the people are saying, oh, I'm not even going to look at the code anymore in like a year and 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 nine defined desk jobs like be the main way of, you know, kind of working, right?
Cause 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 the screen for eight hours, heck, before I worked from home, you know, I at least had to go to meeting rooms on occasion. So, you know, what happened in the last century, we started to go into the gym. Gems happened 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. No, no, that also just doesn't sound very fulfilling for me cause I love doing this. 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 agents code all the time, I think. 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. I empathize with what you're saying, but I also feel like my brain is incapable
of what AI wants it to do now. Like I'm not good enough. It could take, you know, I could be commanding 100 teams 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 more arms. More software, you know, like, 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 come back and fan out again. And then you've got your gas towns 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 like Jason Langsworth 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 is 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 work day 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. 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. And now I'm sweating the details in a way of orchestration. You know, how do I sweat the details
so that I can create something that does the detail work? It's just different. And I agree there's, you're gonna have to balance it. There's an imbalance that's happening. It's all, yeah, if you went to the gym and only did curls, you know. So. I used to go to the gym and only bench and then go into the sauna because that was the fun part. Okay. 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 balanced oriented 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 gonna be like the right output in a lot of ways. And I think like actually zooming in on those details matters. Like I have been working on a little slide framework I use for my presentations. And you know, I, it's a little messy. It's a little hacky because 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.
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 matter 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. Yeah. Yeah, I can barely, I can barely keep like, you know, you're 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. You just wrote like 500 lines of code. I needed you to like add a like optional chaining thing. Like that was it. 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. But yeah, like I have a hard time managing one agent at a time because 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. I think it's also like very new. And it could change significantly as time goes on. I could find that things get easier to manage like larger numbers of them, larger swarms of them. And who knows? They could get more intelligent. Although 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, a 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. So yeah, I have a couple of questions. You said a couple words earlier, and I want to know more about them. So the first one was 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 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, it's like, you don't mess like a hand off like a relay race from node to node. Yeah, you don't really have to do anything at every layer other than pass it down, right? 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. Okay, okay, I think 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 I find at least. 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-level
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, yeah, I'd rather just have like very explicit, very clear types. And I don't mind boilerplate, a little bit of boilerplate for that. Gotcha. Prop drilling is like a skewer that goes through each piece of meat and piece of meat and it's like your component. And 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. Yeah, I don't care. Meat subscribes to my thread.
Is that kind of it? It's like a story, like a state story? Yeah. One thing I will say about Prop drilling that I think is, it's like an anti-pattern. Like people started considering it an anti-pattern. I think a lot because react really like, if you prop drill all over the place, you're gonna have rebranders all over the place because, you know, 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 and... That's a good point. But I do think that you miss something when you start having like,
oh, I'm just gonna use a context for like all my data loading and then I'm gonna 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, and, well, you know, we're just kind of getting it from wherever. And like, okay, where are routes? What is the overall structure of our app? 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 a sitalia because with fine-grained 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. The values on the promise and the state of the promise changes because it's a monad. So you get it all the way down in this leaf, you destructure value from it. And if it's a signolium component, it's a react component wrapped with signolium's memoization. It will re-render, 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 the performance thing 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, I know relay is like an overloaded term, but so is everything else. So nothing to do with relay the data loading library. I was more so thinking like signal relays. Really, what they are is an abstraction
that kind of replaces use effect in hooks. They are almost a self-contained hook and a piece of state. And internally, when a relay is used, so when it's connected through the signal graph, 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. 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 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 note that can communicate something outside world without like exposing the details of that communication to the graph. Excellent. Thank you. For some reason, I was thinking subject and observables or there was an observable that was similar to this,
but I haven't used observables for, I don't know, six, seven years, maybe more. So 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 of observables and not so very much on the same wave length. The odd man out is hooks, but you know, he didn't hear that for me. I did find what geo 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, you can intercept and do compute. Because debugging is hard.
Yeah, debugging a lot of these things is hard. Fair enough 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 mobX is or like what views data is in data components. 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 I keep ragging on hooks that it really is just like, whenever you start looking at a React library and you're like, oh my God, how many hooks are there?
But it's going on here in it. Oh yeah, you're preaching to the choir here. So, if we act as a hammer, what is a hook? If we act as a hammer and everything is a hook, a nail, no, cause what is a hook in this thing? You know, like, cause they do, they're used everywhere as like some sort of like, oh, it's duct tape. Oh, just tape it, you know, oh, you just need more tape just another piece of tape. The thing is like that makes sense in a world, like that is also true to an extent, what's saying, 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, Apollo clients, and then run that anywhere. Like, it has to work in React and that's the only thing and just eyes 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 some cost fallacy along the way. But I like to think better of people. Yeah, I don't know. I like to rag on React. So, but I think that, you know, I don't know who's in charge now.
I know they have React foundation, which is supposed to like democratize some of it. But like, with Versailles being such a like pervasive, like the only one that mattered and react for a little while, I feel like they do want it to be like, oh, you can only be next day as it can only be React. It's all very bespoke. Like, you can't ship it anywhere else except for on Versailles. I don't know about Versailles. That would work there. I got an offer. But yeah, I was then a phantom, the phantom acquisition for Bitsky went through and I was like, well, I'll see how that's pans out and it's been interesting.
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. And it's annoying that the crypto industry isn't doing this because we keep seeing it 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 our texts. Like people are going to be like doing phones, games, like all kinds of things like soon. And it's just going to increase the output of that exponentially, right?
I think that with not crypto necessarily, but with cryptography and a distributed web of trust, you could imagine a less creepy version of that same Altman backed 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 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, 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 own is human, right? Stuff like that. And then get rid of the 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. We talked to Angie Jones about this about like,
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. Interestingly though, I wonder what your thoughts are about. I just saw this in like, I don't know, a few hours ago read it for like 30 seconds. So I know a lot about it.
But Google said that they have solved Bitcoin's algorithm or what do you call it? Algorithms are 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 really, they're not going to release it until 2029, is what they said. They call it the query. They can just go straight to the coin. Wow. Yeah, they're like, they have enough quantum computing something to like figure it out. They claim if they have it, I don't know if it's real. If they they've like, so I know, I only know around the edges of this, but the algorithm is shores algorithm
and shores algorithm does crack RSA. And if Bitcoin has not updated their algorithms to be ready for quantum computing, then they're dumb. And I maintain that Bitcoin is the dumbest cryptocurrency for a lot of reasons. I do not believe personally in personally. And you know, I'm not an economist and I have all the disclaimers here. And this is not at all the view of my employer or anything like that. Just to say. Not financial advice. So, but I don't personally believe in the whole, like, you know, like deflationary currency, like idea of like, I think there are benefits to having a fiat currency where you can say,
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, a capitalistic or perfectly communist 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 can 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. So institutions, organizations need to be able
to react to that. And having a currency, having a central currency, having your own link 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 RFCs, which is kind of great. Okay, we can evolve it. We can slowly move it in a different direction. Went from proof of work to proof of stake. Cool. I think that I'm much more comfortable with that kind of model 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 quantum ready or whatever. Yeah, I have no idea. I mean, Bitcoin, as far as I know, hasn't really been updated at all. That's like part of the why people like it. I don't know, but yeah, 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 like. That's how values 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 just been money on the big. I don't know. I have no idea or 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, go ahead, yeah. No, just that's the other thing that I think Crypto can actually be really useful for is like digital ownership and tying it back to like real property rights in a way. 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 count 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 single use digital copyright. I can go to any data warehouse and they can legally stream this to me. Like, it doesn't matter what the copyright holder says. Like they, I legally have the right to have that data for my personal use. 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 government coming in and be 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 we'll 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 don't know. There should be an option. But I'm now I'm questioning all of my choices.
I've been buying everything through Apple because I'm like, oh, I wanted to do one spot so that like I have it right there. But also been buying Blu-rays so I can have like physical things also. So it's a final records that 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 yes, a brand called data hoarders where they're just people who just like to archive shit because of this exact reason. It's like they're hobby. They like show up. That was a recent Krasam too. Krasam 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 crap? You asked 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 going to, and it was kind of funny. That is funny. Yeah. I mean, did we 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 could just protect themselves with a math equation that they hope I, you know, it's the year 28 and we've got math. It's just, oh, we want our math is just so much for better. Look at that stupid ass math. They try to the MD five child's plate. 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 short algorithm. So like, and not all asymmetric stuff, but definitely RSA, so RSA is like, you know, not great. But there's like elliptic cryptography and then there's, I think it's called the new hope algorithm. I don't know, but probably, probably. I mean, MD five 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 I'll give you one and be like, this is definitely it.
I mean, we'll come to the hood at 75. Yeah, just important. It's just like incrementing. It's like not even doing anything. Yeah. All right, we are over time here. So yeah, what do you want to plug? Obviously, signolium, Vetchium, et cetera. Where can people find these things? Try it out. What do you want to mention? Vetchium.dev, signolium.dev. Vetchium is still like in progress. V1 should be done very soon. Like the API is pretty much finalized and whatnot. But the docs are still working progress and stuff. But yeah, my goal is for it to be the last data client you ever need can run anywhere.
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, you know, our Hodgepodge of like never fully migrated APIs can all work together. I like all the yummy names. I'm so sorry. Signolium. You know, oh, it's they're just so yummy. I like them. I don't know. If you want to like add the GraphQL adapter or another format like GRPC or whatever, please feel free to contribute.
And yeah, you signolium, try signolium. It's awesome. I'm working on async components. That's the example on Fetchium's like homepage. And it like, I'm like, just trying to make sure that it works because I'm like 90% sure it'll work, but I know, I try 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. So rating system zero to eight tentacles, zero being the worst eight being the best four or five or something in the middle. Yeah, Adam, you want to start us off?
I will. I'd say like my first couple of sips, I was happy and impressed. This is my first weeded. So I saw bourbon, saw lots of corn, thought I wasn't gonna like it. I like it. 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 anybody. Like I've really only had maybe a little over one. Anyway, I think I'm gonna give it like a six and a quarter, which for me it's like pretty high for bourbon.
So yeah, so 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 can't drink all whiskey straight. And yeah, bourbon isn't usually my sip in whiskey. Like I usually go for a scotch, but yeah. Well, if Adam had only known. Like yeah, I got it because Liz wanted the bourbon. And I was like, okay, she drinks a good amount of whiskey for she like makes nice cocktails and whatnot. And I was like, okay, we'll get them in. Okay, well, hopefully she likes it. Yeah, it's for me, I'm usually prefer a rye or something spicier.
This is a little bit spicy, which is good. I don't know, it has some flavors that I can't place, which I guess is the red wheat. And yeah, so it's interesting, much more interesting than a typical bourbon. I'm gonna say, I'm just gonna 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 a raise and reviews. We appreciate it, and we will catch you next time. Later. You've been watching whiskey web and whatnot recorded in front of a live studio audience. What the fuck are you talking about, Chuck? Enjoy the show, subscribe.
You know, people don't pay attention to these, right? Head to whiskey.fun for merchant to join our discord server. I'm serious, like 2% of people will actually click these links. And don't forget to leave us a five star review and tell your friends about the show. All right, dude, I'm outta here. Still got it.