Solid with Ryan Carniato

Episode Description

Ryan Carniato explains how SolidJS uses fine-grained reactivity and JSX to challenge React's virtual DOM model with near-vanilla performance.

Episode Summary

Ryan Carniato joins Anthony Campolo and Christopher Burns to discuss SolidJS, a JavaScript framework built on fine-grained reactive primitives inspired by Knockout.js. Ryan traces his programming journey from Knockout through React, explaining how reactive signals differ from both RxJS streams and React's hook-based rerendering model. The conversation explores why Solid adopted JSX — not for tooling convenience, though that proved a major bonus, but for the composability and expressiveness it offers over custom template DSLs. Ryan breaks down how Solid eliminates the virtual DOM by rendering components once, creating real DOM nodes on the first pass and using reactive subscriptions to make pinpoint updates, achieving benchmark results within 5–7% of hand-optimized vanilla JavaScript. The discussion shifts to Ryan's work on Marko at eBay, where partial hydration and out-of-order streaming dramatically reduce shipped JavaScript, and then to Solid Start, an SSR-first meta framework powered by Vite. The episode closes with Ryan's predictions that server-side rendering, streaming, and reduced JavaScript delivery will dominate framework evolution, with multi-page and single-page app architectures potentially converging over time.

Chapters

00:00:00 - Introducing Ryan Carniato and the Roots of Reactivity

Anthony welcomes Ryan Carniato, the creator of SolidJS, and frames the conversation around what makes Solid distinct from React, Vue, and Svelte. Ryan recounts how Knockout.js shaped his programming philosophy, introducing him to composable reactive primitives that he never wanted to abandon. Even as React rose to dominance, Ryan continued working with Knockout's model, appreciating the ability to organize logic around small, composable units rather than class-based life cycles.

Ryan explains that when Knockout's development slowed, he set out to build a modernized version of the same ideas. The discussion turns to what "reactive" actually means — from the spreadsheet analogy where derived values automatically update, to the distinction between RxJS-style push streams and the pull-based signal model used by Solid, MobX, and Vue's Composition API. Anthony notes how Solid's createSignal feels familiar to React developers, and Ryan clarifies that unlike streams, signals let you write normal expressions and pull values on demand.

00:06:52 - JSX, Tooling, and Transferable Knowledge

Christopher asks about JSX and why Solid looks so much like React despite being a completely separate framework. Ryan explains that Facebook created JSX as an open spec, which meant existing parsers, Babel plugins, TypeScript support, and IDE tooling all worked out of the box for Solid without needing custom language servers. The practical benefit is enormous: Solid reuses React's syntax highlighting extensions and only requires its own Babel transform plugin to handle compilation differently under the hood.

Beyond tooling, Ryan chose JSX for its expressiveness and composability. Template DSLs like those in Svelte or Vue can be easier to analyze and compile, but they impose limits on composition — abstracting over control flow or building render props requires new syntax rather than plain JavaScript. JSX lets developers define behaviors, abstract them into components, and compose them freely. Ryan emphasizes that his adoption of React's philosophy — unidirectional data flow, composition, explicit control — was deliberate, even as he replaced the underlying technology with fine-grained reactivity.

00:13:09 - Why Not React? The Virtual DOM and Hooks Dilemma

Anthony presses the central question: why not just use React? Ryan explains that before hooks, React's class-based model never appealed to him, and he would bring Knockout or MobX into React projects. When hooks arrived in 2018, he recognized their compositional power but also their fundamental constraint — because React rerenders entire components top-down through the virtual DOM, developers must manage stale closures, dependency arrays, useCallback, and useRef for non-DOM purposes. The mental overhead grows as component complexity increases.

Ryan then contrasts this with Solid's approach. In Solid, components render exactly once to establish declarative data relationships, and all subsequent updates flow through the reactive system as side effects that directly mutate the DOM. There is no second virtual tree to diff against. When a signal changes, only its specific subscribers update — a text node here, an attribute there. This eliminates the virtual DOM's overhead and the cognitive burden of reasoning about what rerenders when. Ryan acknowledges this is a different philosophical stance — rendering as pure function versus rendering as side effect — but argues it leads to both simpler mental models at scale and hard-to-beat raw performance.

00:19:55 - Benchmarks, Performance, and What They Actually Measure

Anthony highlights the JS Framework Benchmark and isomorphic UI benchmarks featured on Solid's website. Ryan describes how the JS Framework Benchmark tests table operations at scale across over 100 libraries, with most submissions maintained by framework authors themselves — including contributions Ryan made for React Hooks and Svelte 3. Solid consistently scores around 1.05–1.07 against normalized vanilla JavaScript, compared to Svelte at roughly 1.27, Vue at 1.54, and React at 1.93, though Ryan notes Vue 3.2 significantly closed the gap with Svelte.

Christopher challenges whether benchmarks matter for real-world applications. Ryan agrees that single-render performance rarely causes user-facing problems — the bigger issues are architectural, like data-loading waterfalls and cascading rerenders from poorly structured code. He views benchmarks as primarily valuable for framework authors to eliminate bottlenecks and validate design decisions. Still, he notes that real applications can easily render thousands of DOM elements through complex layouts, making the efficiency of the underlying tool meaningful even if the benchmark scenario itself is artificial.

00:27:12 - Abstractions, Developer Experience, and the Learning Curve

Christopher reflects on how React abstracts so much of JavaScript that many developers don't understand fundamentals like event binding. Ryan agrees that hooks simultaneously empowered composition and muddied understanding, which is exactly what prompted Svelte and Vue to offer reactive alternatives that feel more natural. He observes a tension between frameworks that hide complexity for beginners and those that expose control for advanced users, noting that Solid has traditionally targeted intermediate-to-advanced developers.

Ryan discusses how his documentation lead, a Vue developer, has been rewriting Solid's docs to make them more approachable — a challenge because Solid's teaching style resembles React's "here are all the primitives" approach rather than Vue's progressive disclosure. He acknowledges that Vue is navigating the same spectrum with Composition API on one end and ref sugar on the other, while Svelte excels at onboarding newcomers. The conversation touches on the unavoidable complexity beneath every abstraction, whether it manifests as React's stale closures, Svelte's tracking boundaries, or reactive systems' own edge cases.

00:34:04 - Marko, Partial Hydration, and the Server-Side Revolution

Anthony asks about Marko, the eBay-built framework Ryan works on professionally. Ryan explains that Marko was designed from the ground up for multi-page apps, automatically determining at compile time which code needs to ship to the browser — a problem that React Server Components, Astro, and island architectures are only now addressing. By applying Solid's fine-grained, component-free rendering approach to hydration, Marko can isolate exactly which data bindings and control flows require client-side JavaScript, discarding everything else.

