Supper Club × Solid.js with Ryan Carniato

Welcome to Syntax, the podcast with the tastiest web development Treats out there today. We have a super good one. Have you ever wanted, a system like React without all the Complicated choices around things like performance or, you know, why can't our app frameworks be smarter and take out some of the pain while giving us full control over the UIs like we have? Well, today, we have Ryan Carniato to talk about Solid and how Solid JS is taking a modern approach to some of the framework stuff that we've been working on for a little while.

Ryan,

welcome. How's it going? It's Going good. I'm glad to be here. I've I've wanted to come on and talk to you guys about this for quite some time, so I'm very happy to be here today. Yeah. Likewise. You've been one of our most requested guests. People have been really loving Solid and wanting to hear all about it. So,

I think we're really psyched to really pin down exactly what makes Solid so interesting and special and and, just all about the work that you're doing.

So, Ryan, do you wanna give us, like, a quick introduction of who you are, what you're doing, but also maybe a elevator pitch 4 Solid. And why should people pay attention? Sure. Yeah.

I currently work in Netlify on open source, But that's only been in the last year, and that was to work on open source and solid JS. But myself, I was just a guy working in startups.

I'm I'm from Canada, Vancouver, BC.

And I was working in Sartre for, like, a decade, maintaining long lived apps.

And at a certain point, I was just looking at trying to streamline, the process of what I was doing at work.

We had a really old knockout JS app. Yeah. The guy who hired me was actually the the creator of Knockback, JS, which was like a backbone knockout thing. So we kinda had our custom stack, and then he left after a couple years. And then, you know, someone's gotta maintain the code base. And I went and I was like, oh, this could be better. And I was kinda working my, you know, my own time, and I Just built solid basically out of that. Just the experiences I had working in that kind of reactive system. Cutting it short, I I Basically had built like another reactive framework, in a time when, I guess, reactive frameworks weren't actually that popular. Everybody had discovered React in the virtual DOM. And I saw some benefits of what React was doing, but I also really liked what I'd always done.

And this probably wouldn't even got here. Like, I wouldn't be sitting here If it wasn't for a bunch of different aspects coming together, but, React went and released React Hooks in 2018, and it was like suddenly this light With Sean on reactive solutions, in general. Right? This is where view composition API is felt free. All these kinda originated from that. But in Solid's case, it's a little different.

We had those kind of primitives beforehand because that's what Solid is. It actually wouldn't work otherwise. We don't really have components in the typical sense, which makes Solid very different from a lot of other modern frameworks.

We basically had these hook like primitives, and then you can picture just, You know, minding your own business, doing that kind of thing, and then suddenly react like this is how you're gonna build apps in the future.

And, honestly, everything's been a roller coaster for me Since then Wow.

So how long has Solid, as an idea, been around? I made my 1st commit in a private,

Bitbucket repo in August 2016.

Cool. I was Wow. I was working on stuff, you know, throughout that year.

My my oldest daughter was born, in, sorry, in July 2015. And Sometime during that year of being, you know, half awake, half asleep Yeah. I just started, like, you know, going, oh, I'm awake anyways. Let's just kinda hammer on this idea. And I I I started kind of playing around with, you know, different reactivity and different approaches. And then finally, I was like, okay. Let's try and make something out of it. But it wasn't until 2018 that I open sourced it because I want to join some benchmarks.

But I I it was just something that I've been kinda like playing around with different ideas, because I, like, I want to kinda modernize,

knockout JS, really. I I really like that framework if you can't tell. Yeah. It's funny. Knockout, I just went to their website because I wanted to to, relive Knockout a little bit. Man, that thing has not changed.

It's The same old website. Which is incredible

because, like, if you look at it, they were like, interactive tutorials and whatnot, they were kinda like ahead of the curve.

Like, just like the whole teaching thing and they right off the bat, you know, you go through, learn about Observables and computed and, like, basic reactivity, they were really, quite ahead of their game at the time. It's funny to see it now, like,

Over a decade later. Yeah. It has that, like, very, specific, like, starburst aesthetic that I went nuts for in in this era.

It's definitely, hit me in all those spots. Yeah. Yeah. It brings me back to the, the old Jake Ray days of when this kind of stuff and What what else was of this era? CoffeeScript, Jickory Mobile, CentiTouch,

