Atila Fassina
===

[00:00:00] Hi, and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics. Try it free at logrocket. com. I'm Tejas Kumar. And today we have Attila Fasina, GDE for web technologies, SolidJS developer experience team member, and a developer advocate for Tauri and Crab Nebula.

Today, he's here to talk to us about SolidStart v1. 0. Welcome to the show, Attila.

Yeah, hi Tejas, it's awesome to be back here. How's it going? Good. Thank you. ~Okay.~

Good, good. I agree. It is awesome to be back here. I haven't hosted PodRocket since I started my own podcast. This is the first time, actually. And it's so cool to be doing both. And at some point, we should maybe partner. But in any case, we're here to talk about you and not podcasts. Specifically, we're here to talk about Solid Start and your involvement in that project.

Can you maybe just to begin, The discussion provided a brief overview of solid start 1. 0. And why it's significant for the solid JS ecosystem.

Solid has been around for ~around ~about [00:01:00] six years now, maybe a little more than that. And ~it's been ~my take might be biased, but I think nobody can argue that solid has influenced the JavaScript ecosystem in a big part. Ryan's been one of the biggest proponents of signals. Solid is built around signals.

A lot of frameworks are doing that, but Solid was probably the last one of the largest frameworks to actually get to the full stack story. So let's start has been through like three years of development towards 1. 0. It involved like two RCs~ and~ So it was a long time coming and it all went through ~like ~this whole idea of finding an API that was a set of APIs.

That was aligned to the directives of the solid project. It is a big thing because it finally puts solid in the discussion of, okay, we now have ~a full stack ~a full stack solution for our [00:02:00] ecosystem. And that just empowers it a whole lot more in terms of allowing apps to scale, ~allowing, ~giving users or developers in this case more alternatives to decide how their apps should be, okay.

Yeah. So what I'm hearing is solid start 1. 0 is this full stack framework for solid JS being the client side. UI library that uses signals, right? And Solid is famous for its API looking almost exactly the same as React, except it uses and champions fine grained Reactivity. And so Solid Start is the full stack framework around this client side library.

Would it be fair to say that Solid Start is to SolidJS as NextJS is to React? And then if yes, like, how close to NextJS or some similar framework would Solid Start be?

I think it is probably the closest analogy for somebody that's coming ~from ~from React, from a React background. Like if you're in Vue, it would be Nuxt. ~If it were, ~if you were in [00:03:00] Angular, it would be Analog and this kind of stuff. But Solid Text own way of solving things in terms of one thing that the solid community is, and that's why it took so long to get to the API.

And this was one thing that I decided to say ~like ~right up front is that there were a lot of ways of building frameworks and Usually as you start building your framework, ~you need to go like from, ~you need to define a lot of opinions first. Creating a router is something that's very opinionated.

Defining sometimes some set of conventions and as you go more granular and you try to start defining how your developer experience is, you start getting more and more opinionated. So you have frameworks like. Astro, Next. js itself they have ~like ~their image components. For example, ~they have their own ~they're using their own tooling inside to define how to optimize that, for example, or they have their own routing conventions and things like that.

And there is a right way of doing things. And solid decided [00:04:00] very early that no solid starts going to have no opinions. So it is in the very definition of the term, like a meta framework in terms of. It brings a bunch of tools together and it allows developers to basically mix and match them in the way that they feel comfortable.

So if by any reason the router is bringing an opinion you're not comfortable with, you're free to switch them. And they're not even there from the get go. ~So you can ~The idea of solid start is to not give you like the whole kitchen sink, but to give you the building blocks to assemble your own kitchen sink.

And in this case it gives you a lot more flexibility and all these opinions, but then you need to build it yourself in this way. You need to assemble and define how you want it to have.

What does that mean practically? For example, Next. js has the app directory or the pages directory, and in them you have a bunch of TSX files that become pages, right? Or in the app directory you have a bunch of [00:05:00] TSX files called page. tsx and those become pages. If you have to mix and match and compose these yourself with Solid Start, what does that mean?

Does it not have opinions about file system based routing by default and you have to configure that and set that up yourself?

Yeah, solid start itself doesn't. The core is very small. What we have, though, is the solid router, which has all the bindings necessary. So in this case. If you decide, yeah, I want file routes, we do have in Solid Router, an export that's gonna define that in the conventions the conventions for the file system routing are very similar to Nuxt, they're very similar to Remix as well.

So you get pretty much the same developer experience. The only difference in this case is that. They are coming from different packages. So the solution that solid start offers is that you have that CLI where you can define through the CLI. So if you go like PNPM create solid, you have, you go [00:06:00] through the CLI, you say what you want, and then it can bring you like the solid router.

