SolidJS: Decomposing the metaframework with Ryan Carniato
===

[00:00:00] Hello and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics. You can try it free at logrocket. com. I'm Noel, and today we have Ryan Cardiato with us, creator of the SolidJS framework and working on Netlify and Marco.

He's here to cover his latest conference talk, SolidJS, Decomposing the Meta Framework. Welcome back, Ryan.

Hey, thanks for having me again. I love coming on here and talking tech.

Yeah. It's been a while. I feel like it was at least like six months ago last we had you on, so I'm excited to jump back into. The solid world a little bit. Yeah, before we get into much, I have a hunch that most listeners have know roughly what solid is, but can you give us like your quick elevator pitch on why solid matters is why it's worth the consideration.

Yeah, that's fair. I actually have had to change this a little bit recently because a lot of the unique factors for [00:01:00] SOLID are coming very common in other frameworks, but it is a UI framework built around fine grained reactivity, this concept of signals, and It was built from the ground up on that base.

It does not use a virtual Dom. It uses its reactivity to do all rendering in a very fine grain manner, pinpoint updates which gives users a lot of control and a lot of performance. Which, tends to make people pretty happy.

Devs like knowing what's going on usually for the most part, right? It's always good to know what's happening. How about solid start? What is solid start?

Yeah. It's, it feels like everyone needs a meta framework. At this point as soon as we had solid released, it was like, Oh, where's your next JS, does it work with next JS? And luckily for, I mean, kind of two factors we needed that as of kind of hoping that the ecosystem community would get there at some point then beat came out as more specifically beat two and they added SSR capability and it was like too [00:02:00] tempting to just get in and to be fair, beat two's release spawns, not just solid start, but Svelte kit Astro really all these frameworks basically came out of the aftermath of that.

I called it solid start on it because I view it actually as a set of starter templates. So to speak less a meta framework which is because I've never been one of those people to use a meta framework like when I worked at companies, I would build my own web pack configs or, what was needed, design that out.

And, I know that's not everyone's favorite thing to do, but like I never had a use for a CRA or next JS or whatnot. So it was difficult to balance the tension between people wanting these pre configured. Pieces and the fact that I don't like telling people too much of the do, I didn't want to be too opinionated.

But it's table stakes now because of a lot of the complexity that comes with server rendering. Solid start was solid's attempt at a meta framework, but maybe a slightly different type of meta framework.

Yeah, it's interesting. You draw the parallel there, or maybe just[00:03:00] the similarities and how we think about these things like, the starters, the helpers versus the thing that gets a dev using a meta framework. Cause I feel like at least now, yeah. They're almost synonymous so much it's just like starting a new project that you like, you reach for the thing that gets you going with some meta framework and that, it's just tends to be how it happens.

Was that intentional or did that you just end up, falling into that pattern?

Yeah. We've had the complexity that's come from adding server rendering to our single page app world has just necessitated this kind of shift. So when you want more functionality there was already stuff like create react app, which wasn't server rendering, and it was incredibly popular as it's kind of starter template.

A little bit hard to eject, but it was still like a way to get started with react next JS brought in server rendering and then it became the poster child of this kind of next thing where everyone was like, okay, I want something that does all the stuff and it's very easy to get started with.

So it's [00:04:00] gone to a point now, and I think this is a big part of the conversation, which is why. It was obvious it was going to go this way, which is why we started on it, a couple of years ago, but even for react , their official line is don't just pick up react, like , if you're starting a new project, don't just go, okay.

NPM install, react, go install next, go install remix or whatnot. Like they're telling people that if you want it to start a new react project today, that's like. All react like all in on react like not like where you have to you know Trying to make your react work with your php backend or whatever, but you're like fully in on react That means you needed to use one of our meta frameworks.

We do not recommend using anything else they even have like a warning in the docs or saying like hey, you can Go maybe use something like a beat starter, but we don't recommend if you but we don't recommend it So like it's it's quite a big shift when you talk about the biggest player in the ecosystem taking that stance But it's also justified.

I just it never really sat Exactly well with me that [00:05:00] position because as i've never really liked these kind of projects they felt too restraining from where I stat, I like having control of things. If it wasn't obvious from how I described solid.

That makes a lot of sense. In your head, is there a mental, like a delineation between like solid start and one of these things that react is pointing, reactives towards it makes these fundamentally different in some way, or like solve some of that, gross.