all those good things? Our our code base that knockout code base I was telling you about was written in CoffeeScript. I was writing CoffeeScript code all the way into 2020, around the time that eBay hired me because it was it was just like I was working on that startup, coffee script knockout, And we actually just started our big, you know, 7 year or 8 year rewrite, at that point, which some people find kind of amusing. We ended up going with React.

Even though I wrote solid, to be the pragmatic test to me is, like, after supporting this, like, small like, a home brewed library in our up for years, I was like, it's like, you know what? You know, like, I I can't do that to the developers again. Let's let's let's make a different decision. So we went with React, and then we actually end up Turning into React because it was around pre act 10. It was a little bit shaky with some, like, the features we wanted. We wanted all that modern suspense stuff and hook stuff. Because, again, we weren't We were knockout developers. That was the piece that we wanted, and it wasn't like it was just at the transition period. If it'd been a year or 2 later, I would have had a different answer. But it just you gotta be pragmatic at the time.

Yeah. I get that. Oh, yeah. And sorry. This was this was at the company you're at before eBay, or this was this was At eBay. Before eBay. EBay Okay. Largely uses an,

framework that is open source. You can go use it.

And that's what I worked on at eBay. Marco JS, which is, Yeah. An island's MPA style framework, which is incredible in its own right. They they basically had a lot of the modern island's out of order thing everyone's raving over the last year or so. Mhmm. Like, back in 2014. Like, that's how they moved their stack off Java to JavaScript. They needed to have that kind of performance For ecommerce, and in ecommerce, that matters a lot. Yeah. The the Marco stuff is cool. I just did a quick search in my,

inboxes. There's, I think it was Sean Gates. He's was he one of the original creators of it? He's been trying to get me to maybe not Sean something.

Patrick Item Steel is the one who who made Marco originally. He was the creator also of Morphdom, which gets used in a lot of, like, random places like Phoenix Live View and, like, Other kind of things? Oh, we just talked about that. Yeah.

But We're having a bit of a, like, a framework roundup on the on syntax lately. So it's it's Funny. All these different tools we keep hearing about. Yeah. So,

Sean Gates, I believe, was involved, but Patrick was the original, creator. And, he left in 2017, which is a hard hit for the team in the sense that, like, kinda left it in. There's only a couple engineers working on it, and they had to support all of eBay. And I joined the team around 2020, which was kind of an interesting Time period, for many reasons, but, on the tech technology side, at least, it was a time period when no one had even heard of this Kind of technology.

Really no one paid any attention. This is, like, 6 months before Jason Miller's Islands article. This is about a year before Astro came out. And I was like, wow. How can this exist? And I was I was starting to write about it and get people excited, but, like, it takes a lot.

Something I've realized over the years. Even with Solid, like, I wasn't trying to get it like, it wasn't, like, improving on React. I was just doing my thing.

If I had tried to push solid before hooks came out, I I don't think anyone would be paying attention. Like, that's that's kind of the reality of these things that it takes The whole ecosystem to kinda move.

So that's something I just watch or pay attention to, if that makes sense. Yeah. Totally. Yeah. Yeah. So let's talk Solid.

First off, I guess, do you wanna give, like, a what is solid to the average developer who might just be, you know, hearing us talk about all these frameworks? What is solid? What sets it apart? What does it look like to write solid? Right. I mean,

when people 1st see solid. They definitely, think of a few things, and it's usually because the way they've been told about it or what they see. And one thing is, doesn't this look a lot like React? And the other thing is, like, I heard this is really performant. It doesn't have a virtual DOM. And both of those things are great.

Being familiar and being fast are good things.

But as I mentioned before, like, Solid didn't come around, to be like, improve on React. I you know, because I like those libraries before. I just pulled elements from different places.

So, like, if you come in and use Solid, you're gonna be immediately presented with your 1st primitive. Kinda think of it like a hook, And it's called create signal. And that's kind of the core of your experience here. What we have is reactive, primitives, which are basically Stateful variables that can automatically track an update and JSX.

These 2 elements kinda come together, And that, forms the experience, which is pretty important to us because, a lot of reactive libraries don't use JSX. In fact, they use, like, Custom template DSLs, and there's there's there's a reason for that because, there's reactivity runs differently, than, let's say a VDOM library does. So there's there's different kind of considerations that go into designing, how that looks. But for Solid's case, I really, really wanted to emphasize composition, building blocks. Like, the idea is, like, you have these, primitives. Like, if you use create signal, you could also make Create local state signal or whatever or local storage signal. Like, basically, this ability to just kinda build up on the base primitives. And We extend that kind of mentality not just to, like, our hooks, so to speak, but to our control flow. Like, if you have a four loop, you know, or map function is what they do in React. How easy is to go from that to a custom one like paginated, or virtual list? And what I came to realize is we almost always just end up with components in this case. So Solid very much kind of builds on this idea that, I guess it's idempotency in framework design in the idea that the end user should be able to create the primitives that that's library ships.