The results are dramatic: eBay's homepage dropped from around 500kB gzipped to 70kB gzipped when partial hydration was enabled. Ryan also explains Marko's out-of-order streaming, which has been in production since 2014 — the server begins sending HTML immediately, renders placeholders, and flushes completed data sections with inline scripts that insert content before JavaScript even loads. This approach eliminates the need for client-side data fetching on initial page loads and represents a fundamentally different optimization philosophy from single-page app frameworks.

00:38:57 - Vite, Solid Start, and the Meta Framework Landscape

Christopher asks about Solid's Vite plugin, and Ryan explains how Vite provides the building blocks for anyone to construct a meta framework — file-based routing, glob imports, and SSR support that arrived almost exactly when he needed them. He describes Solid Start, an SSR-first development environment heavily influenced by SvelteKit that uses adapters for different deployment targets. The Vite plugin powers all of Solid's starter templates and makes SSR configuration dramatically simpler than rolling a custom setup.

Ryan notes that even the Marko team is adopting Vite, replacing their custom bundler Lasso, which had pioneered on-demand bundling at runtime years before Vite popularized it. He sees Vite as a watershed moment where mainstream tooling finally supports the SSR workflows that frameworks like Marko had to build bespoke solutions for. The convergence of Vite's capabilities with the SSR ambitions of multiple frameworks signals that the next wave of developer tooling will be significantly more capable and interoperable.

00:41:56 - Predictions: SSR, Streaming, and the Future of Frameworks

Ryan predicts that server-side rendering and JavaScript reduction will dominate framework evolution, with streaming as a critical enabler for performance — loading content immediately while data requests resolve on the server. He expects continued growth in the multi-page app space, particularly for e-commerce, where tools like Astro, Marko, and Qwik are proving that not every site needs to be a single-page application. However, he hopes frameworks stay true to their individual visions rather than hastily copying features from competitors.

The conversation closes with Ryan cautioning about growing complexity in the SSR landscape — developers now face choices between SSG, SSR, ESR, streaming, and various hybrid modes. He believes multi-page and single-page architectures could eventually merge, but only if the approaches develop organically rather than being forced together prematurely. Anthony wraps up by emphasizing that Solid represents genuinely important work in framework design, not just another entry in the JavaScript framework cycle, and directs listeners to solidjs.com and the project's Discord community for further exploration.

Transcript

00:00:00 - Anthony Campolo

You guys all ready to get started? We're all good to go.

00:00:03 - Christopher Burns

Everything's solid. How many times can we use the word solid? It's very solid. That's a solid explanation.

00:00:20 - Anthony Campolo

Ryan, welcome to the show. Hi. Thank you so much for being here. You are the creator of Solid. It's a new JavaScript framework, not a meta framework. We talk about lots of things built on React and Vue and Svelte here. But this is really aimed at being a competitor to those types of frameworks, taking influence from them and also taking direction away from them in things that you think could be improved. There's going to be a lot to get in here. It's a very dense, technical topic, and I've listened to a bunch of other podcasts you've been doing and really enjoyed them. When I heard your Pod Rocket interview especially, I was like, we need to get this guy on the show. So you have a long, in-depth history in programming that you talk about on Pod Rocket. I'd like to hear a little bit about that story, and then we can point people to that show to get the full deep dive. But I know Knockout is a really important part of this story and this whole idea of reactive programming.

[00:01:16] So just let us know where you're coming from here and what are some of the ideas forming this new framework that you're building.

00:01:23 - Ryan Carniato

As you mentioned, Knockout.js was a big part of it. In the past I programmed in some back-end web frameworks, but I got my start way back in the late 90s in a pure JavaScript environment. So when I got the chance to work on the front end again in a pure JavaScript way, I was really excited. Knockout just happened to be the thing that was there, and it introduced me to a lot of the concepts of reactive programming that would go on to further shape my perspective. Things like the way you have these primitives that compose. I loved it so much that I never wanted to give it up. So when some other alternatives came out, like React primarily, I just wanted to keep on programming the way I always had with Knockout. React at that time wasn't like the modern class API, but they had a return to life cycles and stuff, which is what I'd been used to in my .NET days.

[00:02:08] And I was like, no, no. I like organizing things with little primitives, like the React hooks kind of concept, and I like building behaviors around that and function components and this whole kind of thing. Knockout had a lot of those elements, and I just kept on going along that path. My old company stayed on Knockout actually all the way until 2019, but it was a big part of my design approach. I wanted to recreate something like Knockout but more modern, especially when it became clear that Knockout was not being maintained as much anymore and its development was slowing down. So yeah, it's a huge influence, even more so than React. Although over the years I've come to respect and learn a lot from React, Knockout was really the starting point with these reactive primitives.

00:02:51 - Anthony Campolo

Yeah, let's start there with this term reactive. Because if you go to the SolidJS website, solidjs.com, this description is "Solid is a purely reactive library. It was designed from the ground up with a reactive core, is influenced by reactive principles." It's like, okay, I think the reactive part is pretty important here. This is a really confused term now, and I definitely blame React for this because as far as I know, when we use this term reactive, we're not talking about what React does. I think it's more akin to what something like RxJS does with observables, but I honestly don't know anything about RxJS beyond high-level descriptions, so I'd be curious if I'm at all close with that idea or what this term reactive really means.

00:03:35 - Ryan Carniato

Yeah, coming up with some of that marketing website material was fun, and I even poked fun at the repetition and reactive myself a bit. We were trying to find the right adjectives to describe this thing because you're right, it is ambiguous. I've written blog posts specifically on this topic, and even the conclusions of those aren't the best because, from a 10,000-foot-away perspective on reactivity, all it is is the concept of declarative programming where if A equals B plus C, when B or C changes, A always updates. That's the most basic idea of it. It's like a spreadsheet. But the truth of the matter is you could describe almost any UI library by that. All the declarative ones, all the ones based off these HTML-binding-looking things, basically have aspects of that. So having React bundled into that group isn't terribly unfair. But on the other side, you have a lot of academic formalized definitions and stuff.

[00:04:29] RxJS, and actually what we do in Solid is slightly different, which doesn't make things easy. And I think that's also where a lot of the muddled conversation goes, because both of those systems at their core have this primitive. Some call it an observable, we call it a signal, some call it an atom. When it changes, it has subscribers and they update. The primary difference in flavor, let's say, is something like RxJS is about a stream. You push updates on and it goes through that stream through a bunch of transformations from start to end, and it always tells you what ends up at the other end. And there's some technical terms for it, like it's not FRP, which makes things even more confusing. I don't want to go too far there.