Quote unquote feeling we have with react recommending starters.

Yeah. I would say it's nuanced and I'd say today, not I, we're not quite where we need to be. It's a lot easier to, when you have a goal in mind to go build it. Then build, say the agnostic version or the generalized version of something, it's always easier to go and be like, okay, I want a project that does SSR and has these features.

And then you go and build it. And then you step back and go, okay how much of these pieces need to be specific to that solution? And with solid start, [00:06:00] we did. Start along a path where we tried not to build new pieces for the meta framework. So there's next router with next and I actually can't say this about remix because remix actually does react router.

But initially they were, it was like remix router. They ended up backporting all that into react at router, which is the same kind of mentality. That I'm talking about in solid start. We started just using solids, typical router that already existed. We tried our best to not introduce any new libraries that weren't already existing in the ecosystem and the hope that the libraries that we chose to include would be minimal and that people would be able to add their own stuff.

We also started from a place where we were like. We want to support client side rendering. We want to not just doing SSR. We want to support different types of mode of operations so that effectively this could replace the basic, create Vite type templates. Like you could get that experience where you're just doing a single page app, not worrying or upgrade that [00:07:00] experience to SSR.

And have them all work under the same system. These were two very key pieces that were important to us when we started solid start. But as I said, that gets us close, but not all the way to where I'd like to see it. Cause I, I'd like to have even less buy in. Like , technically speaking, you could pull your own router into solid start and use that, but it's not as integrated.

I want to do something about that still.

again this seems to be a pattern that has been discovered, right? Like in, in the journey that all of these, the frameworks and then their respective meta frameworks have taken, where maybe not everyone was thinking about it with as much care as you, you seem to be in that like, it'd be nice if these things were.

Largely agnostic and like, you could separate them, put them back together. You could switch from SSR mode back to like fully clients. I don't know, make that all easy and more composable and less specialized, but it seems that this keeps happening. Do you think that there's like something [00:08:00] that should be happening, like architecturally at a higher level to make this easier to do?

So like we don't, you don't have to fully commit to one of these ecosystems to build a modern web app.

Yeah. It is definitely challenging. What I was going to say is what actually really pushed this for me to take things even further than we'd done so far was Tan stack and Tanner Lindsley's work on his router. People will have their own opinions here about, different libraries and stuff, but from where I was sitting, he built the best react router, hands down, not even close.

And I know that's a very strong statement to make, but it was like. It wasn't even debatable from where I was sitting and he couldn't actually use it anywhere because it wasn't part of a meta

And I was just like, this is really wrong. And the fact that like the official line, like you got to the point where he was like, okay, I'm going to make my own meta framework.

I'm like, I like, I relayed right away. Because I mentioned in my talks and stuff, like I wasn't out originally to make a meta framework and to hear this guy who. Made [00:09:00] some of the most useful libraries like react query, like in the react ecosystem made them even agnostic because you can use solid queries felt query, like some of the best libraries across the whole front end ecosystem to see him like being.

Pulled into making a metaframework when he didn't really want to was just like heartbreaking and that is Really for me what like seeing that again happening. I was like, okay, we got it. We got to do something here Sorry, I'm trying to get back to what you're actually

No. I think this is important context. Yeah. But yeah, but I think that this seems intuitive, like to devs, everyone's sitting here. Like, I think a lot of people are of the same mindset, right? Like, this seems graspable, but it's it just seems that we're all so lazy. We want to get stuff out quickly.

So it's we just keep it out. We'll just use the meta framework where I get everything out of the box. Is there a happy medium? Can we have the best of both worlds?

I do think so because I, the challenge is routing is like that fundamental piece of like most metaframeworks are just [00:10:00] like router plus like they're just an extension of routing because the web is based off routing. The web is a router.

Right. 

It becomes this most core piece to how we approach stuff.

And what made things really specific is there's a lot of opinions when you get into zones where there's like APIs involved and like kind of surface area. And one of the biggest ones is the file system based routings that we find in MetaFrames to make things easier. So suddenly you have all these pieces tied in because you want to get the lazy loading.

You don't want people to like have them wrap their own lazy routes. You want to be able to analyze the routes. So there's a whole bunch of. Things that you need. And then suddenly you're like, okay, then I have a router and then it's not easy to just swap it out. But it's this challenge here, because in a sense, the routing is very opinionated.

