A Solid option for building UIs

Oh, hi! Hello there, friends. It is Jerod here, your internet friend, and I have a great show for you prepared today. I am joined by a few of our regular co-hosts. Amelia is here. What is up, Amelia?

Hey-hey! Not much.

Not too much. Nick Nisi also in the house… What’s up, Nick?

Ahoy-hoy.

Hoy-hoy to you. And special guest, from the SolidJS project, Ryan Carniato. Thanks for joining us, Ryan.

Hi. I’m glad to be here, thank you.

We’re glad to have you, we’re happy to hop into all the details of this very cool UI library, that - I wanna call it new, but it’s not all that new; it just feels new, because it’s kind of bubbling up into the zeitgeist. But first, we’re gonna start with a brand new mini-segment called Holla. [Can I holla? Can I holla at you?! Can I just holla – holla-holla-holla-holla…?!] Holla is a new segment where we holla at some upcoming meetups, events, conferences, things going on around the JavaScript, CSS, web dev community. So I put out a tweet requesting hollas, and we got a quick response from JSConfMX in Mexico, and I believe it’s one of their organizers - they said “We at JSConfMX could use a holla. We are posting last year’s talks in the JSConf YouTube channel in Spanish and in English”, so that’s very cool. That was Rodrigo who says that. So holla at JSConfMX. We will link up their website in the show notes and take a look at their talks, which are uploading to YouTube.

If you’d like us to holla at your meetup, conference or event on an upcoming episode, tweet us the info @jspartyfm. [In a matter of seconds we’ll beam your information to one of our skilled field technicians.] [Hey-hey-hey! Can I holla? Can I holla at you?! Can I just holla – holla-holla-holla-holla…?!]

[04:15] Alright, let’s dive right in, Ryan. So as I said before, SolidJS - it feels new. It’s getting, I think, increased eyes and interest… It is very much a frontend library for UIs. Is it a framework? I don’t know. It is a library? Maybe part of the conversation… But it’s not all that new, 2018. So you’ve been working at it for a while. Tell us the origin story, how SolidJS came to be, and what you’re trying to do in this space.

Yeah, definitely. And even the 2018 is kind of a little bit misleading, because I wasn’t very into open source that much; I wasn’t very social. I was just a developer, working on a team, working on a startup, a small company out of Vancouver, Canada. We were a company who had built our stack on Knockout.js and CoffeeScript. This was like 2010-2012 period; I joined the company in 2012, and I was just working there as a developer, and I joined a team that was actually trying to build libraries. If you remember, JavaScript at that time period didn’t have that many – there was less stuff out there, and I happened to chance myself by complete randomness to the creator of a library called Knockback, which was like a Backbone.js Knockout kind of framework… And I just started working there; we built our own ORM, because we wanted to do GraphQL type stuff before GraphQL was all about like linking models and requesting from the server. A whole bunch of kind of interesting projects like that in a startup which was under-funded. So I don’t know if that was the best move, but I kind of got into that zone, and then what happened was my mentor/leadership - he left, he kind of burnt out on the whole startup thing and doing it all himself… And I was kind of left being in charge of all the technical stuff. Our stack was aging, and I wanted to maybe move off to something else, but React wasn’t what we liked. We’d become accustomed to different patterns; we accustomed to using reactivity and these composable primitives, and really Knockout.js had this pattern for years… So I actually started on Solid in about 2015. My first commit in a private repo was in 2016, but I was just building it for myself, maybe my company. I didn’t really think anyone else would use it. Everyone seemed to like React. They liked lifecycles, and classes, and all that.

For me personally - I’ll go back a little further, but… It reminded me of .NET, and - I mean, that’s kind of weird, but when I’d found Knockout, when I’d found these composable primitives, I never wanted to go back to classes and lifecycles and all that kind of stuff again… And the reactive stuff - I could tell was updated performantly, and all this… And this whole idea of the VDOM top-down rendering - it just never jived with me. So I just kept on trying to work on it. Eventually, Knockout kind of fell out of favor, people didn’t care about it, and I just kind of did my thing.

I built some benchmarks, and I worked through that, and that’s what got me to open source the library, because I was like “Oh, I wanna participate in some benchmarks, and I think I’ve found a way to make this approach performant.” What ended up happening was – again, I was just still kind of fine doing my own thing, and then React released React Hooks, and I was like “W-wait…” It looked identical to Solid, and I was like, “Okay, this changes everything. People might actually be interested in this.” And that’s when I started writing articles and started kind of putting it out there… But this was always, at the beginning, for years, just me kind of tinkering on my own personal project, trying to see if I could take my favorite paradigm and show that it was performant, and then maybe my company would use it.

Ironically, when the decision did come - which was also around 2018, and I was kind of (as I said) in charge of those decisions, I steered everyone to React. But – I mean…

Huh!