It can bring you like A boilerplate template for you to get started. It brings you solid meta, which is the other package for metadata. And you can build on top of that, but if you don't want to, you can just do like the bare bones one, which comes with just the server runtime and the bundler, and then you can build whatever you want out of it.

So if you want to create your own router, go for it. If you want to bring another router from another framework and then you Build the right bindings that you might need. You can go for it

As many people would maybe not know from the typical full stack frameworks. What inspired the philosophy behind designing it this way compared to the sort of status quo that we see with Nuxt and SvelteKit and Next.

js 

~think what comes like it's a very similar approach to ~think a framework creator has a very similar approach to what A movie director would go [00:07:00] you have to have that each, you need to scratch yourself. And then from that, you can start creating an experience. And then as you mature that idea, as you is prepared to scale that idea and make it available to others, you start learning and putting up other opinions.

In Solid Start case Carniato, the creator of Solid, has been on record saying that he doesn't like metaframe. He doesn't like things that come baked in and bring opinions into his stack. He likes being able to write their own config files and create their own bundlers and so on. So ~when he decided, ~when there was the need for solid start, he said, okay, I can do this, but then I need to do it in a way that I'm not going to step on any other stores.

I'm not going to step on another Ryan stores if they decide to use that. He was very clear about this. And. A lot of the efforts, like I'm in the DX team. So every now and then we come to him and say, look, how about we do this other API that then it's easier to teach [00:08:00] and it's easier for people to do more use like this or that.

Ryan goes no, that brings opinions. That doesn't land in the core. We can do it like this. We can do it like that. Or go on and create your own template and then you can teach it from there. And people can use it. He actually doesn't envision that Solid Start would be something that the end user would take it and run with it.

It was more like Solid Start is something that another developer would create their own like stack or their own opinionated set of templates. And then others could then go and mass adopt that,

Interesting. And you, so what does the onboarding experience look like then with Solid Dark? Because you've seen me bootstrap next JS projects, right? So INPM, and I don't use the NPM create as I just create a package at json NPM, install, react, react do next create a new directory called pages create index, TSX default export.

And then I have a page. And that's because Next JS is so heavily, opinionated. Since Solid Start [00:09:00] is not so opinionated, what does the onboarding look like? Meaning, if I wanted to create a Solid Start project what steps would I go through? I assume there would be some type of configure the router, and then configure the data fetching or server rendering primitives, etc.

The way you would go in this case if you don't want to use the starter, you would have from the get go install I think two. dependencies, which would be solid start itself and another dependency called Vinci. So Vinci is a second project that was created from another one of our core members Nikhil and Vinci is essentially a thin wrapper around Nitro, which is a server runtime by the NJS folks happens to be the same server runtime that you have on Nuxt.

And on analog, for example. And Vite. And Vite is the one that most people are familiar with. It's a bundler. It has a very declarative API. And [00:10:00] it's a bundler which has the config that people don't usually hate. People usually like a lot setting up their own. configs and stuff like that. So Vinci is built on top of that, which means it can bring you a very declarative API in, in this kind of stuff.

So Vinci by itself can be used to create other frameworks. Like you can even use Vinci with React. You can use Vinci with other frameworks. There's another member of our DX team, Brenly has even created React meta framework with Vinci already. So it is possible, but solid start also exposes a wrapper, a configuration wrapper for Vinci where you can define your app.

And that kind of brings in the basic solid starts defaults. So with that, you can actually create an app config with no like customization at all, and it can just work. Then with that, you can set up like the basic~ the basic, like ~source directories and so on. And with that, you can actually get already something [00:11:00] to the screen going forward.

You would then want, if you most likely, most people do want like some file system routes. ~So you would install~ you would NPM install solid router, which would expose a file routes. And then you can define which directory they're going to look for the file systems. You would define which extension in this case or you just take the default and that's it.

You create a component structure in a syntax, as you mentioned, it's pretty similar to react and that would already work with that. You would already have data loading. You would have bundle splitting. You would already have a server runtime, serialization, all that. To somebody that creates like Next, Remix, Nuxt apps without the CLI I would say that the main difference would be that you do NPM install a few more times So what happens is if you like NPM install Next, the core is gonna come with the compiler.

[00:12:00] It's gonna come With the router, it's gonna come with all the conventions and so on So it's, I dare say, it's more like a monolithic framework, meta framework in a sense, because you cannot easily split them apart. With Solid Start, they come unassembled, but once you have them in node modules, you can just go using them.

And they give you like very sensible defaults to get you a good DX.

I must say this is so interesting because it's solid, it's Ryan Carniato, like flipping the script again as solid did that right with the reactivity primitives going look, everyone does it this way. No, we're going to do something different. That's going to be better. And I think this is the same thing with frameworks is everything's more or less monolithic.