Like it's challenging because every time there's an agnostic project, like I always feel this tension there because like often doesn't work nicely with solid, let's say when someone's trying to make something like. Library or framework agnostic, like on that level, I'm always just no, not happening, like it's very challenging to make that work.

I, but funnily [00:11:00] enough, when I look at things that lower below me in the stack, yeah, I would love if. They, those were, agnostic if, if it could work like maybe everyone could have signals in the browser or something, which is like a different thing that's actually being worked on right now.

There's TC 39 proposal being made currently, but it's funny how depending on where you sit, On in, like in the stack you have different expectations on what sits below you and what's above you.

And I think this is one of those zones is I think when we either try to take on too much ownership or we split things along the wrong boundaries or like slightly incorrect boundaries, that's when things get entangled and what, when we can't break stuff up.

So this has been a hard problem because. Routing is at the core of this. So you have something that's almost very high in the opinion level, but also fundamental. So it feels like you can't break it apart and us well, me and Nikhil, we're working on this and a large Nikhil Seraf members, solid community core team does a lot of the [00:12:00] work on solid start.

We came to this realization. A lot of this actually came from watching Nikhil because he. He doesn't like being told no, that he can't do something. And he was in the situation where he wants to build specific things that he wants to build, let's say, but he isn't, when he's not satisfied something, he'll go make his own version of it.

He's been doing this for years. And in the course of, since he started working with me on solid start till like now, he's actually built five meta frameworks. And he kept on seeing that he was building the same pieces over and over again. There's obvious things like the deployment layer, like all the adapters, like where you deploy, but even higher up in the stack things around handling resources and CSS and even the server runtimes, like VEET does a lot.

More than any bundler that we had previously, but there's still a bunch. There's still a gap between where VEET stops and where these meta frameworks start, where there's still a lot of reusable behavior. So for us, the [00:13:00] key realization was that there's actually two types of routing because everyone who's ever tried to take the like.

Client router like the react router or next writer or whatever, like the thing that you think of in terms of what you use in your application and mixed it with the file system router and made that like the same thing has got locked in this kind of place where they can't swap.

These pieces, and unfortunately this has, led to the place that even when solutions trying to make agnostic versions of those, like for a while, their remix was like saying, Oh, yeah, you can make spelt mix or whatever, or solid mix or whatever, or view mix, I forget what it was, but the idea is you implement your own version of the remix router.

And then you basically can build a framework on it. I've seen other things like V Plug and SSR, where they have like an agnostic router. In my opinion, those types of approaches have never succeeded because between the client side [00:14:00] router, which is very determined by the change system, the framework, like React or solid, like they have different needs on that side. And the file system router and the conventions, the stuff we expect from the meta framework. The actual framework sits and that piece, like whether it's solid or react is different. And if you have to bundle it, like wrap it all together as part of the same thing, it's almost impossible to make it succeed at being agnostic.

So our, the realization was figuring out how to split it apart, basically where to draw the line between what was, below us in the stack and what was above us. 

Yeah. So what in particular with solid, if anything, what, why is that boundary between the router and the library framework? Like why is that different here versus, like something React, react router,

yeah we basically separated out the file system router from the router and made that part agnostic and Nikhil

gotcha.

made this new project called [00:15:00] Vinci. And this was after making those other, like all the other experiments we were working on and he, his goal, as I said, he wanted to not be told what he could do, but he wanted like a Same boilerplate so that when he built an app that was like using server components and that he also had a solid app and that he could basically use the same basis, even though he knew that they would need their own client side router, like when he's using react, he might be using Tanner's router when he's using solid, he might be using the official solid router.

He wanted to be able to separate that out, but he still wanted to be able to have the conventions. So he made a system of basically a configurable. File system router layer, which could support all different types of routing schemes. Like he, he actually has built demos where he has built basically remixes, loader convention next JS's page directory, spell kits plus sign, whatever.

Salt data he literally has a single project, which has all those conventions in[00:16:00] and.

Wow. 

As I said, that's a very cool technology, but that, that wasn't completely the whole story. Like we knew we need this on the file system router bit but we also needed things like server components and server functions. I don't know if you've been following that at all, but there's been this kind of server functions or this kind of RPC call trick where you use a compiler and then you either market using like server dollar sign.

Or in react case, they have like you use server and it's this mechanism that you can basically do these RPC calls from the client. And in you, it works as a really nice model because while the whole web is working, moving more towards how should I pay? MPA multi page app inspired UI.