00:05:13 - Anthony Campolo

That's functional reactive programming.

00:05:15 - Ryan Carniato

Yeah, but it's technically functional programming and reactive programming. Actually the guy from RxJS, Andre Staltz, is like, I'm not apologizing for using the term FRP or functional reactive programming because it is functional and reactive programming. Whatever the difference on the Solid side or the MobX side, even Vue Composition API, it's not about streams. Instead of thinking about a stream where you just flow data in and you get it pushed to you on the other end, these are based around primitives, also sometimes called observables. They're almost more like data event emitters with a value. It's tricky to perfectly describe.

00:05:48 - Anthony Campolo

For us who are pretty common React developers, you do a good job of displaying this just in the code itself, because when you create a signal, you use it for a count variable. When I see that in your example, I think, okay, this is kind of like a useState. So as a React developer, that makes a lot of sense to me. It's a way to have a value change and to track that changing value in your UI.

00:06:10 - Ryan Carniato

Exactly. That's the key difference. It is a value you can pull. You can ask for that value at any time. It inverts the model. When you have something like RxJS and streams, you end up piping. It's like any kind of stream stuff you might have done, maybe in Node or whatever, where you build these chains that you pipe with. The type of reactivity you find in frameworks like Solid, because of the way it tracks, is inverted. It's like the spreadsheet again. You get to write simple expressions like a double count depends on count. Essentially, it's done with functions and they look a lot like hooks, funny enough. But you write your code as if you're asking for a value and writing normal expressions for those values, rather than having to pipe everything into a stream.

00:06:52 - Christopher Burns

I feel like my eyes have just glazed over a little, and a lot of words have been said. Do I even truly grasp the core of it? Maybe the biggest thing I've noticed about these things is JSX. What is JSX? React didn't make JSX, or did they? I don't know, but it's a style that you've used. You use it completely differently to how React uses it to a certain extent, don't you?

00:07:17 - Ryan Carniato

JSX was built at Facebook.

00:07:19 - Anthony Campolo

It was influenced by XHP, which was a PHP extension that did essentially the same thing. Facebook has a PHP monolith very famously, and they took the ideas they already had built around a PHP extension language and ported those to JavaScript. That's the history as far as I know it.

00:07:40 - Ryan Carniato

Yeah, definitely. And what was good about that is Facebook always kind of viewed it as an open spec, which I liked. Even though it came out and helped React and was kind of for React, and that still influences what gets merged into JSX, not a lot has been updated in almost, I'd say, seven years. There's actually a GitHub for JSX separate from React, where there are proposals and that whole thing. But the key thing is they defined a language spec because of that. It meant other tools could be built on it. Things like Babel can build parsers and code highlighting tools, and TypeScript has something they can look at. Even TypeScript is a little bit trickier because it is heavily influenced by React. Because of that, it was really easy for me to approach. I could just go find existing parsing tooling and go, okay, how do I want to transform this? I basically started by just writing a Babel plugin.

[00:08:28] It had all the syntax and everything available to me. It made it really easy. And then once I had that, all the existing tooling just automatically worked. I didn't have to worry about language server. I don't know how you guys do all that syntax highlighting and autocompletes and stuff in an IDE. There's basically a server running in the background. If you wrote a custom template DSL like Svelte or Vue, you basically have to build your own version of that, like Bridget, so that it can handle things. So that's why TypeScript took a while to come there and all that. For the case of Solid, I actually don't know how any of that stuff works very much. I've been learning a bit more because of my day job. I've had a chance to dip into that.

00:09:04 - Anthony Campolo

So are there Solid extensions for getting syntax highlighting?

00:09:07 - Ryan Carniato

That's the thing. We just all use the React ones.

00:09:09 - Anthony Campolo

Oh, okay.

00:09:10 - Ryan Carniato

The only thing that's special is that Babel plugin. But that all happens after all the tools have done their job in terms of syntax highlighting, because they just read the initial ASTs, basically, with the types and the JSX in it and all that stuff. They don't really care how we transform it. It makes life a lot easier. I mean, there's a few places where we get snagged up or I've had to wait for support to come to TypeScript or for specific things, because all the tooling has to support all the features. TypeScript didn't have namespaces on JSX for a while, did some weird stuff, but for the most part it's been built for me.

00:09:46 - Christopher Burns

That was my biggest thing, because when I hear it's a framework by itself that's not React, I instantly think, okay, what's it going to look like? Then I look at Vue, for example. I'm like, okay, this is very different to React. Yeah, it's still using the same kind of angled brackets, etc., but it's very different. When I looked at the demos and quickly played around with one, it literally looks like React. It looks so similar to me. It almost looks like Preact, for example, as it's kind of React but it's not React. But then you look at things like Svelte and Vue and they're like, no, we are completely different. So that's why I brought up the question of JSX, because I think it's so easy to transfer knowledge if you know how these things work. For example, with JSX, you can instantly go from React to Solid and understand how the majority of it works. But Vue and Svelte are quite similar because they use very similar paradigms and things like that.

[00:10:43] So I think it's super interesting that it's kind of like an alternative to React. Is that what you've seen a lot of people adopt it for?

00:10:52 - Ryan Carniato

The choice of JSX was very intentional. The funny thing is, I was on those custom DSLs. Knockout was kind of on that angle, and that's where Vue and Svelte sort of came from a bit, the reactivity. But I felt like I looked at it and I'm like, I get why people ended up migrating off those early reactive libraries like Knockout and went to React. And I was like, is there something we can learn from React? JSX actually is fairly representative of the types of things that I encourage with Solid, which is that same idea of composition and building because the components are basically just functions, the way you can just create your own control flow. You can literally just use JavaScript to construct your views. It was really important to me. I didn't realize it as the tooling thing; I came to appreciate that later. That wasn't completely why I went there initially, even though that's what saved me in the sense of not having to do all that extra work.

[00:11:43] But it was actually because I wanted the expressiveness. Template DSLs have certain limits. Usually the way they're designed is good, it makes it easier to analyze and easier to optimally compile. But on the other hand, there are certain things that are clunkier around composition. There are natural places where you want things like render props, where you abstract over a for loop or some kind of layout control or something like that. And JSX is really powerful to be able to define those behaviors, abstract them, and then that be your component. Whereas most templating languages introduce a new syntax for it, and that syntax usually, while maybe extendable in some of them, isn't composable. You have to change your syntax when you go from iterating over a basic list to making a paginated component. That's why JSX is, I feel like, a really important part. Even if in some future we decide to use a different templating approach with Solid, JSX has a lot of really good benefits in the way it works.