[08:02] We’d spent years maintaining our own stack and dealing with that, and that was the wrong move, I think, for a startup that needed to deliver a product. But that experience for me was amazing, because it’s a different space, where its origin came from. You can see the reflection on the design and all the decisions… You guys had Rich on recently, and he was talking about almost like the agency mentality in media, this constant in and out, doing these small projects and then moving on to the next one, on-board people quickly… That’s the mentality. I wanted to create something that would last years, that you wouldn’t hate your codebase after 2-3 years; that was made specifically to be modular, and made for change. And that’s a different thing. In a world where React has permeated everywhere and it’s really hard to get an edge, or get a footing, most frameworks have focused on lowering the floor; letting people in easier. That wasn’t my priority; I wasn’t changing the product. I just wanted to allow people to have the most control and to, as I said, not hate their codebase after 2-3 years.

That’s kind of where Solid came from… It was me taking arguably old patterns, things that people had done before, and then just kind of modernizing it. And it’s kind of fundamental to my belief and how I look at this ecosystem. When you look at the way frontend’s progressing, when you look at the way JavaScript technologies progress, and the newest/latest thing comes out and there’s all this fear of missing out, and the whole – how should I put it? …JavaScript fatigue. I’ve never felt it myself so much, but it’s mostly from this kind of understanding that almost everything new you see, the things you can’t miss out on - they were already there; if you looked hard enough, they were already there five years ago, they were there ten years ago… And it’s just a matter of when it becomes popular that it comes into light. Like you just said - Solid has been around for a while. Right now people are seeing it. And people look at the benchmarks and then look at that. But truth of the matter is - there has been a lot of advances in different ways, and a lot of frameworks have gotten more performant, and improved DX over timed. But for Solid, the performance that you see in those benchmarks - we had that performance in 2016. I haven’t touched that in like five years. Sometimes the solution is already there; sometimes it just takes a while to come back again.

That’s such a good story… And I feel like I look at Solid and if I were to imagine being like “Okay, tomorrow I’m gonna start building a framework”, it would be totally overwhelming and I wouldn’t know where to start. And I’m super-curious - has Solid changed over the years as you’ve been working on it, like the codebase or the concepts that are involved?

Yeah, I mean, it has changed somewhat. The codebase, definitely. Solid was written in CoffeeScript; like, just off that. And then I converted it to JavaScript, and then I converted it to TypeScript. I’m trailing on the TypeScript side. TypeScript was the hardest adjustment for me.

And when are you gonna convert it back to JavaScript? [laughter]

Never…

I mean, that’s the next trend, right?

[laughs] That’s the next move, yup. It’s happening.

It’s been tempting at times. Sometimes the typing is challenging, and I thank the community for that, because that is not my forte. As a guy who came up in CoffeeScript, when I went back to web dev after my .NET dark ages, essentially, that was all about prototyping. You don’t even declare variables in CoffeeScript. You literally just kind of like have an idea, spit it out on the page… I’ve never felt more productive, whether that productivity caused someone to come by later and have to fix it. You have to remember, I was the lead dev at a startup, and there were some other developers… I probably left a huge wake in my trail. I’d be like, “Okay, yeah, we should just rewrite this whole thing. So I’ll go do that tonight, and when you come back tomorrow morning, I will have refactored the whole thing.” 10x developer here, right? And then the next ten days, when everyone else is fixing bugs… I’m sure I did that. But yeah, it’s a different mentality.

[12:02] But in terms of the actual mechanics - that hasn’t changed very much, and I think there’s been evolutions in reactivity to make the execution more predictable. There’s been advanced in tooling. JSX actually became a very important part of our puzzle, even though I didn’t realize it at first. I did start with template DSL type things like Svelte or Vue, but it was still pretty early on. I made the switch to JSX in 2017. The core paradigm and composability were just so strong and so powerful, and it’s hard to explain sometimes; it’s easier to show, generally speaking… But with Solid, the mentality is very much one where – I know this is a weird one, but people who come in and get hooked on Solid, the thing that they tend to walk away with is they’re like, “Oh, I could have written this framework.” It’s very, very different.

I’ve realized over time – it’s funny, because Solid and Svelte look like siblings sometimes. People are like “Oh yeah, compilers, smart stuff”, and all that… Someone the other day said Solid and Svelte are like the Angular and React of the next-generation frameworks, and I started realizing we’re actually very different… Because on the Svelte side, it’s more like - we keep the syntax, we keep everything very simple. You don’t have to know how this works underneath, we’ve abstracted it to you; it’s just a language, just something you can pick up and use… But I know - maybe not everyone cares about it, but I know exactly what’s going on behind it… But it’s much more complicated than what you see. And it’s a different kind of gap. It’s like “Okay, just write simple JS and it just updates” versus like “Here is a framework that wears itself on its sleeve”, so to speak. When I introduce people to Solid now, I’ve taken a different tact. I’m not saying like “Here, compared to React”, because that’s everyone’s first view of it. It starts from a place of actually like a state library. I just go “Here, write some console logs to the console. Here’s a reactive variable”, and it’ll write to the console. And then the next thing I do would be like “Okay, replace that console log with updating a DOM element that you created. And then replace that DOM element with a JSX element.”