We're going to do it. In a different way and I bet Ryan bets that it's better. And I haven't used it yet. I'm excited to try, but I feel like it is better for the reason being you can compose different things together, and this also maybe makes the self hosting [00:13:00] story somewhat easier depending on how you choose ~to do it.~

to do your routing and server rendering and other things. This seems like a pretty substantial effort, right? It took what, it took three years for it to go from like idea to shipping this. What were some challenges and milestones in those three years?

So the three years I would say if I need to give you like a TLDR of what the three years were, was first, I would say like the first weeks or so months, maybe it was Ryan reluctantly accepting the fact that he was going to build a meta framework. Because he was like okay, we need to do that for the ecosystem.

I'll have to do that. And I want to do it right. So there were a few ~like ~iterations on it on essentially him and the core team and a lot of contributors But Ryan was on the quest for finding the API that would be versatile but strong in the same way. ~So you need, he, we were, ~he was decided in [00:14:00] giving a great DX with a great UX, but remain flexible.

So ~there was a lot, ~there were a lot of iterations. There were a lot of different APIs defining what server actions would be like, or server functions as well. Defining the API routes ~and~ and all this, like what would go inside. the core of Solid Start and what could he take out of the core of Solid Start, changes to the Solid Router in terms of creating the perfect story for the data loading and all this.

So there were a lot of back and forth on this. ~There was also a way~ it was a big effort on minimizing the maintenance effort. Solid is not backed by any ~like ~big corporation in terms of Anything

Doesn't, but doesn't

Ryan is employed by Netlify and Netlify is extremely generous in allowing Ryan to dedicate basically a big portion of his time or all his time.

I'm not really sure towards the development of [00:15:00] Solid, but ~it's, ~it doesn't have any other funding besides that and Open Collective. And so we, or the core team needed to be very smart in terms of, reducing the maintenance part of it, because ~as ~creating like a server runtime and deploying to a bunch of different platforms is a huge effort.

~And ~Nikhil was pretty smart in the sense of, okay, so ~everybody's doing that. Why ~everybody's doing that again and again, all the time. So let's create something on top of the fundamentals. And then the NGIS folks already had created. First H3, which is a minimal server for Node. js.

And then on top of that, they created Nitro, which brings a lot of great DX on top of H3 and offers this server runtime that's already used by a bunch of frameworks. So they decided, okay, let's create something on top of that. And then we can piggyback on it. So right now, as ~the, like ~the first time solid start [00:16:00] ever was.

compiling and building, it could already be deployed to like over 20 presets, thanks to Nitro being already possible. So you could deploy ~to ~to Cloudflare, you could deploy to Netlify, Vercel, AWS, all ~the, all like ~the big players ~and ~in different settings. Like even for example, Nuxt Hub, ~like we~ there was, ~there's ~nothing between us deploying ~like ~solid start to something like Nuxt Hub because the server run time is the same.

So they only defer once they reach the browser, speak. The whole idea was doing that. So in the first, I don't know, two years, one year and a half. ~We were actually ~Ryan was actually investigating where he would base that on there was some talks about using the Astro ecosystem for it, but then there was some different necessities regarding the server runtime.

So then it went to Nitro. Then there was a few other changes in terms of API and making the core leaner. So there was a lot of work throughout these three years, a lot of learning to the point that before reaching stable, before reaching RC, there [00:17:00] was a, some significant breaking changes in the definition of those APIs, both for the router and for the solid core itself.

~So~

and the big 1. 0 general availability push? ~It was~

we launched RC, and I remember it was like 21, March during

during React Paris. That's right. Yeah.

Yeah. We were already very confident that it was ready for the big leagues. There was not going to be like any big API changes and Ryan was like, okay, we need to ship this. It's done. It's been time already.

Let's do this. And the idea was to have DRC to be like short lived, it ended up going for I think a full month. But because in the end, we ended up being a little bit more conservative on defining like ~the nice, ~the nicer docs experience and adding proper onboarding for this and making sure like everything was in the right place for us to help people adopting it.

But I'd say since [00:18:00] DRC there were not like significant breaking changes. I would say that the last big change that we had was December 2023 when there was a big change in the Solid Router. Since then it was like defining what would be the imports looking and finding of course, a few quirks and little bugs.

But that was the biggest change was the breaking change in Solid Router, which was sometime around Christmas. Okay.

functions, you think, use server functions that execute on the server Like ~in, ~in Next.

js 13 onwards but this is not the same, right? This is something that ~Solid J, ~Solid Start, ~excuse me, ~has invented. Can we talk a little bit about server functions in ~Solid JS and the benefits they, or ~Solid Start, and the benefits they bring to and applications both server and client [00:19:00] side?