[00:12:40] And you'll see this common pattern with Solid just looking at things React did. Maybe it was envious at first because it was like, why didn't my framework have it, and just applying some of those principles because I feel like those are the learnings, the philosophical stuff, like the unidirectional flow rather than the technology. Some frameworks are like, we don't like certain elements of the developer experience, and they go over here and they're like, we're very different. I like the philosophy and design behind React. I was like, no, we're going to change the technology.

00:13:09 - Anthony Campolo

Yes, we need to get into next, because I agree with Chris that the JSX stuff is really cool, and it's what really hooked me when I first started looking at the docs because I really like JSX. I love writing JSX. It's the same reason I'm excited for Slinkity because it lets you write JSX in a markdown file. It begs the question, though, what's the point? Why shouldn't I just write React? So I think we need to get into what the actual problem this thing is solving. What problem did you see with it, and what have you done differently that makes this a viable solution to whatever issue you had with the other stuff?

00:13:43 - Christopher Burns

I just wanted to add to it. Why don't you use a virtual DOM? What makes the virtual DOM the virtual DOM? I thought it was JSX personally, but looks like it isn't.

00:13:52 - Ryan Carniato

Okay, you got me on two questions there. I'm going to start with the React side of things. The first question, the truth of the matter is, before 2018, before React hooks, React wasn't doing it for me. Every time I went in, I was trying to bring Knockout. I actually brought Knockout into React, or I'd use MobX, which is fine. This does tie into the virtual DOM question a little bit. I like the primitives. I like composing it from that kind of UI perspective, and I know a handful of libraries that were doing stuff like this. And then when React released hooks, they were like, okay, well, I guess my job is done. React has changed gears and released hooks, and now they have their own primitives. But for me, that actually was what got me excited, because the second I saw hooks, I realized that there would be a difference in the way they execute because they're still thinking in this component rerender, top-down rerender.

[00:14:39] And the reason for that is the virtual DOM, which I can get to in a minute. But because of that mentality, you needed stuff like useCallback, you needed stuff like using refs for things other than DOM elements, because you needed ways of storing references to things that were mutable. Essentially, because the whole function executes, you throw away everything you created in there, so you needed ways to hoist it out of the components. The React hooks model has all the composition, the replacement for mixins, that ability to build stuff. But its model is sometimes a little bit unnatural feeling. You know what I'm talking about. If you've ever used useRef for anything other than a DOM element, you get into these places where you have effects talking to each other and they have to pass data down a useRef, because if you state that, it would cause a rerender. Once you get into this zone of trying to figure out what is actually rendering on each execution and what's outside and what's in the closure, it becomes a lot messier.

[00:15:35] And the thing with the reactive approach, and Vue to be fair has this element too with their setup functions in Vue 3, is that you just set up everything once. You make your data declarative. That's the best way to put it. You say, this is how the data is derived, what the behavior is. So it's not only about grouping and encapsulating stuff into hooks, but also being able to say, this is the rule. Set it up once and then every time it updates, it will apply. To be fair, that sounds like hooks as well, except with hooks you have to be aware of the fact that there's a world outside of your hook that reruns and you have to whitelist changes and stuff. Honestly, some people get really fixated on that dependency array. So you don't have the dependency array, but it's not just that dependency array that you have on the hooks. It's the fact that you have more stuff to keep in your head.

[00:16:24] You can't just look at it and be like, oh, this is a simple program. Here's my state that I declared. How does it update in React? You have to be conscious once the component gets any level of complexity that things are rerendering over and over again. That's the best way I can put it. I don't know if you have any questions about the first part before I go into the second part.

00:16:42 - Anthony Campolo

Yeah. No, go for it.

00:16:43 - Ryan Carniato

Yeah. Okay. So why make it rerender over and over again? You might be asking, why go through this model? Why hasn't React just done this? Why didn't they take this approach? And again, this comes down to the virtual DOM. Largely because virtual DOM is a two-pass renderer. A little bit technical, but essentially when your components run, they create another tree that is not the DOM. And then after they're done updating or changing, building parts of that tree, they're able to diff it against the previous version of the tree and then just apply the DOM updates. But it means that everything is built around this idea that the component renders are throwaway, that you can just rerender, build the new tree, and you always have this diffing to solve your problems. And for that reason, React can abuse rendering as a pure function, essentially something that doesn't have side effects unless you use effects as a way of calling it out where they pull it out.

[00:17:34] But essentially that's the model. They need everything to be top-down rendering. In some ways that's really simple because it's like Redux is simple in that it's like this pure kind of explanation, view is function of state, right? Which is really quite nice to explain at a high level. But another alternate reality, one that isn't based off purity but based on mutation and side effects, which is kind of prescribed to in Solid. What if all rendering is a side effect? Essentially, it's a slightly different view and maybe getting a little bit too on the academic side, but in Solid we render our components once, as I said, to create these relationships. And then after that point, it's only like conceptually the hooks that we run. So you don't have the stale closures because we only render once. We don't need to create a virtual DOM. Essentially, when we create those JSX elements, because we're rendering once, we can actually create the real DOM nodes on that first pass. We just go create the DOM nodes and then wrap all those updates in our effect calls so that whenever the data updates, and this is that reactive system coming into play, it just changes the DOM directly. So there's no virtual tree that diffs against another virtual tree and then patches it instead. It's like events. Somebody changes a data point over here, updates that count, and then it goes, oh, who's subscribed to me? Well, it's this one little div down here that has text. Update the text. It's hard to beat that on pure performance.

00:18:57 - Anthony Campolo

Yeah. And this reminds me a lot of when I was first learning Svelte. I was learning Svelte pretty much as I was learning React at the same time because I was doing React in my boot camp and watching all these other open source things happening. I was really interested in Svelte, and I listened to Rich and other people explain it, and it would make no damn sense to me whatsoever. And it was like, I know all these words combine to make sense, but I don't really quite get it conceptually. But I could look at the code, I could look at the output, and I could look at build times. I could look at all these metrics that were pointing me in the right direction, being like, this is lighter, this is faster, this is more performant. And it was just obvious. So if you don't quite get the theoretical stuff here, I would say you can avoid getting too hung up on it by looking at benchmarks, which is why I really appreciate the amount of work you put into benchmarks and just making benchmarks part of this conversation, because supposedly we're engineers, this is the only engineering field I know where people don't bother measuring things.