Solid doesn’t really have components. It’s not the top-down renderer that you see, and that makes it very different, in a sense… Because in a lot of ways, even Svelte is more similar to React than it is to Solid in the mechanical side. Not on the philosophy side. The philosophy side – this is actually pretty complicated stuff, I guess, but on the philosophy side, Solid is very much on the React side, where we like things to be explicit, and we like things to be these base primitives. We don’t hide stuff, so it’s kind of like, you learn these hooks, apply them how you like, but that’s essentially all you’ll ever need. It’s not a progressive framework. That’s the Vue marketing sell, where it’s like, you learn the one way, and then you build upon it, and learn more, and then you learn more… Solid is like “This is all we’ve got. This is the whole thing. Maybe you could built it yourself.” That’s the angle. Maybe not the most beginner-friendly angle, but it’s like once you get over that ledge, you’re suddenly like “Oh. I could do anything with this.”

So it’s been PaaS since 2016, it’s been open since 2018. When was it that you advised your company to pick React? Was that 2018, was that in that timeframe?

Yeah, exactly. We were preparing for a rewrite for 2019, that we were gonna start the following year, and it was a difficult choice. I actually recommended Preact, because we were starting to see work towards Preact 10, and I’m like “Oh, by the time, it’ll be in the right place.” And we did start in Preact. It was just a little bit too early days. Some stuff like Suspense and Hooks weren’t right. And the biggest reason we made the move to React from Preact was we were finally like “Okay, there’s Hooks now in React. Maybe this will fit our pattern.” We like those composition patterns. It’s really important to us that you could make your own custom hooks and breakup logic that way. We’ve been using those patterns for most of a decade. And essentially, that was the differentiator.

[16:01] We had experience, we had React Native for our mobile app, so we knew how to do React, but it wasn’t as compelling until Hooks came out. The interesting thing of course is Hooks have hook rules, and stuff, and that’s something that took a little bit longer to appreciate… And it’s actually one of the more standout things with Solid, in that it looks kind of like React Hooks, but it doesn’t have the hook rules and the execution model is very different.

So put yourself back in those meetings, only it’s 2022. Does your advice change now? Or would you still say the same thing?

Here’s the thing… When you have a company, like a startup or whatever, you have to make a decision. I think you get a certain number of innovation credits, so to speak… Like, how many things where you can bet on a technology or not. I feel like in 2022 right now Solid would be an okay bet for a startup; they’re like “Okay, we decided that this element of it is important to us.” We had to make a decision if we were gonna build our own design system or use something like Material UI, or something. That would be part of that decision process. At my startup, we built our own design system. Own component-wise, everything. We’d have to rebuild everything anyways, so it wasn’t really – the ecosystem wouldn’t have been as big of a factor, and I think today… You know, especially if I was working there, too; that definitely would have gone the way of Solid. It was just at the time I didn’t feel comfortable enough recommending it, simply because we’d kind of gone through that… And we got out through to the other side, right? We built a bit in Preact, then we switched to React, and they finished the app in React, and they were like – it wasn’t like a clear win over what we were doing previously. They were like “A lot of stuff doesn’t work as well as it used to do, like in a different sense. And there’s new things we have to be aware of.”

It wasn’t all sunshine, so to speak. I mean, there was some good benefits for the startup; hiring new people on was easier, because we’d be like “Oh, we’re just a React shop”, and they’d be like “Okay.” So we could get junior developers easier, and stuff. I don’t think that’s actually – if you’re gonna teach people stuff anyways, I don’t think it’s that big of a boundary using something like Solid, because there’s a lot of similarities on the superficial/surface level, that make it work fine… And I also – I can’t spend most of a decade teaching people Knockout, like how reactivity works… I’d feel more comfortable about it now, but yeah… It took a long time for us to get to 1.0, even though the client-side stuff was really stable… I’m just very careful. I don’t like putting my stuff out there before it’s ready, so to speak. And I’m pretty risk-averse, so it would have taken quite a while. I probably wouldn’t have chosen Solid for my startup till about the 1.0 release time period, which is basically this summer. So I’d feel things have gotten to that point, there’s a community behind it, it’s not me anymore, there’s six members on the core team… There’s more things that make this choice more attractive than it would have been before. There’s some momentum… It is interesting, because that technology decision is one that does tend to stick with you for years.

Back in 2011-2012 you might not have cared as much, in a different way, because people were willing to be like, “Okay, Ember. Angular.” Some JavaScript framework that no one’s heard of, that’s already dead. It was a different time. The mentality around like “You have to do React or you can’t hire people” has kind of influenced things now, in a harder way… So I think it’s harder to make that decision in general, but I think that at this point I would be plenty happy to take on Solid or Svelte… I mean, Svelte is a different category. But I was pretty hot on Svelte even from 2019. Since Svelte 3 came out, I was like “I don’t see why people wouldn’t use this.” Maybe my bias is in there. Maybe I am more risk-taking on that side - because I understand how these things work - than others would be… But yeah, today I would recommend it.

That was a fascinating story, giving us an intro to Solid, what it is, and its origins… And I love that it’s bringing back what’s old as new. Back in my day we used to say Dojo already did that, and I love that you can look at Hooks and be like “Solid influenced that.” That was a solid influence.

Ooooh…! Word of the day.