What I mean by this is even if we're client side routing, with react server components or whatnot We're still server rendering the next page in partial form. That's like the new trends, add client routing to islands. The, and this even fits into, this, I can align it with stuff that [00:17:00] has even been going on with remix and their loaders and actions where they have this very, almost php like I'm going to load my page and then I'm going to post my form and I'm going to do this thing They're doing a client side route there and they're not using islands They don't have the same html thing But they have that same mentality of going back to the page post method the cool thing about server functions Is that it lets us?

Keep this sort of what's called CQRS, like command query segregation thing where, which is something we learned from the GraphQL days where it's really awesome to represent the state of resources in the URL, like on the get side, you want to query it, you want to show the data that's there, but mutations and rest are more awkward, I don't know if you've ever tried to write a move operation with REST. Like it's really easy to add something to a collection with REST and you'll like, put this or create a new resource post here. But it's actually a pain to do like operations that's like move between here and here.

yeah, put this item it, position three, like everyone ends up implementing it. It almost feels pseudo manual still. Like even if you look at the spec, they're never the same. [00:18:00] Yeah. 

And the genius thing about GraphQL was they said, okay, graph on the get side. RPC call on the post side, the mutations are just basically function calls. And this pattern is holding up in this new world, even though we're going to this kind of page load mentality where like, whenever you do a mutation, you run it back through the.

Page render on the way back. So like you, it's like that full cycle, like the classic web this time represent the page by the URL. That's your query. But when you post, we don't need to post to a specific like URL. We can post RPC style. And that's been the kind of big movement. And we built, I think one of the first server function implementations to solid start.

I talked about a year ago, I think at my VConf talk in the past year, almost. Every framework has implemented this kind of RPC style into it. And we thought it was such a good idea. We tried to go make another project called bling with Tanner, which was this idea of that [00:19:00] it was like RP compiled RPCs for all.

Yeah. Cool.

But the reason I'm bringing this up is there's one flaw in our approach in that it was using a compiler that would like compile into it so that like on the server, it would be like the end point we've generated on the client, you'd just generate a call to that end point. But the problem is if that code was never loaded on the server, then the end point would exist.

And you have this kind of interesting tension where, you're. Putting these things in line, in your component files, in your pages, like as you work and if your client side routing and you've got code splitting, you might never hit. The server page. Now, to be fair, we were loading all the server pages on the server, which has a cold start impact.

I've talked to my friends over at AWS and CloudFlare and now everyone, we, but I was like, okay, whatever, for now but it's more than just that end users would start lazy loading code and having the same [00:20:00] problem. The truth of the matter is to, Properly solve these kinds of problems.

It's not enough to do it at a compiler level. You have to do it at the bundler level. So this has to be part of your analysis early on, which where I'm getting to is it fits with the file system router. It actually makes sense that you do it at that phase. So in a sense, our modern meta framework is like our.

It has a few parts. It has our like, like client side router, which is, I was talking about the beginning, our react router, transfect router, whatever, this is the opinionated piece, right? Everyone who writes frameworks do tend to have opinions here and they probably would want to use their router, but I'm just recognizing that there's this router that we, that, the end user interfaces with, then you have the framework, whether it's reacts, felt solid, whatever, and then the bundler piece.

is very important because this is how you do all the file system analysis, right? This is how you need it at that level [00:21:00] to do the, the server functions, the islands, the server components. And then below that you have that deployment infrastructure. You got to deploy to Netlify, you got to deploy to Vercel, Cloudflare.

So for me, once we clearly saw where those four pieces lie, we understood that if it was possible to keep. Our opinions on the, like framework, say as solid JS above the bundler level, it should be possible that like framework client side router, like the router you interact with that's belongs in the, in our realm, everything below like the bundling, the, these kinds of patterns around file system analysis, and even lower down the deployment platforms and the server runtimes, cause they're all different.

Different than Dino, Those, could be. Agnostic to the framework. So this is a very long way of getting to the point of us getting a lot of clarity of where everything actually [00:22:00] could sit. And once we found that we were able to just go much quicker on this stuff because it was very clear, this is very freeing for me and for Tanner.

We were in the process of doing the migration right now, but like I for solid start, since we only care about. The stuff above the bundler, essentially, I was able to delete 90 percent of the code out of the repo,

Oh, yeah.