[00:19:55] I know so many web developers who have never bothered to measure all sorts of different metrics within their own site. So you put a lot of work into this, and your website has two main metrics that I'd like to get into. One of them is the JS Framework Benchmark, where you compare browser performances across different frameworks, and then another one which is the isomorphic UI benchmark, which is the raw server rendering speed. So let's get into both of these benchmarks. What do they mean and how do they compare to other frameworks?

00:20:27 - Ryan Carniato

Benchmarks always need to be taken with a grain of salt to see what they're testing. But the truth of the matter is, yeah, I do spend a lot of time with the benchmarks and even modifying benchmarks to try and test different things. I've written several articles over the years where I've taken the JS Framework Benchmark and changed some aspect of it. For those who don't know, JS Framework Benchmark is basically rendering a large table with a bunch of common table things like selecting rows and swapping rows and deleting rows and updating rows. It's basically like a giant TodoMVC at the scale of 1,000 or 10,000 rows, which people will be like, I'm never going to put 10,000 rows on a page. And they're right. Maybe the JS Framework Benchmark is getting to the end of its usefulness on that side.

00:21:09 - Anthony Campolo

Well, just interject to it real quickly. That part of benchmarking is to not have a single benchmark, is to have multiple benchmarks that you then can compare to each other.

00:21:17 - Ryan Carniato

Definitely. And that's one of the reasons why JS Framework Benchmark is so good. There's actually nine performance tests, five memory tests, and initial load tests. As far as a gamut for JS frameworks, it can be more useful for authors in terms of figuring that out. I was saying for the end user, though, I think over time our browsers have gotten faster, and JS Framework Benchmark has mobile simulations through CPU throttling. It tries to make things like a slow phone. So it's not like we're just like, oh, this is just for desktop. There's an understanding in terms of performance of lower-end devices, but even there we're getting to a point where both the frameworks have gone a little bit faster over the years and browsers have gotten more efficient. Even the bottom line of devices have probably too. But essentially, it's very good at testing all those different things for client-side rendering. And it's a giant TodoMVC, or todo app from a certain perspective, and it's great.

[00:22:06] There are 100 libraries in there. Most of the submissions are actually by maintainers of the libraries themselves. It's a long-held tradition since this thing was first put together in 2016, when Vue 3.2 came out. Evan made the PR himself. I actually wrote the React Hooks implementation, but Dan Abramov chipped in and helped me figure out exactly what I was doing, right or wrong. I'm a bit more involved with others in there. I also did the Svelte 3 implementation as well and again reached out to the community to make sure there are details there, because you need both expertise in the framework to be able to do this sort of benchmark and understanding of the benchmarks themselves to get the best representation. But almost every framework is there. As I said, all the core maintainers have been involved, either making the PRs themselves or chipped in. So in terms of client-side benchmark, it's hard to do much better. Solid itself on the benchmark does quite well. It's put against vanilla JS, like the most hand-optimized vanilla, no-library implementation we could possibly make.

[00:23:01] And that's the normalized 1.0 on the benchmark. And then every other framework is kind of put up against that. I first added it in 2018. I guess the benchmark was actually the reason I open sourced it in the first place. I was trying to build it for my startup as a project, and then I was like, oh, let's open source it so I can participate in this benchmark. Solid kind of hovers around the 1.05 average geometric mean over vanilla. I guess it's about 1.07. Things fluctuate over time within about 5 to 7% slower than vanilla on average.

00:23:31 - Anthony Campolo

And then context for listeners who aren't looking at the website right now, you then have Svelte, which is 1.27, Vue, which is 1.54, and React, which is 1.93. So that's where you can kind of see how these different ones compare to each other. And then you have things like Preact, which is in between Svelte and Vue, and then Inferno, which a lot of people probably don't know, actually scores just after yours with 1.2.

00:23:56 - Ryan Carniato

I do need to update that from what you're saying, because Vue 3.2 was a big change and now Vue and Svelte are right next to each other.

00:24:05 - Anthony Campolo

Okay.

00:24:05 - Christopher Burns

My biggest question I think I have with regard to benchmarks is why do they matter? It's such an interesting question because I've never come across someone say like, this web app is super slow, but so many people say this web app is super slow. Is it because it's coded badly? Is it because the database is far away? In terms of you who've spent a lot of time benchmarking, what's the real stuff that you say is down to benchmarks? Is it responsiveness on a click of a button on a massive web page? Is it how fast it renders?

00:24:40 - Ryan Carniato

Benchmarks don't capture that. And that's why I'm saying they were mostly more valuable for the framework authors to remove any kind of extra bottleneck. On occasion, it is possible for badly written code in any paradigm to perform badly. A reactive program that binds too much data and loses directionality can cause UIs to explode because they update something and unintentionally cause stuff to go off and recompute and cycle. Essentially, because this data updates this data that updates this data, that was a problem we had in the early 2010s. Sometimes a VDOM library can cause a bunch of unnecessary rerenders, and you can rerender the tree just to trigger something, to rerender the tree again, to trigger something, to rerender the tree. So sometimes there are some framework-like aspects related to bad code, but usually I find that the bigger problem is just not properly considering things architecturally, like around waterfalls and async data loading and basically not really realizing where those rerender situations are, where a bunch of things just start cascading.

[00:25:48] It's very rare, almost never, that a single render is going to catch you up. As interesting as it is that Solid can render a thousand rows, or I forget what the current benchmark metric is, but like 30 milliseconds faster than React or something, that's not what you're going to capture. I have seen these things add up, but this only would matter if your code was written perfectly. The framework overhead here is actually not as much as one would think. So most of this is just about efficiency of the tool, and you still have to use the tool properly. I think that's really important here, which is why there's certain aspects of skepticism on a lot of benchmarks. I mean, I do test different things. As I mentioned, one of the ones I tested was trying to put as many components on the page, just trying to see how components could scale. And again, different approaches do scale differently. So this all kind of adds into trying to come up with the most performant design for the tool.

[00:26:46] And maybe on large apps, you might hit situations which aren't like the benchmark but involve still lots of components or lots of elements. You might be not rendering a thousand-row table, but maybe you are still rendering 3,000 elements on the page just because of what the layout is. So there is a limit to benchmarks? Definitely. But as I said, for framework authors, they're invaluable.

00:27:12 - Christopher Burns