[laughs] I wanted to kind of dig a little deeper into it and kind of understand it a little bit more… So I’ve been doing React for years, and kind of the reactive style development in Dojo and things like that, but I am probably not up to speed on all of the terminology. One thing that you mentioned, I think around Hooks, or what they’re called in Solid, was like composable primitives. Can you define that a little bit more?

Yeah, it’s the idea that you can take – I’ll use React as an example, because people are more familiar with it… You can take useState and then be like “Oh, actually, I want local storage. I want the state to always store on local storage.” So you can make useLocalState. And now you’ve just replaced it in file, maybe just renamed the import so to speak, and now you have this new kind of enhanced functionality. And you can wrap obviously effects in it, and memos, and state… And this kind of pattern of taking these building blocks, of smaller core pieces to make things that are specific for you and your app. And we’ve seen repos like that, like react-use, and I think Vue has one too, and Solid has one called solid-primitives - of this idea of kind of building these building blocks out of these primitives.

Because the thing is, the primitives themselves contain the full lifecycle of the updates and the rendering of your components. It’s a really nice pattern, because once you make it about the data, you can group the behaviors together. And anyone who’s seen the intro to React Hooks talks understands this now. I mean, that was actually a pretty hard thing to explain before React Hooks marketing is always hard I suppose. But in general, this ability to put data and its behavior together and then package them up - that’s what I mean by composable primitives. To me, that is like the single most important thing – not the single, but one of the most important things in a JavaScript framework, this ability to be extensible in a way that feels native to it. Like part of the language. It’s not enough to just have state; you need to be able to have derived state, and whatnot.

I feel like one of the things I’m always fighting with React is performance. I guess maybe just because I do a lot of data stuff, and data is expensive when you change it, and there’s a lot of elements that reload… And I think you get a lot of wins for free if you switch – I don’t think Solid is using a VDOM; instead, it’s using reactivity. I’d love if you could go into that a little bit.

[24:19] It’s interesting, because this is a much greyer scale than people might realize, because a lot of the marketing - this is how they pretty much differentiate themselves… But generally speaking, most frameworks kind of – you have a component, and you change something, and the component rerenders. So if you had some data - say you have a list of to-do’s; this is a terrible, but everyone knows it… And you update to Done on one of those to-do’s, it goes “Okay, rerun the component, rerun the list, figure out what’s changed, and update the DOM.” And that in itself was always really slow. So people kind of would come up - in the early 2012-2013 time period; maybe even earlier I guess - with ways to just separate that from the render cycle. Just use events to update one specific part of the DOM. You start going “Well, why do all this work when you can just click the button, update the text?” Like, don’t do all this rerendering stuff.

And the biggest thing about the VDOM was React showed that you could actually do this top-down, rerender the component thing, and it not be that bad. As long as you weren’t reading from the DOM, causing layout shifts, or you weren’t doing a bunch of updates all over the place, unbatched, and things ping-ponging around, you could just make this virtual object and diff it, and the performance was good enough; it was pretty good. And that’s kind of the attractive part of the VDOM. But that made sense, purely runtime. What we’ve seen now is this kind of shift to reactivity and maybe no VDOM, because with a compiler per se you can kind of separate stuff out. And what Svelte does is instead of having our VDOM representation, it just goes “Here’s the code that runs on creation. Here’s the code that runs on update.” Just looking at the code - it can tell from the syntax and it goes “When it creates, run this code. When it updates, run this code.” And then it does a very simple diff. Because whenever the component needs a rerun, it goes “Okay, this data didn’t change, so you don’t have to do anything. This data didn’t change, so you don’t have to do anything. Oh, this thing changed. I’ll update it.” And this is drastically lighter abstraction, and it used the compiler to write it out.

I am getting to my point here… Solid is actually a little bit different, because – a lot of people would assume maybe it works like that, but the thing with Solid’s approach is it is kind of back to that… It’s just an event approach. It does use a compiler, but instead of using the compiler to reinforce a component model, it uses the compiler to basically turn every little expression in your JSX into a reactive computation. I don’t know if that’s clear to people… For a React dev, I just tell them it creates a useEffect everywhere. Essentially, you write some JSX, and I turn the JSX into a bunch of useEffects. Each of those useEffects run independently, like events. That’s probably a terrible explanation. So much easier to show this…

Really stupid question - so if I write everything in one component, versus if I compartmentalize everything into separate components, are you saying the performance is basically the same?

Yeah, with Solid. Because it’s not the components that rerun, it’s just the hooks that rerun. So whether you put them all in the same component or spread them out… This is a big, fundamental shift, because it’s not about performance in the sense like “Oh, this is faster.” It’s about “Do you need to be aware of this when you author your code?” And when you build React apps, you’re like, “Oh, okay, this is a component binary. I’m doing a loop, so I wanna push the state into the item, because I don’t wanna rerun the whole loop.” So you kind of do this game of hoisting and pushing down state to make the performance optimal. And the component boundaries really matter.

