SolidStart: The Shape of Frameworks to Come

Hello, JS Nation. I hope you're all having an amazing event so far and enjoying this amazing conference. I'm here to tell you a bit about some interesting stuff that I've been working and I've been using and I hope that you find interesting as well.

Well, if we were doing this talk in person, I would ask you three questions. The first one would be, have you ever used SolidJS? The second one, actually the first one would be, have you heard about SolidJS? The second one would be, have you used SolidJS? And the third one would be, have you ever watched or read Dune? Because similarly like the main character, Poltergeist, is in the Dune universe, Solid showed everyone the path six years ago. And this was a path of reactivity, a path of fine-grain reactivity, because this is where we were six years ago when Solid came out.

Now, there's a difference between fine-grain reactivity, which is where Solid was, and coarse-grain reactivity. The difference is, when you have a coarse-grain reactive system, the framework needs to run code to basically find out where updates happen to the UI. Whilst when you have a fine-grain system, the framework doesn't need to run this code. It's powered by this primitive which is called signals, and signals tell the framework that something changed, and therefore allow the framework to be more fine-grained in a sense. So this is where we were six years ago. Now, let's fast forward in time. This is where we are. As you can see, almost everyone saw the value of fine-grain reactivity and the signals, and has pivoted to introducing some sort of level, some sort of signals in their code and in their frameworks.

Now, this was happening something new showed up a couple of three, four years ago, and people started talking about this new thing, which is not a new thing, which has been around for a while, but it hasn't been done in the JavaScript world for a while, or hasn't been actively in the JavaScript world for a while, which is server-side rendering. And everyone was thinking, okay, yeah, server-side rendering, that's pretty interesting, it saves us a bunch of time, we can pivot a bunch of stuff from the client to the servers again. We had done that in the past, how can we start doing it again? Well, personally, I didn't like to be configuring Webpack by myself. One of the easiest ways we could opt in into a different rendering mode was by using a meta framework. And every framework had their own version of a meta framework. So for those of you who are not familiar, meta framework, it's called meta framework because it's a framework built off of a framework. And well, those frameworks had their own meta frameworks, Vue had Nuxt, Angular had Analog, React has Next.js or Remix. And these meta frameworks allowed them to do this thing that we needed, which was server-side rendering, had these multiple rendering modes that you could use.

Now, while this was happening, while this discussion showed up, people started asking the question, okay, what about Solid? Where's Solid meta framework? Well, look, in 2021, Vite 2.0 came out. On that same week, Ryan Carnearo, the creator of Solid.js, started working on the new meta framework for Solid, Solid Start. And that's the title of this talk, Solid Start, the Shape of Frameworks to Come. Before I continue, let me just introduce myself real quickly. My name is Daniel Alfonso, I'm a developer advocate. I'm part of the Solid.js DX team. I'm an instructor at Agileio and you can find me pretty much on any social media, anywhere on the internet at the handle DanielJCAlfonso. Some other stuff about me, well, I released a book called State Management with React Query last year.

It has been around for a year right now, well, time goes by real quick. I released a course on AGet called An Introduction to the React Testing Library in last December. And I actually, it's not on this slide, but I actually just released a new course on Aget called Get Started with Solid Start. So after this talk, if you want to check more about Solid Start, you can scan this QR code here and you'll be able to check all these courses.

One interesting thing about this course, it's free for everyone, so if you want to check it out, please do and give me your feedback. Something else about myself, I've been releasing a newsletter about what's happening on the Solid world every month. So basically, I just compile everything that has been happening, interesting updates from the core team, interesting updates from the ecosystem, interesting stuff found online. So please check these newsletters, also on this QR code, if you want to be updated with the Solid world.

So let's go back to the discussion that we are here to listen. And the question is, why do we need a meta-framework? Why is this important? Because a meta-framework, it's not just about multiple rendering modes. It's not about improved developer experience. It's not just about proper guidelines, deployment adapters and being opinionated. At the end of the day, it's about having a faster time to production. That's why we develop. That's why we are paid to do our works. It's delivered to our users. And obviously, everyone wants it to be faster. So a meta-framework basically encompasses all these things, so at the end of the day, we can have a faster time to production, whilst having more quality in our code and a bunch of other things.

Now, there's one key word here that, well, some people in the JavaScript world can get a bit icky with, and this word is opinionated. Because what happens is when people hear the word opinionated, they start thinking, oh, if I'm opinionated, there's no freedom, because now I'm locked in. Now I cannot change something, because this meta-framework is locking me into something. Something I've learned about the JavaScript world in the past years is that we don't like opinionated. We like to be free. We like to feel like we can have the choice to bring a new library if we want to, to do something that we're struggling with. And when we're talking about a meta-framework, there are stuff that goes from most opinionated to least opinionated. So these are the four things that typically are needed for every meta-framework. We have the router, we have the framework, we have the bundler, and we have the server runtime. And as you can see, the router stands on the top of the most opinionated, because, well, the router can be seen as well as one of the hearts of your meta-framework, and it's the one where the most opinions and the most inventions start with.