And I completely agree that they are because it gives you a way to reference your libraries in any way. The biggest thing is that, as Anthony said when he was learning React, he learned Svelte at the same time. I just didn't understand it. I think there's so many things where if you drop someone into this ecosystem of web dev and you said, okay, you need to build something, they'll probably just look up whatever they find first. Probably get to a Medium article that's five years old, say React is the way to go. And then they go, yep, virtual DOM, no clue what it does, but I guess it's needed. Hooks and side effects, no clue about it. Literally guessing your way through development. And I kind of feel like a lot of your first two or three years with React, you kind of don't understand how it actually works. A lot of it's very like, yeah, I use this useEffect thing and it rerenders something in the brackets.

[00:28:11] I guess that does that, but you don't truly know why it's doing it, how it's doing it, if you know what I mean. There's so much stuff that's abstracted away. And recently I coded a widget for my company. One of these things that everybody has, like Intercom or Hotjar. That has really opened my eyes to JavaScript. Why? Because it was plain JavaScript. For example, how do you bind an event to a button? If you ask a React developer to bind an event to a button, they'll instantly probably say, oh, an onClick event. It's like, well, kind of. But that's not how plain JavaScript works. You need to actually bind it to listen to the event. And it's all these abstractions and abstractions; Anthony put an article out that I've not read. But it's so crazy to think how far React has changed JavaScript to this point where you say JavaScript is not JavaScript. Svelte versus React is so different. I think personally, and I've recently hopped across all of them to then make examples of this, this is using that plugin in Vue.

[00:29:14] This is using that plugin in Svelte. It's been crazy to the point where I'm like, yeah, the React implementation is completely different to the one in Svelte or Vue because React is a whole different beast and talks about everything differently and you need to use its paradigms.

00:29:30 - Anthony Campolo

Aren't you glad you finally used something that wasn't React, Chris?

00:29:33 - Christopher Burns

Kinda, but at the same time it's a bit too scary.

00:29:37 - Anthony Campolo

And that article I dropped was by Jared Palmer. He has a fairly famous blog post called React is Becoming a Black Box.

00:29:44 - Ryan Carniato

I think a lot of that conversation kind of comes down to the hooks dilemma, which was hooks being the savior for composition for React, but also being the thing that muddied the water. The second anyone saw hooks, and I also wrote an article a while ago about this, that's when Svelte and even Vue kind of woke up. They're like, okay, if people are willing to take this model with React, we know we can do it in a way that makes way more sense for people and way easier. That's because reactivity, that's the same thing that Solid has. Essentially, that reactivity makes that hooks model a lot easier. That being said, I think there's an interesting dilemma between getting started and later on. In your experience, that's the JavaScript framework dilemma, because you're right at the beginning, you want that stuff abstracted away from you, right? And then the challenge is that later on, you kind of are like, I want control. I want to explicitly know what I need in React.

[00:30:40] As I got more experience in web apps, the more I liked React. I know not everyone follows the same trail. I liked how explicit things were. I don't necessarily agree with the model and it can be really complicated at times, but I liked that I could control to such a degree what I was getting out of it. That's a lot of the elements that I took out of it. Right? Because the challenge is, I know this from working also on Marko, which is another JavaScript framework that's more like Svelte on the side of things. You can bake stuff into the language and it will make things easier, but it's not like the moving pieces underneath are any less complicated. There's always going to be terror in the abstraction somewhere. React's hooks in function components look nothing like JavaScript when you think of them. Like, look at this component. You declare a bunch of variables. Why would you ever expect it to rerun again?

[00:31:28] On the other hand, a perfect example is, why would I expect to write a function that reads state, put it in my template, and if I move it out of my template and put it in a function, it suddenly stops tracking? There are places where there are walls to the different approaches and different trade-offs. For the beginner developer, you're never going to hit those, not right away, like the useRef example I gave you. But when you become advanced and you've learned more of these things, you're like, oh yeah, of course it's this. But all those thises are an accumulation of what you've learned over the years. It's been one of the challenges with Solid, because maybe my target has always been intermediate to advanced developers, which is very unusual for a JavaScript framework. It's felt very much like, we are easy, we just made HTML and CSS, stuff that looks like it.

[00:32:21] You can just pick it up if you know that. I find that deceiving a little bit, because I know that it doesn't actually work that way. And for me, this is what I liked about React. I was like, you walk into React and you're like, oh, these are your six hooks. Learn them well and this is all you will ever need. That kind of mentality. It's different priorities and it's made it challenging. On our core team, the guy Dan, who's in charge of the documentation and teaching side of things, has been rewriting my docs to try to make them easier to approach and stuff. He's a Vue guy and he's always loved Vue, and he's like, this is an interesting challenge because he's like, we have to teach this completely different than Vue because Vue is all like, here's a couple things, don't worry about it and it will progress with you. Whereas with Solid, and I guess it's probably true of React too, it's like, here's the appendix of the things, all the things you need, and here's maybe a bunch of recipes or best practices.

[00:33:14] It's very different and possibly daunting for the beginner or people new to web development. It's tricky for me because I've been doing this for such a long time that when I see them, I see the same thing. So when I instantly just want to cut through the tape, I just want to make it work. But this is coming from a framework author. I think Vue has kind of been going through this dilemma too, because Vue wants to be progressive and scale. So Composition API they now have that are bringing that power to Vue on the upper end. But at the same time they have a new ref sugar to be more like Svelte. They want to cover the whole spectrum because as you make things more complicated, more control, it's harder for beginners and they're kind of spreading out their approach that way. Svelte has done an amazing job of showing people how easy it is to get into web dev. It reminded me of Knockout a little bit for its day, it was like that.

[00:33:59] So it's really cool to see that. But it's also interesting to see that there are different priorities here.

00:34:04 - Anthony Campolo

I would actually like to get a little bit into Marko. You mentioned it really quickly. What is Marko and how does it fit into this whole conversation? Because you're kind of like a double framework author.

00:34:13 - Ryan Carniato

I joined the Marko team just over a year ago, and it was because they saw my work on Solid, actually, that I ended up joining up because they're in the process of rewriting a good part of their client-side framework. They were a library, but Marko is very different than, say, React or another library. It was made for multi-page apps at its core, like you can use it for a single-page app, but it was made for pages that basically render on the server once because it's built with optimizations to send the least amount of JavaScript to the browser. It was made for eBay. For e-commerce, it's all about page loads and making sure that when you get a referral from a search, that page loads as fast as you can from any device throughout the world. And in that sense, you might have heard of newer stuff like Astro, right? It lets you build React or Vue for what are called islands, where basically in an MPA, a multi-page app, you can view most of the page as static, and it's only the pieces that are interactive that need to go to the browser.