[28:09] A lot of the arguments I was making is React assistance feeding into component libraries - maybe they’re better at memo-izing, but they still cause this retrigger a lot of times, and it does matter how they break stuff apart, even if it’s downplayed. Quite often, the thing is for those libraries the components are the heavy piece. You don’t want more components, because that’s when they bring in their instances and the reactivity, and the components become this kind of thing that are actually expensive. So you’ll find like with Vue and Svelte you actually tend to lean towards less components from a performance standpoint, because you don’t want the overhead of components.

So there’s this interesting kind of thing… Vue is actually one of the most interesting ones to me, because they have a VDOM, which makes them want more components, and they want a reactive system that makes them use less components… So it’s like a tension that always works with them. But with Solid, I was like, if components stopped being a thing, maybe you could just not care about that, not have that influence how you author your components at all. It’s just a matter of having this stuff update where it updates. The trick to that is everything is lazily evaluated. That’s getting more technical, but if you picture everything as being getters in the component tree, when you pass props through - you know, like prop drills in React - your component tree, we don’t bind it to anything, we don’t do any extra work at the component boundaries. It’s just a getter. So we just defer evaluating that prop all the way down to where it’s used in the DOM. It’s technical, but it basically flattens the tree to the point that you still are dealing with the old event where you’re like “Here, update this state”, and it’s almost like a stream, like a pipe; it’s just gonna go straight to that DOM node that’s down three components deep and just update that text node. It doesn’t rerun any of the components in between. I don’t know how much that makes sense over audio, but that’s kind of the mentality here.

It makes sense, I think… I’m trying to put it together as like a mental model. You mentioned the JSX basically being turned into a useEffect. Is one key thing there that it’s specifically the JSX, and not the component itself? Because I think one thing I read about Solid is that a component function will run only once, which is very different from React. Is that a big fundamental difference?

Yeah, exactly. Because it’s the hooks that run multiple times. And generally speaking, it’s not like we always wrap all the JSX in a single Effect, so to speak. We just break apart the DOM operations, and it’s kind of like you set it and then forget it kind of thing. It’s a very declarative model. In the same way you declare some hooks, you’re just like “Okay, make this Effect that updates the title”, the JSX kind of does that, too. It just goes “Oh, make this binding that updates this text on this DOM node. And once it’s set, it’s that one thing that will rerun. We don’t rerun components.

This all sounds amazing, and I’m really excited to try it out, because it sounds like it solves a lot of problems I’m always running into. Are there any trade-offs there?

Yeah, there is. Because this mental model – I mean, run once should raise flags for some people immediately, simply because, like “How does anything change?” It might be easy enough for me to say “Oh, you just wrap stuff in Effects and you can kind of picture some attributes on a DOM element or something changing.” But it’s top-level stuff that gets a little bit more interesting. Because essentially, when things are accessed outside of a reactive scope - and this is the same, to a certain degree, with Vue, and it’s the same thing if you’ve ever used MobX - they don’t track. So then people are gonna go “Oh, where did my reactivity go?”

[31:53] So the number one rule of learning Solid generally is don’t destructure props. This drives React devs absolutely nuts. People try and come up with really interesting solutions to solve it. And there are solutions to “solve it”, but they’re all complicated, and they all involve magic. They all involve making certain assumptions that generally I’m not as comfortable making. To be fair, it’s not unlike the ESLint rules around the dependency arrays in React. Solid doesn’t have those dependency arrays; you don’t need to write them, so we don’t have that rule. But the destructuring side - we do have ESLint rules to say “Hey, don’t destructure.” But again, there’s always an exception to every rule, and it’s the thing. I’d say that one, and then top-level control flow. Early returns – like, if you just go “If this return here”, it’s never gonna run again, so it’s never gonna hit the other branch.

So generally speaking, the control flow – I mean, you could do it a couple ways. You could use the reactive system, but generally, for the most part, you just put the control flow in the JSX. You just put it in the fragment. If there’s two different exits, just make a JSX fragment, or ternary operator, and just put it in there, and then it’ll handle it. It does take a little bit of adjustment, but I feel once you’re at least familiar with the pattern, you can get in the flow with it. But it does mean, as you can guess – like, react-compat is not on the menu, so to speak… The execution is very different. There’s no useRef, there’s no useCallback. These concepts make no sense in Solid, because the thing doesn’t run again. So it doesn’t port right away.

I think a good heuristic for people is once you get to a point where you use useRef for something that is not a DOM element, that’s the point at which it doesn’t port directly to Solid and you have to think about it a bit. Fortunately, when you get to the point when you have to use useRef for not a DOM element, that’s usually the point where people start cursing hooks. It’s about the same threshold.

I just think it’s funny that people will go out of their way to try and bring back the ability to destructure, and the patterns that we’re familiar with in React, when that is so much more complicated than what’s actually happening here.

One of the cool things about being built on these primitives - and this is the most wild thing I’ve found about Solid - is we don’t have that many component libraries yet. Solid-Bootstrap is finished up, but we don’t have Material Design yet, or Carbon Components, or Rich Components. There’s a whole bunch of stuff in the works. But we have like three or four projects - actually, probably more than that - where people have just taken Solid and built a compiler in front of it and used the syntax of their choice. There’s like, stuff to sell this in. People really care about that syntax element. And honestly, as I mentioned earlier, that wasn’t my goal, that wasn’t where I was going to. I just wanted reusable primitives. Well, what people have found is because the building blocks are so exposed and so easy, it’s not that difficult to just build that kind of – if you want a Svelte-looking thing, they can just build it on top, and still benefit from some of the other cool stuff about Solid in terms of performance and whatnot.