like just just, it wasn't necessary because the responsibility could be passed to these agnostic tools.

And I talked a bunch about Vinci because Vinci is like this layer that. Keel built on top of Vite, right?

You still need to deploy it and have the runtime. And that's where we came across Nitro

And Nitro it was originated actually as the base of the Nuxt framework from the Vue community.

interesting. Nice. Yeah.

And they decided that they were going to build their stuff in building blocks. So I mentioned that you were asking like if solid start was unique, [00:23:00] I think our dedication to not owning stuff was a bit unique, which is, it's pragmatic to like maintenance

Yeah. Do as little as possible, right? Yeah. Yeah.

But on the other hand, the idea of keeping things modular is very exemplified in Nuxt and like what their ecosystem does.

They tried to build everything as generic as possible, which I applaud them for. I also go understand how much work is when you build stuff generically, it's usually takes much more maintenance costs, but that they got the ball rolling, which is amazing because it means that the. Layers underneath Nuxt can be used by other frameworks.

Nitro, for example, is used in Nuxt, is part of what we're doing here with Solid Start. And Tanner is looking at with his like make a framework thing. I think he's going to call it Tad's Backstart, kind of keep us in line. But it's also already been used by analog, which is angular's metaframework.

So it's picking up some steam here and it's part of on JS, which is this open source collective of [00:24:00] libraries. Like they're very dedicated. To that, like there's Pouya who is like the main maintainer of this. And even though like they work closely with Knox and stuff, it has completely their own kind of governance and they're dedicated to just building this open platform.

Very exciting stuff. And I love it because this, we're finally getting to that place where, when I started, when I saw Vite and I was like. Oh, I don't, I won't have to, take care of this. There'll be that layer. We're finally getting the pieces to make that actually a reality. Which I think is going to open up a lot.

Because we'll see how, if others use Vinci, it's still new and still working through kinks, but just having these pieces available can really accelerate things. And. It lets us focus on the parts that are important to us. So for me, that means. I get to focus specifically on how, say, Solids router or Solid itself works on top of these tools and not worry about what's it going to do when I [00:25:00] deploy it to CloudFlare or, Deno.

And I think that is going to, is really key because it's, it's given me some time and space to like, think about patterns that would say, let you go in. And swap the router. See if the file system router, for example can output, like most of them output to some kind of Jason format that the client router imports.

So

Basically as long as you, and in solid case, we actually have a component called file routes. So you can choose to insert that anywhere in your route tree or not insert it, you basically skip the whole file system router installed start. And, but as long as you have that you could insert that into any.

Router theoretically, but any solid router most definitely. So figuring out how to expose this in such a way that people can, it could really be just a starter where someone, the most basic template doesn't even have, much of a client side router, and then people can just, bring in whatever libraries they want.

I would love that because the truth of matters, we're going to see. [00:26:00] More, I don't want to call them meta frameworks, but we're going to, there's room here for more opinionated frameworks. We're already seeing that like people always have more opinions, right? Like in the React ecosystem, there's Next.

js, but Blitz was built on top of Next. js and more recent example, this is T3 the Theo Brown Base stack, but then everyone else uh, it's a completely different people who actually maintain it. It w it was a bunch of these opinions built on top of next JS, very easy starter almost set up for startups.

It had Prisma and everything just built right in. And you just choose what you want built on TypeScript with TRPC. It was, it's very powerful setup and someone in our community. Or J, or J. Devies is his handle, went and saw, Oh, T3 is so great. He just ported it over and added a wrapper on top of solid start that brought in all those same libraries, like next off and all, like all the, I guess they're called off JS now it's not tied to next.

[00:27:00] And basically brought all the same opinions on top. And I love seeing that people should be able to, for their company, or if you need a more opinionated set should be able to go out and build that. And because I don't want to, because the reality is. In two years, it doesn't matter how dynamic your setup is, how your CLI works in two years, the opinions on what the right tools for the job is will change there.

Like the higher up you get in the stack, the more volatile the decisions are, and often the more opinionated they are. I want to focus on fundamentals. I want to focus on the. building blocks, and I want to make it really easy for people to do this. But I think people, users like developers will come in at all levels.

So there will be the ones who want to use solid start because it's simple in that, like it doesn't offer very much and it's, a great starter place for someone maybe who's never used a front end framework. They can just get started up, maybe into client side render mode. They can just go and just [00:28:00] do the thing that, other people did when they first picked up CRA.

