Ryan Carniato - VIDEO FEED === Noel: ~Hello and welcome to Pod Rocket, a web development podcast brought to you by Log Rocket.~ ~Log. Rocket provides AI first session, replay, and analytics, which surface the UX and technical issues impacting user experiences. Start understanding where your users are struggling by trying it free@logrocket.com. I'm Noel, and today we're joined once again by Ryan Cardo, creator of Solid js. Uh, he's here to talk about a recent blog post called A decade of Solid js.~[00:00:00] Welcome back, Ryan. How's it going? Ryan: Hi. Glad to be back. It's definitely been a little while, but, uh, Noel: yeah, like years, I think, I think it's been a couple years. I don't, I don't remember exactly what the context was last time we chatted, but uh, Ryan: ~probab~ Noel: ~yeah.~ Ryan: probably solid start. Probably. It was probably like just before solid start came out around that, so, so, yeah, just about a year. Yeah, Noel: Yeah, yeah, yeah. Yeah. Very cool. Um, yeah, this, this blog post is an interesting one. It's kind of a, like a, a reflection on your journey and, you know, solids, solids path here and kinda your relationship with it and the framework, community and open source in general, and all this stuff. Um, why did you think now was kind of a good time to, to push this out and get this out there? Ryan: Yeah. Yeah. I don't know. I mean, to be fair, uh, it, it hasn't quite been. years yet. Um, it'll be 10 years, like this summer, but, uh, I, it was, it, it had been exactly seven years from when I open sourced the library. That's Noel: I Ryan: got me thinking about Noel: see. Ryan: Like [00:01:00] when most people, not most people, but some people started becoming aware of solid. But I, I'd started working on solid. Before that, uh, seven years still marks a long time. Uh, Noel: Yeah. Ryan: sitting, uh, in, it was actually on my birthday earlier in the year in February and realizing that it had almost been seven years, Noel: Mm-hmm. Ryan: since I open sourced it and that it was like my birthday was the day that. The gap between when I first open source, solid till present day, um, was the same, had finally exceeded. Um, the gap between when jQuery was re-released Noel: Oh yeah, yeah. Ryan: React was released. Um, like that's a long time in web development. Noel: That's, that's wild. Yeah. Ryan: because you know, people picture jQuery and then they picture react and there was like a whole error in between. Noel: Mm-hmm. Ryan: and. Uh, this year, solid's been around for that long, Noel: Yeah. Yeah, that is always, that's always like an interesting exercise personally. But yeah, I hadn't, I hadn't [00:02:00] done this, done this in like the, in the web tooling framework world. 'cause you're right, like jQuery feels so, so much, so much older than like, you know, react in that and that way of, um, I. It's interesting to think like, do you think that there's this, this kind of, this kind of slowing of, of the tool landscape at large is, is a, is a like a product of kind of the, the maturing, the ecosystem maturing? Um, or do you think there's something like that kind of was really struck there with react that's kind of caused this, this era to be a little bit more stable. Ryan: Yeah, I, I think it's, it's mostly a function of maturing, right? Like there was a lot of stuff back when I was getting into this and, you know, web development and even like, you know, I. Getting into re getting into JavaScript. I spent some time on the backend after, like in the early two thousands when I got back into the JavaScript around 2009, 2010. Noel: Yeah. Ryan: we, we had new libraries, new frameworks all the time. And [00:03:00] even after React the first few years, it was still very fast. I think Noel: It was, yeah. Ryan: naturally were looking for, um, something they could trust. The, the thing is as applications and requirements get more, um. I'm not gonna say just complicated, but like, like the whole quality expectation goes up, Noel: Mm-hmm. Ryan: to want to, expect more out of your tools and you don't want to keep on shifting it. Just bigger projects, you know, more at stake there. was kind of natural that things would slow down. Um. Noel: Yeah. Yeah. I, I, I, I, I, I don't, I don't find it super surprising either, I guess. But I do, I do think it is interesting now because I think, I think that there, there was kind of a point where we were churning through things very quickly and then, then something happened. And like now, now there are still several paths, but they seem to all kind of be, I. Running in parallel and there's like still a big react community, there's a big view community, you know, there's a big S felt community and there's a solid community. Like what, why do you think that these [00:04:00] like kind of are all, are all running with such steam behind them when before it really felt like devs were kind of ju more eager to jump ship and like find the new thing to clinging to. Ryan: I mean, part of it is that desire for maturity. I think what part of it came in too is like. lot more new web developers over time. Um, and this continues to grow. And I think that like we saw a whole generation of people on the web whose entry point was at a different place, right? Like when I started, um, you know, back, uh, we had HTML, um, we had like no one. kind of used JavaScript maybe for something novel, but you had like Scripts and CGI bins and like, Noel: Yeah. Ryan: like it was kind of really rough and um, you know, things. We, you kinda expected to put things together? I think there's been a whole generation, um, you know, since declarative frameworks where people came out and react was that first introduction [00:05:00] to the web. Noel: Mm-hmm. Ryan: so even if you were gonna pick a different solution, it's still gonna kind of resemble I. That somewhat, like you're just like, that's kinda the expectation. And then know, it, we went from that being like an app framework, right? React was built for apps. Noel: Mm-hmm. Ryan: for, you know, highly interactive things to people going, okay, well this is the web. How do I build my static site? And they're just like, I, I know react and like, it it, you know, this kind of universality continued onwards. And I, I think that's kind of why, um. Like, that's not why there's like camps per se, but that's, that's part of that kind of slow down. And where there's not that as much expectation on, uh, exploration because like the baseline, the bo the, the, the ground floor, the abstraction has already been set. People aren't, weren't really peeking under the hood anymore. Um, that's why I think a, we went from that phase where it was a lot of different frameworks and stuff all through 2009 through 2000, [00:06:00] I wanna say 14, Noel: 14 would. Yeah, 14 was gonna be my number too. Ryan: Right, because React came out in 2013. It did take a, a year or two after React for the com completely cement over, but to like the focus of frameworks being on like different things. It's like instead of being like, oh, here's all my different, you know, I. do things this way or these novel things. It was a real DX focus kind of Noel: Mm. Ryan: only new frameworks coming out, um, after 2015 for at least the next three or four years. It's felt like we're ones that focused on a different developer experience. We offer something different than React because we have templates or we have, you know, our HL with our CSS or what, like Noel: Yeah. Ryan: it was like very much a developer experience focus, Noel: Hmm. Ryan: like. The, the vibes you get off Noel: Yeah. Ryan: as Rich Harris would, would, would go later on to say, and I think, um, that was because people didn't want to like, think about something like too different. It was kinda like JavaScript, JavaScript fatigue came in where [00:07:00] people were Noel: Yeah. Ryan: of different libraries and stuff. But 2016 people were like, were not interested in new frameworks anymore, really. Noel: Mm-hmm. Ryan: even though. continued to be built and you know, a few of them were lucky enough to be successful. Um, Noel: Yeah. Ryan: speaking, the, the maturing had started, this whole kinda shift had happened and, uh, frameworks started targeting like the entry funnel. They started looking at like, how do I get adoption? How do I get people to like, you know, look at this and want to use it. Noel: Mm-hmm. Ryan: was much, I mean, that's already a much more mature place if you, it's not just a bunch of people with their technology. It's like marketing. Noel: Yeah. Yeah. It's like, yeah, that we were, we, we hit it, we hit an arrow where you could really like market at the dev experience, right? And like make it like target the developer to convince them. So this is, I feel like this is as good a as good of kind of a. A framework, a foundation for our conversation is anything then, so stepping into this, like whatever, seven and change years ago, what, what was like your [00:08:00] mo your main motivation to kind of, and, and, and, and you know, like what, what, what, what made you optimistic enough to kind of get this out in front of the world and open source it? When, when everybody was so, you know, kind of entrenched in, entrenched in React. Ryan: I mean, at first, I, I wasn't, I, it took me a long time. That's why I, I wrote, like in this article, I, I'd been playing around with stuff like this 2015. I mean, for me, like I actually had tried to build some stuff with. Other framework tools and like use web components like back as far as like Noel: Yeah. Ryan: 14. So I spent a lot of time doing web component, open source stuff, like nothing really popular, but I made a few libraries and did some stuff in my, my company I was working at at the time. But like, it was around 2015 when I realized that React, um, had won, like, it was kinda obvious and I was like, it wasn't about marketing or adoption Noel: Yeah. Ryan: for me. I was like, um, I don't like this. I mean, I, I, I react is right. I had to like. Admit that there was a [00:09:00] lot of mess in like knockout, which was my favorite tool at the time. Noel: Yeah, yeah. Yeah. I, mm-hmm. Ryan: like, and no one was updating it anymore. Like it, it, it kind of died out. And I, I like, they were right. There was a lot of things that were unpredictable and magical. Perhaps Noel: Yeah. Ryan: which is hilarious by modern standards because, Noel: Yeah. Ryan: everything is magical now by modern standards. Noel: the level of magic we're okay with is much higher now than it was then. Yeah. Yeah. Ryan: it was because for a while I thought it was, um, yeah, I, I thought it was 'cause people understood stuff more like I thought that we'd grown as a community and matured and understood our technology more and the magic was gone and that's why we could go to higher levels of abstraction. But sometimes these days, I actually think it's just like, the expectation now is just that the magic is there and I don't need to understand it Noel: Mm. Ryan: It just all goes, you Noel: Yeah. Mm-hmm. Ryan: for me, uh, looking back at that time, I really like, [00:10:00] there, there's gotta be another way. I, I, I remember I, I mentioned this in the article, but I watched some like performance benchmarks, uh, especially one, uh, created by Ryan Florence. Um. Many people know, though, one of the co-creators of, uh, react Noel: Mm-hmm. Ryan: remix, it was a performance demo, um, around like ding, uh, like a stock ticker. And I just, I looked at this and I was like, I, no offense to Ryan, but I'm like, this is not a real app. Like, I, like it Noel: Yeah. Ryan: ludicrous to send like just tons and tons of data, like spam the page as fast as possible. And yeah, I mean React was pretty good at that, but I'm like. There was a whole bunch of things that I didn't picture react, you know, being as good at potentially, like, it just, there was no way that it was going to, if it's gonna re-render everything. I know this is a very mechanical thing, but I, I just like, I'm like, there were other options out there before and I, like, even libraries like that had some reactivity [00:11:00] like view that were coming out at the time we we're like, yeah, we got a v Om we're we, we got, you know, Noel: Mm-hmm. Ryan: plus v Om and I'm just like. Why V Dom? And was like, I felt like I needed to like do a sanity check. You know, Noel: Yeah. Ryan: the, I guess I start on the web too old, you know, before react, before you know, the modern thing. And I was just like, this, this is insane to me that, you know, we can just like accept that this is the, you know, only way. And yeah, so I, I, I made benchmarks, I did tests, I looked at every example. I tried to see if I could build a system that had. Was performant and ergonomic, had all the things that I liked, Noel: Mm-hmm. Ryan: you know, using knockout without, you know, some of the bad sides, you know, knock out the good parts. But more than that, actually having learned from stuff from React, like unidirectional flow, you know, things that may apps more maintainable. I mean, you, you don't need react, uh, to hit these kind of problems when you're building apps. React was popular for like introducing things like [00:12:00] flux, like better data Mm-hmm. but these best practices weren't. They reacts, design helped support them, but they weren't always encoded into React Like, like React did not ship a flux module. Noel: Right. Right. Ryan: it was just like best practices. React was always about best practices. And I'm like, well, why can't we have, you know, best practices that fit around other paradigms? They just Noel: Mm-hmm. Ryan: to be as well defined. React was really good at defining like. Um, sort of it's rules or it's mindset. Let you come in and be like, look, this is like, think immutable, think you know, functional, like think a, like this is how you wanna approach the problem. Not everyone does when they approach react, but Noel: Yeah. Ryan: creators at least had an idea and a direction, which is different than the frameworks before. 'cause the frameworks before were just like, look, the DOM updates Noel: Yeah. Right, Ryan: know, they didn't Noel: right, right. Yeah. Ryan: about, they were like, they were very mechanical, Noel: Mm-hmm. Ryan: like. Any, uh, product evolution standpoint, you know, starts with some kind of technology and then someone, you know, makes the, [00:13:00] uh, the, the Apple product, you know, they, they Noel: Yeah, Ryan: the iPhone and they're like, look, you guys may have had a touchscreen before, but this is a touchscreen Noel: yeah, yeah. Mm-hmm. Ryan: of like, like that for front end. Noel: Mm-hmm. Ryan: I immediately, I was like, I mean, yeah, I, I get it, but that doesn't mean that that's the only way to do it. Noel: Yeah. Right, right. Yeah. I think, I think this, this, this notion that like react kind of, I, it, it feels like even, even in the early days, react was very much, I. The, just the way in which it was, um, kind of, kind of built the way, the way that it felt intuitive to interact with it, very much pushed developers into these patterns that I think made it easier to work on, like larger teams that were collaborating on larger projects versus like going into every piece of your front end, like, oh, someone worked on this component. The way in which they handle like state management and everything was vastly different than some other part of the app. And I think react kind of like smoothed that over in a way that felt very nice. Ryan: Yeah. At least, at least in theory. I mean, it was, it was one of those interesting [00:14:00] things. 'cause like Angular also sought to solve that problem. And, and they did it by saying like, look, we have a library for everything. You Noel: Mm-hmm. Right? Ryan: a service, you wanna do this, here's a service. React wasn't quite as prescriptive in that sense, but Noel: Mm-hmm. Ryan: at least a philosophy, they had a direction and, you know, they're Noel: Yeah. Ryan: the, which is more than what a lot of solutions had at the time. It's, it's, Noel: Yeah. Ryan: ironic now that when we step way further in the future, Noel: Mm-hmm. Ryan: The fact that people did, you know, react had almost fashion because like even though it Noel: Yep. Ryan: principles, best practices change, Noel: Right. Ryan: this is what helps things evolve, that now when people look at React, they call it a mess. But it was actually very, I. You know, it was very freeing at the time to be basically, you know, be, have limits. I know that's kinda weird, but to actually be like, look, this is kind of like the rules. People wanted to be told what to do Noel: Mm-hmm. Ryan: it's, it's, it's, it's, as I said, it's very ironic that, um. On one hand, react was like, this is how you do things.[00:15:00] On the other hand, they were still flexible enough that best practices would continue to change over Noel: Right, right. Ryan: it's, it's, it's, it's, it's a weird, um, conflict. But on the other hand, I don't actually personally find it conflicting. I, that's like my favorite part about React and it's the thing that I, um, wanted to. Capture in solid. It was part of actually, um, that design philosophy, um, really guided me in terms of focusing on primitives. Like React for React is the components, but for me it was like, okay, let's make this about the signals or the reactive system, Noel: Yeah. Ryan: and see how far we can take that. 'cause then we have, um, these guidelines and we have these building blocks that we can Noel: Mm-hmm. Ryan: to expand on top of, um, in a predictable way. ~Uh,~ Noel: ~Yeah. Yeah. Yeah.~ I think, I think that that's well said. Yeah. The um, like, and like, I think, I think that there was a lot of. Difficulty, uh, like an angular always felt, I think, I think it was so regimented that that was a lot of the pain that people felt working on the, on those projects and then react was like, [00:16:00] just unopinionated enough or like it didn't really get in your way. I think it was also to your point of like new users ramping up, it was way easier just like. Get some, you didn't have to understand like react. It was intuitive to look at. It was kind of Dom like, um, but then it, it pointed one in the right direction. So there was like, yeah, some, some guidance, but it wasn't as much, it wasn't this like kind of whole new API that one had to understand to write in it. Um, so yeah, it's interesting to think of those as a spectrum. You mentioned, you mentioned that this kind of like moving away. Um, I guess building with primitives maybe is, it was kind of more something that we've been talking about here in a couple of instances, and that was a lot of your motivation was there, like why was this the thing that you felt was the missing piece? Like you mentioned the vdo with view and like that kind of not really being the thing. Like why, why was your big sell Ryan: Y Noel: com, like composability from the bottom up? Ryan: Yeah, I mean view at the time actually had, uh, something called the, uh, options, API, which was Noel: Yeah. Ryan: [00:17:00] objects. It's 'cause everyone was scared. Of composition at this Noel: Mm-hmm. Ryan: everyone was like, our state should look like plain objects. Noel: Right. Ryan: angular did it. Um, and in that, their case in a very fairly inefficient way, I should say like zone js, they just like wait for every single like event handler, async, anything that happened. We were like, okay, did anything change after that, Noel: Yeah. Ryan: reacted a little bit different where they had at least had like a set state where they're like, okay, this component owns the set state. When you call set state and you update something, we'll rerun the component, Noel: Yeah. Ryan: Um, and view is like, okay, we'll just make these big getter, um, like, it's almost like a proxy, but we didn't have proxies Noel: Yeah. Mm-hmm. Ryan: this big getter blob. And the thing I loved about Knockout was that, um. You, you just made these like little like signal effect computer. You, you just like, to be fair, you could do this with views, objects, but they, they weren't quite as portable. Like in, when I use knockout, like [00:18:00] basically a component was a function. Noel: Mm-hmm. Ryan: was a whole other, it wasn't quite components like we know today. 'cause the view was like. a separate module, like they used to call this MBBM or something, Noel: Right. Yeah. Ryan: uh, view. So it wasn't quite the same as a modern component, but effectively you started kind of building up the, this kind of. E femoral state, Noel: Mm-hmm. Ryan: was associated, you know, like there's the model that persists and then there's, you know, the view that you, you know, update and see in the templating. But Noel: Mm-hmm. Ryan: was, there was this real kind of like middle ground ephemeral state in the view model Noel: The view model. Yeah. Ryan: which, which is kind of like a component. It was like this, the early ground, the differences, it's a separate tree than the view tree where the components. Mix, uh, view model and view together, but like generally still had this kind of building of pieces and we would just, you know. Have a component as a function, and then like it state be functions and then have functions, call functions that wrap functions. Like it [00:19:00] was Noel: Mm-hmm. Yeah. Ryan: it all up like a bunch of blocks and then you'd be like, oh, I have this piece over here. I grab that and call it in here as a function like, composition was like. You know, uh, we always see this now as like a basic example, like used local storage or whatever, but that kind of hook like composition existed in the knockout model because you, like, it was very similar idea. You'd be like, oh, I have a, um, they call them observables, but basically a Noel: Yeah. Mm-hmm. Ryan: be like, oh, I wanna signal the rights to local, uh, storage. Well, I'll just wrap that in a function and then call, you know. Create my own local storage signal. Like that kind of composable ness had been in that model right from the beginning. And when I looked out at the JavaScript e ecosystem, not there. So there was a DX thing that I wanted. And then Noel: Yeah. Ryan: hand, conceptually knowing that when I update this one thing, it updates this one other Noel: Mm-hmm. Ryan: no diffing, no, none of that it. It just all seemed like there's this, all these extra systems being built in that were all completely unnecessary. Noel: Right. Ryan: like. Yeah, and as [00:20:00] I said, I, I was kind of like, okay, well, you know, maybe I just think this, maybe I'm crazy. But then like when I started seeing like, you know, conference talks where people talking like the performance of React, I was like, okay, no, this doesn't make Noel: Mm-hmm. Ryan: I need to vet it myself. And that's, you know, how I got involved and I just wanted to recapture that developer experience and honestly, um. Uh, there were, I wasn't alone. There was a few other Noel: Yeah. Ryan: very similar projects at that time. It just, it was kind of, it was kind of funny because like, as I said, it wasn't, there was a DX element, there was a UX element, but it wasn't like, uh, how does this look? It wasn't like an aesthetic, aesthetic thing that necessarily, it was a very mechanical Noel: Yeah. Ryan: thing. We wanted, you know, to make things, um, you know, more efficient and easier to use from that perspective. Noel: Mm-hmm. Ryan: The truth is we just, it wasn't a world that it seemed that people would be accepting of this [00:21:00] because, know, reacted one, even back then we kind of, everyone knew and just were like, yeah, you know, I have my state. That's plain objects very important. 'cause plain objects aren't magical. Noel: Yeah. Yeah. Ryan: and then I have my, my templating or you Noel: Mm-hmm. Ryan: flavor I choose. And, you know, I just update it and it re renders. And I do the thing like the whole v om spiel Noel: Yeah. Ryan: that, that, that was where the world had had gone to and no one wanted, um, these granular composable, state primitives. ~Um.~ Noel: ~Yeah.~ Which I, and I think, I think the, I think the impulse towards that like, makes a lot of sense. And I think there's a reason it's been successful. Right. It's like, it's it's kind of it It does, it does, it does. Away with a lot of that like. Wiring up, which I think historically had been very gross. Like it'd been very hard to handle and it had been very error prone. Like you'd always get all these weird front end bugs, like, oh, I clicked the button and X didn't happen and without something they're kind of orchestrating and it was always hard. But it sounds like your real thesis here is [00:22:00] that like giving developers explicit control of those signals in a way that's easier for them to grasp and kind of wrangle like that is really the place that you wanted to be Like. Would you say that that's, that that's accurate. Ryan: definitely. I, I was not a junior developer anymore. I, I did have a team, but I had a team of on startup that had been using Knockout. So we were familiar with the technology. We understood signals Noel: Yeah. Ryan: whatever you want to call that type of reactivity, fine-grain reactivity at the time. And we were so, like, I wasn't worried about ramp up or who was gonna like learn it. I was like. have good technology to build good applications. You know, it's, it's isolated, it's modular. It, it, it gives you all these qualities that are really, really powerful when you want to build, you know, decent size apps, you know, you don't have to worry about everything getting entangled. We, we were never debugging why components are re rendering down. 10 trees there, there were places where you're like, oh, this, this, this thing updated more than I expected. But usually [00:23:00] it was isolated and, um, and kind of like within its certain zone, because Noel: Yeah. Ryan: you're dealing with signals, you're dealing with a graph, a data graph, Noel: Right. Ryan: dependencies talk to each Noel: Do one another. Yep. Yep. Yeah. Ryan: it just, it, it made a lot of sense from all the mechanical reasons. It just wasn't nice to look at. Um. Right. So, I mean, and, and as I did more work on the benchmarks, um, you know, it turned out I was like, no, this, this is actually really fast, like insanely fast. Like like with a little bit of modern tooling. That's something Knockout never had. Noel: Mm-hmm. Ryan: we aren't just like more performant than, say React, which a popular solution, popular solutions generally are gonna be like, they're, they're not focusing on performance. They got users to worry Noel: Mm-hmm. Ryan: We were like more performant than everything. Noel: Yeah. Ryan: like, Noel: Mm-hmm. Ryan: you know, um, I say we, but like, there's, there's a couple independent projects at the time. There's myself, um, there's, uh, uh, Adam who did, [00:24:00] uh, Adam Hill, sorry, he did surplus. Noel: Hmm. Ryan: there's a few, there's a couple other, like these kind of like, um, there signals based things. And I like it. Just, this is what finally got me to open source it because I, I, I was just like, I was just like. I want to, I wanna play in the benchmarks. I just want to like, prove it, like from an academic almost standpoint. Like, just like, look, there is an alternative. I get it. You know, it's not fashionable. I'm, I'm, I'm, I'm getting older now. Maybe I'm not fashionable. I don't care, Noel: Yeah. Yeah. Ryan: dev, I, I just do what I do, what I like, Noel: Mm-hmm. Ryan: I, I mean, I mean, I, I mentioned this in the article, things might have stayed that way if it weren't for the fact that React like, you know, less than a year later was like, we finally solved composition. Here's hooks. Noel: Right, right. Yeah. Do you, do you think like, I guess. Did you, you, it sounds like you probably didn't, didn't see that really coming, this big kind of inflection point in react. So did that, did that surprise you a lot and I guess were you, were you [00:25:00] expecting the amount of push into solid that that likely caused? I. Ryan: No, like I, I didn't see that coming all. See, the thing you have to understand is reacts like functional roots and its whole like. Almost like a video game. Thinking of like immediate mode. Um, I don't know if everyone knows the difference, but there's like classical graphics. There's like two different TT type models. There's immediate mode and retain mode, immediate mode. This idea that you can like re-render the whole scene graph every time, it's very common Noel: Mm-hmm. Ryan: uh, video games 'cause it keeps a constant frame rate. It's, it's basically the thing that powers everything. They just recreate the graph every time and. Redraw the game Noel: Yeah. Ryan: it's great because it's predictable. Um, you don't have to worry about weird artifacts happening over time. You just kinda slam it. There's a different model, the retain mode where you actually keep something and you mutate it, um, where you just update only kind of what needs to change. And this is Noel: Mm-hmm. Ryan: understanding way more efficient, but it's less predictable because sometimes you change lots of things. Sometimes you change a few things. Noel: Yeah, Ryan: enough, the dom. Is [00:26:00] retain mode like Noel: yeah, of course. Yeah, yeah, yeah. Mm-hmm. Ryan: right off the bat, there's this. Mismatch between kind of like react mentality and like how the web platform works. so like I was like, if we align ourselves more with the platform, you know, we can do better stuff. And, uh, kind of, sorry, where I'm, where I'm going with this is you could just see this kind of two different mentalities, like the separation exist in the ecosystem in general. React was like the very first to come in and be like. not the very first, but like the first popular enough to come in and be like, no, we think retain mode is good. We can just re-render everything. And you know, sorry, not retain, Noel: Yeah. Yeah. Ryan: first to think immediate mode is good. We can just Noel: Yep. Mm-hmm. Ryan: of mentality carried out into its ecosystem. In terms of what succeeded, there were a couple people who, who were working on signals or, uh, like reactive fine green reactive libraries in React. Noel: Mm-hmm. Ryan: uh. MobX [00:27:00] or observable Noel: Mm-hmm. Ryan: was, is a signaled implementation as state management react. Obviously the, it didn't always quite perfectly, but it was a very good solution, way ahead of its time. Great technology, um, big inspiration for, you know, what I did with signals later and, um, but it never quite fit with like their mental model. Instead, the biggest comp competitor on the, uh, state management side at the time was Redux. Noel: Yeah. Ryan: which was a, you know, you kind of like have this boilerplate, it was very simple in that like everything was functional driven and it was all synchronous and there is no like, you know, event, there's just one store, essentially. Noel: right. Ryan: Redox kind of became the poster child. I, I, I thought MobX was a way better solution, like way more powerful, way more capable, but I. Redux Fit Reacts philosophy and re-render model. And in fact, the guys who created Redux became, um, members of the React core team. Noel: Yeah. Yeah. Ryan: like [00:28:00] there was a definite, like, you know, the, it's funny, after the original criers of React and moved on to different projects, it was actually like the, the Redux maintainers Noel: Mm-hmm. Ryan: became React. So Noel: Mm-hmm. Ryan: there's a passing of the torch here and that mentality preserved. So you, you have to understand like. React was never going to go this direction, which is why it completely shocked me when I saw hooks. 'cause hooks are not the same. And if you ask them about it, they'll tell you something about some functional programming. Noel: Yeah. Ryan: or whatnot and explaining, and they are mechanically different in with hooks, your component reruns then only, and basically it checks the values and decides if the hooks rerun. Whereas like in the signals implementation, your components don't rerun, only the quote hooks rerun. So they, they are like opposites, Noel: Yeah. Ryan: they look almost identical. Like there's no way you look at hooks and then go, okay, these are like. Primitives, like, you know, reacts whole, like previous, like, oh, our state is just objects [00:29:00] was out the window. Like, Noel: Yeah, no, absolutely. Yeah. Ryan: state use memo, use callback, use effect, use, whatever. Noel: Yep. Ryan: and it, you can tell they got to it from a different place. If you look at their, like, um, prior art, when they released hooks, they don't mention signals reactively anything, like along that side. They, they, we were not influenced by that all. But you look at it and you're like. Uh, come on Noel: Yeah. Yeah. Mm-hmm. Ryan: To be fair, they probably weren't. ~I, it just, it's just~ Noel: ~They kind of,~ they arrived at the same po play destination, probably like in a way, right? There's a sim very similar feel to what these things are trying to do. Maybe, maybe by necessity like one could argue, but uh, yeah, it's, it's, it's absolutely there. And it does, it does feel like, like hooks is kind of a roundabout way of reaching this destination. And I think that's part of the reason I still think that like hooks are very tricky to. Gr like, what's actually going on? What's with like, what the framework works for new developers. Even like having a person, being a person that spent a lot of [00:30:00] time in hooks, you're still like, I find myself just like throwing console logs at the top of a, a hook to like, wait, when is this actually firing? Like, it's, it's always, it's, it's, it feels very counterintuitive still. Um, yeah. Ryan: it's interesting 'cause uh, in a lot of ways, like that was the argument they made against, uh, um, what they called key value observables or essentially fine grained reactivity. If you go watch a Pete Hunt talk or Tom Ccino or like, uh, Jordan walk, any of the original React guys and, and when they're not talking about angular. They're talking about basically ember or knockout. Noel: Yes. Ryan: uh, when they, when they, when they're talking about like, what's wrong with that? ~You can, like, there's a great one where, uh, uh, Tom Hunt, uh, sorry. Where he, uh, sorry. Uh, not Tom. I mix their, I put their names together. Uh,~ Noel: ~You're good, you're good. You can look up if you need to.~ Ryan: ~Yeah. I said his, I said his name a minute ago.~ ~Uh, gimme two seconds. Uh. Pete Hunt. Pete Hunt. Yes. Pete Hunt. There, sorry. Let me just like restart that. ~There's like this great talk where, uh, Pete Hunt went to university, I think, or a college, they call in us here. Uh, and basically gave a talk on like selling React and it was a little bit more technical and he broke into like three ways where React was better than these other frameworks. And it was very specific about these kinda mechanical things. Like, uh, in terms of [00:31:00] like the. What happens about like state ownership and knowing what reruns and all, like, basically, he, he broke it down and I, I watched that video again about, uh, a year ago and I was, I was like pretending he was talking about modern React instead of knockout and the video fit perfectly. Like they basically, their whole positioning on this, like Noel: Yeah. Ryan: them, they'll say they haven't, and it's still like, fine because of some academic, functional whatever, Noel: Mm-hmm. Ryan: to be fair. As a layman developer looking at this and looking at, like, they're saying you could literally slot the hooks examples in for the say knockout examples, and it would, you'd be like, yeah, I get what he's saying. Noel: Yeah. Ryan: so it was a big departure. I mean, in some ways it was necessary. It gave that composition. They needed something smaller than a component. They react was all components and they, they were like, okay, we actually need to compose something smaller than a component. How do we do this? Noel: Mm-hmm. Ryan: And the, the, the way of they've solved it [00:32:00] was basically saying, we'll make something that. You can look smaller than a component, but it's still actually the component. That's the level of granularity. Noel: Yeah. Ryan: component based, but we're going to make something that looks Noel: Mm-hmm. Ryan: right? Which is, I said in contrast to like signals where the small thing is actually the unit of change. Noel: Yeah. Ryan: I. I think both models make sense. If you can get into Noel: Mm-hmm. Ryan: just, I don't think either is actually simpler than the other anymore. I think early React like class lifecycle render, Noel: Mm-hmm. Ryan: was dirt. Simple. Simple. Noel: Yeah. I don't think, yeah, it's really hard to argue otherwise. Yeah. Ryan: everything since then, uh, especially into hooks, um, it, they, they wandered into a territory, um, that is kind of similar to where these other solutions that they earlier condemned were. And me that was an opportunity I. Noel: Mm-hmm. Ryan: only me, but for, but for like, I think, Evan, you or Rich Harris Noel: Yeah. [00:33:00] Right, right. Ryan: like, like they, they announced hooks and people were just like, and people were excited about them. And I think people kind of on the peripheral, on the outside were like, wait a second, you guys made such a big fuss about plane data, re rendering, blah, blah, blah. I mean, react has somehow set the fashion people. I don't know what they were scared or Noel: Mm-hmm. Ryan: believe, like I, I was pessimistic. Um, and somehow they were like, no, it's okay to have these kind of data primitives a week. You know, rich is talking about spelt three. Like that's where the compiler idea and like using like Noel: Yeah. Mm-hmm. Ryan: the hooks thing. Evan was like, oh, we're gonna pull out our stuff into the composition API for. Solid already was there, Noel: Yeah. Ryan: wasn't a shift. I, this is what I had been building. Noel: Mm-hmm. Yeah. Yeah. Do, do you think that this, this, this kind of push, this push was, um, this is maybe not, I I was gonna say inevitable, but, uh, the, the place I want to get [00:34:00] here is, is, is less, less than that. I'm, I'm more, I'm more curious if you think that the, the, the fact that these, there's kind of this convergence, right? Like on this idea that we're, we're talking around of like eventually at some point for performance, the developer has to dictate. When things change and how data should flow when it does like this, the kind of signal idea, the, and giving that back to developers, which I think hooks kind of also encapsulates manually one way or another. Do you think that that's like, needs to be a more fundamental, like, should that be a web primitive, should the browser be doing that? Like, that just seems like we've, we've all arrived at this conclusion. Ryan: I mean, that's where it does seem like it is today. Noel: Yeah. Ryan: which is. Interesting. Uh, in its own right. I mean, the browsers had proposals for different types of change management being built in for years. So I'm always very hesitant, you know, going to standards, trying to be careful Noel: Yeah, of course. Ryan: but yes, it does seem like we are, we are developing a language and I, I do wanna call it a [00:35:00] language, um, for reactivity. Um, and this is not a, a language that I think we even invented. If you. Talk to somebody, I'm sure in the academic field there, this language has existed for a while. I Noel: Mm-hmm. Ryan: we just kind of self discovered it ourselves. Um, but there is definitely a language and I think for me it was always important because I like control. I like, you know, as things scale up, I need escape hatches. I feel like it's necessary, you know, as senior dev to be able to, you know. Not go too far into my abstractions. You want to have, decide how much you buy into stuff. You know, like how much, at some point things will change. I think it's an even more interesting topic today because when we talk about designing a language for ui, um. You can't not think about AI and like LMS and all that and all that kinda stuff. So like, that alone makes it almost inevitable because [00:36:00] we might have built it 'cause I wanted more control, but, uh, I think the machine, so to speak, want, wants more control as well. And giving them a, you know, a primitive that's like one step up is a lot more powerful for them. You Noel: Yeah. Ryan: you can argue that something like react is simple, um, because of these constraints and it just kind of reruns and it makes it easier for things to understand it in a certain way and just kind of, but it, it is not at nearly as powerful. Like there's a difference between, know, a lot of times with frameworks you want to restrict power because you give too much to the users, then they'll do bad stuff. Noel: Mm-hmm. Yeah. Ryan: I. If we're going to a, a future where we're, you know, building these where we're maybe not building things we're, you know, maybe AI or something, building things, then having power is actually really important because it will empower it to build better stuff. Noel: Yeah. Ryan: For me, it was always about empowering people because I. Uh, people [00:37:00] like myself, Noel: Mm-hmm. Ryan: who knew what they're doing, people who wanted to get the best, you know, out of their tools. But it, it's definitely interesting. Sorry, I didn't mean to veer off into ai. It just, it's, I, there is a certain inevitability here I think, um, that hopefully like. It, it, it's always like a back and forth, right? Like primitives are an abstraction. It's, it's about finding the right boundaries, Noel: Mm-hmm. Ryan: initially you might Noel: Yeah. Ryan: a really crude abstraction and be like, this is pretty good, and gets you going, and then later you refine it and when you refine it, you can get lower level. It's like the same process when, you know, frameworks build something and then eventually gets into the browser. You like, you kind of do something kind of basic and kind of works, and then hopefully by the time it gets. Into, you know, standards. It's actually something that's well-defined and maybe even simpler or smaller piece, like something that's actually more, uh, extensible. Something, um, more, um, yeah, adaptable. Noel: Adapto, I think adapt. Yeah. Adaptable is a [00:38:00] great word. And I, I, I don't think it's, that's too, it's too far off the kind of off the, off the rails here a notion, because I think, I think you're right. Like I think, I think it's hard for agents, like, you know, whatever, LLMs or whatever, whatever's operating on these things to kind of do, like, be operating at the level that the frameworks in the meta frameworks or op like kind of ask the user to operate at. Like, it's just like we're so. It's so hard to ha kind of have, have all of the context that a developer has. I think were especially like a, some, someone that really understands the internals of the framework they're using. Like it's just, that's not, not what we've seen with the agents thus far. So I think, I think that that is like an interesting notion. It, it, it does kind of beg one to compare like a junior dev stepping into the space doesn't feel that different than an agent. Right. It's like, okay. These are kind of both, like they're just looking at what's exposed and lots of examples online and trying to do the thing as best they can. So like, there's an interesting kind of discussion one could have there, but I don't wanna send us too far down the, down into the weeds here. Um, so I guess, yeah, let's just like, kind of real quick and then I want to, I wanna kind of get to our [00:39:00] little quick lightning round questions. But before we get there, do you think that in general, this notion of devs, you said that kind of when we began talking that you. We're surprised at how much devs seem to be okay with the magic, right? Like, do, do you think that that is maybe like what's, what's causing this pain or like needing to understand the magic of hooks was kind of part of this problem? Or like, like what, what, what is the thing that's driving devs to kind of have this collective understanding that there is like maybe, maybe I need to actually have control of my tools a little bit more. Ryan: Yeah, I mean, the problem is you, you can always add another abstraction, right? You can always, um, you know, make things easier and then easier and easier. But then you restrict it and at certain point you have to break. You will break outta the abstraction, which means that My personal opinion is the bigger the gap is between these abstraction and the need of depth you need to get to the underlying system, the more complicated everything will feel. This is Noel: Yeah. Ryan: React, use effect is a problem. This is completely actually [00:40:00] why. Noel: Mm-hmm. Ryan: first time people realize how React works, and I. I think that as our tools get more complicated, generally the hope is that you don't need to peel the layers. You know, let's build a compiler on top of our framework to, you know, not have to worry about this. And then they Noel: Yeah. Mm-hmm. Ryan: you know, and like auto memorization and all like, and a certain point, it's like it. If that abstraction is, has no holes, then you're right. That will be easy and good to go and maybe you won't need that knowledge. But I don't, I haven't found that to be reality, which means that we do have, we are carrying this weight on on us, and the only way to solve it is not to come up with another abstraction on top of the abstraction. It's to actually remove abstractions. Like go, okay, now that we understand this. better. How do we change the model? Yes, we need abstractions. We need primitives, but how has our understanding allowed us to actually change the foundations? And [00:41:00] that is key. 'cause that's, at a certain point, that's the only way you simplify. There's, there's, there's no, you have to take stuff away. You can't just keep on adding, um. Noel: Yeah. Yeah, yeah. Well said. Well said. I think that that's, that's probably as good a point as good a point to wrap as any let's, uh, let's do some, some quick fire questions and then we'll, we'll wrap properly. Um, I have, I think I have a hunch, but some of the answers will be here, but we'll see. We'll see if I'm right. Um, what's a tech buzzword you wish would go away? Ryan: Um, I mean, I don't know if I necessarily want to, to go away. I just, I, I'm, I, the, the AI related stuff is just. Too much for me. Maybe I'm just not in the loop, but I, I think I, I think it's an exciting area in a certain sense, but for me, I, it, it, at least it doesn't impact me that much because I'm working on mechanical stuff. So it's, it's, it's this kind of thing that I, I, I just haven't, I am, I'm just. I know it's funny to say, but it's something that I, I don't spend that much time. It's only when I come on podcasts like here that I actually end up thinking [00:42:00] about it all that much. Um, so I don't know. I guess anything that's like over-hyped like that at the second, I guess specifically, I think, uh, vibe, coding, you know, the, I, I, I get it's good for prototyping, but it's at a certain point engineers need to engineer, so, you Noel: Yeah, I'm, yet, I'm yet to be convinced. I've seen like a couple little, like very, very isolated examples of it happening, but I just can't, like I, I'm yet convinced as. On vibe coding specifically. I think AI stuff's there. I'm, I'm here for the day when ai, like we aren't, it's not like advertised. It's just like, okay, this thing uses ai, but like, as the user, you don't really need to know about it. It's just like how it's getting its thing, its thing done. But we'll see. That's neither here nor there. Uh, what's one idea you had about web dev in 2015 that you still believe today? Ryan: Yeah, I mean, we talked about it almost this whole, uh, stream. It's the, the idea that like, you do need to put. in, um, you know, people's hands to a certain degree. You don't need to know how to build your tool from scratch, but you at [00:43:00] least need to understand what the abstraction is, you know, so I think it's important that, you know, w you know, things aren't too magical. I think, I think, you know, at the base you need to at least be able to have a good mental model of things, and that's what led me to build solid. It was about transparency. It was like, you see, what you see is what you get. Noel: Hmm. Ryan: Um, yeah, that hasn't changed in the last 10 years. Noel: Gotcha. Nice, nice. What's the biggest myth about performance in front end Frameworks? Ryan: Oh, man. I, I mean, I don't know if it's the biggest, but this one always, this, this one bugs me enough. Like, 'cause I. It, it's the, it's this idea that like, by adding a technology, like say, adding signals to something, suddenly it's faster. It's, it's, it's the same fallacy I was talking about earlier, Rob, but just Noel: Hmm. Ryan: more abstractions, adding more things, that makes it faster. The re like the reason signals frameworks are fast is because they remove something. Like if you have [00:44:00] signals and you make that your core, then that, and that's all it's doing. Then that can be, you know, really performant. But if you. Say your signals with your virtual dom. Well, you're probably on the overhead of the virtual dom and the overhead of signals. You, you're kind of getting the worst of both worlds. You know, like just taking your, you know, react and jamming signals into it won't make react faster. It'll probably make it slower. Most definitely. You know, and that, that's why, you know, when people ask the React team if they're gonna move the signals, I mean, no. They have a very clear path and that path. exclusive to this. Like, sure, you can use it for state management, but it, it's not gonna like improve, react. All of a sudden the you, the, there are architectural constraints. Not every feature, it's just something you can nail on Noel: Mm-hmm. Ryan: now it's better. Noel: Yeah. Gotcha. Yep. I, I agree. I agree. Okay. This, this, I'm, I'm, I'm, I'm gonna go slightly off script on this one. Can you think of a specific, like either project or type of [00:45:00] project wherein this kind of fine-grained reactivity is necessary and like virtual dom and like diffing, like this doesn't, just doesn't work. Ryan: Uh, honestly necessary. No, I, the, these, these technologies, I think there's benefits for ergonomics. I think there's benefits for performance, but I. I don't know if there's anything where it's like, you need this because the beautiful thing about the virtual dom is it's like relatively good enough for most things and, and the thing is people were fine reloading webpage for a long time. I think that idea of like what. The need is, is, uh, a sliding scale and people's expectations will rise. Noel: Mm-hmm. Ryan: there's places that obviously Fine grain really excels, which is places where you're doing lots of minuscule data updates, things like, you know, large tables or dashboards or, you know, stuff like that. Um, I, I just, I, I, I, it's not a matter of you can or can't, you know, Noel: Mm.[00:46:00] Ryan: I guess another really cool example is people using it for video games. Like Noel: Yeah. Games. That was gonna be my point, is to see how like really like up games with a ton of data flowing in and out. Yeah. Ryan: because one of the interesting things is, uh, we've seen a lot of, we have a, we have like a three js, uh, universal render port, like one of our custom renders in three Js. Noel: Yeah. Ryan: if you look at like the React solution, people actually have to opt outta the React state management. Like they use a whole different state library to actually do it performing. Um, you might still want to do that with all, but you don't have to, like the, the signals are performing enough. You don't have to worry about like re-render. Noel: Mm-hmm. Ryan: so it, it's, it's, it is actually works quite well. So I, I think like, there, there are situations where it makes a lot of sense. Uh, I, I, I said there wasn't, um, low memory devices are still a thing. Uh, we're very, very attractive on television devices. That's actually where some of our, like bigger Noel: cool. Ryan: things like, uh, universal NBC like solids used on television Noel: Oh, neat. Neat. Mm-hmm. Ryan: or something like that. [00:47:00] Like, and like we had some interest even from Netflix in that zone. It just, it wasn't a plug and place swap from React, so it wasn't as easy to make that move. Noel: Yeah. Ryan: But for them, but like generally speaking, like there are places where it makes a lot of sense to have these qualities, but a lot of places like it will be good enough. I. Noel: Yeah. Yeah. Very cool. Very cool. Yeah. The, the games example is gonna be mine. Exactly. I've got a couple, I've got a couple side projects where I'm very much hitting this, just like, uh, I've got a ton of data flowing in and out that's like changing really quickly, and I'm like, I'm feeling it a little bit as I'm like dragging stuff and moving stuff around. I'm like, I. This is react I'm fighting or react here in a way I don't wanna be. Um, so I'm glad you, I'm glad you called that one out. Um, this is kind of a question more about you. What do you think is the hardest part of maintaining an open source project that most people aren't cognizant of? Ryan: Um, yeah, I mean, it's, it's interesting. I mean, I don't, I say I don't know if [00:48:00] it's not actually that interesting. It's, it's just. There's a lot day to day. I mean, I don't know if people, pe people will come in and they'll see their issue or their thing that they care about. And the truth is, when you're source, your work is always in public. So like, like there are so many different people you're catering to and that you're like, you're directly talking about public. There's, there's no insulation in the way. Noel: Yeah. Ryan: I've worked on. Product teams and companies and you know, there's customer success team or whatever, like open source, your, your customer are the developers and you're interacting with them directly. So like, I, I don't know if this is like a hidden thing, but it's just, there is like huge amount of just like bookkeeping in the sense of like, not like money or anything, like just PE people Noel: Mm-hmm. Ryan: Capabilities and projects. [00:49:00] Um, and I, people generally only come in for their, like, narrow slice, so they don't see the, the, the, the breadth of it all. Um, so Noel: Yeah. Ryan: it, it's, it's hard to keep on track of it when you also want to build stuff or you want, you know, you know, uh, try new ideas and, and, and whatnot. So like, it's just like. like, you know, you just get, get a, you know, issue. You always hear, I guess, I guess there's been more visibility on this recently where you see open source maintainers kind of like respond back to, you know, rude people or Noel: Yeah. Yeah. Yeah. Ryan: And, and, but it's just like, there's those people in one extreme, but like there's everything in between. Um, it's just these projects end up. Small, but they become massive. Like, Noel: Yeah. Ryan: and it often without the infrastructure that you would find it like a funded [00:50:00] company. So, Noel: Mm-hmm. Ryan: um, yeah, I mean, that can make things, uh, difficult. Uh, at times. Noel: Yeah, yeah, yeah. There's not, there's probably not a lot of open source product managers that are just like, okay, I'll do all of the product triaging and everything, and then I hand it off to the developers. Ryan: any chance you can ask me the question you skipped over? Noel: Oh, yeah, of course. Um, the, the, uh, sorry, hold on. Ryan: What's one fine, one thing? Fine grain reactivity can do that. The Noel: Yeah. Yeah. What's one? What's one thing? Fine Grained reactivity can do that. The virtual dom just can't. Ryan: Yeah, it's funny. Normally I wouldn't say like any technology can or can't do anything. 'cause you can always work around it and find the escape Noel: Mm-hmm. Ryan: you know, like find ways to like make it work. So it's like, in your project, I'm sure there's a way you can make it do what you want, Noel: Yeah. Ryan: there are benefits, uh, that, that people are only starting to realize right now, especially seeing, you know. Fine grain rendering coming into stuff like, uh, salt five or View Vapor, Noel: Mm-hmm. Ryan: start seeing this community start kind of [00:51:00] thinking about like how we approach things differently. And I think the thing that people don't understand is by writing your code this way, you are giving your application knowledge of how data flows through your app. Um, and this is incredibly powerful because it does mean you can do things that just don't make sense or don't work in the virtual dom, like for example. You can, you know, fetch some data somewhere in your app and if that data errors out somewhere, you know, deep where it's being used like say rendering and you like hit an error boundary or something. Well, you retry the error boundary. In, you know, a typical virtual dom library, like I think this is why React doesn't have an error boundary component. It doesn't know what to do. You have to kind of fix the error so that the next time it re renders or whatever, it knows it that it will be corrected. Otherwise, it's just gonna arrogant. Noel: Yeah. Ryan: with a fine grain system, 'cause you know the data dependencies, you can be like, oh, let me retry what errored and trace the data graph all the way up to the data fetching and be like, Noel: Mm-hmm. Ryan: I'm just [00:52:00] gonna re fetch what failed. Like, and this kind of power is incredible, right? So like you can picture, you, you have some data fetching, and then as I said, lower down, you're like, try render something with that data and it fails and you're just like, oh, I'm gonna retry. Maybe the user has a button they can click, can Noel: Yeah. Mm-hmm. Ryan: And this is because the program understands the graph. And, um, this is, this is this capability. People, you know, are only starting to realize it's now getting built into applications, um, because of, you know. Solid Js or you know, view vapors felt like when you start writing your code this way, be unlocking other capabilities like this. We've seen advantage to this, like in debugging you can actually be like, oh, like visualize the graph, like. And I'm, I'm looking forward to, you know, these kind of things working their way into more, into like developer tools, like Noel: Yeah. Ryan: IDE support and stuff. Because like what if like, you can use the data dependency graph to know, like when you edit [00:53:00] code, what, what part of your application could be impacted. Noel: Yeah. Right, right, right. Yeah. Like what, what, what needs to reload, like what tests need to run all that. All that stuff. Yeah, that, that could be very cool. Ryan: So for me, that is some huge benefit to using fine grain reactivity that you don't really get with a virtual dome. Noel: Nice. Nice. That's, I feel like, I feel like that's good as good a note to end on as any, um, yeah. Thank you. Thank you for pulling that question outta me and thank you for coming online and chatting with me. Uh, Ryan, it's been a pleasure as always and I'm looking forward to next time. Ryan: Yeah, no, it was a lot of fun and uh, I always have a lot of fun. I, this podcast is definitely one of my Noel: Awesome. Awesome. Ryan: you guys are, I have something new to share, I will be back. Noel: Nice. Happy to hear it. Happy to hear it. Thank you.