There’s always trade-offs… Perfect example - if you go strictly to like the Svelte-type syntax, with the lets and the $s. Well, composition is challenging. Svelte has a different mechanism for that. They use stores, which is completely separate from the reactive language. So that’s one of those trade-offs; it’s much easier to do local optimized compilation than across files. So it makes sense, but it’s what you value. I super, super-value composition, so that wasn’t the direction I took. But if people don’t care about that element, then they can do it.

I think that’s the coolest part about having adaptable building blocks, things that aren’t necessarily configurable; complex, but just little things that can be used in lots of different ways.

So 1.0 happened last summer. There’s traction now, there’s people talking about it, you’ve got JS Party interested… Tell us about the community. Obviously, when you pick something not as big as React, you miss out on opportunities for community-contributed libraries and plugins and example code and all these things. So that’s always something that the smaller, more indie projects really have to fight against. But it seems like you do have some traction, you have some momentum… Can you tell us who else is using Solid, and about the team behind it? Is it just yourself still? Are there people involved? What does the momentum look like? What does the future look like? Give us that picture.

I couldn’t be happier in the way that the community has developed around Solid. It’s taken time, it’s been slow, mostly because at the beginning I wasn’t really looking to do much. I brought a couple other people in on the core team to help with the website and the docs, and it’s grown now to like six members, and even more people around the ecosystem who are contributing. The good, solid group of –

ding

Yeah, contributors… I knew I was gonna do that at some point; or someone was gonna do that. Contributors - you know, a couple dozen people that participate in the Discord, help on the various projects… I think the biggest thing that I like about our community is because Solid’s built on this transparency, and just everyone knows how the framework works, or feels like they can build it, we kind of really fostered (or have been trying to foster) a community where it’s all about – it’s not about maybe a cultish following, so to speak; it’s not about like “This is the only solution.” Trying to teach people to look at performance, look at metrics and look at trade-offs, and really have a deep understanding - I think that kind of reflects on the way the community is out there.

I have to admit, it does set a bunch of people out on the world who are going to like, “well actually”ing people on twitter. But for the most part, I’m really happy how there’s been a really open discourse to make improvements, and look at the web in general, and even keep our community close to other projects that aren’t looking at that; things like Astro, or Quick, or Marko, which I also work on… Just kind of sharing of ideas. I think that’s really exciting. That is one of the benefits you do get on the indie side, so to speak, you have a bunch of small parties that are all like – they know they’re the small players, they’re not the giants in this, so they’re much more likely to be comrades, so to speak.

Well, it’s easier to get a seat at the table, because you have more opportunity, you have influence in the help, and feel like your contributions really do move the needle. In a larger community you can feel like you’re trying to help or you’re trying to pitch in, you’re trying to evangelize, and it’s like, you’re just one of thousands of other people doing that kind of thing. But smaller communities - you can have more real impact, it seems like, at least at the start.

Yeah. Especially that, and the factor that you have, as I said, other smaller communities kind of coming together, because there isn’t – maybe the rivalry hasn’t formed yet; maybe the lines haven’t been drawn. It’s something I’ve been finding really interesting.

Would you like to start a rivalry right now? Would you like to pick somebody as an enemy?

[40:14] No, no…

Or a frenemy? How about Marko js? I hear that’s… The worst! [laughs]

My work on Marko was part of actually what I think leads to that, because I work on two frameworks, and there’s no way I could possibly – and they’re at times very opposite sides. One’s a single-page app, one’s a multi-page app. Solid - I told you about the modularity and the composability… Marko is on the Svelte side of things. So these are very kind of opposite things. And because of that, and because of my work and the way I talk about it, I think it always has this kind of even keel sort of feel, and I think that kind of permeates through the community and have others feel like it’s a safe place to talk about ideas, and push the web forward.

This morning, for example, Miško Hevery, creator of Angular and quick actually just popped on our server general and just dropped in his latest tutorial video for Quick. It had nothing to do with Solid, but he knows our community is super-stoked about everything that’s happening in web dev, and everything cutting edge, whether it’s Solid-specific or not. And I think it’s a community of early adopters. I love that kind of atmosphere.

On the other side of your question - that’s the community, and that’s a community that has been growing. And the hackathon that we actually started, which is a three month long hackathon, launched in January (ends in April) is really pushing new people to come in and try Solid for the first time.

So I think there’s a lot of room for growth. We did this long hackathon – because we didn’t want people to feel pressured. We just want them to give it a shot, try it out, maybe like it, and kind of spend the time to put in a library that people can continue to use. So this has been a slow growth, but as I said, I couldn’t be happier with where that’s going.