But on the other end of the spectrum, I expect people being like coming in and being like, I need a full framework that does all my things and someone out there built that because they have the opinions and they put all the pieces together. As I said, people haven't checked out create T3 app.

The way that community works and the learning and the aggregation it's, it's, it was amazing thing to see a community effort like that. Build a framework. It wasn't backed by a company. It wasn't like, just the typical like most JavaScript frameworks usually start as one person, like myself with solid or rich with, so it wasn't like that.

It actually was a community that came together to build a framework of all volunteers. So it's very different to see like picture, it is, to be fair, it's a meta framework, like it's built on top of Next, so they didn't have the key building blocks, but I think we're going to just see more of this when the quality of the base tools just keeps on getting so much better.

Yeah. Yeah. It's like these kind of [00:29:00] these, it's almost like a super starter, like a starter that also gets you connected and integrated and plugged into all these other tools. Yeah. Yeah, that sounds super interesting. I could like, keep asking questions and dive into the, the practicality of these different delineations of the layers between the builder and the bundler and the server render and the framework.

'cause I feel like that's just like a super deep. But just to keep us moving along here, in this vein, is there a roadmap to 1.0 for solid start?

Yeah. The plan here is we need to make some shifts from where we were. We released the beta. Just about a year ago, I announced it to be confident and officially went out. I think the beginning of November we, a lot of people were expecting that 1. 0 announcement when I got on the stage again. And we turned down what the reality is we are going to do a second beta for phase one that, the intention is much shorter, but it's going to take these learnings. And we're in the process right now, as I said, of rebasing solid start on top of Vinci for the most part, [00:30:00] like the stuff in your source folder doesn't change, but some of the entry points and middleware, like the configuration server stuff will. So we're figuring out, how to get stuff close to where it was and also figuring out like what we do intentionally want to change here. So there's going to be a shift. It's funny. Solid Start went out as a beta a year ago and we actually haven't really broken anything in the last year.


Marker
---

You know, We gave all the warnings, be careful. People have been using it in production, some big sites as well. Stuff like post. news, which I think they have like almost a million users or something like, like decent, some decent sized startup sites and we're, but now is the time that we're probably going to do a few of those kind of breaking changes to do that.

So the plan is Solstar beta two. In the, there's a few pieces still working on some features around like what I was talking about, server function, RPC stuff, but I imagine in the next. I hate putting dates on stuff, but in the next coming, [00:31:00] month or so definitely before the end of the year we're going to have the beta two out.

And then from there, probably run that for a few months, gearing up to solid 1. 0, but this are solid start 1. 0, but yeah, this is the scenario here. We. We have lots of open issues, but most of them are in the same categories or groupings. And I, we're addressing this basically with a, it is a ground up redesign of the underlying layer.

As I said, it might not impact the developers or users as much but it is for us almost like a second. Shot at solid start but one that we're much happier with because it'll be much more maintainable as I said

Yeah. Nice. It's it's always good to hear when devs are willing and able to take a step back and change some of the underpinnings of work they've been doing to when they have the realization that things may need to change. So yeah that's super cool to hear. Is there anything in particular you'd direct listeners [00:32:00] towards to check out?

Should they just go in and look at the beta and get involved? What, like, where do you guys need help? What would you implore people to do?

Yeah, I the I think once we start doing releases for this second beta I it would be very helpful for people to come in and start trying their apps and Talking, features and trying these things, the challenges, I said, there's been a lot of bugs on the current one that haven't been addressed.

I think this is going to open up, it's going to open up different things that just weren't working before. Currently we're there's a GitHub discussion that I can link for the show notes that where the discussions happening, we're talking about features and the plan there which, get involved put your feedback, learn about what's going on.

Obviously the discord is great too. For that kind of discussion. But generally there'll be some announcements in the coming month or so about how you can get involved with the next version of Salt Start.

Awesome. Cool. Yeah. Again, we'll get links to the discussion and the discord in the show notes as well. Cool. Thank you so [00:33:00] much for coming on and chatting with me, Ryan. It's it's a pleasure as always.

I love coming on here and talking to stuff. pod rocket is definitely one of the, one of the ones that really likes to get into the details, which or at least doesn't stop me from talking. So, um, I'm very appreciative. So, um, I always love.

the good bits. Yeah. Of course. Of course. Anytime. Cool. Thank you so much.