And that, you know, is an interesting design Choice and what makes Solid is what it is. But the other piece, and this is the part that's not as obvious to people, is people also hear That Solid uses a compiler.

And that is true, but maybe not in the way that people kind of associate compilers this day.

Solid uses compiler to transform only JSX.

And for the most part, that means that We aren't changing your code outside of the JSX. We're not changing, like, all your declarations.

We're just kind of Using a different transform than, like, how React does.

It's actually kinda similar to React. Our mechanism is actually, like, 90% runtime. It's not actually compilers doing the things. It's very important that the pieces are composable. And with compilation, it's sometimes difficult To analyze everything ahead of time, you need very strict language. You need very strict guidelines to figure out how to do that. And we really wanted are primitives and our experience to kinda be built from these building blocks.

Nice. Okay.

So when you say that it Compiles to it says I think it says on the website, compiles to vanilla JavaScript, which is, like, we've talked about that in the past. Like, something like Svelte will compile the vanilla JavaScript.

So what does that what does that mean in the context of

solid? The what it means is that, like, all GSX is transformed. So most of it uses this thing called hyper script, which is like a series of function calls. In Solid's case, we can look at the shape of your templates exactly, like things like the DOM or, you know, like, where you have a bunch of Native elements like divs and spans or whatever. And we can go, oh, this is the static parts and this is the dynamic parts. And we can kind of Separate them out. So, essentially, what the compiled output ends up looking like is, like, here, create these Dom elements.

And then where where there's these dynamic holes, use reactive primitives to update them. In fact, we have something installed called create effect, Which is kinda like useEffect, and people might be familiar with that, except we kinda welcome it a bit more in solid.

In that, that's all we do. What if someone looks at our code, generation, they'll see, like, basically, like, create Dom elements and then around each expression where it could change, it's it's a create effect. And I feel like For people kinda coming in to looking at Solid, it feels like very not magical, like, very more much more, like, transparent because you're like, oh, Yeah. Like, if I was writing this by hand, this is what I do myself.

Like, the compilation doesn't do something unexpected. It's like If someone didn't have JSX or didn't have all these kind of modern templating things and that you're writing a jQuery style, I would just write it like this. And that kinda A scale up, scale down kind of thing on Solid's design is really quite powerful because it feels very close to the like, as if you could just run it like jQuery, you're like vanilla JS.

But then you you write code that looks like React. Makes sense. Makes sense. That that's actually really cool to me because I I often Demos and and little projects and whatnot, I'll just run it straight up in in vanilla JavaScript.

But then I'm like, I kinda want the reactivity, you know, and it's nice to to have that option. It's it's kinda cool that you can even look at the output of it and kinda see what it's doing. It's just Creating DOM elements and then where the like like, let's say you had a span with a number in it, and that number could possibly change. You know that ahead of time be and then you'll you'll Set up for that? Yeah. Yeah. I mean, it's actually really simplistic, heuristic. It's kinda surprises people. It's because JavaScript doesn't have reactive primitives in the language. You'd have to do, like, a lot more transformation, and, like like, sell those exact to to do it.

So I can guess if something's gonna be reactive if it calls a function Or accesses a getter, like a member property. So all Solid does is when it sees, like, variables being passed in, it goes, okay. That can never change or statics that can never change. But if it has a function call in it, all we have to do is go, okay. If it's in the in the dom, wrap it in a create effect.

And if it's in, like a component prop or something, we just wrap it in a getter. And this little trick lets us kind of lazy evaluate the whole Tree, it's it's kinda funny how that works because props are just getter functions. So everything just functions down. The only code that gets called in the end is work. It's finally consumed in, like a hook or in the DOM. So that span that you were just talking about, if it read, Like, props dot count that's coming in from above and you're setting some stuff above. The only code that needs to rerun there is that effect that's That's reading that that, that that count variable. It might call some functions to pull it down through the component tree, but no components rerender. That's sort of what I mean when Sola doesn't have components because there's no component instances.

It's literally just a bunch of function calls that are just nested in in each other to kind of set up the tree. And then once it's set up, we have reactivity to give us super fine grained react updates.