On the topic of where Solid is heading, which is what you’d asked about… 1.0 - it took a long time for us to get to 1.0. It came out this summer. And mostly delayed because of server-side rendering. I’ve built a framework that was designed for client-side rendering primarily, and then in the process, everyone wanted server-side rendering, so I looked into it and got better at that and figured out how we could do that.

Since 1.0, we’ve added a lot of interesting features. Stuff like concurrent rendering, universal renderers, like the ability to support things like maybe Solid native, or Solid GL… And most recently, we added support for HTML streaming. And these are all just building blocks that we’ve been trying to piece together to complete that story, so people have the fundamental pieces they would need to try Solid in a number of different applications. But we’re kind of switching gears a bit now… Now that we’ve kind of shown what Solid is capable of, shown the different avenues you could take it, we’re now taking another cycle where we wanna make it easier for people to use, easier for people to come in for the first time, use the SSR and whatnot, and a big part of that actually has been work towards developing our own starter metaframework thing. You’ve seen Sellkit you’ve seen Remix recently, obviously there’s Next.js and a bunch of other things… Last March we kind of started on this, and as I’ve mentioned, we’ve done a lot this year, so I haven’t given it as much focus till now. But we’re taking it seriously.

That’s the number one question people ask, besides “Is there a component library?” Is there a way that we can just get started with Solid in like a full-stack SSR kind of way? And the answer to that very soon should be yes.

[43:51] I’ve been using it for a lot of our demos. People have checked them out. I’ve been basically making Hacker News demos and posting them all over the internet on every different cloud provider, whether it’s Netlify Functions, or Cloudflare Workers, or Vercel Edge. I’ve been using the early alpha version of this Solid Start - which is what we’ve dubbed the starter - as a way of proving out the ability to have Solid completely at the edge, with all the modern conveniences like streaming, Suspense on the server, and whatnot, all from the edge. And yeah, I’ve been really happy exploring that… Especially Cloudflare Workers and Vercel Edge, which is built on Cloudflare Workers, is really, really cool technology. I definitely see a lot of the frameworks are spending a lot of time here. I think it’s gonna really change the way we approach building apps, in a sense. I know there’s different scales, and different companies have different needs, but it’s quite likely that this sort of edge worker approach is almost like the new JAMStack, when you can build it so close to the edge. You don’t necessarily need to be static. What’s really interesting is there’s new technology tricks, new ways to get performance, so I’m all in there, trying to push boundaries and see what we can do.

I’m curious, with adoption, how has that changed after 1.0? And also, is there a certain niche of people that you find are using Solid more than others?

Yeah, there’s definitely now a sense that it’s worth investing in some things. People were relatively resistant, let’s say, from investing in, say, creating certain types of libraries, like component libraries, things that were big investments in time before 1.0. That’s kind of changed. A lot of people are actually trying that.

The other thing I’m starting to see is - yes, smaller companies, projects, things like that, where people are coming in and are like “Hey, we wanna use Solid for that. There’s been a sprinkling over the years, but there’s just been more and more of that.

Part of the way we were able to get sponsors for this hackathon was these companies actually wanna invest in Solid, because they wanna – they wanna get people to learn Solid, so they can hire people in Solid. Companies like 402 and a few others that are sponsoring the hackathon are get back to - Essentially, by putting stuff into Solid, putting stuff into the community, it kind of pays it back to themselves as well. So yeah, this is a big difference from when I was doing this by myself, to kind of see people excited to use it in their projects.

Well, this has been a solid roundup of everything Solid. Ryan, is there anything left on the table, things that you were hoping we’d ask you, or things you would like to say, places to point people to get started, or where the community gathers, that we haven’t talked about yet, that you’d like to say as we tail off?

Yeah, I mentioned a bit before, but I think the website actually has a ton of resources on it. We’ve been trying really hard to gather as many resources as we can, in terms of libraries, articles, videos… And there’s a tutorial on there, very influenced by Svelte-style tutorials. There’s 40 different lessons you can use to learn Solid. I think it’s a great starting place, at least for anyone who is familiar with other JavaScript frameworks. It’s a very quick reference to go like “Oh, this is how I do it in Solid.”

There’s also the Discord. That’s where we live. It’s been growing rapidly over the last few months. If you want a question answered, honestly, jump in there. It’s all linked off the website. But that’s where we live. We’re always online. So do come in, join the community and say hi. That’s definitely the best way to get connected with us.

Excellent. Nick and/or Amelia, any nagging questions that you haven’t had a chance to ask yet?

When are you getting approached by Vercel…?

[laughs] Good one! Good one.

Oh, man… That was floating around for a bit, yeah. I don’t know about that. But they were very, very stoked about the demo. I didn’t realize this at the time, but I did that Hacker News demo on Vercel Edge, with streaming and transitions in Suspense and everything, and I assumed that’s what Next 12 was doing and all that was a demo but I was actually mistaken. I basically had kind of reverse-hacked Next.js to get a full Solid app running on the edge within 12 hours of the Vercel announcement, and they were like “Whoa, this is really cool!” So they reached out to me in terms of getting a Solid integration.