Yeah. So the server functions is like roughly speaking is a way to define like how the RPC ~is ~is going to work within the framework. So with that, you can actually start defining a server code. And at the point, the time you're writing, it doesn't make much difference if you're writing client side JavaScript or server side JavaScript, and your bundler is actually able to split them.

So if you're coming from a React background you're familiar with the directives, like use server, for example. So solid define that as well. ~And ~With this, you can instruct Vite or Bundler to split this bundle. And then this code is only going to happen in the server side, which essentially creates a little Lambda or a server endpoint, if you want to.

And with that Solid is then able to not only co locate the code, but also be a little bit smarter. in terms of defining your types and defining ~how the function is going to ~how the data is going to look like. And then the [00:20:00] JSX is able to know that. If you put that the next level of that would be the actions, which is like server actions, which is a way to define a server function or an RRPC call that's connected to a form, which allows you to send mutations ~from~ from a JSX.

Not that, not different than what like Remix use for example, and also Next. js ended up adopting it later. So what you can do with that, and this is the one thing that Solid does different as far as I know from the other frameworks is that because of this very strong parallelized way of handling the data, Solid is able to do something we call single flight mutations.

which means that ~whenever you submit a form that goes through an action function a server action, ~whenever you submit a form that goes through a server action, this thing is going to go to the server and it's going to run the logic in the server. Maybe it's going to fire redirect, maybe not, but if it does fire [00:21:00] redirect, or if it does fire a new data request, your response from that server action is going to bring the data directly.

So that means at least one round trip less to the client to the server and a much snappier API a much snappier experience and saving a bunch of bandwidth essentially, which. Capitalizes on the fact that solid router, which was that big reroute that I mentioned from December and the whole pragmat, the whole idea of solid start is to parallelize all this data, which is how solid is walking towards is to have data running parallel is to be able to do a lot of concurrent work and handle that in the future.

Fantastic. If somebody wanted to get started with Solid JS or join the community or just start a project with it or even adopt it internally at their company what would you say to them? What's [00:22:00] the best way to go about that?

So I'll say that first thing you can come to this court and you can talk to us and we're always happy to help people testing the waters and seeing if solid is what they need and. help them doing this kind of stuff. I went through this process at Crab Nebula. We use Solid a lot. As Tejas and when I joined we were working together and when Tejas and I joined it wasn't that we were using other kinds of stuff and we had a big conversation about it.

~We have~ we had a lot of technical discussions on it and we decided to go with it. And I would say we are pretty happy about it. We have at this point, two apps with solid in production already. And ~they do ~they take ~a lot, ~very little maintenance. And so we do spend more of the time building features and creating value to our users. I would say it is pretty decent. I would say if you want to test it [00:23:00] out. And if you want to talk to your team about it, you probably My take is usually going from a place of mutual, like common ground. If I would talk to somebody, ~if I would talk to~ about solid, somebody that works with React, for example as you mentioned before, I would talk about the syntax first, because that's something that looks familiar.

And then ~if you'd go~ if you would talk to somebody from Svelte, for example, at this point. self developers know about signals through the name of runes. So you can start with that. Vue developers know it by the name of shallow refs and refs. You can also talk about that as well. Especially with Vue Vapor coming out, it's going to be ~even ~an even easier mental model for them to talk about.

Angular also does that. Quake also has signals. So If any other framework than React, you could start with the fine grained reactivity part. With React, I would usually start ~with the part, ~with the syntax and with how suspense works [00:24:00] and so on. Because the logic we do with suspense, the whole syntax and how you use it and not, it's more or less, it's similar.

We do have a few extra helper components We don't particularly use ternaries, for example, we don't do early returns because our components don't re render, but once you understand those syntax, it becomes a little bit easier. I would say it's a double edged knife. If you're coming from a React background, the syntax being familiar is very nice, is soothing, but then you starting printing your muscle memory there, and sometimes it can catch you off guard when you destructure a prop and stuff like that.

Join the discord. We're going to talk about it a little bit. And yeah, I think past like the little learning curve, you can go and you can adopt. And in my opinion, and I know I'm biased, it is a mental model. That's very easy to understand once you like, see it for how it is. Like once you actually, ~take the, ~take a little [00:25:00] time to learn and to test it and see how it goes.

It becomes a little bit more intuitive. That's how it was for me at least.

Fantastic. With that, I'm happy to leave it here. Listen, Attila, it's so good of you to come on the podcast and talk a little bit about these things. I think people must be inspired and motivated to give it a try. As you heard, the SolidJS Discord welcomes people. It's Solid Start 1. 0. You can find it on GitHub and Google, and we have links in the show notes as well.

With that, thank you so much for coming on PodRocket and talking about these things today.

That was awesome. That was awesome.