So it's a very different type of renderer because even even most other reactive libraries still have, like, a component instant. There there there is a there is a component somewhere,

and we don't. So from so far in the user's perspective, they're getting performance of not having to worry about that entire tree rendering. Right? That's like, one of the things they just get for free without having to, have to put the qualifications

into their code intermediary steps or anything like that. Right? That that's the the the incredible part about it because you just write this and you get that modularity of still breaking your code into, like, components, so to speak. Like, you still break everything apart. But because it all kinda just runs through the system, the benefit is, like, you just kinda author things the way that makes sense to you, And now those are the things that update. You don't have to really worry about it. And because the reactivity is Kind of like not tied to the component system at all. You know, that's one of the challenges of the compiler. You almost always tie the reactivity to the component system.

Global state, local state is all the same. Like, it it there's no difference. You just create a signal. Wherever you put the signal, it works. We still use patterns like context that you might find in other frameworks.

And this is because it's powerful that can have hierarchical Tree ownership of things.

But the the cool thing, again, with Solid and its approach is you just create some signals in that provider way up in the tree And use them wherever else in the tree, and, like, only the things that use them will update. There's no, like, rerendering of the tree. You know? Like, you could put 60 FPS Animation in your context and not even think about it. Nice.

That's, like, one of the worst parts about context in the context API in React. Right? You have to be Very cognizant about how you're using it,

or else you could cause a ton of rerenders that you didn't expect. Yeah. I mean, it's it's just it's it's one of those kind of things where, like, I felt in the last couple years, it just keeps to be these examples where see, I'm a big fan of React for those who don't know, and I Really like that there's different philosophies and approaches to how we can build you eyes, you know. And it's kinda like as old as, like, in graphics, there's this idea of, like, immediate mode versus retained mode. On this idea of, like, things that, like, immediately do updates versus things where, like, they store a model in memory and then you kind of Update the model. Like, there's always, like, those kind of different models that improve performance or, like, simplify your mental model. So I like that these different things exist. But one of the more interesting things I found the last couple years is a lot of the patterns that we've come to really, depend upon and react actually work really well in reactive systems. Awesome.

Can you talk a bit more about I think this is just a concept that a lot of our listeners would like to learn about is I I think that you use observables as well as what these Signals are, like, the ideas behind them. Yeah. Signals is a funny thing because, yes, the the this whole thing started

from my perspective because, the water had gone too muddy, so to speak.

Observables are generally what is called, like, the reactive atom, like the most Smallest piece of state that you can have in a reactive system.

But the problem is everybody started using the term observables even with different styles of reactivity.

And the I I couldn't differentiate them, which was the problem because RxJS happened to get fairly popular, and It uses observables to describe streams, which are not the same as observables are in knockout. They're they're actually very different. An Rx is a different term for what observables are in, like, knockout or mob acts. They call them behavior subjects. Like, it it and I I I was just not having this conversation because I didn't want that comparison.

So I was looking around for names, and one of the libraries I was really inspired by, called SJS, Call them signals.

And Elm actually early on had signals as well. And, basically, from that point. I I was like, okay. I'm not calling these observables. I'm not gonna get into that mess. I'm gonna start calling them signals.

And and I started Kind of referring to this type of reactivity as fine grained reactivity as a way of differentiating from, Rx. And to be fair, that's not, like, maybe the best descriptive term. It's just I was use this reactivity allowed you to do really Fine grain updates easily. Whereas something because it auto tracks. Where something like Rx does, it it's like piping streams, and it generally lends Action more to libraries using things like virtual DOMs or diffing or wider kind of updates just because of it's a pain honestly to wire up all the Little updates. And if you aren't familiar with our ex, this might not make a ton of sense to you. But I just I wanted to split the the the the water, so to speak, and be like, you're here and you're here. Because even in Rx, these are different concepts.

Yeah. So I just went with it. And it's kinda cool because it kind of Differentiated. We fair, Vue has a style of reactivity too, but because they didn't make it into primitives originally, it was part of, like, an options API hidden away. No one's really talking about this.

You, deserves a lot of credit, also being in this kind of world of using this reactivity.

But, yeah, the last year or so, suddenly, you you can't go very far without hearing about signals because pre act, adopted signals, quick adopted signals. I think Angular is even looking at adopting signals at this point. Really? Yeah. And I guess this is one of those things, like, what's in a name? Like, finally, we got a name where it's, like, clear, like, there's no confusion about, like, this is Rx and this is this type of reactivity. So I don't even know what's the the best name. Sometimes I think they should be swapped.

