Noel: Hello and welcome to PodRocket. I'm Noel. And joining us today is Ryan Carniato. Ryan's been on the podcast a few times. He's the author of SolidJS. He's a part of the Marko core team. He's here today to talk to us about SolidStart. How's it going Ryan? Ryan: It's going pretty good. I'm pretty happy to be here. Noel: Before we get into it, can we kind of get a quick intro on yourself and a recap of what Solid is for people that maybe didn't catch previous episodes or just aren't aware? Ryan: Yeah, as you already mentioned, my name's Ryan. I created this JavaScript framework, SolidJS started around 2016 time period. Didn't open source it to 2018 and got to 1.0 in 2021. So it's only been a one full year now or so since it went 1.0. But its big hook is that it's uses something called fine grain reactivity to do all state updates and rendering. I often tell people that Solid is a state library first that just happens to render things, which makes it a little bit unique in this space of a lot of Virtual DOMs and whatnot because Solid does not use a Virtual DOM. It's all this runtime reactivity. Noel: Nice. Yeah. So I could ask, we've done episodes already on the benefits of Solid, the pros and cons of it versus a little more heavy handed framework, if that's a fair term. But if you could give us the two-minute sell, why should devs that are using React or Vue check out Solid? Ryan: Yeah, biggest thing for me is taking the control back. Tools have gotten more complicated over time and while Solid does use some compilation in its JSX, it's really a framework that's transparent. You'll never feel like you lose control of it because honestly you probably could have written it yourself. It just uses reactivity. The same primitives like using state and effects to actually render the DOM. So you never get far from it. Your JSX produces real DOM elements. The updates are all based off this reactivity. So there's no component rendering. You don't have to worry about so much about memorization. There's no dependency arrays, there's no memo, use memo, use React, use callback. None of that hooks around performance optimization. It's generally just you declare some state, you put it in JSX, it's still JavaScript, you can put as many components you want to file, all that kind of stuff. And you basically get this really powerful framework that works. As I said, it looks a lot like React. It has that component-based architecture, but in a sense, it completely scales up from maybe jQuery mentality because every piece is just, it's its own reactive update. So I think that's really where the value is. It basically gives the developer the control back with that ability to compose and be modular. Noel: Yeah, I'd implore listeners to go check it out. It's pretty easy to get started especially if you're used to React libraries already. You can get rolling super quick. So I think it's worth exploring. What's changed since we spoke in the Solid ecosystem world. I think it was March this year changed in Solid since then? Ryan: Right? Yeah. March. We were talking myself and Dylan a lot about the future of hydration and server side rendering and a lot of those changes Solid actually happened. Started to happen a little bit before to go back a little bit. But this past year since 1.0 we've just seen it. Things finally kind of picked up. People were sitting there going, "Oh when Solid gets to 1.0 Maybe I'll take a look at it." And now they are starting to. And ecosystem was a big thing for us, a challenge because who wants to invest in this? But we did a hackathon last January and it filled out a lot of libraries. We now have ports and Material UI, Chakra UI. So we have component libraries and style libraries and a lot of miscellaneous things, animation libraries, Motion One, there's just there I couldn't be happier about having all these libraries coming in and filling out the ecosystem because thing to understand is Solid does not have React compat even if it looks similar. And what's really cool about this is it means that when people want libraries or they build libraries, it's not just about picking up some existing library. There's maintainers and there's people involved. So when this ecosystem grows on libraries, it actually grows more importantly on people. And that's what we've really seen. We're actually seeing people use it, real projects getting deployed to production and whatnot. A lot of startups and smaller things to be fair. But it's starting to get out there. So that, that's been the biggest thing. It's just the usage really. Noel: Yeah. Nice. Yeah, the human element of these community projects is like... You can't really oversell it I don't think. It is so important. It's also, I think that to your point of having component libraries and stuff ready to go UIs and make it easier for people to, "I've got some little side project, I want to try something, I can just pull a component library in this new framework I want to try off the shelf and I can get something pretty good out the door in a matter of hours instead of having to mess with fiddly CSS and stuff." Is always a huge pro. Ryan: And it becomes even more the case when you actually get higher up the stack. Which we'll tie into. So I'll start here in a minute. But when you start talking about things like auth libraries and certain kind of patterns for data fetching, what you find is that you're writing less of the framework code outside of let's say the templates and the JSX than you realize. Which actually means that a lot of the jumps you might go through thinking and porting and stuff aren't actually as big. Actually, it's very familiar and big part of that, which I didn't mention a minute ago is while there's been also a lot of Solid specific libraries, there's been a shift in the ecosystem to what I'd call these framework agnostic libraries I think. And not web components. I know that's what people come to where you're like, "Oh you can use them in any framework." I mean agnostic vanilla cores that get then written in the specific framework. I'm kind of been dropping the term framework native as a term where someone writes something kind of a vanilla core and then they make this felt version, they make the React version, they make the Solid version. And a perfect example of this is the work that Tanner Linsley has been doing. He's rebranded React Query, React Location, React Table to TanStack query, location table, et cetera. And as you can imagine, and he actually just released a router too. TanStack router and we've, we've got Solid integrations for almost all of those. So do you like React Query, you like React Table? Well guess what? You can use those in Solid and stuff like AG Grid has been doing similar stuff. I'm noticing this trend, it's an extension of headless where headless is separates the behavior from the UI. We're actually now seeing it in a way where we're catering that UI actually the specific frameworks to get the most out of them for performance reasons. Noel: Yeah, let's talk about SolidStart a little bit, that's why you're here. What is SolidStart, why do we care? Ryan: Right. SolidStart, and I mentioned it, I started a couple years ago, Solid needed a prescribed way of doing server side rendering. I'm going to start it from that perspective because server side rendering is always, well it's always been classically very hard to configure. It involves multiple builds because what we do when we do server side rendering generally is we have isomorphic JavaScript. We have JavaScript that runs both on the client and the server, which is interesting because both environments are different but you only want to write your code once. That's been where we've been for the last few years and setting that up is actually kind of complicated in terms of builds and configs. People have multiple Webpack configs and all this stuff and I wanted to make that approachable and easy. I was making these SSR demos and people are like, does Solid have SSR, and I was like yeah definitely. But no one could set it up. And this is not a new problem but it's the reason why a lot of the Meta frameworks came up. Things like Next.js, Nuxt, SvelteKit, Remix. So yeah, as I said it was about two years ago, maybe. Was it that long ago? Holy, yeah, it was a while ago. I decided I was trying to push the community to build in this direction because I like focusing on the core mechanics but I realized that this was an ask that was too big. So I started working on a meta framework essentially a Next or whatnot but for Solid and that's what SolidStart it's not only for server side rendering but it is primarily a server side rendering JavaScript framework for Solid. However, a lot of our goals there was to try and make it minimal and follow Solid's philosophy the best we could. As I mentioned before, there's a lot of agnostic solutions out there and people going, "Okay we'll just slide it into the agnostic solution." I was actually having a lot of difficulty with that. I would've done that a hundred percent if I could, but Solid has some specific design decisions that actually make it different than a lot of other libraries in the ecosystem. So my track record with agnostic solutions has been tricky at best. And generally speaking the core of a meta framework is its router and because Solid just fundamentally renders different with this render once approach from the routing level, it wasn't very easy for us to just go and go, "Okay yeah we'll use this other meta framework or whatever because they have a router." And that's where those opinions started. It's funny, I actually had a very nice long conversation with Michael Jackson from Remix for a while. We were like, "Oh can we do this?" And we worked out what we could share and what we could do, perhaps to get Solid and Remix and at the time it was kind of like, "Well yeah we can definitely do it but it's going to be some work and there's priorities to kind of fit in." And I'm like, "I needed a meta framework I like six months ago." So I just went on and initially reluctantly, but once I got into it very excitedly started working on this project. Noel: Nice. Can you get into any of those specific difficulties you were facing when trying to use the more agnostic solutions or is it going to be very hard to follow in an audio format? Ryan: Yeah, I mean it might be a little bit but it does start with the fact the way Solid does rendering. We don't re-render stuff generally we update data props and it just... Stuff like data loading, data fetchers, those mechanisms generally assume a re-render model. And what's interesting about Solid is if you want to get granular control and updates, which is something that Solid values, you actually need a tiny bit of reactivity on the clients. So it's not as simple as just get server side props. It is the easiest way that I can say where some of those problems or considerations. We could do that but it would be a de-opt and I wanted to make the thing that I thought could be most optimal, best solution for Solid. But yeah, that's the primary example of it. Noel: Yeah, I think that makes sense to me. Again, I don't want to delve too deep and make it hard to follow for listeners here. But yeah was a lot of ask for this? You talked about how it'd been on your radar for a while or on your to-do list you'd want to get this set up. What was motivating that? Ryan: Yeah, I mean there was a lot but I mean you always got to differentiate this a little bit because I knew this. I worked in startups for, oh god, almost a decade. And you come with your product and show someone and they would be like, "Oh man, this is amazing. This solves all the problems that I'm looking at." But then towards a certain point in the conversation they'll people be like, "Oh do you have this and do you have this?" And they'll get to a point where they ask you a couple things you haven't implemented yet because obviously it's new, you don't have the resources and then at the end of the conversation they'll be like, "Yeah, this looks really good. I look forward to when you have blank and then we can try it out." And it's funny because while that's promising, it's one level of promising, it's still a no, do you know what I mean? And essentially with Solid, there's a decent amount of that. Because let's face it, the ecosystem is pretty entrenched and the big players aren't going anywhere. So essentially when I was showing people Solid, I get a lot of like, "Oh Solid's really great." I mentioned before, "Oh we'll wait till 1.0 to check it out." Actually before that I was like, "Well does Solid have SSR?" And then it was 1.0 And then it was component libraries and then it was... It's this moving target because the conversation goes the same. If you're not quite at a place where for yourself you're not ready to adopt something new you, you're going to find a reasonable reason. And basically what had happened in Solid's case is the Next.js framework competitor thing had been where the dial had stopped for about almost a year. And that was almost two years ago. So it was a very long time where everyone's like, "Where's the Next.js type competitor." Or similar type of library. So yes there was a lot of ask, I don't know how much of that was real ask, but that was essentially where it's at. And I had to make a determination and honestly it had to be viable for me to do it, because this is a lot of work. And I never used these kind of libraries. I create React app and stuff, I never had any use for them. Which is hard because people are like, "Ah we need this meta framework." And personally, when I did projects for startups and stuff, I always built my own web hack config and did that. Because I found for these projects to be long lasting, I need that control over time and I didn't want... The opinionated stuff was stuff that I'd have to rip out later and if that wasn't easy, that wasn't good and essentially... So I was never the consumer of this kind of product. So being told that I needed, this was something that I had to get over. That being said, Vite actually was the game changer. I mean I'd been playing stuff with Snowpack and Webpack a little bit, but it was like I remember sitting there and going, okay, so to pull this off I need four Webpack configs, I need one for dev... Sorry I need one for client and server and for each of those I need a dev and production version of those build configs. And they're all going to be a little bit different and you can optimize for different things or different tooling. And then Vite 2 comes and they're like, yeah, yeah, one config does SSR and dev mode and everything. And at first you might be like, "Okay so this is parcel, you're just simplifying the process." But it was more than that because of the universal plugin system that Vite had built in where it's based off Rollup plugins. You could write a single plugin that addressed dev SSR client side, the whole gambit. Which meant that from a packaging and up standpoint, we're slicing things like vertically now instead of horizontally, if that makes sense. In the past you might have made, to save yourself from having tons of config. You might have made these super presets and plugins and you need special ones for each of those environments I was talking about. But suddenly now we can slice it the other way and actually make more focused plugins. And essentially that was the game changer for us working into SolidStart. Because then we could be like okay, do we care about file system routing? It started becoming about a specific concern and we could just wrap it up in a plug-in. And this was the shift I needed because I didn't want a system where I was locking people into these decisions. I find the higher up on the stack you get, you take a lot of decision power away from people, which is good, but it also means that ages worse. You carry more technical debt when the more opinionated you are. And Solid's principles have been about these primitives, building blocks. So it was very difficult for me personally to go too far that way. So I felt okay with it as long as I knew that every part of the framework in quotes was something that could be just swapped or replaced or ripped out. I wanted to create a Solid, sort of a pun, foundation for meta frameworks. Like what agnostic libraries do. But I wanted it to be optimized for what Solid could do. Noel: Gotcha, gotcha. So yeah, I think it makes a lot of sense that Vite's plugin nature fits into the mantra a little bit better of what Solid has been trying to do and I think that that makes a lot of sense to me. So now you said you would never have been a user of these pull it off the shelf, it gives you all the config, you tweak a couple things and everything just works. Because again for most production use cases you're going to need more than that and it's going to introduce this debt that you're going to have to go into and figure out later and solve and it might be a little bit less tangible initially. Do you feel that that's still the case as these tools evolved in this post roll up plug-in based meta framework world? Do you think that would still be the case for you? Or do you think that you've come around now and would pull something like this off the shelf? Were you not working on it yourself? Ryan: Yeah, I think that is actually the big change now because now that... I mean to be fair, Solid started and especially it's still in beta, we are still packaging it mostly as a single Vite plugin. But the fact that it could be multiple that you can go in and... We kept a lot of the opt-out pieces that I talked about. If you don't file system routing you just don't import the component. That sort of mentality. We added a couple features to help with SSR and stuff but it everything, because it's all plug-ins it's very easy for us to pull them out. And the biggest part, and I didn't mention this before was I also didn't want to write SolidStart router and SolidStart mydev library or whatever. You'll see a lot of frameworks when they get into that zone they start creating new libraries to support the frameworks mentality. And there's been a bit of shift recently I bring Remix up again because they built Remix and then they back port the stuff into React Router and now they're bringing React Router back into Remix. They're doing full circle on that. But SolidStart started with that. SolidStart literally uses Solid's Router and Solid's meta package. I didn't write new libraries for SolidStart. They're the same ones in the ecosystem. And together with that sort of use of the existing ecosystem and keeping it open to the existing ecosystem with the plugin system definitely changes my perspective. Because with SolidStart, you literally... If you, let's say you want to do a client side app with no SSR, there is an option you can go like, "SSR false." And then you can just go and use the router that you would've been using anyway. You can just go and use Solid the way you would if you just took one of our random Vite templates that aren't like opinionated. The opinions here are basically the router and the meta, which was the head injection library. But even those you can bypass if you really want to. So you're like, what did you build? Did you build actually nothing? It's just about getting that config right, to make sure that you can actually build towards these environments. Because we wanted a baseline for building to the future and also the support stuff. Our experimentation of different ideas which we might talk about later. So yes, I think Vite has changed my opinion on it. It's all started as a prime example of this where we've really taken that far. But I think a lot of the other frameworks are some of the agnostic solutions on Vite are all in the same path. I think literally once Vite showed this plug-in thing, the rest just fell into place. Noel: Yeah, I think that's been a common thread we've been hearing. Yeah, we have some really good episodes listeners, we have some really good episodes on Vite. We have core maintainers and stuff. If you're more curious about why this has been such a shift. So go check those out as well. Nice. You mentioned them, you've played a little... Or we've danced about around them a little bit. SSR is big, routing is big. What else is SolidStart doing that is worth consideration? Ryan: Yeah, so in terms of the feature set that we're priming for 1.0, the other big piece is around our interaction between client and server. Taking this primitive idea and this plugin idea, one of the cool things we actually did was co come up with this concept of, we're calling them server functions but they're essentially like an RPC call, Remote Procedure Call if familiar. But essentially you can basically wrap any function and then get a function back and that function you get back, if you call it on the server, it just calls it directly. But if you call that function from the client in the browser, it masks an Ajax or API call in the background. And what's really cool about this mechanism is you don't worry about paths or any of that stuff. You literally just have a function you call that you can type for example and then you get the benefits of TypeScript and then it just communicates across the client and server. You just call it anywhere and it just works. And this again it was a little bit of a compiler trick. But the reason we wanted this was because we wanted this ability that if someone was using Solid query based off TanStack query or using Turbo Query, it's another one someone came up with or whatever data fetching library that they're familiar with, they could just augment it through functional composition essentially. They could take their promise factory or the getter function and just go wrap it in server. And if you wrap it in server, well guess what? Now that function could call a database call, even though you're calling it from the client, you can literally write your backend code right into your data fetchers and that way there's like no get server side props, no loaders or whatever in that sense. You can literally just write that and that way you can actually through, as I said, functional composing, upgrade any library already in the Solid ecosystem. That's the mentality we wanted do here. Of course, we need good defaults so we actually did add a special create route data and create route action primitives. And those have automatic or not automatic... They have key data invalidation kind of similar to React query or Solid query or TanStack query. But they also do the whole similar to SvelteKit or Remix thing where your actions can also be used with forms and progressive enhancements so you can actually turn the JavaScript off or have it not working and have these forms still work from these actions. As I said, we handle a little different because it's a primitive, it's like a function so you can have as many actions as you want on a page. It's not tied to the URL but essentially you can get that same sort of no JavaScript or if the JavaScript hasn't loaded hydration, avoid progressive enhancement story using these primitives. So that was a big thing although again you don't have to use it's just a layer built on top. We have Solid's resources which are async primitive that are built into library handle Suspense and everything automatically for you. These libraries build on top of that. We have the server function, which is another primitive that lets you do data fetching on the server anywhere you put them together and now you can build a slightly more opinionated story that automates it for you. And that that's a big thing because people coming into SolidStart who don't know about all those primitives, well they can just pick up, create server data, create server action and they get a very simple data loading story that works on client and server lets them fetch their database directly. But then for those who want to use all the libraries they're familiar with, they can just continue to do that as well and have the exact same advantages. So that mentality and practice and one of the big pieces of what we have in SolidStart. Noel: Nice. So can you give me a good use case on one of these server functions? When would a server function ever be being called that would be returning different data than in that initial SSR for example? Ryan: Right, right. Yeah because okay, there's a couple example but generally speaking the main SSR experience that you have with these meta frameworks is that the initial page loads and then you navigate to the next page. And when you do that, that actually happens in the client. So you actually, with nested routing and whatnot, which Solid it has, you essentially will change certain portion of the page and at that point you need to load the code for that page and maybe any data you need to render it. So in parallel Solid will go to the server and request that data and request the JavaScript code and then as it loads in, Suspense will handle any race conditions for you, it will then render in the next page. So in a sense that data fetching on that subsequent navigation actually initiated from the client. So that's why there's this isomorphism. So if you want that data fetching that initiated from the client to directly access your database, you're going to need that code to always run on the server. If you just put the data fetching in the component on the page, it will try and run that code in the browser. So that's why it's important to make that split. So that's, that's an example where after the fact. Another one is a query parameter or something changes in the URL from where you initially loaded it, any kind of client side update that the default when you're in the client would be... And you're just using a create resource or some kind of data primitive would be just to run the code to do the data fetching, generate the promise right there. But with our server functions now we can make that promise generation happen on the server where you can access your backend directly. Does that make sense? Noel: Yeah, no totally. I think that's a great example. So the question that I was working into with that one was I feel like Solid JS's very simple approach to reactivity lends me to or leads me to this idea that it would be super cool if I could just subscribe to a specific data thing of some kind. Like it's a row in a database or some JavaScript object or something on the server and then it would just bubble down as updates occur. And I feel like that would be a... It is a pretty standard use case for these server side functions, right? It's like query some data, give me the updated one, update the component and I'm done. Did you consider at all adding in an additional built-in there to make it so I can subscribe to changes in on some watchable entity and then the front end handles some kind of web-sockety thing to watch for updates there? Ryan: Yeah, it's definitely come across and people have made library... If you've seen convex it's a library that does the database part of it and one of the creators of that actually did a Solid integration because it's one of those reactive wet dreams because of how fine grain Solid updates the DOM, we could literally start it from database change and then... So one table, one field whatever updates and then propagate it through across the wire. Have the client get that one data change and then have that one place in the UI update without rendering anything else. The challenges and we didn't talk about this much. Solid deploys, our SolidStart deploys to CloudFlare, Deno, Netlify, Vercel, work on AWS adapter right now, whom else am I forgetting? All the common targets so to speak. And they all have different capabilities there. We actually use these server functions with durable objects in a demo where we showed using web sockets on a CloudFlare worker. So we actually did use them to make a chat app and I think we have a demo of that in the SolidStart repo. So there are specific platform-based ways of doing that. There's just no general way to do it. So that was one of those things why it's not... I mean you can also use server sent events. There's a few different options there but it's one of the reasons why it's not a universal primitive but it is definitely something that could be built towards. As I said I think the agnostic platform thing is something that we have to address in the future to handle the best on each platform. But right now the adapters are one of the areas where probably are the most beta. Because we've kept them to the equivalent minimal, the lowest common denominator. But yeah, that's one of those types of considerations. But I definitely see potential in that model as well. And these primitives support it because the server functions I mentioned they're just server functions essentially. But you can take that function and go dot URL and you actually get a real API endpoint. And we do support the traditional API endpoints as well, the get, post Next.js style or SvelteKit style API endpoint. I don't talk about them as much because they're more for external APIs whereas the mechanisms we've talked about so far... If you're billing like a monolithic kind of one of these in the framework, you probably never going to reach for those because the wiring is so nice when you can just call function and it just works on both sides. Noel: Yeah or I think if you were having to do it yourself manually, if you've got the server function abstraction already, you just make that call from the server and then just pipe it back down. There's a bunch of ways that you could do it. Ryan: Yeah, it's super powerful primitive and that that's the basis on the thinking we have towards designing SolidStart. Noel: I see. I think that is an interesting topic of, you're back to the previous example of deploying in a framework agnostic manner. It does make certain primitives hard to implement because you're very close to the infrastructure layer of the stack there. It's like, I care about how this is actually running in a way that is probably tricky to encapsulate. Ryan: We have request... We use the web request and response model and fetch that kind of thing. So we have streams and I'll start off we support Solid streaming SSR and all that stuff. And that foundation's really powerful because most of the platforms support it. But as I said, specific things, we have a way of injecting that environment. We have a middleware setup where people can write more complicated handlers and stuff. If it makes sense for their platform. But yeah it's definitely... Oh we have cookies and session management as well so we have the basic primitives you need. But yeah, building outward is something that is going to need more work over time. But probably ecosystem too. Probably ecosystem too, really people building it. Noel: What's on the roadmap for the future? Ryan: So the way this is looking right now is that most of the features that you see right now, if you go into the docs, I mean other than better docs, explain the features better is actually the core of what our offering is going to look like for 1.0. We're missing a couple things around Pre-loading on hover, those kind of mechanisms. But those should be actually built into the router, not into the meta framer. So there's a few places where we can build out into our existing libraries to improve everything rather than focus on SolidStart and those places we need work and bug fixes a lot of configuration stuff between windows and stuff wrangling in the last bits of Vite. Vite is amazing but it's also going to be the that point where you realize, oh this configuration doesn't work quite the way I thought it would or whatnot. So that's where we're sitting mostly on the roadmap for 1.0. It is actually just docs and stabilization. We're actually so far pretty happy with most of the API choices and stuff. At the same time, I told you earlier that it was a platform for our own experimentation. The server functions came out of this experimentation and thought work. We've been actually doing a lot of other work in other ranges that can probably extend past the 1.0 mark. But it's really cool stuff because I think it's actually shaping the way the future of the web is going in general. If you've seen stuff like Fresh or Astro with partial hydration and Marko, sorry I can't not mention Marco here. And Qwik's another one. There's been a lot of work into reducing the JavaScript load and doing this partial hydration, but it's been mostly restricted to multi-page apps because the whole mechanism is based off knowing what's on the server versus the client and then just never shipping the stuff that's on the server. That's basically the gist, there's some more tricks that Marko and Qwik looking into reducing the execution cost of that JavaScript that does make it on that initial load. But that's the last bit of the optimization. Generally speaking, the big win is if you don't send all the JavaScript, you don't have to parse it, you don't have to execute it. And that often makes up the 70 or 80% case and actually more so you don't even have to serialize a bunch of the data and the state management. There's just so much that gets stripped down when you do that. And we saw on eBay that our pages were 60-80% smaller just by doing some kind of rough partial hydration. And we were doing experiments, we actually were like, "Okay, so let's turn off the JavaScript and add islands to SolidStart." And there's actually an experimental flag in SolidStart for that where you can go islands true and then you can go import, like a lazy import, some components and just be like, this is an island. And we did that. Yeah, I mean we didn't go all the way to the zero JavaScript thing. 5 kilobytes or 0 kilobytes was basically the same thing. It was more just kind of proving out this idea because we didn't want to stop there. And what we've managed to do recently, also in the experimental branch, we made a few demos like Hacker Newses and the movies app, the Taste movies app. And actually the SolidStart docs today are actually using this technology as well, is add client side routing back into the equation. And actually it's not just it... What I mean by that is when you're on a page and you request the next page, you don't do a full page reload but instead you have an API that returns back HTML. And what this means is that the components on the next page were actually rendered on the server. So you don't need all the JavaScript to render them in the client. So you can do partial hydration while still doing client side routing. The real trick of this though, because people have seen that before, stuff like turbo links where they do these merges and that. Is we combine this technique with nested routing, in fact SolidStart's nested routing. So when you go to that next page, it's not the full page you reload, it's actually just the part of the new portion of the page that needs to be reloaded. And adding that kind of partial hydration with this nested hybrid routing approach has been... I don't know, for me, it's been just a mind shattering experience even for myself because suddenly you're in this world where it feels like a single page app. You're navigating around, you're seeing the loading indicators, the transitions, all this kind of stuff and you're just like, "Okay, yeah, so I'm working in a single page app." But then you open the network tab and you're like, "Where's all the JavaScript?" It's shockingly so. Sometimes when Nikhil, who's been working with me a lot on SolidStart he'd come up with a new demo and be like, "Oh here's this notes demo." Or he was working on the movies demo and all this and I'd purposely not open the network tab and just play around so that I could give it an honest opinion just so that I could get that shock factor because it was such an adrenaline rush for me. I'm a bit of a performance junkie because that movies app, the Taste movies app that's been going around that the Chrome team and Addie have been pushing around and it's been built in every framework. Well with this approach for SolidStart, you wouldn't be able to tell the difference between it and the Nuxt version, which we used as the template, it feels the same. It has all the animation, the transitions feels so smooth, but it's 13 kilobytes of JavaScript, period. It doesn't matter when you rent go to the next page, you don't need the load anymore JavaScript because it's a mostly static experience. It's just linking and maybe there's a search or something, it's just this... But it's feels like that smoothness that you come to expect from single page apps. Except the JavaScript is not there. Yeah, it's wild because so much less is going on. It loads super fast. To just give you an idea comparatively the versions in Next or Nuxt or whatever are significantly larger. I'm talking over a hundred kilobytes of JavaScript. It's 10 times smaller, even SolidStart normal and SvelteKit, it's less than half the size. And it scales from that, that's just the simple example you can picture because these things never get rendered in the client. You just never need the JavaScript for it. So yeah, in a sense, if you've seen React server components, it's a very similar idea. We do a bit of a swap in, a bit of a merge diff. So basically we can retain the state of the app and the client even though we're server rendering and doing these partials. And I know there's some stuff going on with Next 13 release with the server modes demo didn't work quite right and there's some conversation. And that maybe filtered people's opinions on this, but I'm just going to tell everyone right now, this direction is legit. Having seen it now, especially in the Solid examples and which is always emphasized because Solid is so much smaller. You're just like, "Why would I do anything else?" And we're still working on this and figuring out the best authoring patterns and whatnot. We did play around with the server component APIs. I think we want to take it a different direction to make it more streamlined. Because now we're in a world where actually a lot of the code is server only. It's funny, we started in this world where it was client-only then we made it all isomorphic, right? As I talked earlier where everything runs on both sides. And then we kind of were like, "Oh no, this has to run on the server, we have to annotate it." And now we flipped it where most of the stuff is the server and we actually have to annotate what runs on the client. And I think this is a big shift in architecture, a big shift to the future. So this is one of those, as I said, it's under an experimental flag, people can go use it today, but warning it will change. But this is one of those things that's a little bit further out in terms of the stabilizing and the release cycle. But I think it's a really big game changer. And I've had a lot of fun and Nikhil's had a lot of fun developing this out and understanding the patterns here because I think I finally am starting... I see what that next step or approach generation, whatever architecture of web dev is. It's starting to happen now. I've been talking about it for two years. The pieces are finally coming together. So this is very exciting for me. That's why I wanted to talk about it for a moment because this is the bleeding of the bleeding edge. But the picture is finally coming together after the last couple years. Noel: Yeah, I mean it's bleeding, it's the bleeding of the bleeding edge, but the tech is all there. The browser can do all this already. We just need to get our tooling up to speed to make it work. And I think it'll be cool to see. Ryan: Yeah. Noel: Yeah. We have a few minutes left, is there anything else you want to touch on or plug quick? Ryan: Biggest thing for me, to plug honestly is that Discord keeps on growing people. People should definitely come and join the community, see what's going on, get involved, ask questions, just get in the conversation. I think there's a lot of really cool stuff happening and a lot of really cool conversations happening, especially for people who really want to help with us on the bleeding edge. But even one of the biggest things is our... We've really put a focus recently on documentation and building that up and I think Solid, becoming more accessible to more people is a really high priority. So if anyone's interested in that side of things and making the web more reachable by everyone, I think you definitely should come by the Discord. Because that's really where we're taking things. We've proven now the technical merit of the approaches and now it's about working with the people. So I'm very excited for that future. Noel: No, no, that's perfect. That's perfect. Yeah, we'll have links to SolidJS and SolidStart in the show notes and we'll get a link to the community discord as well, so people can hop in and get involved. Well thank you so much for coming on chat with me, Ryan, it's always a pleasure. Ryan: Jeff. Thank you. I'm always happy to talk about this stuff, share the cool stuff we've been working on and I'm so excited right now about where things heading. Noel: Awesome. Awesome. I'm glad to hear it. I'm glad to hear it. Take it easy. Ryan: Yeah, you too.