[48:25] So yeah, I don’t know about them hiring me, so to speak, but I’ve been working with them recently on a Solid integration. Our new starter, Solid Start, does actually show up in the integration list on Vercel, so you can create an app right away with that, and have it deploy to Vercel Edge, with all the bells and whistles, so to speak.

Solid.

I’ll just throw out – not a question really, but more of a statement, I guess… You know, there was a tweet, I think yesterday, by Ryan Florence, one of the creators of Remix, talking about how the world seems to be ready for the post-React world… And he mentions both Solid and Marko in the tweet. So - just really cool being able to talk to you about that, being able to talk to you about the potential other side of this React coin that we’ve been in for quite a while… Very exciting stuff. I’m really excited to learn more and to unlearn some of the things that I am doing in React.

Yeah. The React community especially has been more supportive than I would have ever imagined. I don’t know how to put it – maybe it’s the philosophical similarities. Maybe they see the same kind of driving motivations and goals that are in React, that have allowed them to attached themselves to it… Because we’ve had really good responses from Ryan Florence and Michael Jackson from Remix… People like Mark Dalgleish with Vanilla Extract, David Piano… Just a lot of people – Tanner Linsley… A lot of people working around the libraries in React, who - you know, maybe they’ve struggled with Hooks, but they generally like the model… But I think they see that Solid kind of carries a bit of the torch, the same kind of mentality as React, and I didn’t expect that effort, as I said. I thought it would be the compiler reactive people. But I think those things that might seem more like on the surface actually maybe make a bigger difference in how we choose the frameworks and tools that we like to use, more so than I would have expected.

It’s been incredible to see the React community on that. When people kind of discover reactivity for the first time because of Solid, someone has to point out to them, they’re like “This is kind of how Vue works.” Vue has been doing this also this whole time. There are differences, but the reactive part – and it’s just because maybe something about the way Vue showed its reactivity, or the kind of mental model abstraction in like Svelte, or whatever, on that side, it just never clicked. And I think the React community has been so supporive in that sense. It’s funny, the more religious wars I have is with other reactive libraries. It’s like Solid is a traitor

Well, there you have it - your opportunity for a rivalry can be with the other reactive libraries, if we can get a real barn burner going. Well, Ryan, thanks so much for joining the show, telling us about Solid, thanks for all your hard work on this cool and interesting and exciting (to use Nick’s word) option in the frontend space. We have lots of options, but that’s what innovation is - we continue to push, and change, and try new things, and push the industry forward, and bring everybody along with us along the way… So thanks for all your hard work on that.

To our listeners, we have all of the things to all the things in the show notes, so check those for all the places to go to learn more about Solid, as well as the Solid Start metaframework that Ryan mentioned there at the end, we’ll have everything linked, too. Holla one more time at JSConf Mexico; check out those YouTube videos. They are uploading in both languages on behalf of Amelia Wattenberger and Nick Nisi. I’m Jerod Santo and this has been JS Party. We’ll catch you all next week!

Funny… So much in my experience with those years in that startup - your boss, Amelia, he was my mentor.

Adan?

No, I guess bigger boss.

Oh, yeah, yeah.

Jason Warner.

I think he’s moved on, hasn’t he?

Yeah, he was my boss for like – I joined the office of the CTO, and then three months later the CTO left… [laughs] I didn’t do it. It’s not because I joined, I swear. [laughter]

No, that’s interesting. See, that’s exactly – I haven’t even kept up on it. It was funny, because in my startup, when everyone took off, I was left by myself; the CEO was the only one left, there was no CTO, no COO, no nothing. And she actually pulled Jason in to be like “Hey this is sales force days. But okay, I didn’t know he moved on, so I don’t know anything.

Yeah, he does VC now.

It’s funny.

Yeah.

That was short-lived then, because was then – yeah, that’s funny…

Short-lived with Amelia there, but he helped do the whole–

Acquisition.

…sale to Microsoft, yeah.

Yeah.

We had a whole conversation with him on the Changelog where he tells the tale. He basically came in there, helped sell it to Microsoft, and it was pretty cool, the way it all went down…

I listened to that before my interview with him, and I was like “It’s cool having podcast episodes before you do an interview with someone”, because you can get a sense of…

Nice! Yeah, we were actually surprised – we didn’t know what the conversation was gonna be when we recorded that episode. He was very candid. He’s like, “I’ve never told this story, but I’m gonna tell it right now.” We’re like, “Okay…” Because it was kind of the inside story of that acquisition, from his perspective, obviously.

That’s cool.

So that was cool. But then I was like, “Amelia, you work there.” She’s like, “Yeah, but he’s gone.”

Surprise… [laughs]

“I know Jason. Oh, he’s gone.” Okay…

So there you go…

So who’s the CTO now, Amelia?

We don’t have one.

Oh.

Yeah, we’re now GitHub Next. It’s just like an R&D team.

GitHub Next.

Oh, yeah.

Sure. Still a sweet job. I mean, it’s still the same job that was Octo, basically. Because that’s what he was doing –

It hasn’t changed a lot.

We asked him what he does and he’s like “My job is like ten years from now stuff.”

Yeah, exactly.

When he was there. So… Solid. Alright.