[00:35:08] The reason for that is because you know the page is going to get rendered on the server. You don't have to worry about rendering stuff on routes. And while this gets rid of those nice routing transitions, and people might lament that depending on the type of site you want, you don't need all that JavaScript. It can be a significant savings if you only send the JavaScript for the few buttons or widgets you need on your page. And Marko, created at eBay back in the 2013 time period, was basically built from day one with this in mind. You'd write your app like a normal app. You'd just write all your code, all your components, and then the compiler would automatically figure out what doesn't need to get sent to the browser. React Server Components are another one, and Astro is another example. We've been seeing this kind of way of manually opting in to this kind of idea of like, this is code that needs to be sent to the browser, but with Marko, it was actually the compiler. They knew that they wanted to do better.

[00:35:54] So with Solid, I'd done a lot of work on fine-grained reactivity. I call it where our renderer is pinpoint instead of by component, and it basically got rid of the components, and components were the blocker for hydration in a lot of these approaches. Essentially you'd go, which components do I want to send to the browser? And this has this challenge that when you have stuff that could be static, never rerendered again on the client below those components, you have to send them to the browser too because they're stateful. There's no way of breaking up the component where you know that you can just not send that JavaScript to render to the browser. So taking a bit of the mentality and approaches that I've done with Solid to make everything pinpoint and not component-based, and applying it to the problem of hydration, that's basically how I ended up at Marko. We have a compiler that can go through all your code and determine exactly what control flows, which data bindings get sent to the browser, and basically not ship the rest.

[00:36:41] And as I said, for something like eBay, this makes a huge chunk. We actually did a test a couple of years ago. We saw huge savings. We already knew that was there, but we turned off partial hydration. When turned off, something like the core of eBay's homepage was 500kB gzipped. With partial hydration turned on, it was 70kB gzipped. With a multi-page app framework that loads the least amount of JavaScript, you have the ability to ship fairly large pages and stuff for ecommerce sites with basically the amount of JavaScript it would take to get started. I think you're at almost 70kB. If you get started on a React app, you got to bring in the 42kB for React. React DOM, bringing your client-side router, that's another ten kilobytes. You bring in your data fetching library. Maybe you bring in Redux. You're basically already at 60-some-odd kilobytes gzipped before you even wrote a line of code. And for certain sites, the page load performance is important.

[00:37:32] That's the thing. So it's really interesting to see a completely different approach to frameworks that has been here this whole time. Another thing that Marko was really good at is streaming stuff that's coming in. React 18, Marko's been doing that since the 2014 time period, streaming partials. And the reason, again, it's so important to Marko is that if you can stream the HTML all on that initial load, then you don't need JavaScript in the browser to actually handle the data fetching or the data rendering after the fact. If you're not familiar with streaming, what I mean is literally we start a request, it hits the server, it starts sending the HTML back while it's fetching your data on the server. And then for our out-of-order streaming, we'll render the placeholders in place and render the page, and then keep that connection open. And then as the data comes back in, we'll flush out the part that goes in those placeholders and a script tag to just insert them in place. So even if your app hasn't hydrated yet, hasn't loaded the JavaScript at that point, we can provide skeleton screens and data content loading without even the JavaScript bundle being present, because it just kind of all comes in on this initial HTML stream.

[00:38:39] And because we know that it's again only rendered on the server, we don't even need to send the JavaScript for those components. It's a very interesting and different approach for highly optimized stuff. And as I said, it opened up my mind for SSR. It'll be interesting to see other frameworks apply those pieces. So I went on a bit of a tangent here.

00:38:57 - Anthony Campolo

Yeah, this is great stuff. Very great stuff. Chris, you had a question.

00:39:00 - Christopher Burns

I've seen you've been working on a plugin for Solid. Can you tell us more about it? Because as you said about a Babel plugin, is this like a replacement for the Babel plugin? Is this an alternative? What are your thoughts on this?

00:39:12 - Ryan Carniato

I use the Vite plugin, which I like a lot, mostly because Vite gives us the building blocks so that anyone can build a meta framework. That's essentially the way I look at it. I know people can build applications with this plugin, which is a key part of that. We use it in all our starter templates.

00:39:25 - Anthony Campolo

As someone building a meta framework with Vite, Slinkity, I agree.

00:39:29 - Ryan Carniato

Right? So this is really, really quite cool. And I wasn't sure I'd ever personally get into this meta framework thing. I like working on the core mechanisms. I like working on rendering and benchmarking and concurrency and reactivity. I just started building the pieces I need. I knew I would need a router, I knew I'd need different pieces of the equation here. And what essentially happened was at one point I was like, okay, people don't know how to put these together. We're going to need some higher-level, better starter. And SSR is too complicated. There's too many different modes, especially when you add things like streaming and different platforms that do and don't support streaming and all this stuff. There's too many different variations. And I was like, how can we put this all together? I actually started with Snowpack because I was like, okay, they have a solution for bundling SSR, but it felt very manual. And I was like, okay, well, we'll get there eventually.

[00:40:18] And then Vite 2 came out with the SSR and it was like, I sometimes joke that Evan read my mind. It had all the pieces that I wasn't developing, like the things I'd pushed off where I was like, I'll get to it eventually. File-based routing. I don't really want to worry about that right now. I'll get to that when I actually have to build the configurations for building the starter or whatever. It was like, oh, here you go, glob imports. Stuff like that was just kind of all built in. It made it really easy. So yeah, we have this plugin which powers all our starter templates. And actually I've been using this as a basis of building a little bit more comprehensive SSR-first starter. It's still very much alpha, which is called Solid Start, but essentially very influenced by SvelteKit. It uses adapters and it basically is a SSR development environment. It makes it really easy to build SSR apps because it's challenging.

[00:41:05] I've seen both sides of it. It makes sense to me why there are meta frameworks when it's so challenging to configure SSR. And it's kind of funny because on the Marko side, which has always been SSR-first, they had to build all their own tools back in the day to support their own bundler and do all this stuff. Vite is one of the first ones we've seen that actually allowed us to displace our old tools. We're using it for Marko as well. Finally have an equivalent. The Marko team had built their own bundler called Lasso back in the day, and it was basically on-demand bundling at runtime, very similar to what Vite does with its non-bundling things. And this was important for us, and it seems like it's taken several years, but we're finally getting to a place where this tooling is going mainstream because people are finally working on these same problems around SSR. So I think it is great. I think it's on the right track, it's a great tool and it's going to power a lot of things coming out in the next couple of years.

00:41:56 - Anthony Campolo

Cool. All good. Chris.

00:41:58 - Christopher Burns

