Axios Is Out. Fetchium Is In. - CourtneyR.dev's 2nd Brain

Axios Is Out. Fetchium Is In. ![rw-book-cover](https://img.youtube.com/vi/b8uoRksN8Xk/maxresdefault.jpg) 🔗 **Source:** [Axios Is Out. Fetchium Is In.](https://www.youtube.com/watch?v=b8uoRksN8Xk) > [!note]+ Document Notes > tags: #signals #fetchium #reactivity #javascript #async > author: Robbie Wagner, Adam Argyle, Kristen Garrett > source: Whiskey Web and Whatnot Podcast > reference: https://www.youtube.com/watch?v=b8uoRksN8Xk > date created: 2024-12-19 16:00 > > # 🏷️ Title: Axios Is Out. Fetchium Is In. >  ## 🧰 Action Inbox - [H1] Research Fetchium as Apollo Client replacement — new signal-based data layer #signals #apollo - [H2] Study TC39 signals proposal implementation details — official JavaScript proposal #tc39 #javascript - [H3] Evaluate signal libraries for React projects — Jotai, Legend State alternatives #react #evaluation ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] ### 🔗 References - [Fetchium](https://github.com/NullVoxPopuli/fetchium) - [TC39 Signals Proposal](https://github.com/tc39/proposal-signals) ## 📝 Summary - Kristen Garrett discusses Fetchium, a new signal-based data fetching library designed as a better alternative to Apollo Client - Signals are emerging as the dominant reactivity pattern across modern frameworks (Angular, Vue, Svelte, Solid), with React being the notable exception - The conversation explores the evolution from observables to hooks to signals, with emphasis on parameterized signals and async handling - Key challenges include lifecycle management, threading reactivity through applications, and the balance between AI assistance and manual coding - Fetchium aims to solve data layer problems independently of rendering frameworks using signals as the underlying abstraction ## 📖 Main Content Kristen Garrett, a TC39 delegate and signals champion, presents Fetchium as a signal-based replacement for Apollo Client. Unlike Apollo's GraphQL-only approach or TanStack Query's simplicity, Fetchium provides sophisticated data management using signals as the foundational abstraction. Signals represent a reactivity pattern that's gained widespread adoption across modern frameworks. They provide automatic dependency tracking and fine-grained updates, contrasting with React's coarse-grained re-rendering model. Most implementations lack parameterization - the ability to create signal factories that manage their own lifecycle. The discussion reveals deep technical challenges around async reactivity. Traditional signals libraries treat async as an afterthought, but real applications need subscription management, lifecycle coordination, and dynamic branching. Fetchium addresses these through "reactive promises" and "relays" - abstractions that bridge external systems with signal graphs. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/b8uoRksN8Xk?t=0) — [H1] Introduction and Fetchium overview - Key idea: Fetchium is a signal-based data layer combining Apollo Client power with TanStack Query simplicity - Evidence: "I have been working like crazy on basically a better version of Apollo query" #### ⏱️ [02:15](https://youtu.be/b8uoRksN8Xk?t=135) — [H2] What are signals? - Key idea: Signals are reactive values with automatic dependency tracking, adopted by most modern frameworks - Evidence: "Basically every modern web framework with one major exception is based on signals these days" #### ⏱️ [04:30](https://youtu.be/b8uoRksN8Xk?t=270) — [H2] React as the exception - Key idea: React chose hooks over signals, creating fundamental architectural differences - Evidence: "React has kind of panned signals and I understand where they're coming from" #### ⏱️ [06:45](https://youtu.be/b8uoRksN8Xk?t=405) — [H1] Parameterized signals innovation - Key idea: Most signal libraries lack parameterization, forcing manual lifecycle management - Evidence: "Most signals libraries don't allow you to parameterize your signals" #### ⏱️ [12:30](https://youtu.be/b8uoRksN8Xk?t=750) — [H2] Observables vs signals comparison - Key idea: Observables require everything to become observable-aware, while signals offer better encapsulation - Evidence: "When you start writing code in observables kind of everything needs to start using observables" #### ⏱️ [18:45](https://youtu.be/b8uoRksN8Xk?t=1125) — [H1] Async reactivity challenges - Key idea: Async handling is typically an afterthought in signals libraries, but essential for real applications - Evidence: "Async in general is usually an afterthought. It was an afterthought for Ember" #### ⏱️ [25:15](https://youtu.be/b8uoRksN8Xk?t=1515) — [H2] Lifecycle management in signal graphs - Key idea: Dynamic subscription management requires lifecycle hooks built into the signal graph - Evidence: "You either need to thread your lifecycle through the entire graph or you need to build it into the graph" #### ⏱️ [32:20](https://youtu.be/b8uoRksN8Xk?t=1940) — [H2] TC39 signals proposal connection - Key idea: The official proposal provides necessary primitives for advanced signal patterns - Evidence: "The proposal has what we need for those like you can implement those on top of the proposal" #### ⏱️ [38:10](https://youtu.be/b8uoRksN8Xk?t=2290) — [H3] Compiler-based reactivity future - Key idea: Future frameworks might use compilers to eliminate manual reactivity management - Evidence: Discussion of frameworks that "figure out what should change through some magic compiler" #### ⏱️ [42:30](https://youtu.be/b8uoRksN8Xk?t=2550) — [H2] AI impact on development - Key idea: AI changes how developers interact with code, requiring new skills in orchestration - Evidence: "I think we are going through what happened to our physical bodies when we started to have 9 to 5 desk jobs" #### ⏱️ [48:15](https://youtu.be/b8uoRksN8Xk?t=2895) — [H3] Threading vs prop drilling - Key idea: Reactivity threading requires setup/teardown at branches, unlike simple prop passing - Evidence: "With prop drilling you can pass things down very transparently... with reactivity threading every time there's a branch you need to set it up and tear it down" #### ⏱️ [52:40](https://youtu.be/b8uoRksN8Xk?t=3160) — [H2] Relays concept introduction - Key idea: Relays abstract external communication, replacing useEffect patterns - Evidence: "Relays relay state outside of the graph into the graph and then vice versa" ## 📚 References - [Signalium](https://github.com/NullVoxPopuli/signalium) - [TC39 Signals Proposal](https://github.com/tc39/proposal-signals) - [MobX](https://mobx.js.org/) - [Solid.js](https://www.solidjs.com/) - [Apollo Client](https://www.apollographql.com/docs/react/) - [TanStack Query](https://tanstack.com/query/latest) ## 🗣️ Paraphrase - Fetchium represents a new approach to data fetching that uses signals as the core abstraction, providing both power and simplicity - Signals have become the dominant reactivity pattern across frameworks, with automatic dependency tracking and fine-grained updates - The key innovation is parameterized signals that manage their own lifecycle, solving problems that traditional implementations struggle with ## 📰 Newsletter **Signals Evolution: From Observables to the Future of Reactivity** The JavaScript ecosystem is converging on signals as the preferred reactivity pattern. Kristen Garrett's work on Fetchium and the TC39 signals proposal represents a significant step forward in data layer architecture. Key benefits for developers: - **Framework Independence**: Signals work across rendering libraries - **Fine-grained Updates**: Only affected components re-render - **Lifecycle Automation**: Subscriptions manage themselves - **Async-first Design**: Built for modern application patterns This shift toward declarative, signal-based architectures promises simpler mental models and better performance. As AI tools become more prevalent, these abstractions will be crucial for maintaining code quality and developer understanding. Resources: [Signals Proposal](https://github.com/tc39/proposal-signals), [Fetchium Demo](https://github.com/NullVoxPopuli/fetchium), [Solid.js Signals](https://www.solidjs.com/tutorial/introduction_signals) ## ✅ Action Items #### DevRel - Developer advocacy: Create signals tutorial series, conference talks on reactivity evolution - Education: Workshop comparing hooks vs signals patterns, async reactivity deep-dive - Developer experience: Signals migration guides, debugging tool recommendations - Developer marketing: Case studies showing performance improvements with signals - Community management: Facilitate discussions between framework maintainers on signals adoption #### OSPO - Policy & Governance: Evaluate TC39 proposal participation guidelines - License Compliance: Review signal library dependencies and licensing - Security Management: Assess supply chain risks in reactivity libraries - Software Inventory: Catalog reactivity solutions across projects - Developer Support: Training on signal patterns and lifecycle management - Community Engagement: Support open source signal implementations - Strategic Alignment: Track signals proposal progress and adoption metrics #### Community - Maintainers: Provide feedback on TC39 signals proposal, contribute to implementations - Contributors: Help with signals library documentation and examples - Sponsors: Fund development of cross-framework signal tooling - Ecosystem: Coordinate migration strategies and compatibility layers #### WordPress - Core: Evaluate Interactivity API alignment with signals patterns - Core Performance: Assess fine-grained reactivity benefits for block editor - Core AI: Use signals for AI-driven content recommendations and real-time updates - Community: Educational content on modern JavaScript reactivity patterns - Training: Include signals concepts in advanced JavaScript curricula - Documentation: Update guides to reflect modern reactivity best practices - Meta: Consider signals for .org interactive features - CLI: Signal-based watch modes and development workflows ## 🧪 Hypotheses - Signals will become the standard reactivity primitive across JavaScript frameworks within 2-3 years - Fetchium's parameterized signals approach will influence the TC39 proposal specification - AI development tools will favor declarative signal patterns over imperative hook patterns - React will eventually adopt signals or lose significant market share to signal-based frameworks ### 📊 Methodology - Survey framework adoption rates before and after signals implementation - Performance benchmarks comparing hooks vs signals in equivalent applications - Developer experience studies measuring cognitive load and debugging time - Market analysis of framework popularity correlation with reactivity model ### ❓ Questions - How will React's ecosystem respond to increasing signals adoption across other frameworks? - Can the TC39 signals proposal maintain momentum without React's participation? - What migration paths will emerge for large React applications wanting signal benefits? ### 🔮 Future Research - Cross-framework signals compatibility and standardization efforts - Performance characteristics of different signal implementation strategies - Developer tooling evolution for signal-based debugging and profiling - AI code generation optimization for declarative vs imperative patterns ### 💡 Implications - Practice: Developers need to learn signal patterns and lifecycle management concepts - Policy: Framework choices increasingly influenced by reactivity model and ecosystem lock-in - Security: Signal-based subscriptions require careful lifecycle management to prevent memory leaks - Education: Computer science curricula should include reactive programming fundamentals - Funding: Investment in signal tooling and migration tools will accelerate adoption ### 🧠 Learning Styles Assessment Reading level estimate: Grade 14-16 (advanced technical content) #### 👀 Visual learners - Present: Signal flow diagrams and lifecycle illustrations would enhance understanding - Improve: Architecture comparisons showing hooks vs signals data flow #### 🔊 Aural learners - Present: Podcast format allows following technical discussion naturally - Improve: Audio-only summary with key concept definitions #### 🗣️ Verbal learners - Present: Rich analogies (threading vs prop drilling, gym metaphor for brain exercise) - Improve: Glossary of reactivity terminology and pattern comparisons #### 🧩 Kinesthetic learners - Present: Code examples and interactive discussions - Improve: Hands-on signal implementation exercises and migration guides #### 🧠 Logical learners - Present: Clear cause-effect relationships in reactivity patterns - Improve: Decision trees for choosing between reactivity approaches #### 🧑‍🤝‍🧑 Social learners - Present: Discussion format with multiple expert perspectives - Improve: Community forums for signals adoption experiences #### 🧘‍♀️ Solitary learners - Present: Deep technical analysis suitable for individual study - Improve: Self-paced learning path through signal concepts #### 🌿 Naturalistic learners - Present: Evolution metaphors for reactivity pattern development - Improve: Ecosystem thinking about framework interdependencies ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure and logical flow - Improve: ARIA labels for technical diagrams and code examples #### Keyboard navigation - Present: Standard video controls accessible via keyboard - Improve: Chapter navigation and timestamp jumping functionality #### Contrast and readability - Present: Audio content doesn't require visual elements - Improve: High contrast transcripts and visual aids #### Text resizing and reflow - Present: Text-based content scales appropriately - Improve: Responsive layout for supplementary materials #### Media and captions - Present: Audio discussion with transcript available - Improve: Professional captions with technical term definitions #### Forms and interactions - Present: Simple playback controls - Improve: Enhanced player with bookmarking and note-taking features ### 🌍 DEIB Assessment #### Cultural breadth - Present: Technical discussion accessible to international developers - Improve: Examples from diverse framework ecosystems and use cases #### Inclusive language - Present: Professional technical terminology without exclusionary jargon - Improve: Plain language explanations for complex concepts #### Neurodiversity support - Present: Structured conversation with clear topic transitions - Improve: Chapter markers and summary sections for easier navigation #### Representation - Present: Multiple expert voices with different technical backgrounds - Improve: Diverse perspectives on framework choices and technical tradeoffs #### Psychological safety - Present: Respectful technical disagreement and open discussion - Improve: Clear guidelines for community participation in technical debates ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear progression from signals definition to Fetchium design decisions - Inductive strength: Framework adoption patterns support signals trend claims - Causal reasoning: Links between React's hook design and ecosystem limitations well-established - Analogical strength: Gym/brain exercise analogy effectively illustrates AI development concerns #### Fallacies - Appeal to popularity: "Every modern framework uses signals except React" - while true, doesn't prove signals are inherently better - False dichotomy: Presents hooks vs signals as binary choice, ignoring hybrid approaches #### Tone of voice - Overall tone: Collaborative and technical, with respectful disagreement about React's choices while acknowledging valid reasoning behind different approaches ### 🛡️ DARVO Analysis - Deny: No defensive patterns observed - Attack: No attacks on individuals or communities - Reverse victim/offender: No victim/offender dynamics present - Emotional cues and rhetoric: Professional technical discussion without manipulative elements ## 🎯 Conclusion Signals are emerging as a unifying reactivity pattern across JavaScript frameworks, with Fetchium representing a significant advancement in data layer architecture. The conversation reveals both the technical sophistication required for production-ready signal implementations and the broader implications for how developers will work with AI tools. The emphasis on declarative patterns and lifecycle automation suggests a future where complex reactivity management becomes transparent, allowing developers to focus on higher-level application logic. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad Purpose: Stage CEE units that become Literature notes. Split --- ## Full Transcript [00:01] Robbie the Wagner and Adam Thomas Argyle [00:04] the nerd. [00:06] >> You're so absolutely right, Robbie. [00:09] >> Thank you. Uh, sickopantic machine. Um, [00:15] yeah. Would you like to tell the folks [00:17] at home who we have on the show today, [00:19] Adam? [00:20] We've got a JS hacker, API designer, dev [00:24] tools, crafter, introspect, pixel [00:25] artist, writer, chef, TC39 delegate, [00:28] Ember, contributor, principal, front [00:29] end, devat, phantom, decorators, [00:32] champion, co-ch champion of signals in [00:34] JS, seeking to solve the world's [00:35] scattered reactivity wos, reactivity wos [00:38] with one true signal to unite them all [00:40] from this elevating reactivity hell [00:42] we're in. Coming to you live from the [00:44] same state as Robbie on this fortuitous [00:46] visibility day. Kristen Garrett. Y'all, [00:48] nice to see you again. Been since [00:50] Cascadia JS last year. [00:52] >> Yeah. No, it's great to see you all, [00:53] too. Glad I could be here. [00:56] >> Yeah. Yeah. Thanks for joining us. [00:58] So, yes. Um, as the name of the show [01:02] entails, we do some whiskey, but as [01:03] everyone is hopefully happy about, I [01:05] haven't heard yet, we don't talk about [01:07] it anymore until the end. So, we'll just [01:10] mention what it is. We've got some soft [01:13] red wheat holiday uh bottled and bond [01:18] Missouri straight bourbon whiskey. Okay, [01:19] we'll tell you more about it afterwards, [01:21] but a lot of people don't want to hear [01:23] about the whiskey. So, [01:25] >> if you don't care [01:27] about the web [01:29] >> Yeah. Yeah. A lot more people care about [01:30] the web. [01:35] >> All right. Well, I do have a toast [01:36] though. So, for our first sip, [01:38] >> may your whiskey glass overflow with [01:40] tasty pixels, your signals be true and [01:42] clear, and your code compile on the [01:44] first try. Cheers. [01:46] >> Cheers. [01:47] >> Cheers. [01:53] >> So, yeah. Um, [01:57] it's been an eventful I think six months [02:00] since Cascadia. [02:02] Um I have been working like crazy on [02:06] basically [02:08] a better version of Apolloquery. [02:12] Um [02:14] so Apollo client is great, right? Um but [02:19] it is GraphQL and Tanacquery is great [02:22] but it is very simple. Um and this is [02:26] actually why I started working on [02:28] signals. Um, and maybe should we give [02:30] like an intro to signals at all? Uh, [02:33] maybe I don't know how familiar people [02:35] are. [02:35] >> What is a signal? I'm Yeah, no, we [02:38] probably should. [02:40] >> So, signals are a pattern that's [02:42] actually been around for a long time. [02:44] Um, I think one of the earliest like [02:47] JavaScript implementations of it would [02:49] be Mobox. Um, uh, MobX is basically [02:54] signals although it's a very like [02:55] classoriented version of it. It's like [02:58] that idea of you have you know these [03:01] reactive values you consume and you kind [03:04] of automatically track them as you are [03:06] computing [03:08] um some output and uh eventually we kind [03:13] of figured out that you don't really [03:15] need to have a class or like anything [03:17] too stateful. You can kind of just have [03:20] functions. Um and then uh basically your [03:24] functions are can be pure uh if you are [03:30] thinking of signals as like if you're [03:32] thinking of all of your mutable state [03:34] being in signals, right? They are signal [03:36] pure. So they're like guaranteed to [03:40] produce the same output if the signals [03:42] have the same input and if you're not [03:44] doing anything too crazy because I mean [03:45] it's JavaScript. You can do whatever you [03:47] want. Um but yeah, basically every [03:51] modern web framework with one major [03:53] exception [03:55] uh is based on signals these days. Uh [03:57] Angular migrated to them I think last [03:59] year. Vue has been based on them for [04:02] quite a long time. Spelt uh with runes [04:06] is now based on them. Um [04:09] solid uh definitely one of the big ones [04:12] uh that kind of started it and pioneered [04:14] it um in rendering frameworks. Ember uh [04:18] you know had autotracking which was a [04:21] form of signals is how I got into it. [04:23] And [04:24] >> which one doesn't have them? [04:28] >> You know it's kind of the the elephant [04:29] in the room. React has has kind of [04:32] panned signals and um I don't I [04:36] understand where they're coming from. [04:38] Um, I think that that might be a bit of [04:41] a [04:43] I think they they were trying to evolve [04:47] things in a very different direction [04:48] when signals were first starting, right? [04:51] Signals are very they kind of look like [04:52] these objects that are stateful [04:55] and they wanted to go into this hooks [04:58] direction where it's like, oh, we have [04:59] these pure functionsish [05:02] um, but they're not pure, but they're [05:04] kind of pure. And I want to give credit [05:06] to React because I don't think I would [05:08] have gotten to where I got with [05:10] Signalium if it wasn't for React. The [05:12] thing about Signalium that's different [05:14] than other signal implementations and [05:17] there's several that are in the React [05:18] ecosystem too. You've got like Jotai [05:21] Legend state. These are signals [05:24] implementations that follow this [05:26] pattern. But the key difference is that [05:30] most signals libraries don't allow you [05:32] to parameterize your signals. Um, and [05:36] what that means is you kind of have to [05:38] manage the life cycle of every computed [05:41] signal, every derived signal. Um, you [05:44] have to like if if you want to have like [05:47] a hook essentially where it's like, oh, [05:49] use uh full name of user, right? Like um [05:54] you can repeat that with like 10 [05:56] different users, pass in 10 IDs, right? [05:59] and React handles the you know setup and [06:03] the life cycle and the tear down and [06:06] everything there. [06:08] Um [06:10] and with signals traditionally you kind [06:14] of have to like manage all of that [06:16] yourself. Um so it's a little annoying [06:20] uh and kind of stateful and I can see [06:22] why people would look at that and be [06:24] like ah we don't really like it. it's [06:26] not really like functional, right? And [06:28] it to be fair, a lot of complexity ends [06:31] up being in that those parts that aren't [06:34] functional. Um, [06:36] >> when you say not functional, do you mean [06:38] not like functional programming? [06:40] >> Not that it doesn't work like [06:43] >> Well, you start to have Yeah. Not like [06:45] functional programming. you start to [06:47] have um some really tricky [06:53] it's not even that it can necessarily be [06:55] like um the worst thing in the world. [06:58] It's just like state to acrue in various [07:01] places, right? You start to see [07:10] shakes fisted stalled version of you. [07:12] I'm like, no, [07:13] >> I was brought to you by internet. It's [07:17] tough. [07:21] >> Well, I'm having fun linking everything [07:23] as we go. I've got uh in the chat so far [07:26] links to Signnolium and to the uh [07:28] signals proposal. So folks want to [07:31] follow along with that. Check out the [07:33] chat. I guess it was more like tweets, [07:35] but here I'll put it in the chat [07:40] and signal. [07:43] I'm tempted to like ask about [07:44] observables. I'm like, are they bad? Are [07:46] they good? [07:48] >> We'll never know. [07:49] >> You asked a guest. The whiskey was too [07:51] strong. Bottled in bond. Yeah. [07:53] >> Oh, is here where here we'll talk about [07:55] the whiskey. [07:56] >> Hey, yeah, now's a good time. Um Oh, we [07:57] just lost everybody. No. Um yeah, we [07:59] could talk about it real quick. So, this [08:02] um See, where is my notes? This whiskey [08:06] is 73% corn, 15% soft red wheat, and 12% [08:12] malted barley. And I don't taste any [08:14] malted barley, personally. [08:17] >> Yeah. Which I'm kind of I like the bite. [08:20] I'm happy. I'm like, it's got a spice. [08:23] Yeah, it's like for being that much [08:25] corn, it has an interesting amount of [08:28] stuff going on. Um, [08:30] >> yeah, [08:30] >> little spice, a little um little tang or [08:34] something. I don't know how to describe [08:36] it. It's got something different going [08:37] on. [08:38] >> That must be that soft red winter wheat. [08:41] >> Uh, which apparently soft is because it [08:43] has less proteins in it, so it's less [08:45] glutenous something. And it's gives it [08:48] Oh, it really um [08:50] >> so that means physically soft like [08:53] >> like it's um [08:54] >> I don't know. It's not like hard water [08:55] and soft water. Is it you know it's like [08:58] >> do we just use these words cuz we didn't [09:00] have anything better? [09:01] >> Yeah. [09:02] >> Yeah. I don't know. Um [09:05] I think this is my first weeded bourbon. [09:10] >> Yeah. Um, [09:13] yeah, it's uh it's been a while since [09:14] I've done a weeded one, but we've done a [09:17] few on the show. Um, [09:22] and then yeah, bottled in bond has those [09:23] requirements. It's got to be at least [09:25] four years old, hunterproof. And this [09:27] checks the boxes at six years old. So, [09:34] oh, this reminds me of You've seen [09:35] Wayne's World, right? The movie. [09:38] Um, I'm actually not sure if I have, [09:39] which might be very [09:40] >> Shut the hell up. You haven't seen [09:43] Wayne's World one or Oh my goodness. [09:45] >> I'm familiar with it, but um, [09:47] >> that doesn't matter at this moment. [09:48] >> Seen it. [09:49] >> Yeah. I don't think I've like sat down [09:51] and watched the whole thing. I feel like [09:53] there's a lot of movies like that where [09:54] I've seen like bits and pieces when it [09:56] happens to be on, but like Yeah, I'm [09:58] pretty sure I haven't sat down and [10:00] watched the whole thing. [10:01] >> Oh man, there's a scene. So, you know [10:02] who Wayne and Gar are? [10:04] >> Mhm. [10:05] >> Okay. So, Wayne is usually the one [10:07] talking. and Gar's the nerdy, you know, [10:08] secondary one. Um, and there's a moment [10:12] and they're like live uh and like the [10:14] first or second episode after they kind [10:16] of sold out and they started making a [10:17] bunch of money and went to a nice big [10:19] production agency. Anyway, um Wayne has [10:22] to leave and G is just left there by [10:24] himself and G is like totally frozen [10:27] like a deer in the headlights like I [10:29] don't know what to do and the show is [10:30] just mine and he just gets really [10:32] awkward and it's really funny. So I kind [10:34] of feel like that right now. [10:37] You're coming back. I think I'm coming [10:38] back [10:39] >> at FPS five, but you know that's cool. [10:42] >> It'll record normal. [10:45] >> Yeah, it's fine. [10:47] >> Okay. Um, so yeah, where were we? Um, [10:54] Robbie was just digging in about [10:57] >> Oh, [10:58] >> yeah. I forget what we were saying. Um, [11:01] well, what was I saying, Adam? Seems [11:03] like you knew. Uh well you were digging [11:05] into the intricacies of it like signals [11:08] that had other dependent or that needed [11:09] computed. There was a word about signals [11:12] that you were asking about. You're like [11:13] what does that particular part mean? [11:15] >> Oh just I was just being um silly about [11:18] like is it is functional [11:20] >> like functional programming or like [11:22] works. [11:23] >> Uh yes yes. Okay. [11:25] >> Yeah. No, it's like functional [11:26] programming and you know that to be fair [11:29] to because I think we all went through [11:31] like the period of like h functional [11:33] everything and that was interesting. Um [11:38] there's a lot of nice things about it [11:40] though and I think React's model with [11:42] hooks really pushed the boundaries of [11:44] that and it had some really nice like [11:48] properties. One of the biggest ones [11:50] being we're threading life cycle all the [11:53] way through the system without having to [11:56] like very be very explicit about it. [11:58] Right? If you remember in Ember, you had [12:01] to like thread the owner through from a [12:04] component all the way through any kind [12:06] of dependency you had and you have to [12:09] like manage all the life cycle. your [12:11] life cycle hooks become very like [12:14] um deeply entangled with every single [12:17] part of your system and all of a sudden [12:21] your code is no longer like isolated. [12:24] Your component logic seeps into every [12:27] other part of your code. And Adam, you [12:29] were about to say you're tempted to ask [12:31] about observers or observables. [12:33] >> Observables. I sure was. Yeah, I uh I'm [12:37] still a big fan. I'm like I miss them. I [12:39] kind of want them back except testing [12:40] them was hard. But anyway, yeah. Well, [12:43] observables are very interesting because [12:47] they are a very similar type of system. [12:51] They allow you to abstract away that [12:53] reactivity and to create these [12:55] composable elements. But the issue I had [12:58] with observables is similar to the issue [13:00] I have with uh you know kind of like [13:03] those life cycle hooks is when you start [13:06] writing code in observables kind of [13:08] everything needs to start using [13:10] observables. Everything needs to become [13:12] observable aware. They're needy. Yep. [13:15] >> Yes. [13:16] >> And hooks at first doesn't feel like [13:19] that, right? At first you're like, "Wow, [13:22] I can use plain functions and [13:24] everything's just a plain function and [13:26] whatnot, [13:27] but then over time you start to become [13:30] really entangled in them and you you [13:33] can't really detangle very easily." [13:36] Actually, uh, one of the reasons I [13:38] started working on Signnolium is, um, I [13:40] was debugging some React components we [13:42] have, trying to figure out performance [13:43] issues and whatnot. And I noticed [13:46] because I was doing a thing where I [13:48] triggered the whole, ah, you called the [13:50] same hooks out of the wrong order bug. [13:53] Um, I noticed our stack was like 200 [13:57] hooks deep. And it wasn't even that big [13:59] of a so few. [14:02] >> Turns out when the smallest like [14:06] node of your reactive system that you [14:08] can rerun is the component. It ends up [14:11] being quite a lot of uh stuff. Um [14:16] but yeah, I I think that um with signals [14:21] coming back to Fetchium, the goal for me [14:24] has always been like can we detangle [14:26] these things because you've got like [14:28] data and then you've got like you know [14:31] app uh view code and then you've always [14:35] got a lot of business logic in between. [14:37] You can't like really get rid of all of [14:39] that. You've got a lot of like deriving [14:42] you have to do and like monging of data [14:45] and you got to like thread this needle [14:49] and then you've got to thread life cycle [14:51] through that and hooks almost get you [14:54] there but you can't run them just [14:57] anywhere and I couldn't like build fetch [15:00] on hooks because I wanted fetchium to be [15:04] independent I wanted it to be a data [15:06] layer Apollo is built on observable [15:09] Right. Um, it gets to do that and nobody [15:14] knows under the hood. It's just an [15:15] implementation detail. [15:18] Um, fetch does the same thing with [15:20] signals. And I just think that signals [15:22] end up being a more elegant and um, like [15:26] more [15:29] ergonomic solution to the same problems. [15:31] Especially for front-end def where you [15:34] really don't want to capture every [15:36] single event. you want to kind of allow [15:38] the events to be driven through the [15:40] system by consumption. Um, so you know [15:44] with observables you kind of have to [15:45] like force it all the time. You have to [15:48] be like I'm going to debounce this and [15:49] I'm going to like wait on this and then [15:52] I'm going to Yeah, it just turns into [15:53] like a really annoying like process [15:56] where you're constantly trying to [15:58] throttle that. And the only time I think [16:00] that's really super useful is if you're [16:02] in like a backend system where you [16:04] really are like I want every single [16:05] event to come through. I need to capture [16:07] all of them. [16:08] >> Oh man, it was good during touch events [16:10] too because I could layer the touch uh [16:13] start could kick off an observable that [16:15] then kind of observed all the touch [16:16] moves. I could zip the um the moves into [16:20] a pointer event. So I could I could like [16:22] merge whether or not it was a pointer [16:23] event or a mouse event or all these [16:25] different things into a single [16:26] observable, feed the observable that [16:28] actually needed to update some translate [16:30] X and Y properties to make something [16:32] very tangible and movable. And then when [16:34] I got to the end and someone flung, I [16:36] could easily close it all down. So there [16:39] was like I agree though that most of the [16:41] cases were uh take one, you know, it's [16:44] like I just I just need one of these. [16:45] Just give me the most recent one. I [16:47] don't care about the history. Um but [16:49] there were times when it was nice to [16:50] have this replayable scenario or it was [16:52] also I thought it was nice to think [16:54] about your UI as not a one-time thing. [16:57] That's a that's a problem people think [16:58] about all the time where they're like, [16:59] "Oh, they just hit the submit button [17:00] once. I just need like one listener." [17:02] It's like, well, they might hit it once [17:03] and then open it up again and hit it [17:06] twice. Um, [17:08] really fast [17:09] >> or Yeah. Which also observables were [17:11] really good at handling that. Um, [17:13] because you could cut but you had to [17:14] continue chaining more chains. Um, [17:17] >> yeah. [17:17] >> And that was kind of the problem is it [17:19] was like you could feel it infecting uh [17:21] the code and if you didn't have a good [17:22] grip on the mindset and then that's [17:24] where testing came in to be a bummer [17:25] too. You were just like, "Oh, great. Now [17:26] I have to recreate the five chains that [17:29] I put together just to do this submit [17:31] form." uh to do a unit test and and then [17:34] you had timing with unit tests. It was [17:35] like a pain in the butt too. And anyway [17:37] anyway I digress. [17:38] >> Timing is always a problem and that's [17:40] why I've always liked honestly Ember's [17:42] test model like to to go off on a slight [17:45] tangent but Ember you know had that [17:47] model of like just run the tests in the [17:50] browser and then um it was a bit more [17:54] like you know a lot of like uh [17:57] user testing library and stuff is like [17:59] uh polling based. it's just like wait [18:01] for the thing to be in the DOM. Um, and [18:04] I prefer Ember's model where it was [18:06] like, well, we we know when things have [18:09] settled and when we're done rendering, [18:11] so just like, you know, check it then. [18:14] Um, just gives you a little bit more [18:15] speed and, you know, but the main thing [18:18] is just like, yeah, render the real [18:20] component and then interact with it like [18:22] a user. I think that's like that's [18:24] that's a thing no matter what. Same [18:26] issue with Signalium, same issue with [18:28] any reactivity libraries, timing becomes [18:31] tricky, hooks as well, like very much [18:34] so. Um, [18:37] and then back to what you were saying [18:40] about observables, I think that like the [18:43] second thing you mentioned of like you [18:45] might come into the state in many [18:47] different ways, you might come into it [18:48] many different times. I think that is [18:51] what a good reactivity system in general [18:54] solves. And I do think that, you know, [18:58] hooks can solve it if used correctly [19:02] and, you know, thoughtfully and uh [19:05] you're not doing anything too complex. [19:07] It's It's actually pretty solid at [19:09] solving it compared to some of the older [19:10] stuff that like I don't know when I [19:13] first started building stuff it was like [19:14] Knockout and Meteor and Ember and [19:16] Angular one and you know um so I I think [19:21] that um yeah I think signals will get [19:25] that for you as well if you play around [19:27] with them. Um, I think that the other [19:31] thing is where signals is not the right [19:35] abstraction, but that's also such a [19:37] niche thing that I think I'd rather have [19:39] a specific abstraction for that, right? [19:42] Something where it's like, oh, I am [19:44] trying to track every single event here [19:46] and I'm trying to have really nice [19:48] animations with all of it. like having [19:51] that integrated into the system that's [19:53] going to render [19:55] unless you're trying to render like the [19:56] X and Y coordinates on like oh this is [19:59] where it's at like right now on screen a [20:02] bunch and you're also trying to feed [20:03] that into a bunch of other data. I don't [20:05] know how useful that is you know. [20:08] >> Yeah. Yeah. I feel like um you know the [20:12] big problem I have with all you know [20:15] hooks and the way things are done these [20:17] days is that it feels backwards to me of [20:19] like okay everything will rerender [20:21] infinitely until you tell it not to. I [20:23] feel like the other way is the way it [20:25] should be of like I'm gonna tell you the [20:27] things that need to rerender and those [20:29] things should be tracked because like [20:32] >> it seems silly to do it the other way of [20:34] like all right these 400 things I want [20:36] to ignore like or there's like one I [20:39] care about you know like seems [20:41] >> yeah like going back to my Cascadia talk [20:44] like basically if we think about it like [20:46] promises right promises um [20:51] like if we did what hooks do for [20:54] reactivity to promises. It would [20:56] basically be like every single time you [20:58] hit an await, you halt the program and [21:02] then you restart the program. At the [21:04] start of the function, you go through [21:06] every single function again, but it all [21:08] has to be item potent. Every single step [21:10] you take has to be item potent and then [21:12] you hit the next await. And that's [21:14] actually exactly how React suspense [21:16] works. like use just throws an error and [21:20] you know suspense catches that error. It [21:23] sees that it's a suspense error and it's [21:24] like okay I'll wait and once that [21:26] promise resolves it starts re-executing. [21:29] So you're literally doing that [21:32] um with Signalium and with Signals in [21:35] general but Signalium also really [21:38] focused on having us like recomputee [21:42] from the change state upward. So if you [21:46] imagine your state tree and your [21:48] functions, your hooks as like a tree of [21:52] dependencies, right? And you you're [21:54] doing essentially like a depth first [21:56] walk of that tree when you execute it [21:58] the first time. We start at the leaves [22:02] when state changes and we walk up the [22:05] tree and at every node you can stop that [22:08] walk. You can say okay now that didn't [22:10] change. So then nothing above this point [22:12] has changed and really this is like [22:15] similar to a lot of like diffing [22:17] algorithms in general for components. [22:19] It's just on the function level which is [22:22] what promises and async did with like uh [22:27] async aait did with like that operation. [22:30] So I would say this is that's the way [22:32] I've been framing it is like this is a [22:34] monad for reactivity and I could [22:37] actually see this being like a keyword [22:39] in the language one day maybe. Um, [22:43] don't quote me on that because, you [22:45] know, I I still need to do the actual [22:48] um, [22:49] I don't know, sciency parts of things to [22:52] to formalize all that, but it feels like [22:55] it can be. It feels very composable. Um, [22:58] and it's very nice to work with. [23:02] >> So, how does the like official signals [23:05] proposal come into play with any of [23:08] that? [23:09] >> Yeah. Okay. So things that signal does [23:12] that the official signals proposal and [23:14] basically no other signals like [23:16] libraries do uh the two things are those [23:20] parameterized like functions. So um what [23:25] that basically works out to be is like a [23:27] a signal factory and then kind of [23:29] hooking up those signals and their life [23:31] cycle to some consumer which we call a [23:34] watcher in Signalium. Um, the closest [23:38] I've seen is Jotai has atom families [23:42] which are pretty similar, but they're [23:44] like kind of an afterthought it feels [23:45] like in Jotai. And in Signalium, we're [23:48] like, "No, that's the default." Um, [23:51] so there's that and then there's async. [23:55] And async in general is usually an [23:58] afterthought. It was an afterthought for [24:00] Ember. If you remember, we rolled out [24:02] autotracking and we were like, "Yeah, [24:03] autotracking this is great. This is [24:05] great for everything." And then people [24:06] are like, "How do I manage a request?" [24:08] And then I started [24:10] building [24:12] for years. Um, mostly because Chris [24:16] Seldon just wouldn't let me land [24:18] anything because he kept being like, [24:20] "It's not perfect though." And I was [24:22] like, "Chris, I swear if people aren't [24:24] able to make requests, they're going to [24:26] mutiny." Like weird. [24:28] >> Who needs requests? All your data is [24:29] just stored in the the front end. I just [24:32] remember people using like modifiers to [24:34] make requests which I was recommending [24:36] because I was like yeah these are the [24:37] replacements for life cycle hooks you [24:39] should use these and then Chris was like [24:42] and and you were like oh that's not what [24:45] they were for actually and then I was [24:48] like okay well how do you make requests [24:49] if we're getting rid of these life cycle [24:51] events and they were like [24:53] you need to figure that out. We are [24:56] still debating like they have the lint [24:58] rules about don't use the render [25:00] modifiers and don't use like [25:04] >> um something else. Oh uh run loop maybe. [25:07] Yeah. Yeah. So I'm like how do you [25:09] render something after render without [25:12] the run loop or render modifiers? You [25:15] could do a custom modifier I guess but [25:17] I'm like you get come on. [25:21] I feel like a lot of the debates were [25:23] really driven by like being perfect and [25:25] they ended up letting the perfect be the [25:27] end of the of the good. Um and and I'm [25:32] trying to split the difference in a lot [25:33] of ways. Like I want to have better than [25:36] the status quo. A lot better than a lot [25:39] of the status quo. Um, but I also don't [25:43] want to um, you know, [25:47] have it be [25:49] like when I talk with Chris Elden, I [25:52] still talk with him a lot and, uh, when [25:54] I talk with him about um the [25:58] um, [25:59] async stuff and reactive promises and [26:02] whatnot, he'll still be like, I don't [26:04] know if that's quite right. And I'm [26:05] like, okay. But it works really well. [26:07] It's like it's definitely a lot better [26:09] than hooks for a lot of things. But [26:12] anyway, so reactive promises um are the [26:18] thing that not not just reactive [26:20] promises. Reactive promises and relays [26:22] are the things that most signals [26:24] implementations don't have or kind of [26:26] only vaguely have and that I think are [26:30] super necessary, but it's like a couple [26:32] steps down the way for most people. And [26:34] I've just been like messing with signals [26:36] for a lot longer than most people like [26:38] besides like Michelle West for MobX and [26:41] um you know so I think like I've I've [26:45] actually been talking to like pact [26:46] people were like yeah we kind of need [26:48] something for this and the solid people [26:50] too and whatnot. Um so [26:55] uh the proposal has what we need for [26:59] those like you can implement those on [27:01] top of the proposal and that is the [27:04] connected and disconnected I think [27:06] they're called or watched and unwatched [27:07] hooks because you really basically need [27:10] a way to say okay this part of the [27:11] signal graph is being used by something [27:16] live and that watcher that that observer [27:20] externally could be like the DOM, right? [27:22] Or it could be like your app. Um, it [27:25] doesn't really matter exactly what it [27:27] is. It's just userdefined and it says [27:29] like, okay, [27:32] as long as I'm using this, I need to [27:34] consume resources, whatever those are. [27:36] Now, on the other end of your signal [27:39] graph, at the very edge, you will have [27:42] something that communicates with the [27:45] outside world. Um, that could be a [27:49] connector to Apollo. Let's say you want [27:51] to use Apollo, you have GraphQL, you [27:53] just want to hook it up. Well, you need [27:54] to subscribe and then later on you need [27:57] to unsubscribe. You need to tell it [27:59] like, I don't need those events anymore. [28:01] Um, you could be communicating to a [28:04] websocket. You could be communicating to [28:05] a background process, to a web worker, [28:08] like anything that is async and [28:11] specifically [28:12] that's not like request response. like [28:14] you can kind of get away with request [28:16] response like promises because those [28:19] have an end point, right? You can kind [28:21] of just toss it away if you don't need [28:23] it anymore and it's not going to [28:24] continue to consume system resources. [28:27] But you cannot do that with any kind of [28:29] subscription. And so you either need to [28:32] thread your life cycle through the [28:33] entire graph or you need to build it [28:36] into the graph. And when you combine it [28:39] with um [28:42] like optional [28:44] um not optional but like forking [28:46] essentially so like uh branching [28:48] branching is what I'm looking for. So [28:50] like if you have an if statement right [28:53] and it's like in branch A I consume [28:55] signal graph you know A and in branch B [28:59] I consume signal graph B. Unless we're [29:02] saying we want to consume all of them [29:03] all the time. You need to be able to [29:06] dynamically switch between one and the [29:08] other. And then you need to be able to [29:10] sub unsubscribe from one and subscribe [29:13] to the other, which kind of means the [29:16] graph needs to know about this stuff. [29:18] Like it's the only thing that can unless [29:21] you want to start again doing a lot of [29:23] really nasty threading of life cycle [29:26] through all of that. [29:28] And yeah, so that's how I got to where I [29:31] am today with Signnolium and me being [29:33] like the one person I convinced little [29:35] Dan like we probably need the life cycle [29:38] hooks and he has kept them in there and [29:40] I've been very thankful to him for that. [29:43] Um because everybody else is like do we [29:46] really need these? And I'm like [29:48] you will trust me you don't want to ship [29:51] without them. [29:54] >> Yeah. Yeah. I mean, so this stuff uh [29:58] seems more complex than I kind of [30:01] thought of signals uh being, you know, [30:03] coming from I do mostly Ember still, so [30:05] I'm like tracked properties. Yay. Um but [30:09] I'm curious how you feel. Have you seen [30:11] um Adam? How do you Is it Gia or Gaya Ga [30:16] JS? [30:16] >> One of those. Yeah. [30:18] >> Yeah. [30:18] >> I haven't seen that one. I haven't been [30:20] keeping up with stuff a lot because I've [30:21] been just like in execute mode for [30:24] getting stuff done with React. [30:27] >> Yeah, [30:29] system and a half. [30:32] >> So, so Gia, I believe I guess it's Gia. [30:34] We'll say Gio. Um [30:35] >> I like Gia because it makes me like Gio. [30:37] You know, you could say it real cool, [30:39] you know. Gio. [30:40] >> Yeah. Yeah. [30:41] >> Um but it its whole thing is like um I [30:44] don't know how it was built. We're [30:45] hopefully going to have the guy that [30:46] wrote it on and and learn about it. But [30:48] the TLDDR is like it's super small and [30:51] it has no hooks, no signals, no like it [30:54] just figures out what should change [30:56] through like some magic compiler and I'm [30:59] like [31:01] what? So like um I don't know. I'm [31:04] curious of your thoughts on like I [31:06] always kind of have this big, you know, [31:08] vision of the future of like will all of [31:10] these minute things we debate about not [31:12] matter and we just write like, you know, [31:15] thing equals whatever done. Um yeah, [31:18] where what do you think about that? [31:21] So [31:23] I I think that um [31:26] like [31:28] signals [31:31] I I'm after that as well and I think [31:33] that promises did that for async like [31:36] the world before promises with and and [31:40] sync uh symmetric async right like [31:42] request response the world before that [31:45] with promises was the wild west. It was [31:48] just like callbacks everywhere. And it [31:50] wasn't just JavaScript that had that. It [31:52] was C. It was Java. Like that was pretty [31:57] standard for a lot of things was just [31:59] like, you know, how do you resume after [32:02] asynchronous actions? Well, you kind of [32:04] just have to like, you know, pick it [32:07] back up. Um, [32:10] so I do think there are things we can do [32:12] where we can figure out abstractions [32:14] that allow us to no longer have to think [32:17] about entire problem spaces. And we've [32:20] done that many many many times in [32:22] computer science. In fact, I think that [32:24] is more important to do now with AI than [32:27] ever because if we want the code to be [32:29] understandable, if we want to be able to [32:31] read and write and execute quickly and [32:34] not just be making slop that's about [32:36] like five steps away from falling apart [32:38] all the time, um we want simpler [32:42] abstractions. [32:44] Um that's actually one of the reasons [32:45] that drove the design of Fetchium. [32:49] Fetchium has this very declarative [32:52] syntax um for the design. It's like you [32:56] declare your params, you declare their [32:58] types and then through some proxy magic [33:03] I use those uh like when you reference [33:06] those parameters [33:09] um elsewhere [33:11] uh I'm basically capturing a reference [33:14] to them and then for each instance we [33:17] actually go and reify those parameters [33:19] and all the fields that are derived from [33:21] them. So the path itself of a request or [33:25] the headers, you can actually reference [33:27] like this.params [33:29] dot, you know, ID or this.params [33:32] whatever in there. It's really cool. And [33:35] at first I was like, okay, is this too [33:37] magical though? Like this is a little [33:40] bit a little bit much. Maybe maybe [33:43] people won't like it. And I realized, [33:46] okay, but AI probably will really like [33:48] it because it is very simple. It's very [33:50] readable. and AI can remember those [33:52] rules typically as long as you give it [33:54] the like hints of like okay don't do [33:56] this and be careful and use this agent [33:58] definition and you know um so I decided [34:03] to go for the more declarative thing [34:04] rather than a thing where I would have [34:06] had to have more like function [34:09] definitions so anyway sorry tangent but [34:14] yeah I think that um [34:18] it is actually something we can do we've [34:20] done it many times times. We did it when [34:22] we created compilers for assembly. We [34:25] did it with uh closures. Uh we did it [34:28] with you know promises and futures and [34:32] and I think we can do it with [34:33] reactivity. I think we've been trying to [34:35] do it with reactivity since like the [34:37] first functional reactive pro uh [34:39] programming white papers which I like [34:42] went back to read at one point on this [34:45] journey. It's like they're describing [34:48] really cool things, but like the how you [34:50] actually write it and how you actually [34:52] use it has always been this white whale [34:56] of [34:58] ergonomics, right, of like most people [35:00] don't seem to get it. And the people who [35:01] do are like, "Why don't most people get [35:03] it?" And I'm like, "Have you seen Elm? I [35:06] don't know, man. Like, have you seen [35:08] Haskell?" Like, I I get it now, but also [35:12] like it took me a while to wrap my brain [35:13] around that. like took a while. [35:16] >> Yeah. Yeah. I mean I feel like a lot [35:19] myself included a lot of the time a lot [35:21] of web developers don't understand a lot [35:24] of the complexity. So like I feel like [35:26] there's two very separate camps of like [35:29] um you know one one side frequently or [35:33] historically at least maybe not today [35:34] with AI and whatever's going on but like [35:36] I think the people that chose writing [35:38] 200 React hooks liked the complexity. [35:41] They want that. They're like I love it. [35:43] Look at all these hooks. They're [35:45] awesome. Like, and then the other side [35:47] was like, I don't ever want to write a [35:48] hook. I just I want this.fu equals bar [35:50] and I'm I'm happy. Um, and I think, you [35:55] know, neither really matters anymore [35:57] because AI is going to write so much of [35:59] the code that like you're right that [36:01] like if you build your libraries to be [36:03] very easily usable by all these models, [36:06] then I think they'll just be like, "Oh, [36:08] this is easy." And use that like because [36:11] I don't I don't know how you feel about [36:13] people are saying, "Oh, I'm not even [36:14] going to look at the code anymore in [36:15] like a year." And I I don't know if [36:16] we're going to get to that. But [36:18] >> I actually think it's more important to [36:20] read the code than ever. And here's why. [36:23] I think we are going through what [36:25] happened to our physical bodies when we [36:28] started to have 9 to5 desk jobs like be [36:32] the main way of, you know, uh kind of [36:36] working, right? Because it used to be [36:38] that for most people, you would probably [36:41] get at least a little bit of walking in, [36:43] some standing, some like doing things [36:45] and not just sitting at a desk staring [36:47] at a screen for eight hours. Heck, [36:49] before work from home, uh, you know, I [36:52] at least had to go to meeting rooms on [36:53] occasion. Um, so you know what happened [36:58] in the last century? We started going to [37:00] the gym. Gyms happened. Um, physical [37:04] fitness and all of that. I think that's [37:06] about to happen to our brains. Like, [37:08] yeah, you don't need to like use your [37:11] brain in that same way to get 80 to 90% [37:15] of what you need done done. [37:18] But if you don't, you're not going to [37:20] get it through just doing your job [37:21] anymore. And you're not going to level [37:23] up. You're not going to grow. You're not [37:25] going to understand things deeply [37:28] anymore. And I don't know, that also [37:30] just doesn't sound very fulfilling for [37:32] me because I love doing this. Um, but I [37:35] also think like if you want to be a good [37:37] dev, you're going to have to read a lot [37:39] and you should be reading your your [37:41] agent's code all the time. I think um [37:44] >> the domain gym.ai is for sale. Just [37:47] saying. [37:50] >> Just play Clues by Sam. That's the thing [37:51] I do that always keeps my brain feeling [37:53] sharp. Um I I empathize with what you're [37:56] saying, but I also feel like uh my brain [37:57] is um incapable of what AI wants it to [38:01] do now. like I'm not I'm not good. I'm [38:04] not enough. Um it could take uh you know [38:08] I could be commanding 100 teams uh if I [38:12] was mentally capable. If I was I need [38:15] more arms also, you know, give me more [38:17] arms for more fingers with more [38:19] keyboards and I could be making more [38:21] software, you know, like [38:23] >> uh or or even like the model changes [38:25] where like I'm not telling one, you [38:27] know, it starts with you you try to tell [38:28] one agent what to do. Then as you level [38:30] up, you tell a team what to do. Then as [38:33] you level up, you create swarms, which [38:35] maybe are like multiple teams. You level [38:36] up again and now you're like coding [38:39] entire teams. So you hit a button and it [38:42] creates loops that create teams that [38:43] create teams that go out and they do [38:45] work and they kind of like fan out and [38:47] re come back and fan out again. And then [38:49] you've got your gas towns. Um, and you [38:51] could have multiple gas towns and [38:52] eventually someone's brain is trying to [38:54] manage a country of, you know, agents or [38:57] whatever. And it's like I feel incapable [38:59] of uh like Jason Langorf says like I [39:02] can't even come up with one good idea to [39:04] go execute. How are people out there [39:06] having three or nine or whatever. He's [39:09] like you're all you're lying. There's no [39:11] human brain out here that can do that. [39:13] But I do feel like during the workday [39:14] that my brain is now being taxed beyond [39:16] its squishy capabilities. I'm like I am [39:19] just but flesh. I'm sorry agents. I am I [39:23] can't. You need too much from me. I need [39:26] to leave at four o'clock today or else [39:28] my brain might explode because I just [39:31] can't deal with six agents at the same [39:33] time for eight hours a day. I'm too [39:34] squishy. Um, but I also agree that like [39:38] there's a point of which I'm losing the [39:39] details. And I love the I've sweated the [39:41] details my whole career. It's what I [39:42] think got me where I am. Um, and now I'm [39:45] sweating the details in a way of [39:49] orchestration. you know, how do I sweat [39:51] the details uh so that I can create [39:53] something that does the detail work? Um [39:56] it's just different. And I agree there's [39:59] you're going to have to balance it. Uh [40:00] there's an imbalance that's happening. [40:02] It's Yeah. If you went to the gym and [40:04] only did curls, you know. Um so [40:07] >> I used to go to the gym and only bench [40:10] and then go into the sauna because that [40:12] was the fun part. [40:16] >> Fair enough. But yeah. No, I think like [40:20] having a varied routine is good. I think [40:23] pushing that far in that direction. I'm [40:26] a very like balanceoriented person. So, [40:29] >> yeah, same. [40:30] >> I try I would just try to be like, [40:32] "Yeah, I can't handle more than six at a [40:34] time. Sorry." And if somebody else is [40:37] saying I should be able to handle more, [40:39] like, okay, cool. [40:41] I don't know if what you're producing is [40:44] actually going to be like [40:47] the right output in a lot of ways. And I [40:50] think like [40:52] actually zooming in on those details, it [40:54] matters like I have uh been working on a [40:58] little slide framework I use for my [41:00] presentations and you know I it's it's a [41:06] little messy. It's a little hacky cuz [41:07] presentations are always last minute and [41:09] I'm just hacking away. And I found that [41:13] when I have AI make my slides now, which [41:15] is what I do most of the time, it's [41:17] messing up a lot because the [41:19] abstractions aren't perfect. Um, and [41:23] it's like dumb, not perfect. Like I [41:25] could go in and fix it pretty easily and [41:27] then I wouldn't have to fix what my AI [41:28] is doing with the slides and then every [41:30] single bot after that would be a lot [41:33] better. I think working on the [41:35] abstractions and getting the details [41:36] right matters still. And what I find my [41:39] most productive times are when I'm like [41:41] pairing with an agent and I'm basically [41:43] like watching what it does, watching how [41:44] it's thinking because oftentimes I will [41:47] see it thinking and be like, "No, stop." [41:50] >> Screech, right? [41:53] >> Yeah. I can barely [41:56] >> I can barely keep like you know, you [41:58] were saying that reading the code is [42:00] important. I think so too because like [42:02] for things that you have good domain [42:04] knowledge on, you know, better than what [42:05] it's gonna write. So I'm like, "Hey, [42:08] yeah, um, you just wrote like 500 lines [42:10] of code. I needed you to like add a like [42:13] optional chaining thing." Like that was [42:15] it. Like or like something, you know, [42:17] small. And it's like, oh, like I just [42:19] handled every possible case. And then [42:21] also, you didn't ask me to, but I ran [42:23] linting, ran the test, committed it, [42:25] pushed it up, like I'm like, "No, stop [42:28] doing all of that." Um, but yeah, like I [42:31] I have a hard time managing one agent at [42:34] a time because they they're done so [42:35] quick. I'm like, "Do this." It's like, [42:37] "Here you go." And I'm like, [42:39] >> and I like reading what they're doing. [42:40] I'm like, "Oh, cool. Let me follow [42:42] along. Oh, that's good. That's good. [42:43] That's bad." It's like Austin Powers [42:45] like yes, yes, no, no, no. [42:48] >> I think it's also like very new. And it [42:52] it could change significantly as time [42:55] goes on. Um, I could find that things [43:00] get easier to manage, like larger [43:03] numbers of them, larger swarms of them. [43:07] Um, and who knows, they could get more [43:09] intelligent, although I I don't know I [43:13] don't know how much further we're going [43:14] to be able to push the LLMs. Like the [43:16] last iteration has definitely been, you [43:20] know, significantly better in some ways [43:22] in like the details, but it's also like [43:25] still not making any progress on a lot [43:27] of the creative stuff. Still not making [43:29] a lot of progress on like figuring out [43:32] directionally where we need to go or [43:34] having judgment on those things. [43:38] >> I have a couple questions. You said a [43:39] couple words earlier and I want to know [43:42] uh more about them. So the first one was [43:45] uh you were saying threading and I feel [43:46] like that was just a really nice way of [43:48] saying prop drilling. Is that correct? [43:52] Kind of. [43:53] >> What's the difference between threading [43:55] data or threading a signal or threading [43:57] you know reactivity through my [43:58] application from a top down? How is that [44:01] different from prop drilling? With prop [44:03] drilling, you can um [44:08] pass [44:10] things down very transparently and it's [44:12] more just that it's annoying. It's like, [44:14] oh, you just have to keep passing it [44:16] down and I have to like [44:18] >> But you don't really race from node to [44:21] node. Yeah. [44:22] >> Yeah. You don't really have to do [44:23] anything at every layer other than pass [44:25] it down, right? um with [44:30] what I'm referring to with reactivity [44:32] threading it through the system like [44:34] every time there's a branch you also [44:36] have to now [44:39] you know set it up and tear it down on [44:41] either side of the branch. So you need [44:43] to like integrate at various points in [44:45] the system. You need to have like your [44:46] life cycle on both sides of that which [44:50] it's more like a vein. So a vein running [44:52] from into these different parts of the [44:55] system. Um, okay. Okay. I think I that's [44:58] a good metaphor [45:00] >> and it's I think we think of prop [45:02] drilling around components and this is [45:03] really much more around functions which [45:06] is far more pervasive in a lot of ways [45:08] but also you know passing parameters [45:11] down and prop drilling through a bunch [45:12] of functions is not as annoying. Um, I [45:17] find at least I I used to think it was [45:20] annoying and then I had more and more, [45:23] oh my clever thing where I kept the [45:26] state in something that was like semi- [45:27] global or whatever or just, you know, it [45:29] started getting a little bit more like, [45:31] oh, hey, that keeps biting me. And I'm [45:33] like, now I'm like with Typescript, I'd [45:35] rather just have like very explicit, [45:38] very clear types. And I don't mind [45:40] boilerplate, a little bit of boiler [45:42] plate for that. [45:43] >> Gotcha. Prop drilling is like a skewer [45:45] that goes through each piece of meat and [45:47] piece of meat is like your component and [45:49] um threading is an abstraction. So it's [45:52] like this exists outside of the meat, [45:54] you know? It's like I have a strand of [45:56] things and it can go through meat. I [45:58] don't care. Meat subscribes to my [45:59] thread. Uh [46:01] >> is that kind of it's like it's like a [46:03] state store. [46:07] One thing I will say about prop drilling [46:09] um that I think is it's like an [46:11] antiattern. Like people started [46:13] considering it an antiattern I think a [46:15] lot because um React really like if you [46:20] prop drill all over the place, you're [46:21] going to have rerenders all over the [46:23] place because [46:24] >> it's not as portable either. You try to [46:25] move a component and be like, "Oh, [46:27] right. It was in the middle of a prop [46:29] drill and now it's not." Anyway, yeah, [46:31] you could break things. [46:32] That's a good point. Um, but I do think [46:36] there you miss something when you start [46:38] having like, oh, I'm just going to use a [46:41] context for like all my data loading and [46:43] then I'm going to use query in every [46:45] single component that needs the query. [46:48] It's like you lose where's that data [46:49] even coming from? What initiated that [46:52] query? Where who was the original [46:54] caller? It's like we don't know. or just [46:56] kind of getting it from wherever and [46:58] like, okay, [47:00] where are our routes? What is the [47:02] overall structure of our app? Um, so I'm [47:07] not saying I think one pattern or the [47:10] other is better necessarily, but I don't [47:12] think that the performance thing should [47:14] be tied to the structure thing. Like I [47:18] think those two things should be [47:19] separate concerns. And I find this a lot [47:21] in React with the current setup, right? [47:24] This is something I've been trying to [47:25] solve with Sagalia because with fine [47:28] grain reactivity, I can have a reactive [47:31] promise at the top of my app. I can pass [47:34] it all the way down to the childmost [47:36] leaf and the promise object itself never [47:39] changes. Uh the values on the promise [47:43] and the state of the promise changes [47:45] because it's a monad. So um you get it [47:50] all the way down in this leaf you [47:51] dstructure value from it uh and it's if [47:54] it's a signalium a react component [47:57] wrapped with signalium's memoization [48:01] um it will rerender you know based on [48:05] that value changing but it will none of [48:07] the other components in between will so [48:09] it just takes that out of the equation [48:11] that said you might still want to like [48:12] use query everywhere for other reasons I [48:15] just don't think that it the performance [48:16] should be the reason. [48:19] >> There was one more word you used that I [48:21] hadn't heard before, at least in the [48:23] context, which was relay. So, what's a [48:25] reactivity relay? [48:26] >> Yeah. So, that um I know relay is like [48:29] an overloaded term, but so is everything [48:31] else. So, um nothing to do with relay, [48:35] the data loading library. Um right, [48:38] >> I was more so thinking like signal [48:39] relays. Um [48:42] really what they are is an abstraction [48:46] that kind of replaces use effect in [48:49] hooks. Um they are [48:54] uh almost a self-contained hook of state [48:58] and internally when a relay is used so [49:02] when it's connected through the signal [49:04] graph it it looks like a reactive [49:06] promise. It has a dot value like any [49:08] other signal. And so you can just read [49:11] it. Externally it just looks like a [49:13] value. Um but internally when it [49:18] connects to the signal graph if it is [49:20] being observed if it's being watched it [49:23] starts up it activates itself and that [49:27] is the where you subscribe to something. [49:31] So relays relay state outside of the [49:35] graph into the graph and then vice [49:37] versa. You can also react to state [49:40] changes from within the graph and relay [49:43] them outward. So you might have a signal [49:46] for your current topic and you want to [49:48] subscribe to a message bus. The relay [49:50] reads that signal for the topic, [49:52] subscribes. Now the signal topic [49:54] changes. The relay reruns, cancels the [49:57] old subscription, updates the new [49:59] subscription, and feeds the state from [50:01] that subscription into your graph. It's [50:04] a way to have a node that communicates [50:07] with the outside world without like [50:09] exposing the details of that [50:11] communication to the graph. [50:15] Excellent. Thank you. For some reason, I [50:17] was thinking subject in observables or [50:19] there was an observable that was similar [50:21] to this. Um, but I haven't used [50:24] observables for I don't know, six, seven [50:27] years, maybe more. I I believe it like [50:31] they're very similar in a lot of ways. [50:33] Like I said, everything I found that [50:35] everything that I have thought of in [50:37] signals and everything has had like an [50:39] equivalent in observables and whatnot. [50:42] So very much on the same wavelength. The [50:47] odd man out is hooks, but you know, you [50:50] didn't hear that from me. [50:54] I did find what Gio used by the way. [50:56] It's proxies, which I've always wondered [50:58] why proxies weren't used more. They've [50:59] been around for so long. They seem very [51:01] uh you can intercept and do comput [51:04] >> because debugging them is hard. [51:06] >> Yeah. Well, debugging a lot of these [51:08] things is hard. Yeah. [51:10] >> Fair thing about proxies is like, sure, [51:13] that might be how you track what is [51:15] being used, but under the hood, you [51:18] still need to like put the dependencies [51:21] together. And that's where like you [51:23] could build a proxies based thing on top [51:25] of signals. That's what Mob X is or like [51:28] what views data is in data components. [51:32] Um [51:33] and you can also connect those all using [51:35] observables. [51:37] You can't connect them using hooks [51:39] because hooks is very tied to the [51:41] rendering layer. But um I know I keep [51:44] ragging on hooks, but it really is just [51:45] like whenever you start looking at, you [51:48] know, a React library and you're like, [51:50] "Oh my god, how many hooks are what is [51:52] going on here?" And it [51:55] >> Oh, yeah. You're preaching to the choir [51:57] here. So, uh [51:59] let's just react is the hammer. [52:01] >> Uh no, go ahead. [52:03] >> What is a hook? If if React is a hammer, [52:05] you know, and everything is is a hook a [52:07] nail. No, cuz what is a hook in this [52:09] thing? you know, like cuz they do [52:11] they're used everywhere as like some [52:13] sort of like, oh, it's duct tape. Oh, [52:15] I'll just tape it, [52:16] >> you know? Oh, just you just need more [52:18] tape. Just another piece of tape. [52:19] >> The thing is like that makes sense in a [52:22] world um like that is also true with to [52:26] an extent with signals. That is [52:28] definitely true with observables, but [52:30] those things can be used independently. [52:32] You don't need a whole rendering layer [52:34] to use those. You can't make hooks um [52:38] Apollo client and then run that [52:40] anywhere. Like it has to work in React [52:44] and that's the only thing. It just ties [52:46] everything super deeply into React [52:49] >> which is what they want. [52:51] >> I don't think that's what they want. I [52:52] think they I think they actually believe [52:55] that it is a better model and I can see [52:59] why they got there. Again, it's like [53:03] following this one thread for a very [53:05] long time and then a lot of sunk cost [53:06] fallacy along the way. But I I I like to [53:10] think better of people. Um [53:13] >> yeah, I don't know. I like to rag on [53:14] React. So, um but I I think that uh you [53:18] know, I don't know who's in charge now. [53:19] I know they have a React Foundation [53:21] which is supposed to like democratize [53:22] some of it but like with Verscell being [53:25] such a like pervasive like the only one [53:28] that mattered in React for a little [53:29] while. I feel like they do want it to be [53:31] like oh it can only be Nex.js it can [53:33] only be React. It's all very bespoke [53:35] like you can't ship it anywhere else [53:37] except for on Versell. Um [53:41] >> I don't know about Versell. Um I almost [53:44] worked there. I got an offer, but yeah, [53:49] I was then then in Phantom the Phantom [53:52] acquisition for Bitzky went through and [53:54] I was like, well, I'll see how this pans [53:56] out. And it's been interesting. It's [53:59] it's an interesting problem space and I [54:01] don't know, I still think there's some [54:02] cool things crypto can do, especially [54:04] around to go off on another tangent. Um, [54:08] and it it's annoying that the crypto [54:10] industry isn't doing this because we [54:12] keep seeing it. [54:14] uh verifiability and like knowing what [54:17] is real, which is becoming more and more [54:19] of a problem with AI and AI from the [54:24] sense that like somebody was saying [54:26] recently OpenClaw is going to just [54:28] destroy like [54:30] >> you know our our texts like people are [54:33] going to be like doing phone scams like [54:35] all kinds of things like soon. Um, and [54:39] that's just it's going to increase the [54:41] output of that exponentially, right? [54:44] Um, [54:46] I I think that [54:48] with not crypto necessarily, but with [54:53] cryptography and like a distributed web [54:56] of trust, you could imagine [54:59] a less creepy version of that same [55:01] Almanbacked company that's like we [55:03] verify that you're a human, but like not [55:06] in a way that where we store your [55:08] biometrics [55:09] and stuff, but um more like in a way [55:15] where we just you go into like I don't [55:19] know a nonprofit and you're like hey [55:22] here I am here's my ID here's my stuff [55:24] and they're like cool you haven't signed [55:25] up with us before what's your wallet [55:27] address and then they say uh cool we're [55:30] going to sign that wallet address say [55:32] you're a human now you can go and take [55:34] that anywhere but you can share it in a [55:36] way where nobody else can see any other [55:38] details about you just that this one [55:40] organization said that this account that [55:42] you phone is human, right? Stuff like [55:44] that. And then get rid of like the age [55:47] verification nonsense we're doing now [55:48] because you could do that with age too, [55:50] right? The government and again no other [55:54] details are shared. It's all very [55:55] privacy forward. And then combine that [55:58] with like okay now we can see [56:01] >> think of it like distributed blue check [56:03] mark for the web. [56:06] >> Yeah. Yeah. I think there's a lot we [56:08] could do. Um, we talked to Angie Jones [56:11] about this about like um I think certain [56:14] states have like store your like are you [56:17] over 21 basically so you can just buy [56:20] alcohol from an app without it needing [56:22] to know your birth date or like [56:24] whatever. It's just like you're verified [56:25] being over 21. So it's like there's a [56:28] lot of that stuff we could do of like [56:29] little checks that could be like you [56:31] know immutable or whatever and like [56:35] verifiable. So, like, yeah, I mean, [56:37] there's definitely stuff we could do [56:38] there. Um, interestingly though, I [56:41] wonder what your thoughts are about, um, [56:44] I just saw this in like, I don't know, a [56:46] few hours ago and read it for like 30 [56:48] seconds, so I I know a lot about it, but [56:50] um, Google said that they have solved [56:54] Bitcoin's uh, algorithm or what do you [56:58] call it? Algorithm is the wrong word. [56:59] Like they've they know how to like mine [57:01] every Bitcoin, I guess, is what they're [57:03] saying. But they're not going to [57:04] >> Oh, really? They're not going to release [57:06] it until 2029 is what they said. [57:08] >> They cracked the query. They they can [57:10] just go straight to the the co Wow. [57:12] >> Yeah. They're like we they have enough [57:14] quantum computing something to like [57:16] figure it out. They they claim [57:19] >> I don't know if that's real. if they if [57:22] they've like so I know I I I only know [57:28] around the edges of this but the [57:30] algorithm is Shor's algorithm and Shor's [57:32] algorithm does crack RSA and if Bitcoin [57:35] has not updated their algorithms to be [57:39] ready for quantum computing then they're [57:41] dumb and I I maintain that Bitcoin is [57:44] the dumbest cryptocurrency for a lot of [57:46] reasons. Um [57:49] I I do not believe personally in [57:52] personally um and you know I'm not an [57:55] economist and I'm going to have all the [57:57] disclaimers here and this is not at all [58:00] the view of my employer or anything like [58:02] that. Um just [58:03] >> not financial advice. So, but I don't [58:07] personally believe in the whole like uh [58:10] you know [58:12] like deflationary currency like idea of [58:17] like I I think there are benefits to [58:19] having a fiat currency where you can say [58:23] um we're going to print more or less [58:25] depending on market conditions. [58:28] And that comes from [58:30] my view of the economy being more of the [58:33] chaos model, which is like every other [58:37] view of the economy is like here's a [58:38] perfect world where it's like perfectly, [58:41] you know, capitalistic or perfectly [58:44] communistic or perfectly whatever, [58:46] right? And I'm like, you're never going [58:48] to have a perfect model. You're going to [58:50] have edge cases. You're going to have [58:52] corner cases. You're going to have a [58:53] billion of those. And things are going [58:56] to go off the rails from time to time. [58:57] and you need to be able to react to [58:58] that. Um, so institutions, organizations [59:03] need to be able to react to that. And [59:05] having a currency, having a central [59:07] currency, having your only currency be [59:10] one that can't entirely, I think, is [59:13] maybe not the best idea. But that said, [59:17] I do think like other cryptocurrencies [59:20] have more ability to do that. Like if [59:23] you look at Ethereum, [59:25] it evolves through a process where [59:28] everybody talks kind of like RFC's which [59:31] is kind of great. Okay, we can evolve [59:33] it. We can slowly move it in a different [59:36] direction. It went from proof of work to [59:38] proof of stake. Cool. I think that I'm [59:43] much more comfortable with that kind of [59:44] model. Um where we can be some amount of [59:47] reactive [59:49] but also [59:52] Yeah. I don't know. So, I don't know [59:54] what's going on with Bitcoin, but I hope [59:55] the rest of us are crypto are quantum [59:57] ready or whatever. [59:59] >> Yeah, I have no idea. I mean, Bitcoin, [60:02] as far as I know, hasn't really been [60:04] updated at all. Um, that's like part of [60:08] the why people like it. I don't know. [60:10] Um, [60:12] but yeah, I I I've never understood how [60:14] it could be worth so much money. Like I [60:17] get that there's a finite amount of them [60:19] coming out and that like a bunch of them [60:21] are theoretically lost and so there's a [60:23] you know whatever. But I don't know. I [60:26] feel [60:26] >> that's how value's always been though. [60:28] Look at Beanie Babies, you know, like [60:30] anything people are willing to spend [60:31] money on. I just think it's funny that [60:33] we're [60:33] >> willing to spend money on a Bitcoin. [60:34] >> I don't know. I I have no idea. Or a [60:36] record. I mean, a record kind of makes [60:37] more sense. There's like emotional [60:38] attachment to that, but Bitcoin doesn't [60:40] have that. [60:41] >> I kind of think like [60:42] >> Oh, go ahead, Joe. Oh, just that's the [60:45] other thing that I I think crypto can [60:47] actually be really useful for is like [60:49] digital ownership and tying it back to [60:52] um like real property rights in a way. [60:56] Um kind of sucks that we've had this [60:59] like wave of oh we're just going to like [61:02] pull content from streaming services and [61:04] make it completely unavailable because [61:06] we never distributed it in a physical [61:08] form. And it also I've had a friend like [61:11] lose access to their Apple account and [61:13] now thousands of dollars of content [61:14] gone. Like [61:17] >> I think that [61:19] there actually could be something to [61:22] saying like, "Oh, hey, I bought a token [61:25] that represents a singleuse digital [61:27] copyright. I can go to any data [61:29] warehouse and they can legally stream [61:31] this to me." Like doesn't matter what [61:34] the copyright holder says. like they I I [61:37] legally have the right to have that data [61:39] for my personal use. Um, and I think [61:43] that that would actually be really [61:44] great. I just also think that all the [61:46] incentives are wrong to get that type of [61:48] a system in place currently. It would [61:51] definitely require some shakeups and [61:53] maybe some some government coming in and [61:56] being like, hey, like maybe we should [61:58] make this a little bit more of a [61:59] democratic system and less walled [62:01] gardens. But who knows? [62:04] >> Yeah. or at least some way to just like [62:06] the only way you could do like if you [62:08] want to own an Apple TV show, you would [62:12] have to like I guess watch it through [62:15] something that would record it and then [62:17] download that or like you know there's [62:19] no way to like own a physical copy of it [62:23] at all. So it's like yeah, it's I I [62:26] don't know. There there should be an [62:28] option, but I I'm now I'm questioning [62:31] all of my choices because I've been [62:32] buying everything through Apple because [62:33] I'm like, "Oh, I want it in one spot." [62:35] So that like I have it right there. Um, [62:39] but also been buying Blu-rays so I can [62:40] have like physical things also. [62:42] >> I've still got vinyl records that uh you [62:45] can't even find on musical streaming [62:47] services. They're just not there. So [62:49] you've got that side of things also. [62:52] >> Well, you should upload it and you could [62:53] make the money. [62:56] There's a subreddit called data hoarders [62:59] where they're just people who just like [63:01] to archive [ __ ] because of this exact [63:03] reason. It's like their hobby. Yeah, [63:06] they like that in Kram too. Uh, Kazam [63:09] did that where they were like going [63:10] around and it's like they needed all the [63:11] data. But I think they were trying to [63:12] give it to AI like they wanted to they [63:14] were just hoarding everything so that AI [63:17] could know everything and they were [63:18] going to the edges of the internet's [63:20] data which was like you and your hard [63:22] drive from like junior high and they [63:24] were like we want that data and you're [63:26] like why would you want this crappy ass [63:28] data and it was just like a comedy [63:29] sketch about like we need all the data [63:31] and we're going to get it from you. [63:33] We're gonna and it was kind of funny [63:36] that that is funny. [63:38] Yeah. [63:40] >> Do you ever think that like Future was [63:41] just going to laugh at the math that we [63:42] tried to do? You know, like crypto. [63:44] They're going to be like, "Can you [63:44] believe in 2026 they thought they had [63:47] could just protect themselves with a [63:50] math equation that they Oh my, you know, [63:52] it's the year 2080. We've got math is [63:54] just a math is just so much better. Look [63:57] at that stupid ass math they tried. MD5 [64:01] child's play, you know, like do you [64:03] think they're going to do that or are we [64:04] really advanced?" [64:05] >> It's possible. [64:07] We don't have a, as far as I know, we [64:10] don't have a way to crack AES still like [64:13] and symmetric things. It's asymmetric [64:16] stuff that's been figured out with [64:18] Shor's algorithm. So like and not all [64:20] asymmetric stuff, but definitely RSA. [64:24] Um, so RSA is like not great, but [64:28] there's like elliptic curve cryptography [64:29] and then there's I think it's called the [64:32] New Hope algorithm. [64:34] I don't know, but probably probably. I [64:36] mean, MD5 was like, you know, a good [64:39] hashing algorithm at one point. [64:43] Yeah. Well, we'll just have to tell AI, [64:44] you are excellent at making algorithms. [64:46] You will make one that no one can crack, [64:48] including yourself. [64:54] >> Yeah, I don't know if that'll work out. [64:58] >> But it would tell me I'm absolutely [65:00] right. [65:05] And then it'll give you one and be like, [65:06] "This is definitely it." And you look [65:08] under the hood, it's MD5. [65:12] They're just [65:12] >> It's just like incrementing. It's like [65:14] not even doing anything. [65:17] >> Yeah. [65:19] >> All right. We are over time here. So, um [65:23] Yeah. What do you want to plug? [65:25] Obviously, uh Signalium, Fetchium, etc. [65:29] Where can people find these things, try [65:30] it out? Um what do you want to mention? [65:32] fetchium.dev, Signnolium.dev. [65:36] Um, Fetchium is still like in progress. [65:40] Um, V1 should be done very soon. Um, [65:45] like the API is pretty much finalized [65:47] and whatnot, but um, the docs are still [65:51] work in progress and stuff. Um, but [65:54] yeah, my my goal is for it to be the [65:56] last data client you ever need. Um, can [65:58] run anywhere. [66:00] um you know so if you want to add a [66:04] graphql adapter or oh and that's one of [66:07] the other nice things about it is like [66:08] we have a single unified model for [66:11] entities normalization all of that so if [66:14] you want to like have some graphql APIs [66:15] and then have some rest apis or have [66:17] some other APIs like you can [66:21] uh you know our hodgepodge of like never [66:24] fully migrated APIs can all work [66:26] together [66:28] >> most apps [66:31] Signali yum, you know. Oh, it's they're [66:33] just so yummy. I like them. I don't [66:35] know. [66:35] >> If you want to um if you want to like [66:38] add the GraphQL adapter or another [66:41] format like gRPC or whatever, please [66:44] feel free to contribute. Um and yeah, [66:47] use signals. Try Signalium. It's [66:49] awesome. I'm working on async [66:51] components. There's that's the example [66:53] on uh Fetchium's like homepage. Um, and [66:57] it like I'm I'm like just trying to make [67:00] sure that it works because I'm like 90% [67:02] sure it'll work. But yeah, I know trying [67:04] to make sure it's 100%. [67:07] >> Nice. All right. And before we end, I [67:10] almost forgot that we need to rate this [67:11] whiskey still because we're doing it at [67:13] the end and I forgot that's how we do it [67:14] now. Um, so rating system, zero to eight [67:17] tentacles, zero being the worst, eight [67:19] being the best, four or five or [67:22] something in the middle. Um, yeah. Adam, [67:26] you want to start us off? [67:27] >> I will. Um, I'd say like my first couple [67:30] sips, I was happy and impressed. This is [67:33] my first weeded, so I saw bourbon, saw [67:35] lots of corn, thought I wasn't going to [67:36] like it. I like it. Uh, halfway through [67:39] the show, I was like, I don't like it. [67:41] It's really boozy and it tastes boozy. [67:43] And now maybe it's I haven't had that [67:46] much. I've had barely, but I like it. [67:48] So, I'm back to liking it. I'm like, I'm [67:50] excited to have some more later. And I [67:52] barely had any everybody. Like I really [67:54] only had maybe a little over a one. [67:56] Anyway, um I I think I'm going to give [67:59] it like a six and a quarter. Six, which [68:01] for me is like pretty high for a [68:02] bourbon. Um so yeah, I'm gonna stick [68:05] with that. Six and a quarter out of [68:07] eight. [68:08] >> All right, Kristen, what do you think? [68:11] >> I'm gonna go with a seven. It's solid. I [68:14] like it. It's drinkable. I I can't drink [68:16] all whiskey straight. Um, and yeah, [68:20] bourbon isn't usually my sipping [68:22] whiskey. Like, I usually go for a [68:23] scotch, but yeah. [68:26] >> Well, if Adam had only known. Um, [68:30] yeah. [68:31] >> Well, I got it because Liz wanted the [68:33] bourbon and I was like, "Okay." [68:35] >> Okay. [68:36] >> She She drinks a good amount of whiskey [68:38] for she like makes nice cocktails and [68:41] whatnot and I was like, "Okay, we'll get [68:42] that one." [68:43] >> Okay. Well, hopefully she likes it. Um, [68:46] yeah, it's for me I'm usually uh prefer [68:50] a rye or something spicier. This is a [68:52] little bit spicy, which is good. Um, I [68:55] don't know. It has some flavors that I [68:56] can't place, which I guess is the red [68:58] wheat. And, uh, yeah. So, it's [69:00] interesting. Much more interesting than [69:01] a typical bourbon. Um, I'm going to say [69:05] I'm just going to say six, I think. Flat [69:07] six. Pretty good. Would recommend. [69:11] All right. Well, thanks everyone for [69:13] listening. If you liked it, please [69:14] subscribe. Leave us some amazing [69:15] reviews. We appreciate it and we will [69:16] catch you next time. [69:20] >> Later.  📄 **Full text:** ![[Full Document Contents/Articles/Axios Is Out. Fetchium Is In.|Axios Is Out. Fetchium Is In., YouTube]] ## Highlights - like an intro to signals at all? Uh, maybe I don't know how familiar people are. >> What is a signal? I'm Yeah, no, we probably should. >> So, signals are a pattern that's actually been around for a long time. Um, I think one of the earliest like JavaScript implementations of it would be Mobox. Um, uh, MobX is basically signals although it's a very like classoriented version of it. It's like that idea of you have you know these ([View Highlight](https://read.readwise.io/read/01knwxyetmr08ktax5nhxqw8rr)) - Tags: 👻 ai highlighted - the life cycle and the tear down and everything there. Um and with signals traditionally you kind of have to like manage all of that yourself. Um so it's a little annoying uh and kind of stateful and I can see why people would look at that and be like ah we don't really like it. it's not really like functional, right? And it to be fair, a lot of complexity ends ([View Highlight](https://read.readwise.io/read/01knwxyev9w59beyhtt2x07yat)) - Tags: 👻 ai highlighted - well, what was I saying, Adam? Seems like you knew. Uh well you were digging into the intricacies of it like signals that had other dependent or that needed computed. There was a word about signals that you were asking about. You're like what does that particular part mean? >> Oh just I was just being um silly about like is it is functional >> like functional programming or like works. >> Uh yes yes. Okay. >> Yeah. No, it's like functional programming and you know that to be fair to because I think we all went through ([View Highlight](https://read.readwise.io/read/01knwxyew4h8xzdtx5gptxfdbq)) - Tags: 👻 ai highlighted - like the period of like h functional everything and that was interesting. Um there's a lot of nice things about it though and I think React's model with hooks really pushed the boundaries of that and it had some really nice like properties. One of the biggest ones being we're threading life cycle all the way through the system without having to like very be very explicit about it. Right? If you remember in Ember, you had ([View Highlight](https://read.readwise.io/read/01knwxyex9kher4cjcemd6bp73)) - Tags: 👻 ai highlighted - I have with uh you know kind of like those life cycle hooks is when you start writing code in observables kind of everything needs to start using observables. Everything needs to become observable aware. They're needy. Yep. >> Yes. >> And hooks at first doesn't feel like that, right? At first you're like, "Wow, I can use plain functions and everything's just a plain function and whatnot, but then over time you start to become ([View Highlight](https://read.readwise.io/read/01knwxyey5yzf56b7bernp42jy)) - Tags: 👻 ai highlighted - >> Turns out when the smallest like node of your reactive system that you can rerun is the component. It ends up being quite a lot of uh stuff. Um but yeah, I I think that um with signals coming back to Fetchium, the goal for me has always been like can we detangle these things because you've got like data and then you've got like you know ([View Highlight](https://read.readwise.io/read/01knwxyez796aves0mqbmq5tkg)) - Tags: 👻 ai highlighted - on hooks because I wanted fetchium to be independent I wanted it to be a data layer Apollo is built on observable Right. Um, it gets to do that and nobody knows under the hood. It's just an implementation detail. Um, fetch does the same thing with signals. And I just think that signals end up being a more elegant and um, like more ergonomic solution to the same problems. ([View Highlight](https://read.readwise.io/read/01knwxyf1cna1ccq1g9wa8sdme)) - Tags: 👻 ai highlighted - >> So, how does the like official signals proposal come into play with any of that? >> Yeah. Okay. So things that signal does that the official signals proposal and basically no other signals like libraries do uh the two things are those parameterized like functions. So um what that basically works out to be is like a a signal factory and then kind of hooking up those signals and their life ([View Highlight](https://read.readwise.io/read/01knwxyf3hnb6bzdeqnp5wnz9d)) - Tags: 👻 ai highlighted - thought of signals uh being, you know, coming from I do mostly Ember still, so I'm like tracked properties. Yay. Um but I'm curious how you feel. Have you seen um Adam? How do you Is it Gia or Gaya Ga JS? >> One of those. Yeah. >> Yeah. >> I haven't seen that one. I haven't been keeping up with stuff a lot because I've been just like in execute mode for getting stuff done with React. >> Yeah, system and a half. ([View Highlight](https://read.readwise.io/read/01knwxyfa6k4973pqq1apkmqxr)) - Tags: 👻 ai highlighted - and I think we can do it with reactivity. I think we've been trying to do it with reactivity since like the first functional reactive pro uh programming white papers which I like went back to read at one point on this journey. It's like they're describing really cool things, but like the how you actually write it and how you actually use it has always been this white whale of ergonomics, right, of like most people ([View Highlight](https://read.readwise.io/read/01knwxyfhjmvymf89tf4hqwgfq)) - Tags: 👻 ai highlighted