Ben: Hello and welcome to PodRocket. Today I'm here with Ryan Carniato, the creator of SolidJS. How are you doing, Ryan? Ryan Carniato: I'm doing pretty good, glad to be here. Ben: Yeah, glad to have you and we're still early in our video podcast journey here. So, for the avid listeners, watchers, out there, you probably see my newly redesigned plant-themed background. If you have any feedback on our video format or production value or things like that, definitely let us know in the comments. Ben: But Ryan, today, I'm really excited to learn about Solid. So maybe you could give us a quick intro to what is Solid and how does it help people build great web apps? Ryan Carniato: Yeah, Solid is a JavaScript framework, declared JavaScript framework, very similar to React or Vue or Svelte and there's no shortage of those. But a while back, several years ago, I just started on this journey of creating the experience that I was looking for. I was actually a big fan of a lot of the earlier JavaScript frameworks and stuff that came out before React. React came in the scene it and just complete displaced all of those. It had good reason to, but I thought I could take some of those older paradigms and modernize them. That's really what I've done with SolidJS. Ben: What are some of those early frameworks that you really liked? Ryan Carniato: Yeah, for me was KnockoutJS was probably the most standout of that bunch, but there was a few other of these. The key part was they were based on this idea of reactivity. Basically you had observables and then they would automatically subscribe and update your view without much consideration of structure, which is the problem and why that they got displaced over time. But there was something really freeing about how simple the model was. I was a dotnet programmer through the 2000s working asp.net and had all these giant isomorphic life cycle function, C Sharp code that would hide the JavaScript on you. Around 2009, 2010, we saw this change where we were getting actual JavaScript frameworks, things like Backbone and Angular. A lot of those took ideas from the server, like the NBC thing. Ryan Carniato: Knockout was a little bit different. It was just basically completely event driven almost and granular. For me, this felt really freeing. It was just like, "Get rid of the components, get rid of the life cycles and stuff." Honestly, when React came around, they brought that back and that wasn't really where I was at. I was much more on composition, you know, building small building blocks and composing behaviors around those. Ben: Maybe tell us a bit more about the architecture of Solid. What did you take from those earlier frameworks like Knockout? Did you borrow any ideas from React and how did you improve upon that prior art? Ryan Carniato: Yeah, exactly. The base concept was like Knockout. We have these concept of observables. I actually use the term signal these days because RxJS has claimed the whole observable thing and they're a little bit different. They work like simple event emitters, they're not unlike streams, but the difference is a signal actually holds its value and can be polled for that value whenever asked. It's not just a push based system. Ryan Carniato: But yeah, I took that reactive core, but the problem with that was, and this is the classic problem you see when React was introduced and they introduce flux, there is this conversation about how the old Facebook messenger could never remember if it's seen your notifications. That was like, and that was because stuff, messages are bouncing all over the place. So what has kind of happened in the meanwhile since those days was MobX came out, it's a state library for React, and we've kind of seen the ability to take that reactive model and streamline it in a way that is predictable and synchronous. Ryan Carniato: And really what I did was I took that sort of predictable reactive execution and then took concepts from React like you unidirectional flow and kind of read-write segregation and built it into something that looks a lot like React. You more or less have function components with JSX. And you just write your state using these primitives, which happen to look like React hooks. And for most people coming in, they'll just kind of see React. But actually underneath the scenes, it's actually quite different. The JSX actually is compiled to something slightly different. It's compiled into these fine-grained reactive computations, I'm going to call them. But more or less for a React developer, you can almost picture like your view is getting drawn with use effect. Like I'm compiling the JSX into a bunch of use effect commands. Ben: And under the hood, like, are you using a virtual Dom like React or I'm not positive on this, but some of those previous frameworks like Knockout, I don't think they had the virtual Dom concept. Ryan Carniato: Right, right. Exactly. The virtual Dom didn't exist back then. And even like early versions of View, didn't use a virtual Dom and they were reactive in the similar way knockout was. View two they completely cemented on that virtual Dom approach and continued into View three. But for solid, these reactive primitives are really all you need to update something. They don't really care what the update is, right, to them everything is a side effect. That's why I was mentioning like using effects to render. More or less you just have some data, when the data updates run that function, and that's overly simple, but it helps kind of build the mental model here because what it means is we can do whatever we want in those side-effect functions, more or less. And the whole key here in the approach is we keep things granular or fine-grained is a term I like to use. Ryan Carniato: So instead of diffing large immutable structures where you basically like the B-Dom, the way it works is you render top-down and you create a whole tree. You know, maybe it's a partial tree cause we kind of know that whereabouts which components update, and then you compare it to the previous tree after you've done that. And then you find all the little differences and you update the Dom. Where the approach with Solid is that kind of information where stuff updates is in the data. So when you update one piece of data here and maybe some piece of data, somewhere else, it's already directly subscribed to the exact spots in the Dom that needs to be updated. So you update the data and then it just calls, it basically calls the function to update the Dom. There's not much in the way of reconciling or diffing or whatnot. So it's the reactive permanents and cells that basically memorize or hold the values that we need for comparison. Ryan Carniato: So we do some shallow comparisons, every framework does diffing or comparisons to certain degree. And you know, if you're dealing with a race sometimes is a little bit more complicated. Some items might've moved or whatnot, but generally speaking, we don't need a whole virtual representation to compare it. We just, almost like one for one pinpoint update. What depends on the data you update. Ben: And can you have component level state in Solid or it's all like a global kind of globalized state that is passed down throughout your hierarchy? Ryan Carniato: Yeah. And then we can, how do I put it? Our components are just functions. So it's a bit misleading, but you write it the same way because the idea here is while I don't put much value in the componentry, the big, I guess, innovation in the approach to solve it over MobX or even View or other people kind of playing with this fine grain stuff is we nest our effects. If you view all rendering as a side effect, then, and the way reactivity works, it only cares about where the value is read. Ryan Carniato: So it only updates or reruns the function closest to where the value is read. You can actually kind of, it's hard to visualize obviously, but you kind of onion your layout, where like components, where you have components and components, components. We kind of have effects and effects and effects. And the only difference is those effects originate from dynamic decision points. Like maybe a condition in your JSX instead of the components, we kind of flatten the componentry in those places. Ryan Carniato: But what it means is, when you create a signal or, you know, some state underneath one of those effects, when you reexecute that effect, you are basically throwing away that state and recreating it again. So there is a sort of ownership, it's just not directly tied to the components. Instead it's tied to your apps structure, basically it's the control flows. It's the decisions, the dynamic points in your code that actually are the boundaries. Ryan Carniato: And this works really well because we're not adding an extra extraction. We're not adding extra boundaries, like in a framework like React, it's when you're optimizing, I don't know if people are too aware, but you actually break components apart on purpose for memorization purposes. You know, that you're like this part updates. I want to isolate that change. Dan Abramov had a great article about like when to use memo or, and this is the same kind of concept here with any v-dom structure is you usually have to kind of think about, okay, I want this row item to update independent of the list of rows. Ryan Carniato: So I'm going to make that a separate component and these kind of structural things matter, whereas with Solid, and this is actually pretty unique to Solid almost even than other non V-Dom libraries. This isn't true they're they still work components, but with Solid because the control flows dictate where those boundary points are, we don't really care how you break up your components. Like essentially you just build your app and we'll basically optimize where all the switches happen and where all the boundaries are. Ryan Carniato: So this is a big part of the performance piece. And it's also, as I said, why I can't, it's a long answer to explain whether components can hold state because they can't, but it doesn't matter because in Solid component renders once, you know, so like when you choose to have a condition and it's show don't show, when you go to show it, it's only going to run down that side of the show side, once it's not going to rerun that whole part of the tree. So it will sit there and be used in all the closures and basically like build up your Dom view and just be there for you to use until you switch it to off. And that will cause something above it to rerender and free it all, but it's not the component that's doing it. It's actually the way you architected your application. Ben: Got it. So moving on for a bit, one of the, you know, one of the best value props of React in my mind is the incredible ecosystem of third party tools and plugins. To what extent are tools and the reaction tool chain compatible with Solid, and, you know, if kind of any key differences, where would you, you know, not be able to use best in class tools for React system? Ryan Carniato: Yeah. I mean, that's the thing. And people, people kind of are surprised by my answer here because I didn't actually build Solid because I was worried about adoption or thinking about that. I was literally going, I like this paradigm. I think it is good. I think in a lot of ways it improves on things. So ecosystem and compat were actually the last thing that's on my mind, which is kind of unusual perhaps. But, there is some in there, there is some not. Basically anything that relies on React's execution model, basically is a no-go. It's really difficult to play both execution models on top of each other. They're just that different. It's like, there's just expectations. Even when the hooks look the same because of Solids, like only the hooks rerun and reacts the components rerun, you instantly hit this kind of incompatibility, just because of like with React, you have to be aware of like stale closers. Ryan Carniato: You can keep, you can refresh the state outside of the components and have different state in the different hooks. Like those kind of considerations aren't in Solid, which means that we can't just use the library. So there's no like simple compilation work to transfer it. We have to kind of port them, which for simple components is dirt simple because simple components do genuinely just run that way. Ryan Carniato: But once you are using use-Raf for not a Dom node, you've probably hit a zone where the React component is not executing like Solid. Cause Solid does not have user app for use callback. And obviously not using use callback with Solid has no downside. You just hook up the, you know, the event listener or whatever it is, and there's no issue. But use-Raf has significant execution meaning, and there's just no analog with U Solid. Ryan Carniato: It just doesn't make sense. It would just be a normal variable. And once you kind of get into that zone, you can't convert it. So yeah, there's no React compat. It's not like you just slide this in, you know, Preact or Inferno, you can almost just like hit a switch, alias, the things, we can't do that. But what we do get to leverage on the community is tools that are kind of closer to the build system, right? We're using JSX. So TypeScript, Prettier, you know, those are easy for us to interface with syntax highlighting. I never had to worry about any of that. You know, some people came in recently asked me with a language server and I'm like, I never touched language server. Honestly, it, it just worked out of the box for me, you know, ES Lint and all the, all the kind of tooling pieces. Ryan Carniato: And this actually applies a lot into a lot of CSS, CSS and JS tools, you know, Tailwind, all the compiled tools, all of those kind of things, things that look at JSX even. There are a few exceptions when the like emotion has a thing where they try and take over the JSX pregma, like actually be the one rendering the JSX. We can't do that. We have a separate babble transform. So we can't do that. But generally speaking, all the CSS and JS solutions, state, generalized state library solutions, things like XDate or Redox work fine. Ryan Carniato: It's just the stuff that is like in component, essentially. Like the hooks themselves will, are not compatible with Solid, but everything that's kind of not relying on the hooks, which is, as I said, most things are so it's, but you know, we've recently seen things like React query kind of isolate its core and not be react specific. Right? Ryan Carniato: The core Apollo is actually a graph is an like almost like an RXJS style GraphicQL client. So there's stuff there, but like I said, what we're missing then is that integration layer that wrapper and those, you know, need to be written. And sometimes I just kind of whip them up in an example, but, you know, realistically, you want someone to be maintaining a package and like being accountable. So we're still building out that ecosystem. Ben: And how does performance for a Solid app compare to React and View and or maybe even some of the more performance focused, you know, React kind of spinoffs like Preact? Ryan Carniato: Yeah. Yeah. I mean, a lot of things go into an app and its performance. I'm going to be the first one to tell you that architecture takes a huge piece of it. Just the way you structure code. The biggest places where people lose performance often is how they parallelize data fetching, lazy loading, all those pieces. There's a reason why, like NextJS and like those kind of frameworks have been gaining a lot of popularity recently, just because it's complicated. Right? Ryan Carniato: And I've been building a lot of our solutions for Solid to account for those kind of pieces. That being said, if we get past, you know, the, you know, the architectural thing, assuming you're doing the right patterns and whatnot, Solid's approach is fairly lightweight in a sense because everything is built off these reactive primitives, it actually reduces code quite a bit. Ryan Carniato: So if we're talking, just bundle size, it has a really nice story, right? Solid you might go over the repo and see that's like 6.3 kilobytes. And you're like, oh, Preact's only four kilobytes. But it's, generally speaking, I mean, it depends on how you build your app. But most people who build Preact probably add Preact compat or they add Preact cooks. Preact is very granular into what pieces you use. If you just use the core library, then that's fine. Ryan Carniato: In my experience, generally speaking, Solid is very comparable to Preact in size, generally speaking, and maybe just a tiny bit smaller in most things. Svelt is definitely smaller when you do small apps, but Svelte ox compiler makes bigger components. So I have been, I saw some great articles. Someone said it, I love that to do NBC is basically being used the unit of measurement, but there's a comparison that showed that, like, if you put 32 to do MVCs on the page in Svelt, and 30 in React, that's the tipping point at which React and Svelt become about the same size. And Lou did same thing. Ryan Carniato: And he said that, and he found that with View, it was 19. And if you're doing SSR is actually 13 because Svelte's code for SSR hydration gets significantly bigger. With Solid, that number is about two and a half. So basically once you get past like making to do NBC, Solid will be smaller than Svelte. But that's like size. It's funny, cause stuff like that actually probably ends up impacting more. Although my passion has always been on pure execution speed and like Dom rendering. And that's definitely where Solid has had, you know, a bit of an edge. I've really focused on raw rendering speeds. And obviously that benchmarks well, but it means that Solid, like, you know, spitting up, like, I don't know, a thousand Dom elements on a page or, you know, something along those lines, something that you see like an initial load. Ryan Carniato: Solid's performance is quite nice. It's easily, you know, 20 or 30% faster than most other JavaScript frameworks, like including the clones. And then obviously React, in some tests, I've seen it twice as fast. But that's that's on the client side. The service side is actually more interesting. No one really pays attention to it because I haven't really hyped it, but Solid's raw string rendering. Because we compile the JSX, we get kind of, we can kind of choose what we can compile to. Ryan Carniato: And we actually compiled differently on this client and server. And we actually swap out the runtime a little bit. So it's not reactive, which is kind of crazy. But in the end, using Solid on the server with JSX is very similar to using pug or something. Like we basically remove the framework overhead. And in many, some basic tests that we were doing, Solid was easily 10 to 12 times faster than most of the other JavaScript frameworks, especially like React or Preact in terms of server side rendering. Ryan Carniato: So there's a lot of elements when you talk about performance. Architecture is going to trump anything I said at the end there, but I wanted to kind of walk through the pattern there because it's very easy for people to pick up Solid, make a small sample app and go, wow, it's so fast because of in micro benchmarks and micro tests, because the raw rendering is so performant, you know, people come onto the discord occasionally and they're just like, oh, look, I made this happen. It's, you know, a third of the size of my previous React app and it's, you know, this many milliseconds faster. Ryan Carniato: I get those stories a lot. But, I honestly think in most cases, people weren't optimizing one of them it's too easy for people to kind of come in and go, like, here's some old app that I already wrote. And then now I know a bit more and I wrote this new app and it's faster. I think a lot of these comparisons are slighted one way or the other. That's why I do like the JX framework benchmark, because it's actually maintained by a lot of maintainers. Ryan Carniato: You'll see like when View 3.2 came out, Evan Yu went in there and made the PR himself. Like, and it's good for us to help kind of, I think it's better for the framer authors than the actual end users to get an idea of like how we've improved performance on this, you know, in the various places. But as I said, I mean, I gloat a little bit, but Solid is like the fastest on that. It's only about 7% slower than VanillaJS. So it's closer to VanillaJS than it is to the next, most popular framework in terms of performance. So, you know, it's fast. Ben: It's fast. And so, Solid hit 1.0 about two months ago, I believe? Ryan Carniato: Yeah. Yeah. End of June. It's taken a while to get there. Definitely. Ben: Yeah. Well, I mean, congrats on that milestone. And how do you kind of see things evolving over the next couple months or the next year or so? Ryan Carniato: Yeah. Yeah. The funny thing is like most of the course thought that Solid was ready for 1.0, back in January. I mean, I've been talking about it for like two years and then I was finally like, okay, it's time to go because I kept on wanting to do more. And mostly there's been a lot of advances and server rendering. I wanted to make sure that our solution was good. Basically. I wanted to, you know, React 18 coming and you know, there's a lot of changes coming out there and people are playing with stuff. And I wanted to make sure that the core of Solid's APIs wouldn't have any major breaking changes right away to chase those. So I actually kind of already implemented a streaming SSR and, you know, a few of those, you know, kind of features kind of coming up in the future next year in React. Ryan Carniato: I went ahead and implemented Solid, you know, through last summer. And I, now that we're there, we still have more work to do as people can build on those API's because they're stable, but there's basically a couple of key things that we're focusing on. The first is we want to make it easier for people to work on Solid. We have like a simple beat starter, but we are working on something more to kind of like server-side rendering story. People come in everyday and like, how do I server-side render with Solid? And the answer is like the same as almost every framework. It's actually tricky. You got to configure two different builds and have them talk to each other and like do all this stuff. We don't want you to deal with that, so we're building Solid Start, which is kind of like a starter template. Ryan Carniato: And it basically, it will have, you know, easy adapters to deploy to different environments. Like we already have a working demo with CloudFlare and, you know, NodeJS works and, you know, there's a of platform to kind of work with and it'll support all the different methods of server rendering with Solid and Hydration. So we feel like that's really important to get a really solid starter, so to speak. And we pulled a lot of influence there from like Remix, run from React and Svelte kit. Ryan Carniato: So that's kind of the elements that are kind of coming together, but that's a big project that's taking months. And it's funny, it's not the core stuff so much, you know, like we have the streaming rendering and all that kind of stuff. It's more of that it takes a lot of config and management to build these things to be generalized for every solution. Ryan Carniato: Like this is not my forte. I'm not going to lie. I enjoy solving the tricky problems. So coming up with something that, you know, someone doesn't come in and be like, you broke it on windows again. I did break it on windows again. It is definitely a challenge, but yeah, over the next few months we're going to have like an official starter that'll have a full isomorphic, kind of like a, obviously NextJS is huge, so I don't want to make a comparison to that. And like, they have millions of dollars funneling into making that system, but, you know, a mini NextJS. Like Svelts kit is a better comparison. And that's kind of what we're working on there. Ryan Carniato: And then the, on the second front, there's still like a lot of technology pieces that I want to chase after. I mentioned streaming, our streaming is still rudimentary. I want to do better. And there's a lot of stuff on the SSR side that has room to explore. I think current single page app frameworks kind of hit a wall there mostly a couple of years ago, and it hasn't really progressed that much. React is actually one of the few that have been working really hard at this over the last couple of years, and it's kind of becoming React 18. And I think that's going to be enough to push everyone else to like think and go, okay, maybe I need to spend some more time here. And we've been aware of that and been working on that with Solid, but there's still more work to do, you know, small team trying to do this stuff. Like, as I said, we got, we have elements of it. And we have, you know, suspense on the server, automatic hydration through layers and components. Ryan Carniato: Like there's a lot of really cool stuff that we're doing that to my knowledge, no other frameworks doing yet, but that's not going to be the case in six months or a year. I think you're seeing another kind of, it's a term, it's like gold rush to the new stuff. It's kind of funny, cause I know there's this desire for things to kind of stabilize and like, no more JavaScript fatigue. And I don't want to do stuff eight different ways, but realistically we're at the tipping point right now, I think, of another sort of a burst of innovation . Ben: And maybe outside of, you know, outside of Solid and what you're working on, like what else excites you kind of in terms of that burst of innovation? Like we talked a bit about the isomorphic kind of NextJS and the other isomorphic options, but anything else that's particularly exciting? Ryan Carniato: Yeah. I mean, I don't know if everyone knows this. I work on two frameworks and I mean, this is my work again a little bit, although I can't take credit for the ingenuity that's coming out of this completely cause these guys were working on it before me, but I, I work on Marco at eBay. And basically, to put this in context for people a little bit, there's been a sort of new type of framework to attack SSR. People are kind of getting tired of single page app frameworks, basically hogging all the resources, putting tons of JavaScript on the browser. And one of the recent projects that's gained a lot of attention and obviously excites me too, is Astro. And Astro is basically a static site generator and people look at it and they don't quite get it at first. Ryan Carniato: So like, oh, it's like a NextJS maybe or Gatsby, but it's different. You can use any framework, but that's not the important part. The important part is that they've architected in such a way that your page is mostly static. And then you just put some islands on there. And Solid actually works with it; you can actually Solid on it. And what's cool is if you aren't thinking single-page app, if you are just, you know, classic app, you know, load a page, click the link, go to the server, get the whole page again, it means that everything between your components never needs to be shipped to the browser. You don't need like component code and while we all know that if you do these full-page navigations, they can be a little bit maybe laggy. But I questioned that thinking a little bit for two reasons, because first of all, most of the time with these navigations, you got to go back to the server for data anyways. Ryan Carniato: And a lot of the complexity that comes around these solutions of, you know, reason why the reacting and looking at like server components and stuff too, is that there's these waterfalls that happen when you try and like load different lazy chunks and load different, you know, JavaScript and whatnot. And the thing is that can get complicated as your app scales. And honestly, it's not necessarily fast too, you know? And the other thing is if you let the browser handle this, the browser already is kind of smart. It knows to hold almost like suspense. I think suspense is modeled after this browser behavior. If you are on a page and you click a link, until you serve up that page, maybe there's a timeout on it. The browser will keep on showing you the current page and show a loading indicator. And then the other page will come into view. Almost to the point that on, you know, quickly responding servers, you actually don't even see the flicker anymore. Ryan Carniato: And a lot of the technology, you know, if you have a static site that's hosted at the edge, then you, you know, you probably have pretty quick communication there. Like it's in a CDN. And I think for sites that need the maximum performance when they load, like e-commerce, there's some studies a few years back, Jake Archibold from Chrome team, I believe. He basically showed that the median size for JavaScript is something like 350 kilobytes in 2018. I'm sure it's higher now. But I, you know, I was looking at a few other studies and stuff, and basically they were showing that, you know, if it took longer than you know, maybe three or four seconds to load a page, you have bounce rates, like really measurable bounce rates, like 25%. By the time you get to five seconds or six seconds, we're talking like 50%. Ryan Carniato: And the thing is for e-commerce when your business depends on sales, this is not good. And on the slowest devices, like those Moto G4's or whatever, like in Jake's study, he was showing that 350 kilobytes of JavaScript took 15 seconds to get all interactive. So like even, do some simple math. I mean, it's not linear, but divide. What do we need to get back to three seconds, right? Divide that three 50 by, by five, essentially, and 15 by five and get three seconds. You're at 70 kilobytes. Your page, if you're on an e-commerce site, you don't really want to be loading more than about 70 kilobytes on that loading page. And I mean, I hate to break it to most people, you get to 70 kilobytes with React before you've written a single line of code. Like it's literally React itself. Ryan Carniato: Maybe your Redux fly Barre, maybe Axios for your data fetching. Like you're basically already there before you did anything. And that's, I mean, that's the most obvious way for me to kind of put that out there, but it means that these MPA frameworks are interesting because Google has recently kind of tightened down a bit and been like, yeah, we're going to actually use performance scores to rank your pages. So if you want to make money on your e-commerce site, you want to get those top listings, you need to be fast, essentially. And people are looking at alternatives, right. And there is a lot of exploration happening there on the single page app site. And I think we'll eventually get to some interesting solutions, but the beautiful thing about a multi page app kind of mentality is that regardless of what, like you don't have to worry about those other pieces. Ryan Carniato: Like essentially you just, you never need the shift that JavaScript, there's no lazy loading considerations. It's just send the Javascripts you need. And so there's a really long way to get around it because I, you know, I mentioned Astro cause some people heard of it. Marco is like the dynamic site version of that, like more like NextJS version of the multi page app framework. And you know, it's been used at eBay since 2014 and it's basically a mature dynamic way of doing the same stuff Astro is doing instead of, you know, making manually kind of put your islands on the page. If you just write your code, like an app, and it automatically with its compiler just pulls out the islands and ships determines what code needs to be shipped to the browser and which code doesn't. And that work for me it's really interesting. Cause I think like Astro static today, but it's not always going to be. Ryan Carniato: People are going to be looking into these kinds of technologies and techniques. I mean, to be fair, you know, I was talking a little bit with Dan Abermoth from React and, you know, Marco was actually influenced by the, some of the PHP techniques that were used at Facebook years and years ago. And we brought into JavaScript. React's been trying to bring elements of that into React. And that's what's been taking so long. Like suspense is very similar to a concept that we have in Marco called async fragments, and you know, the streaming's SSR and the server components, all that kind of stuff has been more or less had a version of it in Marco since, as I said, about 2014. And so I'm very excited about how we have these like single-page app frameworks, like Solid or React. Ryan Carniato: And then we have, well, I mean, Marco and Aster on this other side, and it's kind of converging maybe in the next couple years. Right now they're separate camps and people are only just beginning to identify that there's value on both sides, but you know, this is part of that innovation story that I'm talking about, that we actually have different players all kind of coming in. Like it's no secret that where we're heading is server side. I just don't think that DHH is right. Like, I don't think that the rails guys are all sitting there going like yeah, told you so, it's coming back. Not in the way that you thought that it's coming back, like it's coming back a little bit different. It's not like we're like going no build or stuff. No building and tooling is actually the fundamentals here in terms of being able to offer it. Ryan Carniato: I mean, it's always been really important on the client side because we know we have these strict limitations. Every ounce that you can shave off, you know, tree shaking. But it's more than just tree shaking, like it's actually dead code elimination, compilation like Svelte or Solid or Marco. All these things are kind of coming together to kind of make these very optimal apps. But with this experience, that is a single app experience, you treat state, like it's a single thing. You write one application and it just works across browser and server. And that's the focus. It's, you know, whereas on the rail side you always had like, oh, and there's the JavaScript. Like there was always like this, like here's the rails app, and there's where I have to get my hands a little messy. And there you know, benefit to that too. Ryan Carniato: And it's interesting to see how the different sides are aligning. But for me, I'm actually seeing like this tools, no tools kind of avenue being an interesting point of conflict or contrast over the next little while as we kind of see, as I said, the single-page apps and the multi page apps kind of merge on one side on the tooling side. And on the other side, maybe rails is aligning with web components and standards based stuff. Ryan Carniato: I don't want to necessarily say this is a us versus them faction thing, but there's been a lot of opinions here about the direction the web should handle. And me kind of standing back, I can see these alignments and things already happening. So yeah, I don't see things settling down. I see a lot of innovation, a lot of really interesting competing products trying to do slightly different things to accomplish more or less the same thing. And we'll see, you know, what comes up on top and what's the best way to do things for the future. Ben: So, Ryan, this has been really awesome learning about Solid and Marco, you know, for folks out there who are maybe interested in either project, what's the best way to learn more or potentially get involved? Ryan Carniato: Yeah. I mean our websites are pretty good. There's tutorials, solidjs.com. We have full tutorial setup, forties tutorials, very influenced by Svelt. And then Marco, we have a full listing of all the different syntax. All the different, you know, compiler hooks and whatnot. But really our discord is where we live always on discord on both. So come in and say, hello, you know, ask your questions. There's a lot of people right now, kind of getting interested in Solid now for the first time. So there's a lot of activity, people going, like trying to find component libraries and working on them. And yeah, if you want to get involved, just come and join the conversation. There's always people there to help and people there working on stuff. And that's true to Marco as well. Our discords are both linked off the websites, so definitely come check it out. Ben: Great. Well, thanks again, Ryan. Ben: Thanks for listening to pod rocket. Find us at pod rocket pod on Twitter, or you could always email me even though that's not a popular option. It's Brian at log rocket.