My final question is what's your biggest prediction where you think Solid is going to go in the next year. And what about the other frameworks where you think they're going to go? That will differ from Solid potentially.

00:42:13 - Ryan Carniato

That's an interesting question. I actually think that a lot of the goals, or at least the target, seem to be somewhat aligning. How we get there is going to be a little bit different, but it's been very clear the writing has been on the wall for a couple of years now. That server-side rendering and finding approaches to reduce JavaScript are things very much on people's minds. Really, though, it starts with server-side rendering and approaches to that. And personally, I think streaming for server-side rendering, like in React 18, is really important in terms of performance. It lets you load content right away, unblocking the browser and letting your data requests happen faster. Obviously, there's a whole slew of people working on static solutions, and that's why different frameworks are going to attack this differently. But for Solid, we have a basic version of streaming. My intention there is to actually finish up that streaming story in the next several months. I think that is a keystone in terms of being able to look at ways to maybe separate what JavaScript we send to the browser and things like React Server Components.

[00:43:17] I think for the single-page app side of things, React's vision is actually in a pretty good place. Some people might disagree that it's too complicated, that there are too many pieces and you can do it different ways. But generally, directionally, I think for single-page apps we're going to see work in that direction. Improved hydration, essentially, and streaming is a big part. On the other side, though, I think it's going to be really interesting because I think that stuff like Astro is gaining some more steam, and I think that a lot of people are realizing, oh, maybe my e-commerce site doesn't need to be a single-page app. You know, the old, if you have a hammer, everything looks like a nail. I think as much as there's been this desire to consolidate and be like, there's one way of doing everything, maybe there will be in the future. Maybe that's the ideal working towards. In the short term, we're going to see a lot of evolution on the multi-page app side, especially in areas like e-commerce, just because what it can deliver is so much more performant.

[00:44:10] That will influence things. What I want to see is that the frameworks kind of stay true to their vision and not get muddled too much, not be like, oh, I see them doing this over here, I'm going to try and copy a piece of it just so I can check it off. I hope that's not where this goes. I think in the future, multi-page app and single-page app could merge into the same kind of application architecture, as long as the approaches develop out naturally in their own way and they don't make it muddled or more complicated for people coming in. Because honestly, there's a lot of details in SSR, and I think the truth of the matter is we know that the developer experience isn't up to snuff. Things like Next.js are aiding a lot, but there's still a lot of innovation happening in this space, which means more combinations, more challenges to face over the next couple of years. And I'm hoping that something new or some approach can streamline this for everyone, because otherwise server-side rendering is definitely going to be a tricky thing to tackle, and you see every framework working on it.

[00:45:07] As I said, SvelteKit is a first-class citizen for Svelte, we have Solid Start with Solid. I think SSR is on everyone's mind. We know there's a lot we can still do there to make it better.

00:45:16 - Christopher Burns

You quickly said about everyone doing all these things, and for me, I felt the past three or four months is like everyone you say, oh, I need to build an e-commerce website, which one should I use, Gatsby or Next? And now I feel like people are bludgeoning people around the head, going, use Astro or Slinkity or Eleventy. You're like, what? I've been so used to just these two over here for ages.

00:45:40 - Ryan Carniato

That's a whole other thing too. There's a bit there with Astro, which is kind of walking this fine line, which I'm quite excited about. And, you know, Marko's also right on that kind of line. Even Qwik, the new framework from Misko Hevery, is also kind of walking that kind of line. But there's a challenge here because these things go in cycles, essentially, and most of the multi-page app backing is a little bit, I don't know the term, old-school mentality. So when they see that, hey, we're trying to cut down JavaScript, hey, we're moving to considering doing multi-page apps, instantly people's heads can go back to how it was, even Rails for that matter, right? And I don't think it means going back to that mentality, but that's where this is kind of coming from. We're seeing static generators, which keep things simple, but this is going to extend into dynamic sites to get those same advantages. That's why Rails is coming up in the conversation here.

[00:46:28] I think what we're going to see is JavaScript frameworks fill in that gap because JavaScript is the language of the browser. You could argue that WebAssembly offers some options here, but because JavaScript is the language of the browser, it's really one of the best ways, or only ways, to develop your app as a single app experience and have it work server and client seamlessly. And that's why I think the difference this time. Right now, the argument's too much like, oh, is it Rails, you know? Like, is it classic MPA versus single-page app? But the real answer is probably somewhere in the middle. It's cool to see things starting to occupy that space, even if it's just on the static side. On the downside, I say a lot of complexity because now you suddenly have to know, okay, what's ESR? What's SSG? SSR? You know, there's so many different options here. I saw a recent talk from Rich on SvelteKit, which is doing a lot of different modes for rendering, and even then you're like, okay, how do I want to serve?

[00:47:26] My page is static. Is it static? There's a lot of complexity in terms of figuring out how to approach this and more options. So for those who are kind of going, okay, you know, JavaScript fatigue, we're kind of settled in now, I still feel SSR has a lot of movement, which is where we're kind of heading and where we've been at the last couple of years. I mean, the writing's on the wall. This isn't future talking. This is stuff that's been in the works for the last couple of years. That's what the React team has been doing for two or three years. This is what SvelteKit has had going on for over a year now. This is what people are working on, and we just have to figure out a better way to deliver it to end users.

00:48:02 - Anthony Campolo

Awesome. Well, thank you so much, Ryan. This was a mind-bending episode for me and hopefully for our listeners. I really appreciate you getting out and communicating these kind of ideas, because this is not simple stuff, but it's consequential and it gets into really the guts of what we do day to day and how the tools we use actually work. So it's really important that web developers understand this stuff and don't just think like, oh, this is just the new hotness, another JavaScript framework. I don't think that's what's going on here at all. I think there is actually really important work happening here. So really glad to get you on and give you a chance to showcase this. So why don't you let our listeners know just where they can get in contact with you, where they can learn more about Solid, and where are some good links that they can direct themselves to to learn more.

00:48:49 - Ryan Carniato

Thankfully, we now have our home page, which has everything linked up. Whether it's the GitHub, the Discord, I strongly recommend going and checking us out on Discord. That's where our community lives. Discord is great. I'm also on Twitter at Ryan Carniato and also at Solid_Underscore_JS on Twitter. But again, that's all linked off of the website, which has guides and docs and articles and tutorials heavily influenced by Svelte. A lot of great resources there and your gateway into the community, so to speak.

00:49:23 - Anthony Campolo

Awesome. Thank you so much.

00:49:24 - Ryan Carniato

Yeah. Thank you.

00:49:55 - short split/interjection

And good.