Like, signals maybe sound better for a stream. I don't know. But it is what it is.

Interesting. So if if we were to, like, clear up what signals is, it's signals is Reactive state that like like other pieces of the application know when that state is updated. Is that what that is?

You can tell me I'm totally wrong. Yeah. Okay. Yeah. Fair enough. I I wanted a it's like an history lesson here instead of actually answering the question. Love the history lesson. Don't worry. But, Yeah. It's good. Yeah. Signals, you can picture as, like, an atom of reactive state. And the key part of systems with signals is that, Usually, there's at least there's usually 2 other pieces of the language, so to speak. There's the idea of derived data and the idea of side effects. And the whole key to the signal observer pattern is that you use When you use it with these derived values or with, the side effects, reading the signal in the context as in accessing its value underneath The, the function where those are executing automatically tracks the updates. So you don't need dependency arrays, and you don't need a compiler. This is not a compiled mechanism. I mean, it's literally just using the runtime stack. It's like like what those things do is, like, they're like, okay. I'm gonna run a tracking effect, essentially, something that listens for signals. It just kind of put something in the global, and then anytime a signal is read under that global, it's like, oh, hey. This effect's running right now. You should Add it to its dependencies, and you can just picture it like adding it to, like, a set. And then next time when the signal gets updated, it just calls all those functions again.

That that that's kind of the core mechanism of of of it. Okay. So it's it uses the fact that everything runs once. And then once it runs once,

it can run again because it just keeps track of what it what happened the last time it ran. Is it is it fair to say that is Kind of similar to, like, at event listener and, like, clicks,

where you you throw something I guess it's not not global, but is is that somewhat Similar or or not not People like the Pub Sub comparison as well where you I know, like, yeah, I've used, you know, message streams and or message queues and all that kind of stuff. The I think the biggest difference is is in 2 ways. First of all, signals have a value to them.

And this is part of why I was saying they're different than RxJS. Like, you at any point, you can read them. Like, it's called poll, but you can, like, read The value. So you you kind of view these as variables rather than like a container that passes messages. It changes the way you write stuff. And the Okay. The second, difference is derived data can get complicated and messy and side effects writing to other signals. And we we you can get into this mess, and this mess is actually what existed in knockout JS and kind of aided in its departure from mainstream Front end.

What happened though since then is, libraries like basically solve this where Instead of viewing, der deriving values. And by deriving, I mean, like, pretend you have count, now you have double count. Like, the idea of, like, you could create something that It's based on that other value, but it's also a value itself or, like, I don't know, like, taking it from first name and the last name and having a full name. And in the case of Solid, this is actually even the way it renders. Like, we use these kind of dry values to do control flow. Like, how we, like, convert up, like, a 4 loop into a into something that gets inserted in the DOM. Yeah. These these this kind of, approach It has to not just like butterfly effect on you. And one of the biggest innovations in the well, it's now, like, 7 years old is the idea that we actually can ensure That each function only runs once on a given change set of changes. So and it runs in order to make sure that, like, all the changes apply at the same time. So, Basically, there's a sort of scheduling topological sorting mechanism built in. So that's but a huge piece of signals. Like, there's no diamond problem where, like, You prop it like, you send a bunch of messages out and then they converge and they notify too many times. Everything like like, if you from the same set of changes. You know that everything will run once, and that gives you a huge amount of predictability and guarantees. And that's something you don't find in a normal event system.

We actually, like, trace through this, like, reactive graph as we often call it. Yeah. That was that was fantastically

put.

That makes a lot of sense. Taking a slightly different direction. One thing I noticed, is that you describe web components as first class citizens In Solid.

And I I wanted to know, like, what what does that mean in the context of how how web components get used inside of Solid And look what makes them 1st class citizens. Right.

