Let's Learn SolidJS

Captions provided by White Coat Captioning (https://whitecoatcaptioning.com/). Communication Access Realtime Translation (CART) is provided in order to facilitate communication accessibility and may not be a totally verbatim record of the proceedings.

JASON: Hello, everyone. And welcome to another episode of Learn with Jason! Today on the show we have Ryan Carniato, thank you so much for joining us.

RYAN: Hi, Jason. It's awesome to be here. Been looking forward to this.

JASON: I'm super-excited to have you on. We've talked a little bit on Twitter and the stuff you're working on is super-cool. But before we talk about that, I want to talk a little bit about you. For folks who aren't familiar with your work, you want to give us a little bit of a background?

RYAN: I'm just a web developer. I have been at this now for quite some time. Over 15 years. And I was just working at a startup doing my deal and at some point -- I'm a big fan of, you might have heard of it, Knockout.js. It's a bit older. But I'm a huge fan. It went out and I worked on tool and frameworks built on knockout. And kind of kept to myself, worked at my startup, hoped one day we would use that project. And then, you know, before I knew it, I was building tools and frameworks that other people used. I now work at eBay.

JASON: Sure.

RYAN: They hired me to work on the Marco framework, which is another JavaScript framework. I've kind of taken my hobby passion project to be my profession. So, I mean, that's --

JASON: Nice.

RYAN: That's me.

JASON: Yeah. That's -- and that's the dream, right? I love it when you're able to find, you know, you start out in a career and you start to figure out which pieces of that career are the ones that really give you a lot of positive value. You enjoy it, you, you know, it creates value for other people, it's the thing that can get you paid. So many things like than oh, my god -- Chris. 29 months. I can't believe I have been streaming for 29 months. That's wild. When you can make that into your job, that feels like the dream. That's the best possible outcome is that you can wake up and go, man, I can't believe they let me do the thing I was doing anyways and like give me a paycheck for it.

RYAN: Yep. Honestly. And Marco and Solid are different enough -- I get to explore different sides of the coin. Marco is on the Svelte side of thing where it's all compiler, clean, syntax, less code. And Solid is much more on the explicit side. I get to explore both sides. I'm a big benchmarking fan. I play with all the frameworks. It's really quite fun.

JASON: Yeah. Yeah, yeah, yeah. That's good. I'm excited. You work on Marco, you work on Solid. And Solid is very interesting because the way that I've seen Solid discussed, and I'm just gonna give you my passing perception of watching discussions and you can tell me how wrong I am. But my -- my like observation of what people say about Solid is that it is -- it's reactive without a V DOM. Which is interesting, and the VDOM for people who aren't super-familiar, that's what makes React reactive. They kind of build another copy of the DOM, the VDOM, the virtual DOM, and you can mutate things without having to change the entire document. And the reason that we have that is because the perception is that the VDOM makes it possible to be performant because making those transformations in the DOM, the argument is that cannot be performant. But Solid is saying that's not the case. And if you look at the size of Solid, it's 6.5 kilobytes, it's a baby framework. But also screaming fast. If you look at benchmarks. Solid is closer to bare metal browser APIs than it is to other frameworks in terms of performance. And, none of that makes sense to me when I think about it. Wait, wait, wait. Like, how can you do that? Because there were very good reasons that the tradeoffs were made in frameworks like React and Vue and Angular to have that kind of VDOM in these abstractions over the browser. So, what's different in Solid that makes that possible?

RYAN: Yeah. Solid in some ways is -- how do I put it? Too simple. That's not something you brag about -- I'm not saying it's easy, necessarily. The idea is it's all made of the same pieces.

JASON: Okay.

RYAN: And Solid is built on reactive primitives, I mentioned knockout, you might have seen MobX. Even Vue has this. The big difference in Solid with the other contemporary libraries is it's those primitives that do all the rendering. There's no virtual DOM. There's no top-down render cycle or anything like that. If you have done a hello, world in MobX or something, you write the signals, the term we use in Solid, and write something, create effect, autorun in MobX. You update your field and it spits something out in the console. This sort of thing is like the simple example and everyone sees that and they go, oh, it's cool. It automatically updates, it automatically runs. All Solid is doing is applying that same idea to the DOM.

JASON: Interesting, okay.

RYAN: There's no, now we're rendering. It's just, oh, I'm going to -- you update this data. This field in the DOM is related to it. Let's just update it. It's just like an event.

JASON: Oh, okay.

RYAN: So, it's very small. You posted that 6.4kb, that's so misleading. We have tree shaking. Solid for smaller apps, not using suspense and apps and fancy things is much smaller. It's actually 3.8 kilobytes.

JASON: When you said "Misleading," it was oh, it has plugins? Oh, it's too big.

RYAN: It's much more in the range of pre-act.

JASON: Gotcha.

RYAN: Every part of the renderer uses the same thing again. We just reuse a lot of code, essentially. So, it can be really small. The compiler does very little. That's not something I can just explain on the compilation side. But it literally -- when people look at Solid, they're surprised how little there is there. Oh. This is how I would have written it by hand the way the compilation works.

JASON: I gotcha. Okay. Cool. Yeah. And I'm seeing a lot of folks are excited to see you on the show. A lot of first-time chatters. Welcome, everybody. Glad some folks are catching the show for the first time live. Welcome. I hope you're having a good time. So, let's talk a little bit about the kind of tradeoffs here. So, when we're talking about, you know, we're keeping this close to the browser, these are -- these are simple APIs. What are the -- like what are the upsides? We know a couple of them. It's a much smaller framework. So, there's a lot less to download and work. So, what are some of the upsides and then like do you -- are you trading anything for that? For those upsides?

RYAN: Yeah. I mean, this whole exercise, and by that I mean designing this framework, has been kind of walking that line. As I said, what gets compiled, the basis size, the base thing use make are actually pretty performant, there's not much to them. So that means we're really depending on the reactive system. I sometimes use the term "There's no safety net." Everything -- and this was kind of the down fall of the older reactive library like Knockout. MobX shows glitch-free synchronous execution that's readable. When you create something in Solid, you're creating a real DOM node. If you re-render everything, you're re-creating the DOM nodes. While a virtual DOM cushions that impact. Everything built with Solid is built with purpose. There's helpers specifically. There's a little bit -- the data is reactive. You're not just dealing with plain objects. You have to recognize there's reactivity here.

JASON: Right.

RYAN: There's a big upside with the performance, size. But to be aware if there's patterns or paradigms designed with virtual DOM in mind, whatever, we'll just throw it away, that doesn't always transfer to Solid. We have been thinking in a performant manner. Routing is an example. Solid has nested routing because we needed to not re-draw parent to not do wasteful updates. Like with React and remix yesterday and everything. That's because VDOM is like whatever. It's good enough. In a certain way, Solid's approach doesn't give that. Generally you can build good patterns around performant things, right? We're seeing this in React. Like it's a joy to use Remix and its nested router. There's no down side tradeoff of using these same patterns in Solid. It's good to do less work. Just the VDOM will punish you yet. Same with Vue, Vue has a reactivity plus a VDOM. It's got the whole thing. VDOM is kind of like the safety net. This kind of you can't do wrong kind of thing.

JASON: Gotcha.

RYAN: You take that away. You get performance and you get smaller and you get that. So, I mean, there is definitely a tradeoff there.

JASON: I gotcha. Yeah, yeah, yeah.

RYAN: I think the only place that I've really felt it, though, I claim you can use React in the model for everything. Which is pretty much true. It's a little bit harder for things innately based on diffing. Hot module reloading. That's the only thing in the Dev code. You're replacing whole files and code on the fly. That takes more thought and consideration for something like Solid. But for end user code where people are interacting, touching things, pulling in table data, that kind of stuff. You're not going to feel that. In fact, the granular updates and the simpler model actually aid a lot in performance.

JASON: Yeah. People are saying they want to see the code. I want to see the code. I'm ready. While jumping over, remind the chat, please refrain from framework bashing. We are not here to discuss which is best, we are here to learn. Keep it positive. Nobody is better or worse. You're just learning here. So, this show, like every show, is live captioned. You can find that on the home page of learnwithjason.dev. We have Amanda from White Coat Captioning taking notes -- taking down everything we are saying and making the show accessible. Netlify, Fauna and Auth0 kick in, put money in the bucket to afford things like captioning. So, thank you very much to them. We are talking to Ryan. So, make sure you go and follow Ryan on the Tweeters. And we're talking about SolidJS today. You can find out more here. All right. With that, I have no idea what I'm doing. What's my first step if I want to do this?

RYAN: Well, you came to the right place. This is our website. If you look, there's a tab there that says "Get started" which is a good place to get started. And we have a starter template here. There's a few different templates and starters. For this, we're going to start bare bones. Like anyone coming in to check Solid out for the first time. Run in the terminal.

JASON: Great.

RYAN: To get on the Vite app. We use it and it's a nice experience and we're really stoked about it.

JASON: Great. Let me create a project. It's gonna be called let's learn SolidJS. I love to get -- it's jump a cool -- what a great way to approach this problem. But now I need to get init in it, and open this up.

RYAN: And npm install as well when you get a chance.

JASON: So, we'll npm install and then just poke around in here. I got called out by not looking at the README. So, let me start by opening the README.

RYAN: I mean, a lot of this stuff is mostly just kind of Dev commands and whatnot and links to Discord and the website. Just stuff. The original person who put the template together actually used a lot of pnpm. You don't need to use that, you can use yar or whatever.

JASON: Yeah, I definitely did not use pnpm. But, okay. All right. I'm looking at a few things here. I see Vite. That's always exciting. Vite is super-fast. I see an index.html, and this div id root. This is in every framework, React, Vue, whatever, this is what you'll see. And then I got a source folder. So, what's kind of my first step here? How should we get our heads around how this works?

RYAN: This is a clientside routed typical route. And we have stuff for isomorphic and we have a different starter I might mention later. For this, our entry point is index.jsx. And this is gonna look really familiar to anyone who has used React. A lot of our APIs do look similar. I have a lot of respect for React. I like how explicit it is. And we've kind of borrowed that. And Solid, which we didn't talk about too much, is a framework built on JSX templating very similar to React. It's just everything else that's different.

JASON: So, it's pretty -- so, familiar in terms of, you know, we're not learning a whole bunch of new APIs, importing an app. This looks like -- I'm gonna make a guess, this is a component and we're importing our CSS. I like this pattern. You know where it's coming from. I'm assuming this goes through all the processing and minification and all the stuff we want so we don't have to build all those pipelines themselves.

RYAN: Thanks to Vite.

JASON: Yeah. Thanks to Vite.

RYAN: We're leaning hard on Vite. This is the stuff that I'm -- it's not the part that excites me as much. I'm so glad other people have put the work into the Dev tooling. I'm very UX-focused. I'm very concerned about end user experience and performance and translations. To have people creating great Dev tools that work for any framework, it just makes my life so much easier.

JASON: Absolutely. And we won't get deep into that today. If you want a good deep dive on what it is, and this is with Sunil Pai, we build a Vite project and what makes it cool and why that's exciting. So, I've got -- let's see. So, then this is pulling in from the app. So, that's app JSX here. And -- boy, does that look nice and familiar. I feel like I can get right into this right away. We even have CSS modules. You're speaking my language. This is great! I'm happy.

RYAN: Yeah. Again, a lot of Vite stuff. When you run this example, it should look very, very familiar.

JASON: Okay.

RYAN: Maybe this is a play I like to do. But I love borrowing stuff from other frameworks and taking it unapologetically. This sample is something every React developer has seen at some point.

JASON: Yeah. Okay. So... this is great. So, edit, save to reload. Okay. So, let's try. I want to make a change.

RYAN: If you haven't seen this, this is create React app. We moved the React logo. Yeah. And to be fair, our -- as I mentioned before with HMR, there is some differences in the way it works. Our HMR does need to blow out state below the change because it needs to re-create the reactive graph. When you have nested components, we can't -- we can't really reconcile stuff that happens like below the root change. If you're changing the root component, you are going to re-render like most of the app. This is something we are still kind of doing research in as I mentioned before.

JASON: Gotcha.

RYAN: This is one of the trickier parts.

JASON: But that's the tradeoff of not having a VDOM. You can't create two instances and figure out what's changed and merge them back together.

RYAN: And to be fair, even Svelte has an easier job without the VDOM because they're still component-centric. In a lot of ways Svelte is very similar to React. I know no one ever says that. But you still have behind all the compiler magic a function that goes rerun this component.

JASON: Yes.

RYAN: And that's like -- it might as well be called set state from a mechanical standpoint. I understand you can do equal signs. Solid doesn't have that and we're gonna show that a bit more as we go. What that means. But, yes.

JASON: Yeah. Okay. We've got the basics here. And I'm very happy that, you know, this -- this syntax makes this feel approachable to me. So, you know, I think that a lot of times for me what I'm always looking for is how do we make this feel -- how do you ease the learning curve? And like if we're gonna get into reactivity which is something I don't know a lot about. Like MobX is not something I have a lot of experience with. But JSX, I know how to write JSX-based component files and I know building with Vite. This I like because I have smaller hills to climb to get to the point where I can build something real with this language. Or with this framework.

RYAN: Definitely. There are a couple little small differences that you're gonna notice right off the bat. And actually to answer a question from chat, we do support TypeScript. It's written completely in TypeScript. That's a big thing. I chose not to use that. I'm not the best TypeScript Dev and I wouldn't be able to guide Jason through TypeScript as well. But Solid is all TypeScript. But the other small thing is we do try to lean towards DOM conventions more than React conventions. Just because you use JSX doesn't mean you have to use it like React does. If you notice, it's not class name.

JASON: Right. I noticed that immediately.

RYAN: And you can use className. React is common enough that we have to consider these sort of things. But just little differences. Like this one always hangs up people on every single stream I have ever done. OnChange does not fire on key stroke, it fires on --

JASON: Ah.

RYAN: Things like that are gonna hit the React developer. All that in React that's built in, it's extra layers of code to do behavior they've defined. Whereas we tried to keep close to the browser.

JASON: Yeah. I mean, that's great. Like it's -- I love -- I love that, you know, it's good to stay familiar with the tools we've got. We've got minor differences. But it sounds like we've got -- like you've probably filled this. If I change this to the React way, that will still work. But we don't have to. We can just write this and that also makes portability good. If we know the caveats, like onChange, I can copy-paste in. I have a React component that looks almost exactly like this. I use Preact most of the time and it supports class. I could copy paste out of my components into the framework and it will just render. That's nice.

RYAN: Yeah. And Preact, that element was a big influence. Kept things small and I have a lot of respect to Jason and all to make those decisions and it definitely was an influence.

JASON: Yeah. The work that they have doing on Preact, like Jason Miller is doing amazing work over there. Like how do you write that much functionality? Like pure API compatibility with zero JavaScript. Unbelievable work over there.

RYAN: Yeah. That is a challenge. We have a lot of the same APIs as React. But on the other hand we're not going for exact compat. From that perspective, I can do stuff differently, I don't have to worry about mimicking that behavior. That's a challenge. React, especially the new stuff, there's a reason it's big. It's complicated and they are doing really powerful stuff. Not for a learn SolidJS session. I'm outspoken in the community about how frameworks work. I do a lot of teaching about the internals. I have a stream that I do. Again, I don't think it's for all audiences. But it's definitely one of those things where like I have other framework developers and people working on like libraries going, oh, wow, I watched your stream to learn about other frameworks even though you're talking about Solid.

JASON: That's a good point. I'm dropping your Twitter so people who want to follow you can follow for announcement when is you go live. We've got JSX makes sense. I'm on board. Hot reloading works well enough that I'm happy. So, what -- what next? What should we start looking at?

RYAN: I think we should create a component. I think maybe a counter or something. I think this will just kind of do that. We can make a new file, make a new folder, whatever you want. But counter JSX. Okay. You can start this the way you might want to start this in React. Just kind of think about how you would do that.

JASON: Wait. I'm on a -- yeah, we can do that, right? This is okay?

RYAN: Let's do export default. Right now our HMR works better with it.

JASON: Okay.

RYAN: And then, yeah, for now let's just return whatever. Just like a div with to do. Yeah. And let's see if we can get that wired into our component. We might have to say -- oh, no, you already did save. Sorry.

JASON: Counter. And then let's drop that in. Let's drop it -- we'll just drop it right below here.

RYAN: Hopefully -- I don't know if the styling will get into our way.

JASON: It did. Let me do this, then. Let me -- you know what? Let's declare bankruptcy. We'll... and then I'll get rid of the logo and we won't use the styles. Boom! We're at a -- we're at a stock web page here.

RYAN: There we go. Okay. Cool. As you can see, you can just import your counter component. Let's go into the counter and do some stuff now.

JASON: Okay.

RYAN: Now, I guess the first thing you want to know is how do we manage state, I guess? I think that's probably the first thing. So, we want to display --

JASON: If I like pseudocode this, right? I have a button, add, remove, and then we need a total count so we'll do like a current count is -- and this would be our number. Right? So, we need to make that live.

RYAN: Yep. Okay. Perfect. So, the first thing you're gonna want to do, then, is you're gonna want to import something called "Create signal" from SolidJS. And signal is our primitive. It is -- it is a -- it's our equivalent to use state, but it's basically a reactive atom. It is the thing that we listen to. It kind of drives our whole app. And to use it, you go const tuple count -- write it like use state. Equals createSignal -- okay. There is one big difference here.

JASON: Okay.

RYAN: Is that "Count" is not the value. Count is a function. So, it's a getter instead of the value. That is the biggest difference.

JASON: Okay. so, I wouldn't write it like this, I write it like this.

RYAN: Exactly. Right.

JASON: Yeah.

RYAN: And from there, we can actually write this the same way you would use React. Everything else is pretty much the same as React. So, we can write our click handler.

JASON: That would be setCount, count plus 1?

RYAN: Yeah, let's just do it like that, you can use the functional form too. We have the recursive. Don't worry about it. Let's just do this.

JASON: So, we've got 1. And then we've got a remover function. And so, that will do a minus.

RYAN: Yep.

JASON: And down here, I would just do an onClick. And add my -- if I can type -- add. And then we'll take this whole thing --

RYAN: Yep.

JASON: Change it out for remove. Okay. Nothing exploded. Wow, okay. All right.

RYAN: Yeah.

JASON: Look at that go!

RYAN: Yeah. And there's nothing really fancy here. At least at a glance. As I said, this is -- this is pretty much similar to how you React. I mean, there's a few differences. And maybe -- I don't know. Should -- are we comfortable yet enough for me to maybe show what some of those differences are?

JASON: Yeah, why not? Let's do it.

RYAN: I think I have been kind of -- this is -- most people when they write component write code. This is the thing you're going to do. Don't worry about too much else, just write your code. It's signal use state, but it's very similar. I want to show you something, inside your component body, below remove or something, write console log something. Like hello, whatever. Something just that we would be able to see this. And then let's look at our console in here if we can. And yeah. We see some hot reloading stuff going on. But you see that hello. Maybe clear the console for a second and -- just when you refresh the page, you're still gonna get that. Yeah. Hello. Now click the buttons.

JASON: Interesting. Okay.

RYAN: So, this is the first thing that you're gonna notice that is different between Solid and a lot of other frameworks. Components only run once. And you might be going, what? How is this possible? And if -- if -- I mean, I can show you the compile code, but maybe that's a little bit too technical. The gist of it is, it's because we transform our JSX differently. Each -- instead of components updating, it's where -- it's where things are used that's updating. You could picture that there is just a little function wrapper around that current count is, and that's the only part of the whole app that's rerendering. Essentially that little paragraph element --

JASON: Yeah.

RYAN: Is the only part that's rerunning of all our code here.

JASON: Interesting. Okay. So, Chris asked a question a minute ago which is -- does Solid have a way to just ignore this middle section of DOM in the app? And I think what you're saying is that that's -- that's just how it works.

RYAN: Yes. Yeah.

JASON: Interesting. That's -- okay. So, that's where the performance is coming from, then. Is that you're not having to go through the whole DOM. You're literally just attaching a tiny bit of transformation based on me saying -- so, I'm using the reactive data here. So, these pieces will have reactive stuff. But like this div, that's -- that won't ever be changed. That's completely ignored.

RYAN: Yeah. And the thing is --

JASON: Oh!

RYAN: It's we -- let's just -- I'm gonna show you a second primitive here that isn't necessary-necessary. But just cement this. can you import createEffect from Solid as well. And this is just -- if you have seen useEffect in React, it's very similar. Let's wrap our console log in createEffect. This will I hope give you a better idea what's going on. You will see the hello once. Because there's nothing reactive in that effect. It's just hello. But can we go hello and just plus counter, however you want to do it.

JASON: Okay.

RYAN: Yeah. And again, call it as a function. But now when we do this and you press the button.

JASON: It does the thing.

RYAN: And the reason is, it's only this effect function that's rerunning. That's the only thing that needs to rerun is this one little function here. And all you have to do to picture how Solid works. Pick we looked at JSX and made a couple createEffects in there. Essentially. And instead of console.log. We're doing element --

JASON: Inner text or something. Yeah, yeah, yeah. All right. Okay. You have my attention. Because this is -- this is exactly the kind of stuff that I think is fascinating. Because a lot of times what I'm worried about is that when I make a decision to go with a JavaScript framework, I always feel like I'm over-indexing on JavaScript. Because what I need is for this button like I have -- this is the button. That's the thing that needs to be interactive. The rest of this is text that I wrote to explain why the button's important. And if I'm like forcing the browser to re-render all that text every time I click the button, I always feel like, ah, man, I wish I could do this differently. And I love -- I love that this is doing it -- this -- I think Astro has promise in the same space. You get a little bit of component. This is cool. This is very, very cool stuff that we're seeing.

RYAN: Yeah. And, yeah. Exactly. And I'm -- so, people are asking what the difference is with Svelte? We're gonna do it piece-by-piece here.

JASON: Okay.

RYAN: First difference from Svelte in this exact example. Svelte reruns the whole component. To be fair, they organize your code in such a way that there's an update and create cycle. It's only the update part. Instead of separate createEffect, they pull the things that update and rerun the update block although a component level. They do a div checking if the value has changed so they don't overrun. Solid does do that in some places, but generally speaking, Solid is a lot like Svelte with a lot less diffing.

JASON: Okay.

RYAN: Generally speaking, this is all it is. You can look at the source code and see the compile and the effects and whatever. But essentially, this is your component. The -- and the thing, and I want to mention this here. Is these are DOM elements. These are actual -- your JSX, if you went like const div equals div JSX, you would be holding a DOM element.

JASON: Oh! So, I don't need to get into the ref system and stuff like that.

RYAN: We use refs because it works well in the flow. You don't want to be in the JSX.

JASON: Sure.

RYAN: Refs are very useful, but also very simple in this model. You don't need a special printer or create ref. Essentially, it can be assigned to a variable. Let ref, and ref equals whatever and it will get assigned. It doesn't rerun again. You know when you get into trouble in React when you use ref for something other than a DOM element. Is this stateful? Is this a ref? You have to work through what is an actually stateful change and driving the code and what's a mutable change to persist between executions. What's that value inside that closure -- all that stuff.

JASON: I think you just encapsulated in one sentence what people find confusing about React. I'm saying this as someone who writes React code every day. I love React code and this isn't a bash. This is a statement. React has multiple layers of abstraction and you have to hold them all in your head to be able to do some more complicated things. Because statefulness is one abstraction. JSX is an abstraction. Refs are another abstraction. And then underneath all of that is the VDOM as well. So, you're like, okay, if I was in JavaScript, I would do document like query selector div and then I would just change its text. But if I'm in React, I can't do that so I have to use a ref. But then I have to get like the ref current element -- like you just get all these things that are -- you can do it. But you start to see how people feel it's really removed from the use the platform statement. Right? Like that's a...

RYAN: Right. And the thing is, and I'm a huge fan of React. You can tell from the APIs and the stuff that we do here. But the thing is, this reactive model does have this simplification.

JASON: Right.

RYAN: The component runs once. There's no stale closures because like you don't have to worry about a world outside of the hooks. Like it just -- like it is what it is. And the -- so, I mean, that's a big part of it. And this is -- to be fair -- Solid is not the only framework that benefits from the reactivity. Vue, is kind of like the top of this thing. Svelte. Svelte, my argument is one of the cool things about Svelte isn't necessarily the -- how should I put it? The less syntax and whatever looks like JavaScript. It's actually just the fact that you just write the statements and then think just run and do it. In a sense, this is more verbose. But also write the statements and do it.

JASON: Right.

RYAN: The big benefit about Solid, how transparent it is. When people look at what the template is, oh, it's literally what I would have written by hand. Oh, clone these DOM nodes, set effects. That's what we compile to. But yeah. Okay. The other thing I want to show you, which might be mind bend to people. Can you take that create count? This is just an exercise. Most of the examples that show the difference of Solid are contrived. But take the signal call, the setCount there. Put it above -- like just the line above. Like -- yeah. Perfect. Okay. Let's -- let's see. Saved our file. Okay. Let's run it.

JASON: What? Wow! Okay. So, that's something that... looking at this, my mind says yes and my heart says no. Because it feels so out of my experience. Because like you said, the component doesn't re-render everything type so I don't need this -- I don't need this to be part of the component because it's not being rerun.

RYAN: Yeah. And that's the thing.

JASON: Oh!

RYAN: Reactivity has nothing to do with components. My components here, Solid's components, are just functions. They are literally nothing. No instances, nothing. There's no overhead. This is why Solid scales. I've shown this. The classic problem with reactive libraries is they have the observers, the wrapping components, the heavier things are. It's like a forced memorization. A VDOM is relatively cheap on creation. It just spits out the non-polymorphic, polymorphic structures, sorry, technical. And --

JASON: You just sad non-monomorphic. Like I had any idea what you're talking about.

RYAN: Yeah, sorry. It's like this efficient machine that's kind of designed to do this one thing. Reactive systems add this kind of memorization. So, they're really good on update. They section parts off. But they're kind of expensive on creation because they have to do that.

JASON: Right.

RYAN: And the philosophy with Solid is the components should be the boundaries. It's the control flow. There's an if statement or For Loop. That's where to break stuff for performance. If you add extra boundaries in, you're adding extra overhead. I often like to say. This is not in VDOM. But I'm a big fan of VDOMs. People say the VDOM is pure overhead. Well, your reactive framework is pure overhead too. This is a very different sort of take.

JASON: Right.

RYAN: And the key thing here is Solid's signals are just reactive atoms. They have nothing to do with this. There is a tree that -- in terms of our like effects that get removed and stuff. So, you can't necessarily just like throw effects out everywhere. But generally speaking, our state, like if you want to make a store or something, or, you know, just like stick signal in a file and import it. It has that kind of simplicity as Svelte. It's the same primitives everywhere. You don't need state management because the whole library is state management. Yeah. So...

JASON: Good question from the chat. Robin is asking, if you have two counter components, would they share state right now?

RYAN: Yes. Exactly. I'm not suggesting -- yeah, it became a store. You created a store.

JASON: Wait, though. Because that's incredible too! Is that like... so, if I want to share state, I just have to move it outside of the component and I'm done. I don't have to write any kind of like wrapper components or state management. I'm just like, hey, here's state. It's used everywhere and just keep it. Oh, my god. I feel like -- I feel like things are -- things are changing in my world as we speak. My whole world view is shifting.

RYAN: Yeah. A lot of times we focus on the performance. I'm not gonna lie. That's where I started. That's not where I started. I started with Knockout.js. It was actually this, just not as refined. But then I focused a whole bunch on performance because everyone is like the VDOM is so performant. I'm not sure that's true. It can be performant. But it's not an innately, because this is and is not slow. The truth is everything is fast. If grow on benchmark JS, Solid is not the fastest there are a couple that inch it out. Right next to Solid is a VDOM library. I just straight up put there, VDOM, not innately slow. There are implications of how you write your applications, though. And I think that our model and actually really nice. I think we kind of get full power of reactivity here, right? People look and see React and see the syntax. It's hard to explain this sometimes. But once you see it and give it a chance. You start to understand. This is also where Solid has specific syntax. We didn't do the compiler game. This primitive portability -- the philosophy behind this. All the primitives are hook-like. We have been doing this primitive game, Knockout, this far predates React hooks. And even our Vue are just these. The components trump them up, but even the div is a div. Makes it easy to have all these little pieces that you can compose. One of the funniest things that I mentioned last week was I realized people like to build on top of this kind of primitive thing. To the point where we're still early in the ecosystem days. We don't have a bunch of component libraries. A solid bootstrap came out yesterday, which I'm stoked about.

JASON: Oh, notice.

RYAN: Generally speaking, people compile from sum DSL, this is Svelte -- there's more projects like that than there are actual component libraries because it's so easy to take a base set of primitives and just generate the code you need. You get the leverage of that size and performance. It's just like a layer.

JASON: Oh, yeah.

RYAN: Personally, if syntax, I love the work that bigger frameworks like Vue and Svelte to a degree now. It's getting to become one of the bigger frameworks. And the people in the community, and churning out the best DX patterns and that stuff. Because realistically, if good patterns emerge, we can just copy it. Like I told you, I unapologetically copy things. Because what I have here with Solid is just very powerful primitives, very powerful tools to represent whatever you want.

JASON: You know, you're touching on something that I'm very happy about which is it -- it felt like there was a period, say, 5 years ago, where we were furiously presenting new frameworks. And there were always new frameworks. And we all got tired, right? Like there was JavaScript fatigue. We had to name it. And but then it sort of felt like we consolidated and there were only a very small handful of options and that was the way that we did things. And that helped, I think, it swung the pendulum towards what DX is. Instead of making this what people will do, but how to do it easier. But I think the pendulum is swinging back and more frameworks are emerging. People are rethinking, what did React get right? What can React improve on? What did Vue get right? What can Vue improve on? I like seeing this innovation in the space because it means knew people are gonna be presenting ideas that not only will be able to borrow the best ideas from Vue and Svelte and React. But Vue and Svelte and React will borrow the best ideas from these new frameworks. It feels like this is sort of a Renaissance. We found a good pattern with React and Vue and Svelte. People like the way that they build apps using these frameworks. What could be better? Let's improve. Let's iterate and then we'll diverge a little bit and then converge in a few years and have a small set of new and improved -- or hey React took the ideas from the best frameworks. Or something else will emerge and React will go the way of Backbone. It is cool to see the innovation happening again because it felt like it slowed down for a little bit.

RYAN: The funny thing, I felt the slowdown, I get it, people were tired. I wasn't tired. I did the majority of my work off the radar. I honestly thought, no one will like what I'm doing. This is before React hooks.

JASON: Sure, yeah.

RYAN: And people are like, how do you do this without class life cycles? What are you talking about? You can't do this. This is a toy. And they didn't understand what I was doing here. No, no, this is an older approach. This is like 2010 time period. And the thing is, there is so much going on. Especially on the server rendering side. This is an area I'm very invested in in terms of looking at patterns and stuff. As it probably goes outside of the beginner topics. But there is a lot of stuff. And a lot of what I have been doing with Solid, as I said, it's at a different stage in the phase. React ecosystem is at the Next.js, Remix level. We're building the meta frameworks to make those things powerful. Solid is the early adopter change, okay, completely shaking up the fundamentals. Completely. And in a lot of cases, you can't port that into the other libraries. They have an expected behavior. React will never be like this. Never, ever, ever, ever will be like this. I usually never say never, but for React, I will say it will never, ever be like this. Svelte being a compiler, I love compilers. They have a little bit more range.

JASON: Right.

RYAN: We can change the output as long as we don't change the language semantics. And I think that's interesting and I work on compiler Marco, I think there's a lot of interesting growth. I think right now we are definitely at a phase where people are starting to come out of the woodwork to see that innovation happening.

JASON: For sure.

RYAN: It's a natural cycle. You go and start pushing the meta frameworks. Oh, my Next.js app that does my blog site is 120 kilobytes. Why can't it be 8 or zero kilobytes? That's the thing. Solid is very much at least on the single page app side of things is kind of innovating patterns there. Similar to Svelte. That's our zone. Great things on the multi-page side, Marco, Astro. Really interesting time to be in web Dev.

JASON: Yeah. And Brittany put it well, they're not enemies. They're borrowing ideas and pushing to make the web better. That's such a good way to put it.

RYAN: I don't know when it became the Highlander. I make that joke. There can be only one. It was in the like that. I'm a bit older, you know, as I mentioned. I actually cut my teeth on web Dev like in the first wave like '95 period. I was like a 12-year-old kid making websites. I watched the cycle happen. I built this simple JavaScript and then I was in there for Dotnet, PHP, Java, the whole fun thing. And when I found Knockout.js and jQuery to some degree, knockout, wow. I'm back here. Back to the JavaScript thing, library over framework kind of mentality. We go over the cycles over and over again. In early 2012, '12, pre-React, no one assumed there would be only one. Somehow that's the dialogue for the last 5 years. We have to find the one framework.

JASON: I've seen -- there's a phrase that I hear. Like VCs apply this to platforms and stuff. But I feel like it applies more generally. Which is that life is just the slow cycle of bundling and unbundling things. Like we, you know, we say like, well, we need more options. And so, we see the options spread. And then we go, this is too many options and we consolidate. I'm too restricted and need options and then we spread. We saw that with cable to Netflix and now everybody is bundling their services put all of your content subscriptions under one bundle and pay one price. Oh. So, cable? But I think it is slightly better than cable. It's an iterative process. Those how this works. Same thing. We felt we were too restricted when everything was jQuery. We exploded out into tons and tons of options, that was too much. We need to consolidate. And we were on the leading frameworks. I'm too restricted and need more topics. I'm vastly oversimplifying. But I think that that's a -- it's a normal cycle that I've seen everywhere in and out of web Dev. And I'm excited to be in the exploration phase. I always like it when we're -- as a culture we kind of go, okay. It's time. Let's get weird.

RYAN: Yeah. Yeah. No. This is great. Why do you think this doesn't get more attention, Ryan? Honestly... there's a lot of people -- developers in the world. I don't think I can get the word out enough. It's shows like this is where people actually watch and people are that you're gonna do that. And honestly, I didn't try to get attention initially. And I think a lot of people do just see this -- see React and two, ah, it's faster, smaller React. So what? I like to think this is actually gonna improve people's lives, improve the way they approach the problems. The thing that hasn't been said here, where is the dependency array? Where is the dependency array on that createEffect? And use callback, use ref? Where are these things they just don't need to exist. And that's a thing of React. And don't get me wrong. I like React. And then similarly, like, you know, Svelte, you know, the stores, where is the Svelte store? There isn't a Svelte store. It's just the same signal. I think there's ways, the way we just hoisted it out. I think there's ways and powerful things we can do here that go beyond the normal selling points. It's something really hard actually to sell it to people. I don't like comparing Solid to other frameworks. But it's where the conversation goes. It's great, it's reactive, fine-grained and reactive. Yeah, so, how is it not React? Well, because it does this. I'm pushed into that dialogue. I don't feel comfortable... like I'm fine that you choose to use React over Solid. It makes sense. A huge ecosystem or whatever. I'm not gonna push you on it. I don't want to be too aggressive.

JASON: I will say one of the things that I find most frustrating about some dialogue now is that I feel people show their... I guess... maybe lack of pragmatism when thing that one tool can solve all problems. Like I think there is a -- there is a point of -- call it whatever you want. Being jaded, gaining wisdom, experience. But where you just kind of realize that, you know, each tool is built to solve a certain subset of problems. And if you expect that you can like take -- you pick up a hammer and go, great. I'm gonna drill in this supporting bolt here. Well, that's not what that's for. You might be able to solve that problem but not in a ergonomic or easy way. There's a reason the toolboxes have lots of tools -- thank you for the subs, everybody. I appreciate it. Now we've got a hype train. Here we go. But the fun -- like... for me, I guess, I've started to notice that are more senior a developer is, the less likely they are to say tool X is bad and tool Y is good and you should always use tool Y. It's more of a discussion of here are the tradeoffs of X and Y. Based on what problem you're trying to solve, make the tradeoffs in your head and say, you know, I am better served by this set of tradeoffs than this one.

RYAN: Yeah. Like most definitely. And I think it's cool when we get to convergence points where tools stride out of the comfort range or are good in the area, but there are different categories of things. For example, the divide between sites and apps is still real. As much as I would like to say that we're moving towards something in the middle where we can like -- like and you kind of can sort of pull it out. When you have a really small framework like Svelte or Solid, you can build sites good enough. But then there's tools like Astro, Marco, you should be using that for sites. It's a tool built for that. Eventually this converges. But yeah, it's always tradeoffs. Should -- should we -- I'm trying to think --

JASON: Should we write some code? We probably should write -- I have a question. And you can tell me if you would rather show off something else. But I was thinking, we started talking a little bit about stores and shared state and stuff like that. So, what if I want to build another component that uses this state and kind of derives a value from it? So, you know, maybe a limit thing. Like if the count's under 5, it says one thing, over 5 another thing, over 10, something else. Is there something else you would rather show than that kind of connected component thing.

RYAN: That's not bad. The thing is we have a context API. It's the same as React's. But we wouldn't need to showcase that. And I don't think anyone needs that baggage for this. The other options were we look at doing an API request from some public API like Swappy or something.

JASON: Yeah. Let's do that. Let's pull some data. So, I have a -- I built an API specifically so we would have something easy to grab. So, I have a schedule API that we can hit that will just pull episode JSON.

RYAN: Beautiful.

JASON: Okay. I'm gonna create another component and this component is going to be called Schedule. And inside of it I'm going to export default function schedule. And this is going to return a div and we'll make that a to do. And up here, I want to pull in this -- this thing. So, let me save that. And then --

RYAN: Okay.

JASON: And we'll come out here. And let's just include it real quick.

RYAN: Beautiful. So, Solid has a built-in primitive for this because we want to handle things like suspense. And while we don't need suspense to do this example, we'll just start with that. The first thing you want to do here is go import creator resource from SolidJS. Create resource.

JASON: Okay.

RYAN: And then essentially, all we have to do is... how should we do this? So, let's just stub out the -- the hook so to speak. So, const like -- yeah. Let's do const, square bracket.

JASON: I like that Cassidy waited right until we were gonna do code to flood the screen. Okay. So, I -- I am creating a resource here.

RYAN: Basically -- what is this? A schedule?

JASON: Yeah, it's a schedule.

RYAN: And then equals. Like get out of the array. Equals createResource. And what this does is basically take answer async function. It's a function that returns a promise. So, we can just -- yeah. Whatever we want to do here.

JASON: Okay.

RYAN: We're probably just gonna use fetch on this. Like I said, we don't actually have -- we don't care from the promise is. We just need the -- a way of fetching from the API.

JASON: Okay. I can just like return fetch.

RYAN: Yeah.

JASON: And then we'll put this in there. And that doesn't need any arguments. So, we can then just do like a... r e...

RYAN: JSON, yeah.

JASON: So, that's -- there's our resource.

RYAN: Yep. And the most simplistic thing you can do -- thing to do -- literally just put "Schedule" in there. Call as a function.

JASON: Right, right, it's a function.

RYAN: Obviously we need to format it or something. So, yeah. JSON, yeah. Okay. So, I mean, this is the basic thing. Does this API have any IDs or something? I mean --

JASON: Yeah, we've got IDs here.

RYAN: We can also iterate -- is this a list? Let's iterate over this list.

JASON: Yeah.

RYAN: So, Solid uses -- you could use map. But map is a map function. And if you know anything about a map function, when it runs, it runs to completion. It's the same that you use a For Loop with an early exit rather than forEach. Solid can deep with the loop. Capital F4. Since you're in JavaScript, you don't need to import this. If you're in TypeScript, you need to import it.

JASON: It already grabbed it for me.

RYAN: For each is the name of the attribute, equals, schedule function. Exactly. And then our function takes a render prop, essentially. So, you can --

JASON: A render prop or a -- like one of these.

RYAN: No, you don't have to do render. Sorry. The children's a function.

JASON: Got it.

RYAN: So, you can...

JASON: So, what do we get in?

RYAN: Curly braces in the forEach. Like inside -- sorry, the for. Like there. Yeah. And then item arrow function or whatever.

JASON: Ah! I understand. Yep. I'm with you. I'm with you. So, then I can do one of these and I can do like an item dot -- what is it? Title?

RYAN: Yeah.

JASON: Title. Let's start there and see if we can get this to print out. I didn't break it. I thought I broke it. I didn't break it. Here we go!

RYAN: Like I said, you could use a map function, but sorting or moving the list or doing anything, then it would re-make a bunch of DOM elements because map has to rerun the whole map.

JASON: Holy buckets, did that just work?

RYAN: The other piece here is this is automatically keyed. For information for people who cared, this is keyed to the data. If we were swapping stuff, the for component basically adds the keys for you automatically.

JASON: Ah... that's really nice.

RYAN: That's just a basic data fetching. Now, if we like an ID or something, like if we wanted to drive this off state, let's say you wanted to grab like you have like a input or a URL and you want to like drive it off like ID1, ID2, ID3, I don't know if that's something we can do here. We can also have the resource basically... it's very similar to React query, the create resource API. So, it's possible to essentially pass the first function in where you say --

JASON: Okay.

RYAN: Where you say pass the query to the fetcher, so to speak. We made a version that's just the fetcher. But you can also pass the query to the fetcher. If that makes sense. I don't know if we should go there or not. But, yeah. We just loaded some data. There was --

JASON: Yeah, so, we've got some data here. And so you brought up something which I am interested in. Which is if I wanted to show like a sub-page for this, and, you know, maybe we could do this either in state, like if I put the slug here.

RYAN: I guess we could also pull in Solid app router.

JASON: We've got about 20 minutes. Whatever you want to show off. Yeah.

RYAN: Okay. Are you familiar with React router 6 at all?

JASON: Enough that I like read their migration guide.

RYAN: Okay. I'm trying to think if we go that way. Because we could just pull it in if we had a route. We also -- we could handle in state. But it's a little bit more complicated.

JASON: There's some questions about just the querying in the fetcher which honestly I only sort of understand what you mean. So, maybe what we could do is -- is mess with this data a little bit. Like one example is I only passed the slug. Maybe we could generate the URL so that we can actually like link these. Is that a thing that we would do in the -- in the fetcher? Or how does that work?

RYAN: Generate the URL so we can link these.

JASON: , like these. If grow to learnwithjason.dev and put in the link, that doesn't come out of the URL. Only the slug comes out of the API. If we wanted to generate it, we would need to prepend the web, the URL to the slug. Is that -- like is that the use case for the query in the fetcher? Or am I misunderstanding what it's for?

RYAN: It's so, like if you had a list of things and you wanted to get the first one or the second one and pass in an ID and drive that by state. So, like if you --

JASON: Oh! Okay.

RYAN: I'm just right now we're just fetching something and whenever the component amounts, it fetches it. This is the list view, if you had the details view, how would you make the details view work is essentially what I'm saying.

JASON: Okay.

RYAN: You can pass in basically the argument. Like a simple way of doing this. Do you have a way to query by slug? Like... or does it just... like there's no like parameters. Can you go schedule/ID?

JASON: That is a wonderful question. Let me find out if this does what I -- I don't know if I built that. Let's see... I did! Ha, ha! So, I have -- I have an API to pull data for a given episode.

RYAN: Right. We just need to know the slug. So, what we can do is we can make an array of, you know -- of some slugs or something. And then just like -- or like a drop down or something. And then -- and then essentially based on the state of the drop down switching or the -- or the input or whatever, we can basically pull the specific data for it. So, instead of a -- yeah. We...

JASON: Do an option and then the val -- whoops. Then I need a -- whoops. Get out of here. What are you doing? Value can be the item slug current. And we can put this here. And so, this is not gonna be perfect. But now we've got a drop down and each of these is gonna have its slug as its value.

RYAN: Right.

JASON: We can do a query based off that.

RYAN: Right. We can make a second resource that drove -- I mean, usually -- yeah. It's funny because I think it's the same data. But let's pretend that we fetch less on the list and then we fetch more on the details.

JASON: Yeah. Let's assume I wrote an efficient API. [ Laughter ]

RYAN: Then we could just create another resource here for like the specific one. And then essentially take that and stick that in there instead and then put the wild card into the -- yeah. Exactly. Replace that with like a slug or something.

JASON: Okay. Like this.

RYAN: Or, no. Use a like JavaScript dollar sign --

JASON: Oh, I gotcha.

RYAN: Like that. And then assume that the slug is getting passed into the async function here. And then, okay. We need some state. Let's go create. Let's add a createSignal somewhere in here as well.

JASON: Okay.

RYAN: And put it up there.

JASON: I will do slug, setSlug.

RYAN: Exactly. And we're gonna --

JASON: And... or I guess we can start with like false or something so it's...

RYAN: Yeah. Exactly. And we want to tie this to a change handler on the select element, right?

JASON: Yes. We do. HandleSelect. And that's gonna be an event. And then I want to setSlug to be event: Target: Value.

RYAN: Assuming we got our values right. And beyond that, all we need to do is -- okay. Wire it up. So, to create resource, pass slug as the first argument in front of the async function to that one, yeah.

JASON: Like this?

RYAN: Yeah, slug, comma. Perfect. And then finally, we need to display our episode below our select list.

JASON: Yes. Okay.

RYAN: Fragment.

JASON: Fragment.

RYAN: Yeah.

JASON: And then we'll get a -- do like a section. And then inside this section we want the title and that's gonna be enough. We're gonna -- we're just gonna put the title in.

RYAN: Okay.

JASON: So, that means we need to be able to pull this data, which is gonna be the episode.

RYAN: We still need -- yep. Do that first.

JASON: Do I... like... how would you? Would you do it episode title or is there a convention for doing it differently?

RYAN: That's fine. That's fine. What else, we need to add the change.

JASON: OnChange?

RYAN: This is fine to be a onChange. Blur event --

JASON: For people who get tripped up by this because it's handled differently in React. Would it be on key press?

RYAN: On input.

JASON: On input. That seems good. That seems fine.

RYAN: On input element and you want to get the key stroke. That's fine.

JASON: If I want to do a if slug, so, if slug -- I should do this differently.

RYAN: There's a -- I mean, sure. You can do this if you want. Solid handled ternaries perfectly fine. We have a show component. Let's do the ternary. Slug's a function.

JASON: That's right. Slug's a function.

RYAN: Okay.

JASON: And this, theoretically speaking should start by showing us nothing.

RYAN: Yep.

JASON: Now it does. Now I'm going to choose one. And it should query it. And I must have screwed something up. Yes, I did. And the thing that I screwed up is reading title of 32.

RYAN: Okay.

JASON: I'm assuming is --

RYAN: Oh, yes. Because there's a time period in which the slug is set and the episode hasn't loaded yet.

JASON: Right. Because we got to do suspense now.

RYAN: Right. But we can -- what time is it? [ Laughter ] But how about instead of slug just make it "Episode." That might be the easiest thing. Like there. Just make that episode.

JASON: Okay.

RYAN: And now let's see...

JASON: Hey! Look at it go.

RYAN: Right. I mean --

JASON: And we could make this better, right? Like I could do... something like... like that.

RYAN: Yeah. And if you're gonna do this, I'm gonna say, why don't you just make that the show component.

JASON: Okay. And I do that like, show.

RYAN: And then it's when episode is a function.

JASON: Episode...

RYAN: And then just -- yeah. Just stick the children in. And then for the -- for the -- for the other thing, it's fallback. So, on the show component, go fallback equals. And then drop the loading in. Actually, yeah. This is actually gonna be great. Sorry. I just realized. Cause -- so, this -- now this will work. Or it should work.

JASON: It does.

RYAN: Okay. And then now if you just change the show to suspense... oh, actually, no. Don't change the show to suspense. Sorry. Wrap the show with a suspense.

JASON: Okay.

RYAN: And then --

JASON: Did that come in? It did. Okay.

RYAN: And then move the fallback to the suspense off the show.

JASON: Okay.

RYAN: Move the fallback up to there. Move that on to the suspense. This should --

JASON: Wow!

RYAN: Work. Because the resource automatically registers the suspense and does all that.

JASON: I think I just timed out my own database.

RYAN: Yeah. It did come in. Delayed. Too many requests coming in on the free tier of AWS or something.

JASON: This is slick. This is really, really nice to work with. Where we... I mean, we've got like pretty straightforward stuff going on here. None of this looks wild to me. I know how to use the fetch API. So, I understand that. This is -- this is cool. This is very cool.

RYAN: Yeah. I -- I'm hoping that just these are a few core primitives we built in. And then you can do so much with them. Obviously, this is the basis of other stuff. And maybe when we finish up solid start, of kind of -- come on again and show you that. We're building our own meta framework similar to Stealth kit's, similar to remix. It has nested routing and all those things. I put a few demos up. You might so seen those on Twitter. I deployed one to Netlify. It's all the same demo using this kind of starter kit that we're working on. But, you know, it has, you know, file-based routing and all the advanced features. But the key part for today is just with a few simple primitives, you can do so much.

JASON: So, there's a question about what -- what happens to a fetch like this on SSR?

RYAN: Yeah, so, it depends on what you want to do. If this is a pure SSR function, when you do this, it's -- it depends on the mode. But if you -- if you're doing async rendering, okay. Yeah. Let's just start there. It's just gonna fetch it on the server while it's rendering. And then it will wait until the end automatically. Suspense boundaries fill out. And ship the page with everything in place. If you're doing streaming, it's a little different. It will actually stream the place holder over on to the page. You'll see the loading state in the browser. And then when the server finishes the request, it will then stream in the rest of it and then insert it into the page. So, basically, with SSR, what you get generally is for these requests that happen on initialization, they'll happen on the server instead of in the browser. And in that way, you get more performance. Because you don't have to wait for the page to like come back, request the JavaScript, come back.

JASON: Right.

RYAN: Request the server, come back. There's like three inherent waterfalls. Async is pretty good. Then you can wait for everything and ship it. Streaming is even nicer because you start streaming the page -- the part of the page that's ready. You bringing in the images that are already available. You start bringing in the resources and loading everything ahead of time. Streaming is -- in my opinion, it's the best thing coming to server side rendering and single page apps. Multipage apps have things like partial hydration and techniques to produce JavaScript. But on the it's coming in React 18. It will make React the third to support this. We have it in Solid. We have had it for a couple years now. This is Markos thing. Markos had streaming SSR since 2019. It's a big deal. For dynamic rendering, non-static stuff, this let's you not block your page loading, load stuff immediately on the server and basically get the best of all worlds. If your network is fast, then you're -- like you're gonna see those loading states and it's gonna feel like it's instant. Especially on the edge. You get the static stuff almost immediately and the dynamic stuff flows in. This basically is a good argument for why with the common edge maybe SSG doesn't need to be pushed as far. Streaming is key there. It's not just the proximity to the edge. It's literally you can respond immediately with the static stuff while the dynamic stuff is coming in.

JASON: Sure.

RYAN: And then on the -- sorry. And if your network's slow, if you have bad Internet connection, streaming is gonna look a lot like wait to render async. Because by the time everything loads up, well, the request on the server is already long done. Your page just loads and it's just there and ready for you.

JASON: Yeah.

RYAN: The whole spectrum. Streaming basically improves the performance across the whole spectrum if your data latency is high. If your data latency is quick, then maybe it's no different than async rendering, the traditional stuff in Next.js, whatever. But if your data latency is higher, streaming is a huge benefit. And if you think about it, closer to the end user, customer. What you hopefully have is faster network and maybe slightly slower data latency. The edge is built for rendering.

JASON: I get it. This is a place where a lot of the platforms are exploring and moving toward. I think there's a lot of high potential there. Okay. With that, we've got about 5 minutes left. While you were explaining streaming, I did just a quick little bit of CSS to honestly just to see how -- how well that worked and surprise, it worked really well. You just define your thing and then you do your thing. And then if you inspect the thing, it does a custom class so that you don't end up with app collisions which is just so dang cool.

RYAN: Yeah. Thank Vite for this. I'm no CSS expert. But it's really nice this is built in. Solid doesn't have like the built-in template stuff. But I -- but there's so many CSS-in-JS libraries. Extract or style components, goober, emotion, endless list. Some of the ones that are JSX-based we have to do a custom wrapper for. But most are plugged in the way that React is. Like CSS modules here, just works really quite easily and quite nicely. And in terms of HMR, the CSS is actually pretty good compared to the components. I'm pretty sure that -- that just hot reloads like nothing.

JASON: Right. Yeah. This is slick. This is really, really nice. It feels good to use. And, you know, so we have been able to build out like pretty decent number of features here. We've got, you know, some stateful stuff. We've got some async stuff. We got suspense up and running in a -- in like zero minutes which is always a lot of fun. Anything else that you want to show in like 4 minutes?

RYAN: Ah, man. I think any other topic would get too big.

JASON: Here's what we can do instead then. Let's take the time and start looking at a few ongoing resources. Also, chat, if you have questions, drop 'em now because we're running out of time here. We know we've got the getting started on solidJS.com. Where else would you send somebody if they wanted to dig in and further with Solid?

RYAN: The tutorial section, honestly. This is one of my favorite things. We shamelessly stole this from Svelte. There's 40 plus tutorials here with every feature. The drop down, you will see that there is a ton. This is the Svelte thing all over again. It's -- there's an example, there's a solve. Play with the playground. This is the -- we're working on making this more beginner-friendly and getting things started. But if you're kind of experienced in web development at least and, you know, have at least some bearing of some of the topics other features in other JavaScript. This is the go quick side. This is how you do this and solve it. I use this to look up pretty much all the time when I look at Svelte or other frameworks. This is our Rosetta Stone.

JASON: This is great. A question in the chat. Anthony is asking, we talked about tradeoffs earlier, what is SolidJS bad at? What are the short comings? We have heard what the new technologies do well, but not what we lose. Cliff's notes versions.

RYAN: Things that are innately diffing. We have data diffing. Those terrible benchmarks that Spam the screen Solid is pretty bad at. The biggest thing is it's just not compatible with React. This is a big tradeoff. Because you just can't leverage that current ecosystem at all. And it probably never will. It works differently. But I mentioned, I think HMR is a very difficult challenge. But I'm not usually thwarted by those. Solid has concurrent rendering which people consider a significant challenge without a VDOM. We have SSR hydration, the whole thing. Like those are difficult challenges when you don't have a virtual representation. I think they're solvable. I think, you know, mostly just incompatibility. This is kind of like starting from square one again. And not everyone's ready to do that.

JASON: So, it's a little more of a, you know, you're gonna find yourself in unexplored territory if you start adopting SolidJS because a lot of what React has well-paved where you can go to Node and find a library that does what you want, in SolidJS, that work hasn't been done so you'll be one of the people paving that path.

RYAN: Yeah.

JASON: By going and doing that exploration. I could say that could be a down side for some people because, you know, the plug and play is not there. But it's a huge upside for people who feel like everything that could have been invented for React is done, and you can't contribute to open source because everything is in the tuning phase. Solid is at the we need a baseline primitive for this common UI feature. You can go out there and be the author of that library. That's a cool space to be in if you're looking to get into open source.

RYAN: We have a project for that called solid Primitives. It's run by our project manager. And it's got a to be of different primitives. We're accepting PRs and going through the process. We're collecting a large set, as you can imagine, solid bag based off of primitives is like React views, Vue has one too. We're building up the collection. Definitely check out Solid Primitives for that. Someone actually mentioned about destructuring. Okay. We didn't talk about this in here. Because Solid is reactive, where you access the data actually matters. Destructuring props loses reactivity. I don't consider this a down side. It's like our one hook rule. Basically if -- in most things, you know, like there's all those hook rules in terms of stale closures, got to be in order, all that have. Solid doesn't have the hook rules. The one rule is don't access reactive properties outside of where they're used otherwise it won't track. Destructuring props is basically off the table. We didn't hit it today. But don't destructure props. Then you'll be good. That's our one hook rule. That was our tradeoff.

JASON: Cool. Okay. That makes sense. Why...

RYAN: Oh, what does the community look like? Go to the Discord. I think we are probably up to about 2,000 members on the Discord today. Last night there was a Hacker News post randomly and essentially we -- we got a whole influx of new people. There's always people working on projects. We have component libraries being mentioned on. Bootstrap came out. Someone is working on solid carbon components, solid headless, headless UI. There's just a base of bunch of projects all in the 50, 60% range that I know in the next couple months are going to come out. The ecosystem is growing really rapidly since the release. six members on the core team, a lot of active members in the Discord. The links are right at the top of the Solid side. I see you're doing a Netlify deploy.

JASON: It's been SPA, should be straightforward.

RYAN: I don't have the links, but Charlie Gerard did a great set up, go and click the button, and you're good to go. I don't have that link on me offhand. But great Solid starter for people who want to deploy to Netlify.

JASON: Let's see... was it the restaurant one? Or something else?

RYAN: It might have been the restaurant one. Because at the bottom, there's like -- yeah. Deploy to Netlify.

JASON: Okay. We'll make sure that shows up in the show notes for anybody who wants to learn. We will call this a success. The site is deployed, you can look at the source code, and you can look at it. We have a host of resources. And go and follow Ryan, again, because there are lots and lots of things to learn by watching just like honestly just eavesdropping on Ryan's Twitter conversations is very informative. So, we have had live captioning on this show like we do on all shows. We've had Amanda from White Coat Captioning here all day, thank you for being here. Made possible through our sponsors, Netlify, Fauna and Auth0 to make this more accessible. Check out the website. This is stream number two, we have two more. Talk about design systems with Georges Gomes on December 2nd, that's Thursday. Build your own design system. That's cool. I got a peek at Backlight Dev. And talk Natalia Venditto and lots of fun stuff. And it keeps getting better, passwordless auth, UI review, I'm going to stop reading. I will get them wrong. It's amazing. You can add Google Calendar here and find it on Twitch. This is where we stream. Make sure you mark that calendar. With that, Ryan, any final words for everybody?

RYAN: I don't know. Thanks for watching.

JASON: All right, y'all. We are gonna go find somebody to raid. Stay tuned. Ryan, thank you so much for hanging out with us today. We will see you all next time.