Now, let's get back to the question that we started this talk with, which is, what about Solid? Hello? Hello? Hello? This May, Solid Start was released. And now we're currently on the 1.06, if I'm not wrong.

So now you might be thinking, wait, didn't you say that it started to be developed in 2021? It took three years for Solid Start to be out, because in the Solid team we wanted Solid Start to be... Hello? Hello? Hello? A shape of frameworks, look out. Hello? We wanted Solid Start to be a non-opinionated thing that can give us the best developer experience and still give the control to you, the developer. We went through two beta phases, some major API rewrites. But at the end of the day, we ended up with something that we believe can be this thing that we claim to be the shape of frameworks to come. But let's check a bit more about Solid Start. Because there's this slide here. It could be an inspirational slide from an inspirational talk. This is literally how I think about Solid Start. Because Solid Start is meant to be a non-opinionated way to start your applications, and it's meant to be that, a starter. It's meant to be opt-in on stuff. For instance, one of the really exciting things about Solid Start, you don't even need a solid router. And remember, the router is the most opinionated thing in the metaframework. I talked about that. But for Solid Start, if you don't want to use the solid router, you don't have to. You can bring your own router. You can bring time stack router, for instance, if it supports, when it supports Solid Start. So it's about shaping your path. It's about shaping to your journey. It's about not having stuff that you don't need in your applications. Because that happens most often. Solid Start is about choosing your own path.

Now, let's see a bit what is the heart and what takes Solid Start. So at the top we have Solid Router. Remember, I told you Solid Router is optional. You don't need it. You can break it apart and bring something else. Then we have Seroval, which is our amazing serializer. We had to bake it in ourselves and create a new serializer for Solid Start specifically because there's a lot of interesting stuff that Solid Start needs and Seroval is really important for that. I won't talk about this because we won't have time, but if, for instance, you have attended or have watched React Summit this year in Amsterdam, Attila Fassina, one of the Solid DX team members as well, did a very good talk about Solid Start as well, and he went a bit more deep on Seroval, so I definitely recommend you checking that talk.

Then we also have Solid. Obviously, we need the framework. So Solid is the heart of Solid Start. And then we have Vinci. So Vinci, it's a wrapper around Vite and Nitro because we needed some extra configurations and we had to create Vinci. So one of our core team members created Vinci to handle the needs of Solid Start and it's powerful enough to support Solid Start and also support things like 10Stack Start, which is coming up pretty soon. I'm really excited about that. But, like I said, it's a wrapper around Vite and Nitro, Vite being the developer environment and Nitro being our server runtime. The reason why we went with Nitro is because it's, once again, powerful to power analog and power Next. And it builds this connection between communities. I think this is one of the real cool things about having Nitro as our server runtime. Because we are helping each other grow. We are growing with each other. We're supporting each other. And when someone from analog fixes something in Nitro, it will affect Next. It will affect Solid Start. And it brings this community support that I haven't seen so far in a lot of stuff. So it's really exciting.

Now, enough talking about what makes Solid Start tick. You might be thinking, okay, what about the features? Well, there's all of these features. There's plenty of them.

There's a lot of them. I won't have time to go through all of them, but I want to show you a small demo where we'll go over them. So I have this application here, where basically you have your Pokemon list, and you can catch your Pokemon. So if I go here and I say, okay, I want to catch Charizard. And the image number is six. I control Master Ball. And now I have Charizard on that list. That's basically what this application does.

Let's check how this translates into code. So let's open Visual Studio Code here. So here we have a Solid Start demo. And it would start typically in our app config, where we have our defined config and we're telling, okay, this is not the server-side rendered application. So we have server as false. This means that we are doing a single-page application, like the traditional we have. And if we check our app.tsx, so the start point of our app, we have our router. So in this case, we're using Solid Router. Remember, you don't need Solid Router, but that's what we're using here.

We're using File Routing. So File Routing, it's very useful to help do things like automatic lazy loading for some components. So this really helps when you're doing tree shaking. It's also pretty helpful when having a large application, and you don't need to basically import all the routes here, lazy load them yourselves, add them here. This component will just go. So File Routing, File System Routing just basically tells your application, hey, instead of having me loading all the components, you're going to look into our source. You're going to look into a folder called Routes, and you're going to turn the routes there into basically routes for my application. And each route is loaded then inside of this suspense boundary that we have here. So when I go to the index route, which is basically this route that we have here, what's going to happen is that Solid Start, it's going to turn this index component itself into the index route. If I go into the Catch Pokemon route, it's going to turn into the slash Catch Pokemon route. Now, that's not what I want to show you, just showcasing a bit of some of the stuff that we have here.

Let's check what we're doing in this application. So first in our index page, we're doing something, okay, we have Pokemons and we have Create a Sink, which is one of Solid's primitives that turns a promise into a signal.

