RobbieTheWagner 
Adam Argyle Welcome to Syntax! Welcome to a brand new episode of the Front End Happy Hour podcast. Welcome to this week's JS party. Live from Ship Shape Studios, this is Whiskey Web and Whatnot. With your hosts, Robbie the Wagner and me, Charles William Carpenter III. 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 Oz, publicly, for us all to see.
And it feels like a glimpse of how software is going to be built in the future with agents, except that's also now. But what's Oz? The cloud agent orchestration platform by the Warp crew. You got to check it out. Warp has also made their cloud integration even better. Find Ben Holmes and ask about the RAD Codex integration they just added too. You can also publish an agent session from Cloud Codex or open code to the cloud with one click and then monitor or steer that agent from your phone browser or some other computer. It is sick. All right, go ahead and close CMEX 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 too, adding Kimi K2.6, GLM 5.1, Minimax, and Quen. Check out warp at warp.dev or oz at oz.dev. Sweet. Back to that episode. Hey, what's up, everybody? Welcome to Whiskey Web and whatnot with your hosts, Robbie the Wagner and Adam Thomas Argyle, the nerd. You're so absolutely right, Robbie. Thank you, sycophantic 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 tools crafter, intro specter, pixel artist, writer, chef, TC39 delegate, Ember contributor, principal front end, dev app, phantom, decorators champion, co-champion of signals and JS, seeking to solve the world's scattered reactivity woes, reactivity woes. 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 y'all too. 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 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 just want to hear 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. 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 Tansat query. So Apollo client is great, right? but it is GraphQL and 10-set 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 with that. What is a signal? No we probably should. Signals are a pattern that's
actually been around for a long time. I think one of the earliest, like, JavaScript implementations of it would be MobX. MobX is basically signals, although it's a very, like, class-oriented 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 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 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 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. 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. Vue has been based on them for quite a long time. Svelte 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. Ember, you know, had auto-tracking, which was a form of signal, how I got into it.
Which one doesn't have them? you know it's kind of 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 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 Jotai, LegendState. 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 lifecycle of every computed signal, every derived signal. um you have to like if you want to have like a hook essentially where it's like oh use a full name of user right like um you can repeat that with like 10 different users
passing 10 ids right and react handles the you know setup and the life cycle and the teardown 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, ah, we don't really like it. It's not really like functional, right? And to be fair, a lot of complexity ends up being in that those parts that aren't functional. When you say not functional, do you mean not like functional programming? Not that it doesn't work. Well, you start to have, yeah, not like functional programming.
You start to have some really tricky. It's not even that 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 more complex patterns with things. By the way, I'm sorry, my internet connection seems to be really bad right now. It's a 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. Give it a second. I've got 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. Boop. And Signalium. I'm tempted to like ask about observables. I'm like, are they bad? Are they good? We'll never know. We lost a guest. The whiskey was too strong. Bottled and bond. Yeah. Oh, here we'll talk about the whiskey. Hey, yeah, now's 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% 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. Yeah. little spice 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 which apparently soft is because it has less proteins in it so it's less glutinous something and it's gives it oh it really um so that means it's 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 because 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 yeah bottled in bond has those requirements it's got to be at least four years old hunter proof and this checks the boxes it's six years old so oh this reminds me of uh you've seen wayne's world right the movie um i'm actually not sure if i have which might be very surprising 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 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 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 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 okay i think you're back at fps5 but you know that's cool it'll record normal and yeah it's fine okay um so yeah where were we um robbie 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'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 does that particular part mean oh just I was just being silly about like is functional like functional programming or like works?
Yes, yes, yes. Okay. Yeah, no, it's like functional programming. And, you know, to be fair to because I think we all went through like the period of like functional everything. And that was interesting. 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 lifecycle 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 lifecycle your lifecycle hooks become very like 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'm still a big fan. And 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, you know, kind of like those lifecycle 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. 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 can't really detangle very easily.
Actually, one of the reasons I started working on Signalium 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 called the 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? in doubt 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 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 munging of data and you gotta 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 build Fetchium on hooks because I wanted Fetchium 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. Fetchium does the same thing with signals. And I just think that signals end up being a more elegant and like more ergonomic solution to the same problems, especially for front end dev 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 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 start, could kick off an observable that then kind of observed all to 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 someone 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, it's like, 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 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. And it's nice to think about things. 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 is 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 to do a unit test. And then you had timing with unit tests.
It was like a pain in the butt, too. And anyway, I digress. Timing is always a problem. And that's why I've always liked, honestly, Ember's test model, like 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 it was a bit more like, you know, a lot of like, user testing library and 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 we know when things have settled and when we're done rendering so just like you know check it then 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. 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
you're not doing anything too complex it's it's actually pretty solid 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
But 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, 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, OK, everything will re-render infinitely until you tell it not to. I feel like the other way is the way it should be of like, I'm going to tell you the things that need to re-render and those things should be tracked because like.
It seems silly to do it the other way. Like, all right, these 400 things I want to ignore, like, or there's like one I care about. you know, like, yeah, it's weird. 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, two 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 idempotent. Every single step you take has to be idempotent.
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. With Signalium, and with signals in general, but Signalium also really focused on having us like recompute from the changed 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 above this point has changed. And really, this is similar to a lot of diffing algorithms in general for components. It's just on the function level, which is what promises in async did with like async await 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 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 and it's very nice to work with. So how does the 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 functions. So what that basically works out to be is like 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. 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. 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 um mostly because 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 gonna mutiny like we're 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 lifecycle hooks so 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 lifecycle 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 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 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 you know have it be absolutely perfect like 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 okay but it works really well it's like it's definitely a lot better than Hook 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 like Michelle Westrate for MobX.
And, you know, so I think like, I've actually been talking to like pre-act people were like, yeah, we kind of need something for this and the solid people too and whatnot. So 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, did, 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 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, 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. 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. you could be communicating to a web socket. 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 lifecycle 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 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 lifecycle through all of that. And so that's how I got to where I am today with Signalium and me being like the one person
I convinced little Dan, like we probably need the lifecycle 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 trash properties yay um but i'm curious how you feel have you seen um adam how do you is it gia or gaia g-e-a-j-s one of those yeah yeah i haven't been keeping up with that a lot because i've been just like
in execute mode for getting stuff done with react which yeah so um and a half so so gia i believe i guess it's gia we'll say gia i like gia because it makes me feel like geo you know you can say it uh real cool yeah yeah yeah um but it its whole thing is like um i don't know how it was built we're hopefully gonna 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 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 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. 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 dot params dot, you know, ID or this dot params dot 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 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 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 dot foo 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 know I don't know how you feel about people are saying oh I'm not even gonna look at the code anymore in like a year and I don't know if we're gonna get to that but I actually think it's more important to read the than ever. And here's why. I think we are going through what happened to our physical bodies
when we started to have nine to five desk jobs, like be the main way of, you know, 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 the screen for eight hours heck before i 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 percent 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. 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. The domain Jim.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. I'm not 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 can get you more arms, more software, you know, 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 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?
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. 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? Um, so I used to go to the gym and only bench and then go into the sauna. Cause 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 balance 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 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 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 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 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 and 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 power's 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. So. Yep. 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 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 it's like
you don't necessarily hand off like a relay 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 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-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 is 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 i don't care meat subscribes to my thread uh is that kind of it so it's like it's like a store like a state store yeah one thing i will say about prop drilling um 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 going to have re-renders all over the place because, you know.
Well, 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 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? Who was the original caller? It's like, we don't know. We're just kind of getting it from wherever.
And like, okay, where are our 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. 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 Signalium. 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 it's if it's a signalium component it's a react component wrapped with signaliums 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 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 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 node that communicates with the outside world without 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. 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 and 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 gia 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 compute Because debugging them is hard. Yeah. Well, debugging a lot of these things is hard. Yeah. The 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 MobX is or, like, what Vue's data is in data components.
um yeah 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 you 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 they but it's going on here and it oh yeah you're preaching to the choir here so uh let's just react as the hammer uh no what is a hook if react is a hammer you know and everything is is a hook a nail no because what is a hook in this thing you know like because they do they're used everywhere as like some sort of like oh it's duct tape
oh just tape it yeah you know oh just you just need more tape just another piece of tape 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 clients 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 yeah i don't know i like to rag on react so um 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 Vercel 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 Next.js. It can only be React. It's all very bespoke. Like you can't ship it anywhere else except for on Vercel.
I don't know about Vercel. I would work there. I got an offer but yeah I was then then in phantom the phantom acquisition for Bitsky 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'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 i from the sense of like somebody
was saying recently open claw is gonna just destroy like you know our our texts like people are gonna 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 sam 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 um more like in a way where we just you go into like i don't know a non-profit 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 gonna sign that wallet address say you're 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 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 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 gonna really they're not gonna release it until 2029 is what they said they cracked the query they can just go straight to the the coin wow yeah they're like we they have enough quantum computing something to like figure it out they they claim if they have i don't know if it's real if they if they've
like so i know i don't i only know around the edges of this but the algorithm is shore's algorithm and shore'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 you know i have all the disclaimers here and this is not at all the view of my employer or anything like that um just to say not financial advice no 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 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. 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 RFCs, 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 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 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'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 value has 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 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. 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 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 single use 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 shake-ups and maybe some some
government coming in and being like hey like maybe we should make this a little bit more of 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 don't know 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 wanted in one spot so that like i have it right there um
but also been buying blu-ray so i can have like physical things also i still got final 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 shit because of this exact reason it's like their hobby they like show up that was a recent krizam too krizam 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 gonna get it from you we're gonna anyways kind of funny that is funny yeah i mean do you ever think that like future was just gonna laugh at the math that we tried to do you know like crypto they're gonna be like can you believe in 2026 they thought they could just protect themselves with a math equation that they oh my you know it's the year
2080 we've got math it's just oh our math is just so much better look at that stupid ass math they tried to the md5 child's play you know like do you think they're gonna 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 and symmetric things. It's asymmetric stuff that's been figured out with Shor's algorithm. And not all asymmetric stuff, but definitely RSA. So RSA is not great. But there's elliptic curve cryptography and then there's, I think it's called the New Hope algorithm. I don't know, but probably. I mean, MD5 was 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 and you'll come to the hood at 75 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, Signalium.dev. Fetchium is still in progress.
V1 should be done very soon. The API is pretty much finalized and whatnot, but the docs are still a work in progress and stuff. But yeah, my goal is for it to be the last data client you ever need. It 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 um i like all the yummy names apps are signally 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 grab kill 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 like just trying to make sure that it works because I'm like 90% sure it'll work, but I try to make sure it's a hundred percent. Nice. All right. And before we end, I almost forgot that we need to rate this whiskey still cause 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. Yeah. Adam, you want to start us off? I will. 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. 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 think i'm gonna give it like a six and a quarter six which for me is like pretty high for a bourbon um 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 I usually go for a scotch well if Adam had only known I got it because Liz wanted the bourbon and I was like okay she drinks a good amount of whiskey she 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. Alright. Well, thanks everyone for listening. If you liked it, please subscribe. Leave us some ratings 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? Enjoyed the show? Subscribe. You know people don't pay attention to these, right? Head to whiskey.fun for merch and to join our discord server i'm serious it's like two percent of people who 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 out of here still got it