It's it's funny. I think some of that copy is from much earlier days. I was a Big, big web components proponent. And I Solid did the reason Solid doesn't have components today is because of web components. I I credit I was I was in that wave of people like, oh, now Now that we have web components, we can kinda, like, create our own framework to do work the way we want. And then maybe in a few years, the browser will add a bunch of stuff, and then we won't even need frameworks anymore. It's like, that was where my my head was at. I was like, I tried to make our reactivity based off some, like, object dot observe spec, and, like, later on, there's a observable spec. Was trying to, like, really align with it. So all the early work of Solid was around support for web components. I I do stuff like our portals Support Shadowdomes, so that you get the if if anyone's worked with web components with portals, it's it's kind of a pain to get the styling to, like, inject through in the way you want it to. I I I was, like, taking considerations of that. Our 1st version suspense worked with web components. Like, it actually was able to grab the elements and stick them on on an off screen document so that we could trigger the right, DOM events. Oh my gosh. And and actually make it make it work. Oh, wow. To be fair, that doesn't happen anymore. We do have solid element, which makes it really easy wrapper, and we do support stuff like our event delegation works through, bubbles through the what do you call it? Like, the web component boundaries. Like, we actually, like, reverse the They they do something where, like, they try and isolate it. We kinda reverse that so we can still make it work. Like, there's a lot of consideration we gave to web components in the design and handling of them because of that those early days. I have to admit, the web component side has not got the latest features. It has not got server side rendering and hydration.

It's not got,

transitions and concurrent rendering and any of that kind of stuff. So Yeah. It's funny. I just saw that. And it's like it's just like one of those things where, like, The promise of web components has never, like, truly matched the the actual

the experience of it, and so it it was interesting to see. That that's the question And I wanted to ask, why aren't we using web components? Because Scott and I, for years, were like, oh, yeah. Maybe we'll get into web components. And then then recently, We've been starting to look a little bit more over at them, but, like, oh, maybe they maybe we should be checking them out. But, like like, why are we not

all using web components? Do you have do you have any thoughts there? I have a few. I think it's Mostly that the there's, like, a mismatch of expectation that can happen. When web components are first presented, we were looking for something. We were looking for, like, okay. Now that we're like, it was early days for us building full apps in the browser. Like, really even though Ajax was, like, 20 Yeah. 2005, I wanna say.

And Chrome and, you know, SpiderMonkey, you know, be it. Like, all the performance stuff happened around 2007, 2008.

Like, It it took a while and then, like, the 1st real JavaScript frameworks was, like, 2009, 2010 time period, like, in terms of, like, full frameworks. I know there's, like, Mu tools and stuff, but I mean, backbone or angular or whatever. And so web components are coming out of that world in, like, 2012 kinda time period. And I think what we wanted or expected To solve there was a little bit different. And, like, it's kind of unfortunate that there's the word component to mean what we mean in modern Frameworks and what it means in web components and those not being the same thing.

And I think what we've seen over time is that Even the frameworks that are very HTML first, you know, kind of, you know, give this feeling of being closer to the DOM, you know, stuff like Marco or Svelte or whatever.

They've they've moved over time even further from some of those, like, semantics. Things like slots, for example, are eager in In the DOM and not in frameworks because we've realized, oh, we wanna orchestrate stuff better. We have we want more control. And I think we've just seen this divergence essentially where There's a difference between wanting elements that do stuff, which is what web components are, and writing modular code, which orchestrates applications, which is what components and frameworks are. Like, they they basically have different ranges of expectation in use. So I feel like If there's probably places where I want web components. You know, things like widgets and, like, the Zendesk thing that's popping up in the corner or, like, Maybe, like, some kind of design system where I was like, okay. I'm gonna make these kind of things that are elements. But treating them as frameworks, Like, in that sort of way, there's kind of like this mismatch. You can do it.

But the challenge is that, at least what what I found is, like, You're just kind of adding this DOM element overhead and extra boundaries in a place where you don't actually need any of that. And that was a big revelation for me because I was, like, building everything in web components, and I was, like, benchmarking and scaling stuff. And then I was just like, why am I putting all these extra Dom elements here that I don't need. Yeah. And it's funny. I mean, that aligns with my experience too where, like, I, you know, prefer to write everything in a framework. But now, like, the things I use a web component for would be like a video streaming element. Right? Video streaming has edge cases. It has JavaScript That's required. It has UI things that I don't wanna have to deal with it.

Throw a web component on there. It's an element, and then it it you know, the framework Can orchestrate every everything else.

Do we wanna maybe get into solid start a little bit? By the way, solid start, Awesome name.

Just about as as good of name as you can have for this type of thing. So Yeah. That's fantastic. Start being what I, consider or what people are maybe calling, like, a meta framework, an application framework for building things in Solid. What's situation in which you would pick solid start versus picking solid. Right.

That's an interesting question, and it's something that I've been kind of, like, working out, over the last Couple years, I I've been working on solid start for a while now.

It came out because I