And we are basically saying, okay, I want to fetch Pokemons. And while we are fetching Pokemons, because that's what suspense is useful for, we have a fallback to show loading Pokedex. Once we have our Pokemons, we show our Pokemon list. We also have something here, which is basically, a little information for the router to know, okay, when you're going into this route, you can preload some data. And why is this useful? Well, let's imagine typically the typical process of data fetching and loading components. So our application loads and our index starts rendering. If that index has a component, that component then it's fetched and rendered, and if that component then needs some data, that data will be fetched. And as you can see, we're having a waterfall.

Now, when we have preload, we're basically telling the router, hey, this component here is going to need certain data. And what's going to happen is instead of the component going one, two, three, and then at the three part fetching the data, the router knows that, okay, if this component needs this data, let's fetch it in parallel. So instead of going one, two, three, we just go one, two. And this starts, we start having, basically getting rid of network waterfalls. And it's an optimization for fetching data. Now, what would happen traditionally here, if you didn't do anything else, is you would fetch data here, and you would fetch it here. And now you're thinking, okay, but now we have two requests. Well, that's why we introduced this new thing we have inside of this getPokemons function, which is called a cache. So this is a cache, but you could think about this as a resource deduplication mechanism.

So avoiding the duplication resource mechanism, what's happening here is every time this getPokemons function is called, we're going to fetch the data and then cache it underneath this cache key called Pokemons. This means that if in that round trip that it's happening on the browser, if this data is fetched, once it's going to be cached during that round trip. And the next time that request happens, we just serve it, that these data, instead of refetching it. There's also something really interesting that we have here. So we have this directive called useServer, which is something to let the bundler know that we want to run this function on the server instead of running on the client. So it means that every time this getPokemons function is called, this block of code here is going to be executed. It's going to happen an RPC call from the client to the server. The server fetches the data, returns it to the client and then the client has access to it and caches it. That's basically what's happening here on this part. And as you can see right now, we've just seen some pretty cool thing in just two minutes. We've seen data preloading, we've seen file system routing, we've seen caching, we've seen server functions. Let's check the catchPokemon part. So the catchPokemon component is basically just a form.

And it's a form that has a form action. Remember, forms have been the staples of mutations on the web ever since ever. And an action is basically just something that the form will call whenever it's submitted.

Let's check this action. So we know first of all this is an action because we're tagging it with an action. And what we're doing here is once again calling useServer. So now we have a server action. And we're basically getting the form data from the form to catch a Pokemon, which means adding that data to our database. And then we're telling the browser, OK, once you've added this data, go back to the previous route.

So we don't want to stay on the form. And this is gonna lead to a very interesting feature. Because now I want you to focus on before we take again. What would happen traditionally? So we have our form. So when we submit the form, we typically do our POST request, right? So we do the POST request. And then we would have to navigate to our route to go back. So now we would have to navigate. So we would go to the index. Once we are in the index, now we would need our data. So we would have to refetch the data. That's typically the process. So POST, navigation, and fetching data. So three requests.

So I want you to go to check the application with me. Because now I'm gonna open the Network tab for a bit. And I want you to show you something interesting. Let me just check if the application is still running. Okay. It should still be running. It is. Hello.

I had to kill the application and start it again. But let's check it. So let's catch a Pokemon, shall we? Let's clean everything. Let's catch a Pokemon. Let's try Wukario. So Wukario. And I think the image number should be 448. I hope I'm not wrong, but it doesn't matter. 448. We throw it. And we caught Wukario.

Now there's something interesting happening here. Because there is only one request. Why? Shouldn't there be three? Well, this is what we call single-flight mutations. And it's one of the features that, so far, I've only saw it start to. What's happening here is, when you have an application that knows your router dependencies and knows what needs to happen, what happens is, when we do that POST request, because the router knows where it is, where it needs to go and where it happens, whilst the POST request happens, we return the next page already, and we start fetching the data in parallel and stream it back in. All in a single flight. And this avoids having the three requests we would traditionally have. And it's really, really exciting.

Unfortunately, I don't have more time to show you more stuff. But this is hopefully just something to give you a quick taste on how SOLIDSTART works. So let me just finish my presentation. As you can see, SOLIDSTART, it's not a framework, definitely, but it gives you freedom. It's not automated. It gives you this liberty of doing the stuff that you want with what you want. And like I said, it's meant to be a starter, meant to be a way for you to start your journey and do your stuff the way you need it, how you need it. So that's why we say SOLIDSTART is the shape of frameworks to come. It's having something that is non-opinionated. It gives you the freedom to choose your path. And we are really excited to see how this is going to affect other stuff. We are already seeing other meta-frameworks being built on top of SOLIDSTART in the SOLID ecosystem, which is really, really exciting. So with that said, I'm Daniela Fons. Thank you so much for watching my talk. And if you want to check, connect with me online, Daniela J. Ciafonso everywhere. I'll see you around. Have a good event. Bye!