A Solid primer on Signals

Hello, everyone. Welcome back! You’re listening to JavaScript Party. Sorry, I meant JS Party… And we’re here with a very exciting guest today. And with me to welcome in our guest and this awesome topic is Nick. Hello, Nick.

Ahoy-hoy. Hi, Amal.

How are you today?

I am super, super-excited for this JavaScript party…

I know. Me too. It’s gonna be a special party I think today, because we have none other than I think the thought leader, influencer himself, Ryan Carniato. Hello. Welcome, Ryan.

Hi. Thanks for having me today.

Yeah, we’re excited. And you’re a thought leader and influencer because you’re the creator of Solid, and we’ve seen a proliferation of some of the APIs and functionalities, and things that are in Solid really proliferating throughout the ecosystem, which is fantastic… And so we’ve invited you here today to talk a little bit about Solid, but more so what I’d like to broadly dig into are some of the principles within Solid, specifically making a case for reactivity. I’d really love to dig into that, because we’re seeing that everywhere, and we’re seeing Signals pop up everywhere, too. And so I’d love to talk about real world use cases, pros and cons… It’s not just about perf, so what are some of the other benefits… So lots to discuss today. But before we get into all of those topics, why don’t you introduce yourself? You’ve been on the show before, we had you here in 2022, so welcome back… But for those who may not be familiar with you, tell us a little bit about yourself.

Yeah. Let’s see here. You already mentioned I created Solid.js… But yeah, I’ve been working in web development for quite some time, since I was a teenager making websites for my band… And I was kind of like a product engineer working at startups, and then at some point in my spare time I decided to make a JavaScript framework, because trends in JavaScript frameworks had kind of moved away from what I liked. As you mentioned, before reactivity has always been for me something that - well, not always; I actually only really found out about it in 2010. But once I’ve caught that bug, so to speak, I just kept on pushing with it. And then around 2014-2015 everything kind of changed, and people were not into reactive libraries anymore as much. Things like React had proliferated… Sorry, proliferated. Sorry, things like React had proliferated.

Ploriferated. I can barely say it. It’s a big word.

Things like React had proliferated… And from there, I wanted to continue doing what I like to do, so I decided to try and modernize the approach to reactivity, and I wrote Solid.js. Since then I realized, because of how much the ecosystem had changed, no one knew about these things very much anymore, after only a few years… So I spent a lot of time educating, and writing articles, and over time streaming, and teaching… It became a big part of what I do. So yeah; I mean, that’s me. I’m the Signals guy.

Yeah, you’re the Signals CEO, more specifically. That’s what we’ve heard. That’s the name on the street anyway.

Ryan, I’m curious… Based on that story, React coming out seemed - not to put words in your mouth, but it seemed kind of like a bummer. What were you using before that?

[00:07:37.02] I was using Knockout.js… Which was chaotic, definitely, but it had a lot of good things. And when we got to that point, when performance benchmarks, and people were talking about different paradigms came out, I feel like there had been a real shift, and the popular solutions didn’t really work like Knockout, and certain things were getting discounted, maybe prematurely. It’s one of those tricky things… Because the most popular frameworks, I guess, around the time React came out, would have been Angular, and then something like maybe Backbone type stuff…

I was in the Backbone camp.

Yeah. And there were things like Ember too which had reactivity, but the types of things or assumptions that were made about these systems - some of them were very valid, but some of them also didn’t quite sit right with me. I kept seeing these performance benchmarks, and not only were the situations kind of unrealistic to me, where people were going lik “My framework’s fast, because I can dump my whole database onto the page a million times a second.” No one really wants to do that. You want to send less over the server wire, right? You want to do less updates, if possible. You don’t want to just like brute-force it. But that was like the mentality. And you know what? React is really good at taking something that’s really, really inefficient, and making it slightly more efficient. Basically, React is really good at putting a floor on how bad your performance can be. But actually making things fast - well, that’s another question.

Yeah. And let’s dig into that, because Solid is – so again, I really want to focus broadly on some of the principles, so I’d love to briefly set the baseline for folks around Solid… What is it? How is it different than tools like React? And I think for me one of the coolest things about Solid is how fast it is. The only thing faster than Solid right now in the “market” is just using vanilla JS. So extremely low overhead… And vanilla JS doesn’t have too much on Solid either. It’s just a teeny bit, just a teeny bit faster. But obviously, the benefits of using a framework or a library like Solid – actually, framework or library, Ryan?

Yeah, I mean, I’m pretty fine with either. We’re on the library side, I guess, philosophically, kind of like React, where our intention wasn’t to provide everything for you, it was to provide basic pieces that things could be built on top of. So either…

Either, yeah. We need a merged word, so please, somebody, internet, make that happen. I can’t keep saying “framework or library”. It’s quite a mouthful. But anyways, so tools like Solid are just – you get a ton of other utilities. So anyways, so without further ado, please, what is Solid, and how is it different than React?

I built Solid under kind of an experimental idea. I was like “What if Signals or the reactivity was the whole framework?” What if it was every part of it? What if instead of having a separate render, or like a separate diffing thing, we just took Signals and see what we could do with it? Because conceptually, I start from very vanilla JS kind of mentality. I was like “Okay, if I was to write this all with vanilla JS, how would it work?” Well, it would work very quickly, but it would be a little bit verbose, and there’d be a lot of duplication, repetition. You want to kind of generalize stuff. And I decided that what I would do basically would just - almost like jQuery; just write some reactivity that would update the DOM where I needed it to… So I could just like be “When I update this value, have this place in the DOM update.” It seems simple enough. But I wanted to see if I could take that, that kind of scaled down, or simplicity, so to speak, and then also scale it up to be able to handle application needs of modern web applications. And this was primarily client-side focused. I cared about dashboards, and things with a lot of interactivity.

And as it turned out, it was quite doable. Taking a little influence from Knockout, taking what we’ve learned in time about how to make more consistent reactivity from things like MobX. I realized that we could just basically use a compiler for syntax. And I didn’t want to invent one of those; a lot of people spend a lot of time on that, and it’s whole stories about the language… Svelte is a perfect example of this, where a lot of care and concern has gone into the aesthetics of how it is to build, and what it feels like…

[00:12:16.18] I just grabbed JSX, basically, the first thing on the shelf; all the tooling works for TypeScript… You know, linting, color, Prettier, all this stuff. And I was like “Can I just compile JSX to DOM elements in a way that I can put the reactivity in?” And that’s basically what I did. I basically took stock JSX and had it output what I would have written by hand, if I was just kind of jQuerying it. And… Yeah, I mean, the results were, as you can imagine, very quick, because writing vanilla code - it’s quick. There’s not much else to it. But the question is, could it scale up to be able to handle all the scenarios that were needed? And that was something that had to be proven. And I believe over time we have.

I started working on Solid back in 2016, and I open-sourced it in 2018. And by that time I had the DOM in a pretty good place, and we started winning at benchmarks, so to speak. But they were a good starting point. But it wasn’t the ending for us, because – for me, the reason I even started this was because I liked the way I developed in Knockout. I liked data flows, I liked, the spreadsheet mentality. I liked the idea that you kind of set and forget it. You create these rules, you update your data, and everything just propagates.

So that’s like the core of Solid, it was trying to be simple. It wasn’t about adoption, it wasn’t about who could get in here. There’s a bit of a learning curve, because you have to learn about Signals to begin with. But at the same time, it gave me complete control. This is something that I liked. I could always go right down to the metal, and update the DOM directly… Because in Solid, a div JSX element is just an HTML div element. It’s just a real DOM node. You always have access. And because it was constructed in this sort of way, our components run once, because they’re just function calls that just create some stuff that will update in the future. So there’s this very simple thing – and in early days, components were really nothing. Now we do a little bit of extra massaging in the reactivity through our props, but generally speaking, a bunch of these elements just kind of came together in a way that even I didn’t understand at first, but ended up being able to not only emulate most things you would expect - everything from context, concurrent rendering, transitions… You know, all the features you’d expect in a modern framework, but even stuff beyond the web; there’s a lot of – you don’t need a virtual DOM to do universal rendering. We have mobile, we have desktop, we have televisions… There’s tons of libraries/frameworks. I say tons, but there’s at least three in each of these categories where you can choose to and use with Solid, purely reactive, and be able to render to a phone natively, or render WebGL 3D scenes. So this ended up being a different model to basically accomplish pretty much everything you could do in virtual DOM, or like a React-like library. And it was just built off this one building block, basically.

That’s cool. And that building block is the fact that you don’t do “dirty checking”…

The Signals.

The Signals, okay. You’re right; those scapular updates, right? You’re not like looping through all the nodes to see what’s different. Your create an update paths are separated out.

[00:15:51.07] Right. When you know how data flows through your app, there’s a lot of things you can gain from that. And it’s not to say that you don’t need the diff; you can always mix and match these things. The most powerful control aspect here isn’t just the way that you can kind of roll down or scale up, or whatever. It’s the fact that the granularity of change is really up to you. You control the containers. It’s kind of like you could change the size of your components in React. Well, you can basically change even more granular if you want, or wider, the size of what updates, with Signals. You get the ability to control that. It’s like a different dimension. And while that seems maybe like a lot, or complicated, the most amazing thing you see - and I sometimes demo this - is just how you start from a place of this where you’re just kind of doing the jQuery thing, and it literally just morphs into something like React. In fact, most people that you talk to, Solid, when they first see it, they might even dismiss it, because they’re like “Oh, so it’s just React.” Literally looks like React, to such a degree that some people even say “Oh yeah, that’s one of the reasons to choose Solid, because you can just move from Solid to React.” And I’m like “It’s not necessarily that simple. There’s actually a lot of different things going on here.” But the fact that you get that impression shows how successful it is at its abstraction, and its ability to, as I said, roll down and scale up.

I think that that’s like a big appeal of it, is that it does look so much like that. Because honestly, I don’t care too much about React specifically, but I like JSX. I like setting up my components and thinking in terms of components like that… And then the idea that this function is going to run once - I can’t tell you how amazing that sounds right now. Just based on debugging that I’ve had to do recently, I’m just like “This is so bad…!”

Yeah. I mean, that’s one of the trickiest pain points that we hear. And again, this wasn’t me trying to like make the anti React. I have a lot of respect for what React has done. It was just that Solid came at a time when people were getting to large-scale React apps and really experienced that pain in rerendering, and trying to figure out when to memo what, and it was just not a problem. I remember they made a video that they’re showing how the automated compiler would work, which we’ll probably talk about a bit later… And I looked at the example, and they went through this whole talk explaining what you would do in React and what it would construct to, and I think it was really brilliant to kind of show the compiled code, and then get back to the nice code, and being like “Oh, yeah, this is great.” But then the cool part about that demo for me is I built the same demo in Solid, the original version they started at in the first two minutes of the talk, and it just worked the way it was supposed to. The whole talk, the whole compiler, the whole thing just didn’t happen. There’s no create memo, or memo, or everything; just, that was the way it worked. And that’s pretty powerful when you consider that – like, we do leverage the compiler, to use the JSX, but it’s a templating thing. Most of Solid is actually a runtime library. That’s why I don’t actually consider Solid that similar to Svelte. We use the compiler almost begrudgingly, to the point where we’re like “If we need to compile it because it’ll help the DX or the experience a bit, we will.” But I don’t want to necessarily sell that. I like keeping things transparent. I like keeping things simple. In a sense, the compiler is like another level of abstraction. It makes things easier, but –

Yeah. It’s magic.

Yeah, what happens under the hood gets more involved. And I find that the farther you get from the bare metal to the abstraction, the more jarring it is when you have to peek under the covers. That’s my personal theory, actually, why people don’t like use effect. It’s not because of all the other stuff. That’s the moment when you realize React doesn’t work the way you think it works.

Break: [00:19:38.25]

So I think for me this is when I kind of - I don’t wanna say “fell off the React bandwagon”, but this is when React started to feel really unintuitive for me. Hooks just never really worked in the way that I expected it to work, and then there’s all these rules that you had to remember. And so like looking at Solid components, it just feels like React the way I expect it to work; the way I wished it worked, actually… So that’s also lovely. But can we talk about the compiler a little bit? Because that’s a little bit of the secret sauce here.

So you’re saying this is more of a runtime library, and you use the compiler begrudgingly… And so what is the compiler doing? Because I would expect the compiler to be figuring out where all the Signals are, and – I don’t know, I’d expect it to have some kind of a map upfront, and then that’s how you’re able to do this scapular updating… But I don’t know, you tell me. What is it doing?

Okay. Yeah, it’s actually a lot simpler than that, because all our dependencies are dynamic. The compiler doesn’t handle the reactivity at all. So what it does is JSX has one thing in it that makes the standard transform not very helpful for us. And that is it evaluates all the holes, all the expressions eagerly, and then passes them in. And in a reactive library, you want to – we use auto tracking, so you want to be able to access the values under some kind of reactive scope. So the compiler had to go in and put a bunch of functions, wrappers around each expression. And we can be a little smarter, because we can tell, like, if you don’t call a function, or access a property on something in an expression, it can’t be reactive. And this is one of the biggest changes. A signal has to be called as a function, whether it’s using a getter or something; it has to be called as a function. So we can always just pass it straight through normal values. But if we see that it calls a function somewhere, then we have to make sure to wrap that expression in a function. That’s actually mostly what the compiler does.

So there’s just a bunch of function calls that happen, basically, when there’s a signal update or whatever? So like you have this chain of functions? That’s really smart. That’s like crazy smart. It’s so simple, but it’s like crazy smart, too.

The other half is we do the same thing that Lit does. We look at the JSX as a template, and then pull out the HTML string so we can clone it, so that we can create all the elements [unintelligible 00:25:25.28]

Oh, right, right, right. And that happens with the compiler, right?

Yeah.

Okay.

But it could happen at runtime. Lit does it at runtime; the first time it runs, it grabs it. That difference is minimal. But essentially - yeah, we use the compiler so that we can do that. So basically, when you create real DOM nodes, it’s a matter of cloning the nodes, and then walking to the locations, and basically taking those functions and wrapping over the element reference. A little bit technical, but essentially, you basically clone the nodes, collect the nodes, and then basically pass them into effects that would update the DOM.

[00:26:06.16] So there’s a little bit more to the compiler, but the non-native element part, the components - they’re just basically function calls. Just like normal JSX, so you can move them around or whatnot. And we just have to make sure that we wrap the props in functions.

And it’s worth calling out – and thanks for that excellent explanation, by the way… It’s worth calling out that Lit doesn’t use a compiler, and that’s like a big – that’s like a very intentional trade-off that they’ve made. And that’s kind of magical. It’s so great to have this beautiful JavaScript, this JSX-like thing that’s not quite JSX, it’s using string templates, and whatever else, but there’s no compiler involved with this. It’s pretty awesome.

Right. And that’s actually one of the things here, part of the design in terms of the function things. We actually support tag template literals; we have a version that works like Lit [unintelligible 00:27:01.03]

Nice!

So we don’t actually need the [unintelligible 00:27:04.24] But now you’re the one wrapping all the expressions in the functions.

I see. I see. That makes sense.

And personally, I find that very onerous, which is – I mean, there are ways around it, or you can like design your APIs in a way to kind of cater to it, using like class properties, and stuff… I know Lit’s been putting signal reactivity into their stuff. I think it uses Preact Signals as of late. But this was one of the big ergonomic gains that we got from using the compiler, was that – it’s why it looks like React, because you can basically just stick the expressions in the template, and they will track and work properly. And you can’t do that without some kind of transform that makes sure that you don’t run the expressions up front.

And so just a couple more things on Solid before we move on to like some of the general principles… So looking at your API, it feels Reacty as well; not just in the shape of the components, but the API itself. The names of your functions… Like, you have create context, use context, you’ve got children, you’ve got lazy, you’ve got create effect, create memo, all these things that feel very Reacty. So can you talk us a little bit through some of your intentions there?

Yeah. It just made sense at the time. One thing to remember is Solid was out before React Hooks. So we didn’t have the use convention per se, and we actually didn’t have the tuple convention of returning the arrays with the two arguments. I actually grabbed that right from React. But yeah, I mean, React for stuff like context was obviously an influence. We had provider, and some way of using the context… But essentially, we had our APIs doing the fine-grained thing, looking a lot like hooks, and then React Hooks came out, and I was like “It looks almost identical.” At that point, I was like “Let’s just adopt a similar convention.”

The truth of the matter is returning the arrays, like the tuples, was something that I’d been struggling with for a long time. Reactivity is often cited. One of the previous things that people always criticized was it was like two-way binding, and chaotic updates. And I believed a lot in React’s philosophies in terms of unidirectional flow, single binding, there’s no two-way, all that kind of stuff; data down, events up. And I really wanted the segregation, but almost every Signals API up to that point - because you need to have a getter and a setter - generally were on a single object, or their proxy, or literally an object with a getter and a setter on it. And I played with a bunch of APIs to try and make it nicely, and then I saw hooks, and it separated them so that people would name them - which is great when you destructure the array - and it made sure that the get and the set weren’t on the same thing. And I was like “This is what I’ve been looking for.”

[00:30:09.18] Like, I’d been playing around with these primitives, these Signals that look a lot like hooks for years and years before. And it never occurred to me, this pattern. React released Hooks… I think I spent more time jaw-dropping about the fact that they solved my API problem when I watched Dan’s original talk, more than actually the fact that React was getting hooks. I was like “That’s it! This is what I’ve been looking for.”

So this was still pre 1.0 for Solid, so within a couple of weeks I’d updated all our APIs to resemble more like React. I chose not to use use, because use to me suggested something that was used; like that would maybe do multiple times. I chose create to signify that this only runs once, like a render function. And yeah, that’s how it went there.

It was just kind of funny, because Solid had something that looked like hooks and JSX before React had hooks. So I wasn’t like trying to copy React initially in how we did it. We had function components – back then React had class components. So we were very much – I didn’t want classes, I wanted function components. It had all the pieces I needed. And then once I saw React, it was really easy just to make those finishing touch APIs to make them look similar… Which obviously confused people. But I made those decisions not because, again, I wanted to copy React directly on API surface, because I knew that they were not compatible… It was because I think React made the right decision there. I think enforcing the read/write segregation I think [unintelligible 00:31:37.27] these are all really good design details in terms of the React Hooks API, and they only made the Signals API stronger.

So is it safe to say that like hooks was influenced by the Signals API a little bit?

I don’t know. They released something where they talked about all their influences for React hooks, and there’s a document there… None of the Signal libraries that I’m familiar with showed up on that list. I was suspect at the time, because I feel like “How could you not notice all the similar libraries?” Solid wasn’t the only one back then. We’ve kind of got popular over time, but there’s been Knockout, but then there’s like CanJS, Reactive, Svelte 1 and 2… There are a ton of prior arts here. And somehow it just kind of slid by on React’s influence on hooks. So I don’t know, we have a long history…

I mean, it could be like a TV commercial. Sometimes you don’t know you’re being subconsciously influenced, but you’re suddenly craving Subway’s $5 footlongs, you know what I mean? It’s like you don’t know, but it could just be a subconscious influence, you know? [laughs]

Brought to you by Carl’s Jr.

I also think that you have to – we didn’t talk about it much earlier, but when React first came out and they were talking about the power of their model, in terms of just rerender everything, throw it all the way, it was very much in opposition or opposed to basically doing these kind of – what they call KVO, key-value observable patterns. Like things you found in Ember, or even Knockout to a degree, where they were using these signal-like things. They’re saying instead of worrying about the data flow, and they had all these ping-pong issues – there’s a classic story about Facebook Messenger always showing notifications, or something… They were like “No, we just rerender it all.” And that was the ground they were built on, which is largely why I don’t think – they generally never really nod to Signals, and why when everyone’s like “When’s React gonna get Signals?”, I don’t expect that anytime soon. It’s almost like their philosophical grounding of like “We are not a Signals library.”

Right. But they are getting a compiler, and that’s some big news. So they dropped – I don’t know, maybe an RFC, or a blog post (or both) on this… And we’ll link it in the show notes. And that’s something that is on my agenda. I want to talk to the team about this, because it’s a huge shift for React… But React is getting a compiler, which means some of the clunkiness around hooks and all this other stuff - it hopefully will just go away, because they’re able to leverage some better kind of analysis… So that’s something right, Ryan? That’s interesting…

[00:34:17.11] It is definitely interesting. Well, it’s a bigger shift. And we will talk about Signals in this podcast…

Yes, we’re gonna get to it next. Next. Next. Next topic.

No, but the be fair, this shift is huge, but for maybe reasons in my opinion that people aren’t seeing right off the bat… Because I do think it will make React a lot easier to use. I think you might not have to worry about when to use memos much… And I think the default performance characteristics will get a lot better, especially for larger apps. I don’t think it will have a huge impact on micro benchmarks, but those things don’t matter, really. But the average person who goes on and writes a React app - I think it’ll get a lot easier to use, which is a big boon. This was some of the criticism they kind of felt; they’re a big, popular framework, and when you had stuff like Vue, and then later Svelte, come and be like “Look how much easier this could be”, there’s a kind of tension there between new developers coming in, “Are we making things too hard for them?” and whatnot.

But the reason it’s a big shift, in my opinion, isn’t just because of the fact that there’s a compiler, and it makes things easier. It’s that React was the library. We hinted at this earlier, they were the gist JavaScript thing, where you know, we don’t have data primitives… I mean, they then introduced hooks, but they were simple over easy; they gave you all the primitives up front, they weren’t progressive, they didn’t try and hide stuff for the compiler… Now they are. And I think this is a very fundamental shift in where React actually sits in the whole scape of the ecosystem. Because a lot of developers - not all developers - really cared about React transparency. React, actually, for all its warts from being a hugely used framework, massive scale, been around for over 10 years - for all that, a lot of developers like that control, understanding exactly how it worked, having that ability to be like “Yeah, this is just some JavaScript running. JSX is just some function calls.” A very kind of simple, render it, throw it away kind of mentality. And React has been on a trajectory away from it. And the compiler almost ends, or finishes that arc, where the React of now is not very much like the React of 10 years ago. And ironically for me, the React of 10 years ago is what Solid aspires to be.

Oh, yeah. I’m so with you. Yes. Yes, yes, yes. And I’m so excited for React, because I think this compiler is going to just really simplify its API again. It’s going to make it easy to use, and I think easy to understand… I think it’s just gotten big, and complex – well, “complex” is a loaded word, but I’ll use it… Complex, chunky… And this just, I think – I don’t know, it just goes back to kind of bringing things back to simple, I feel. I don’t know. I’m excited about this change, personally.

Easy, maybe.

Easy. Yeah, easy

Because I don’t think the compiler actually makes anything simpler. That’s actually the point I’m trying to drive home.

Okay.

Yeah. I’m confused on that… I’ve heard of the compiler, and I’ve heard of the examples of it, like, making it easier because you don’t have to use memo, or use callback, or things like that. But as far as my knowledge goes, that’s where it ends. Is it doing anything simpler than that to fundamentally changed the way that I would interact with React?

[00:37:57.06] Well, I mean, because you don’t have to worry about that, that does reduce the API surface, in a sense… So then it is maybe easier in the sense you’re not thinking about these things. I was more kind of just getting at that there’s always a trade-off when you opt into another level of abstraction there. Solid is not the most hardcore on that side, React is not the most hardcore on the other side, or whatever… It’s just the scale of things. And finding the balance is really tricky. And the one thing that is, in my opinion, always true is you can always make something easier by adding another level of abstraction, but making something simpler is really hard.

But it’s not going to do something like bring React closer to Solid in terms of like “This is now a function that runs once”, and you’re going to fundamentally change the way you think about that.

No. React is still React. They’ll try and reduce the number of rerenders automatically for you. In some cases you might still have to actually help it along a bit. No obstruction is perfect. But generally speaking, that’s why it’s good for React, because React – this is their vision. They want to keep with that vision of rerender, and… They’re just doing it better now. That’s the idea. They’re cleaning it up.

Fundamentally it’s still the same lifecycle, it’s just more streamlined. So this is fascinating, and hopefully, everyone, we’re going to have a chance to talk to the React team about this. This is like a huge shift, and I’m very eager to hear from them as well, their thoughts on this.
Getting back to our Solid and reactivity principles… We’ve mentioned Signals a lot. We had the Angular team on maybe a few months ago I guess now, talking about how they’ve incorporated it into their framework… You’ve been called the CEO of Signals. Signals is a huge principle here in this reactivity world… So Ryan, can you just break down, like, what are Signals, for folks who may be completely not familiar?

It’s funny we’ve gotten this far without actually saying that.

I know, right? I know. We suck. I’m sorry, everyone.

I’ll admit, I have no idea what a signal is. It looks interesting, but I have no idea what’s actually happening.

Okay. It’s always hard to come up with the one sentence line for people, because whenever I describe it, people are like “Oh, so they’re an event emitter.” People are familiar with events. But what Signals actually are is they are a directed data graph. And it’s because you don’t just make one signal, you make multiple Signals that listen to other Signals, and effects that run off that… And you basically make a graph, not unlike your component graph that you have when you use a VDOM library. But this is about data dependencies. Kind of like hooks even; you know how you have the array in React, and then you know what that hook depends on. In the case of Signals, we use autotracking, so you don’t need that array. And when you access values under a scope, it creates a dependency, which means whenever any data under that scope updates, that thing will run again.

And the reason Signals are interesting these days is because they come with guarantees. They execute synchronously. They make sure that on any given change, they only run once. This offers a level of predictability, which might have not happened before. You don’t have this problem with things bouncing around; you don’t have this problem with updating two things, and then part of it propagates and then part of it propagates again and it runs twice. Things are batched together, they run in a reasonable order, and you get a system which is all concerned about how data propagates through your application.

[00:41:39.09] And if you’ve heard of this before, a lot of state libraries, even in React are Signals libraries. Things like MobX. You might have come across this in the past when you’re managing state in React. But the reason that people are interested in it right now - and it is largely from the influence of Solid, and we can talk a bit about the further impact of it - is the idea that basically you can use this whole system to manage all the rendering in a very, obviously performant way, but also a very understandable way. It’s easy to see compose, not have to worry about rerenders etc. And this comes with a lot of benefits that are I think perhaps more obvious to say framework authors at first, but then once people start authoring with these patterns, they start being able to almost make sense of their apps easier with this model.

Yeah, that makes tons of sense. And thank you for that wonderful explanation. I’ve never really thought about it as a directed data graph, and I’m like “Yeah, that makes so much sense, actually.” So we’ve seen Signals kind of – I’m calling it Signals-Signals everywhere. Literally, it’s just popping up everywhere. Even Lit’s starting to – there’s something in Lit Labs, they’re working on a Signals integration for Lit, we’re seeing it in Angular… So can you talk about this proliferation, but also how Solid made it – I feel like just Solid being the spearhead for this is fascinating… And to the point where now we’re also seeing – there’s a proposal on the web platform to add Signals as a new primitive for JavaScript. That’s huge. And I know you were somewhat involved in that effort, or there was a committee… And I think Rob Eisenberg and Daniel Ehrenburg are the champions for that… And we’ll link that in the show notes for anyone who wants to see it. We hope to maybe do a show about it… But anyway, so Ryan, talk to us about all this.

Well, yeah, I mean, this is one of those things where, as I said, I think it caught the framework authors’ eyes before anyone else… Because I was out there, publishing Solid, doing good in benchmarks back in 2018-2019, and I started writing articles about it, and getting it out there, and talking about just mechanical things. Not just like – basically, how this approach to rendering heads solve the problems of the past. And at a certain point – I mean, I don’t know the exact catalyst of it, but other frameworks started looking into this. At first, maybe just to differentiate themselves from React. Preact was one of the early Signals adopters, out of kind of like the more known frameworks. Qwik decided that they wanted the resumability to be even more fine-grained, so they added it. Resumability actually depends a lot on reactivity in general, but they’ve got Signals because they wanted to be able to ship even less code.

And I’m trying to think here, but just like the Angular team were looking for an update. I first started talking to them I’d say probably in 2020… And they were looking at the future of Angular and seeing where they could go, and they had Zone.js and this dirty-checking approach, and people were using stuff like Zoneless, with [unintelligible 00:44:58.08] but they were hitting all these weird timing bugs because of like the maybe async nature of stuff like RxJS. And they really just wanted a synchronization system, and that’s what Signals gave.

And over the course of I’d say six months, we just saw this huge proliferation of – Vue announced Vue Vapor, which is basically… They already had Signals, for people that don’t know. Composition API in Vue is a Signals API, that they released… When did they release that? Like 2020, I want to say… But they had reactivity before that, but they decided that they were going to actually make a mode that compiled like Solid does, so they could get the benefit from the extra performance. And Svelte - that was one that I wasn’t expecting, because at the cost of making things a little less easy, but definitely more powerful, they introduced runes. And Svelte 5, which is probably coming out pretty imminently here, which also compiles to basically the same thing as Solid.

[00:45:58.15] So between Vue and Svelte basically now outputting the same approach that Svelte has been using for like the last six or seven years, and between all the other frameworks picking up the Signals for the DX reasons, like just being able to have an easier to manage state, and make it more I guess predictable, we’ve gotten to a point where almost every JavaScript framework is using some sort of Signals, at if not core, like first-party level. You mentioned Lit integrations… Honestly, the list just goes on and on. I feel like I’m missing people. Just name any framework and it’ll be a Yes, except for React pretty much at this point.

Yeah. Well, I would say vanilla JS is getting it too, right? Because it’s getting added to the platform, you know? Yeah, so can we talk about the platform? To me, this is just fascinating, to actually have this low-level directive added to the platform… Huge, but also awesome. And also, like, who’s going to use this? Is this for library authors? Is this for regular old Jane and Joes? Who’s this for?

Yeah, I mean, this was a tricky one… And they did a very smart thing by getting the group together initially that they did. You have to understand that sometimes the framework authors are not always - well, how should I put it? Were always maybe a little bit suspicious of web standards. There’s been a lot of efforts over the last 10 years or so to almost build a framework into the browser, with a lot of the Web Components stuff… And it’s been kind of challenging, because these are very ambitious proposals, that kind of in some ways you might say bypass the frameworks, but in other ways don’t cover the use cases. So we knew with Signals that we wanted to make sure that there was some amount of agreement. And having seen this proliferation already happen, the framework authors were already all in communication with each other. I’d met with the guys at Angular at various points, and Qwik, and Wiz, and all of them, and we were already talking about “Could we use the same Signals implementation?”

And yeah, Dominic and Svelte we’d been talking as well, and he was the one who was actually close with Daniel and the TC39 thing. So almost immediately –

This is Domenic Denicola, right?

Dominic Gannaway.

Okay, okay. Just clarifying.

The original author of Inferno. Yeah. And now did a lot of the heavylifting for Svelte 5 and the runes implantation. So this group that came together to discuss this last fall was basically all the people I just listed, plus people from Ember community, people from Vue. We had Preact. Almost everybody was involved at some point in terms of just on the framework side trying to figure out what we could agree on. And the interesting thing is the core Signals and computed values or piece we actually mostly agreed on. The part that we knew was going to be hard was the side effects. Because every framework has different ways they want to update, and schedule… And we decided for our initial proposal here just to not really include that. Have the ability to create your own systems to be able to do the effects. But basically, just for the most part put out Signals and computed values… Because - I’m not saying someone would do this, but you could very easily… And there’s actually a library called Reactively out that does this. You can basically pull the data without using effects, with like a set interval or something, and it’s fully functional from a Signals perspective. Because the key part of Signals is just having that data graph. So as long as you know when things change, and how to only do the work that’s needed, you could basically ask for the values whenever you want it.

[00:50:01.03] I didn’t talk about this before, but one of the key differences between a lot of the Signals implementations and like RxJS and other reactivity - it’s actually a push-pull hybrid. You don’t just notify people like events. It’s all about actually reading the values. So we actually completely agreed on that. The challenge is, this is suggesting that we need wrappers right off the bat, because everyone’s gonna have their own effect approach, right? Every framework. And in the case of the APIs, Signals are an interesting thing, where while the framework needs some extra data, especially if it wants to do complicated things, like walking the graph, or concurrency, or different use cases, hydration, serialization, resumability… I didn’t even talk about the impact of Signals on SSR. Whatever. My point is, the end user usually doesn’t have to worry about any of that stuff… So it’s very difficult to have an API that we put out there, even for the Signals themselves, that people are just going to pick up and use, because it’s going to just have extra stuff, and be clunkier. And there’s different philosophies between different frameworks. Svelte doesn’t want you to actually ever hold the signal. They use Signals and runes, but you never actually hold it, so to speak. It’s compiled away.

Solid, actually, funnily enough, has a similar philosophy in that everything’s just a function. So again, we don’t want you to worry about all these details, just call a function. So the API surface on this proposal - it’s very difficult for us to ever come to a point where it’s just like “Yes, this is what everyone should use and be interoperable.” We’re almost all expecting ourselves to wrap it. And I think that’s very interesting for something in the standards, because when you have other standards, putting a pre-made framework basically, in the browser - this is kind of at odds with it, because people are like “Well, make an effect. Make this just work with the DOM APIs.” And if you do that, you’re kind of assuming a lot. And I think it’s very difficult for us to make those assumptions for the future.

Yeah, you just highlighted so many things, Ryan… One being just kind of – yeah, there’s still a lot of alignment that needs to happen in like how this is supposed to work… And it’s worth noting this is just stage one. So it’s gonna take a long time to move through all the stages. And in order for that to happen effectively, this is what the work of the champions – this is what they do. They’ll be working with folks like Ryan and other framework authors, and people not just on the library author side, but other people, just software engineers, writing web apps. They solicit feedback, you can also give feedback… So anyway, so we’ll link this in the show notes, and I think once the proposal is further along, we’ll invite them to the show. It’s probably a little too early to have a productive conversation about this now, but thank you for walking us through that, Ryan.

I tend to go deep, I’m sorry. But yeah, we are at stage one, so this is a good place… It’s open, people can talk about it, which is really what we want.

Exactly, exactly.

I was gonna ask, I do have one question around this - and please correct me if I’m wrong, because I might totally just not be thinking about this correctly… But the way that I see this right now is like 10-15 years ago we had promises everywhere. We had Bluebird promises, we had the Promises/A spec, we had all of these different – you know, dojo deferreds, jQuery deferreds, all of these different things. And then we got promises as like a part of ES6. And having it as a primitive that was in the browser, or in the language, led to things like async/await, and all of these side effect ways. Are there things like that, that we could possibly anticipate with Signals becoming a primitive in JavaScript?

Yeah. I mean, that’s the hope here. There’s one side on the syntax side, which you mentioned, async/await… Which, it’d be nice if we had ways to actually natively handle Signals maybe not so bulkily, if there’s some syntax for it… The other side of it - and this also promises is a great example of… When you debug in the browser, you can track through the async/awaits now. You go in Chrome Debugger and you set a breakpoint. You can walk through the then, or the await, and actually see the context of how everything runs. That kind of ability for debugging with Signals would be a game-changer. That’s one of the pieces I’m most excited about.

[00:54:29.11] I don’t care as much as if everybody’s libraries necessarily all work together, because it’s a hard problem… But if we can all be able to leverage the tools built into the browser, it would be such a win. Because if there’s one complaint about people with this stuff traditionally, it was “It’s hard to know what’s happening when stuff can execute anywhere in the tree.” But on the other hand, with good developer tooling in this area - and we’ve already seen this to a certain degree [unintelligible 00:54:55.25] this knowledge of the data graph stuff is like a superpower. You can go “Oh, I’m updating this, and I can see that it updates this thing right over here.” And that ability to leverage this would be incredible. I mean, once there’s that foundation for things… It’s interesting, because sometimes if you’re popular enough, things will get implemented for you. When the tuples came in React hooks, suddenly browser performance for destructuring tuples was improved in all the browsers. And that’s just from sheer power of popularity. But getting these standards takes that to a whole new level. I’m very excited for the future of Signals here when people understand that it’s a thing, because there’s so much more you can do with the tooling, as I said, when you know how data goes through your apps. Picture the developer experience when you can actually go “Huh… If I set this here, what are all the points in code that could be affected by this?” We can know exactly what updates when you set some kind of value. The tooling at every level has – there’s just so much we can do.

Yeah, and I was hoping we would get into some of these real world use cases, because there’s a lot more to the… There’s like the surface things that I think everyone knows that this brings to the table, and then there’s all this other stuff that you won’t even think about, like DB updates… You updated a field in the database, and it updates something in your UI automatically. That’s the kind of clean handshake that you can achieve between the stack… And just stuff like that. But before we get into that, I want to just – you made me very curious about something that you said… So how does Signals impact server side rendering, Ryan?

Well, the funny thing is - and I don’t know if people know this… I worked at eBay for a few years. And this was the turning point for me and Solid, because it’s when I finally decided to pick things up. I was working on Marko, which is their framework at eBay… They’d read my articles, and the team there was like “Ryan is working on here. We’ll actually improve the performance of initial page load at eBay.” Like, eCommerce. They didn’t care as much about update performance, they just wanted to make sure that the pages could load as fast as possible, and we can load the least amount of JavaScript. And what was kind of realized was if we knew the data dependency graph, then we can know what changes and what’s static. And Marko’s an example of one of those really heavy compiler frameworks, similar to Svelte. A lot of compilation going on. And we’re like “If we can use Signals or build them into our language, then we can basically tree-shake out the static parts.” Think like islands, like Astro, but automatic. You don’t have to set the islands. Server Components is another one; you don’t have [unintelligible 00:57:47.15] We just shake out all the parts that don’t need to ever be updated again, and only minimally send the code for the stuff that does.

[00:58:01.05] And in a lot of ways, Qwik and resumability also took a page from this book. Initially, for them, they just lazy-loaded everything, and they didn’t know definitively if something would ever get to the browser or not. But because of people writing their code in a signal way, like seeing the data dependencies, connecting the dots like this, and because the execution, again, doesn’t need things to rerender, it doesn’t need it to rerun, the stuff that doesn’t rerun - well, it can run once on the server, and not have to ever go to the browser. And you can tell that through static analysis and compilers. So even though it’s a performance gain in terms of like updates, it can actually be a huge performance gain for creation and initial page load. It’s like the trifecta, so to speak.

That’s wild… And we’ve mentioned lazy-loading and resumability a bunch already, so I hope we can get into defining it in just a second… So we’ve talked a lot about Signals. It’s kind of the core principle here behind what’s enabling all this reactivity. But it’s not just about performance, right? So there’s this whole – you’re separating out the creation path and update path, which comes with a bunch of other really cool side effects… For example, rendering performance goes up, because your create path is a lot more optimized, similar to what you were just explaining… Your complexity scaling is – your app doesn’t get slower the more components you add, or the more JavaScript you’re shipping. It doesn’t scale linearly in that way. And then the hydration stuff that you talked about, right? The lazy-loading and resumability. And then obviously, no crazy hook rules… So there’s a bunch of other kind of principles… So maybe we start with the resumability piece a little bit, and some of the benefits of reactivity being hydration, and being able to have that control.

Sure. Yeah. I mean, the big one for this one is that if you’re not going to run your code initially, when the page loads, that’s a big performance gain. Like, even if you load the JavaScript, not running it, to block interactivity, it actually has a big impact. It’s not just about how fast the page shows up, especially with people on slow connections, it’s about how fast they can interact with it. Because often, if you can interact with the page before it loads, one of two things are going to happen. It’s going to either lose your clicks, and you get frustrated and be like “Why is this not working?”, or it’s going to have progressive enhancement, which is generally a good thing, because it’ll work. But I always feel bad for the – and this is something we thought a lot about at eBay, when we’re talking about global eCommerce… I always felt really bad for the people in that situation, because it’s a no win. Because even if you click on the button or the link, and it works now, you’re now going back and doing a full page reload, and waiting the whole time again. Whereas they don’t know – if they waited another half a second before clicking, maybe the JavaScript would have loaded, and it would have done just a quick client-side thing. So if you can just eliminate that whole hydration side of it, the experience can be considerably better, especially on low-end devices and slower networks.

And in order to not run the code - sorry, getting back to the Signals part - you kind of have to know what to wake up when there’s an interaction. You don’t want to just defer hydration; you don’t want to just be like “Okay, I’m not gonna do anything now. But now when you click on it, I’m just going to block everything and hydrate the whole app at that point.” That won’t do any good. You want to be able to be like “Oh, I know I actually only need to run this small bit of code.”

So Signals became a big part of this both for the granular ability to wake things up without running it the first time, and because it’s a data graph, if you can serialize it, if you can send it across from the server to the client, then you can kind of just wake up in the same state you were in. And since it’s just putting data in the graph, so to speak, it’s just an easy way to serialize the internal state of the framework.

[01:02:09.26] So in this way, using Qwik as an example, you can interact with part of the page, and then if you click a button like Add to Cart, it knows that it’s gonna be adding – due to the reactivity, it knows that at point “Okay, now is when I need to actually run the code to update the shopping cart count”, or whatever.

So these techniques – this is why also Wiz from Google is very interested in it… Because some of these frameworks were doing stuff like this, and Signals is just like a built-in - well, potentially in the browser - primitive to be able to just configure this kind of communication in a predictable way.

That’s so powerful. I feel like we need like a whole show just to unpack this… I don’t know, what do you think, Nick? It’s pretty mind-blowing, right?

Yeah. I mean, there’s just so much here. I mean, honestly, a lot of these things we’re talking about are performance things. But there’s this impact that people don’t always see about performance. And I want people to understand this - having good performance alleviates pressure on you achieving the UX you want, right? Basically, if the performance of what you’re building is not good, your developer experience is going to suffer at some point. Maybe not initially, because you just wrote it up. But once you have to go in and actually fix the problem, everything gets considerably worse for you as a developer.

So what I’m getting at is if performance matters, and you treat that as a mindset, then there’s a whole bunch of stuff that you have to do, that you might not be doing already in your framework. For example component boundaries matter in React in terms of what reruns and what updates. Whether you memo-ize them or not. But also just like where you break them apart. If your framework isn’t governed by how you lay out your components - and as I said, most frameworks, any ones that do dirty checking, or whatever, they do matter, like the size of your components or where you break them apart, or where you put the state. These things matter. You suddenly just don’t have to worry about it. This is a huge DX lift; even though it’s performance that drove it, suddenly you’re not worried about it at all. You can arrange things the way you want to arrange them.

So all of these pieces here just – and I guess this is why it might be obvious to the framework authors… We spend so much time trying to get people into the pit of success. We want people to be able to just write what they want to, and then have it be performant, and them to be satisfied. If we just get that performance essentially as a baseline, we have so much more room to improve the developer experience.

Break: [01:04:51.10]

So in addition to everyone starting to slowly adopt Signals, there’s also just this general convergence… You’ve seen the Spiderman meme, where everyone’s pointing at each other… It really feels like everything is starting to sort of work the same, and I’m wondering, is there a future where it’s gonna be “What syntax do you like?”, because ultimately these things all work the same…? That would be nice.

I mean, with Solid, Vue and Svelte it might be that in six months.

Wow.

I mean, there’s some different features that we have, and obviously, we’re always evolving. Solid’s spent a lot of time on Signals. The current version of Solid has more or less existed since 2019, where Vue and Svelte 5 are coming into it this year… But on a base level, that is what it’s going to feel when you pick up you Vue Vapors, Svelte runes, or Solid. You’re gonna be like “These are all basically the same thing.” So do you prefer dollar signs, do you prefer dot value, do you prefer calling things as functions, or whatever? That’s kind of the difference. We’re obviously going to continue to evolve this, but it’s interesting that sometimes when you have this innovation in this manner, it actually causes things to just consolidate. But despite all that - opinion. And this was one of my biggest things I respect about Rich Harris. He understands this way before I ever understood this… Things like these opinions, or bike-shedding, or how it aesthetically feels will always be different for people, enough that people will continue to choose based on like those facets, even if things start to converge like this.

That makes sense. It makes perfect sense. Yeah, I mean, this is an exciting future. I don’t know, Nick, I’m eager to hear about some real world use cases. How about you, Nick?

Yeah, I’m also just really excited about all of the future good debugging, the good – it just seems like developer experience is just going to become so much easier and better around all of the frameworks… So that’s really exciting.

Yeah. Real world use cases. Okay, so when you say that – I mean, we could talk about a couple of types of examples here… But what were you thinking?

Oh yeah, sorry. So basically, it’s not just perf, right? Like you said, it’s not just the performance improvements that we get to leverage, but there’s a lot of other things that shake out. We talked a little bit about the resumability stuff… There’s all these other benefits, like being able to – I’ve seen you mention this before, you mentioned that you have an IDE that links to everywhere where you update said state, for example; being able to have that traceability throughout your app is another benefit for using Signals…

[01:12:17.26] Okay. Yeah. I think I follow you. That one doesn’t exist as of yet, but I can see how it would be possible. And actually, it was [unintelligible 01:12:23.24] who was basically talking about this. He was very excited about Signals for a bit, and he was like – because someone had brought a Signals port to Rust, in a framework called Leptos, which is almost identical to Solid, but in Rust. And so it was in his language, and in his place, and he was talking about basically using stuff in the IDE to be able to trace it. I don’t believe anyone’s built that. But a more common, practical thing - library writers. I work a lot with Tanner Linsley, who creates the TanStack. React location – or I guess it’s now called TanStack Router, TanStack Query, and numerous other libraries. And one of the interesting things for him was trying to figure out how to manage state. And you’re like “Why do you need to manage state? Because these are these universal libraries.” But even if you’re dealing with data fetching or whatnot, he builds dashboards, and large tables, and very interactive stuff, and he builds tools so people can use it. Quite often, when he was working with stuff for React, for example - and all his libraries work with React - he’d be in this interesting place where he couldn’t use React state primitives and context because they weren’t efficient enough. And this is a common case. Things like Redux at one point switched to using pure React context with set state, and then they realized it was too slow, and they went back.

Basically, anytime you write any kind of state library with React, you have to basically make your own external state management, and then have that feed back into React’s update cycle. So yeah, this was one of those challenges, because then React had a concurrent mode. And this meant that now you use external source. Basically, you had to jump through even more hoops to try and get it to play nice on the React side. And it got to – I mean, I’ve seen this; this is probably why a lot of the people who seem to be the most critical of things like use effect, or people who write state management libraries for React, like XState, TanStack Query. You see a certain trend here. And it’s because they’re basically pushed into being kind of like this outside second-class citizen.

And one of the cool things, one side, when you have a framework that manages state, it means that yes, each version of that plugin for the different frameworks are going to need to use that framework state. But because there’s a set way of doing it, you just adopt it in. And ironically, if it wasn’t for React needing to work the other way, and since it’s the most popular TanStack library, Tanner could have just like basically just pulled in Solid’s version for Solid, Vue’s version for Vue, Svelte’s version of the state management primitives, and just like not have to ship all this extra code with the library. And this has been one of the big challenges, because when the state primitives understand concurrency, when they understand the pieces - because they’re built into the framework and they’re completely exportable - then you are giving those powers to the library authors.

In Solid we have something called create resource, which is a basic async primitive. But when I say basic, I mean it handles data fetching, it automatically serializes for SSR, and it automatically triggers suspense on the server and client, so it automatically does out of order streaming… Because the framework knows this. All Tanner and group have to do is just make TanStack Query wrap that create resource, and then suddenly it works in all of those functionalities. Suddenly, you just take Solid query, which is the TanStack Query version for Solid, and everything above works. Out of order streaming, automatic data serialization… The whole suspense, the whole transitions, the whole thing just works.

[01:16:24.17] It’s hard just me saying it, the impact of that, but when we added server functions - they’re called server dollar sign, but now we use server like React does for syntax; sometimes it’s easier to go along with them. Those just fall right in, too; all the pieces just compose in the third party, because they’re all built with knowledge that the other pieces exist. And that’s sort of what I mean by primitive design. It’s a real case where Solid query ended up being so successful there that the TanStack Query dev tools, the one that everyone installs, the ones for React, Svelte, Vue, are now actually built in Solid. So yeah, it was a good use case for us.

Yeah, I can see that interoperability also being good for teams working on really large web apps, that own different pieces of a thing, too. It just makes everything easier to integrate. Super-cool. So yeah, I think we’re gonna pivot to like talking about a less fun topic before we wrap… So I’m really curious to hear about what you see as like adoption barriers. Because with React having so much momentum, and first player – they weren’t even the first player, but there’s just so much adoption… And then there’s also a corporation that’s attached to it, which, similar to Angular, it gives it this huge sway in terms of other enterprises feeling “comfortable”… What do you see as an adoption barrier for libraries like Solid ?

I mean, yeah, how do you compete with that? I mean, you don’t. When I first started out, I wasn’t worried about adoption, so it was very easy for me. I just built what I thought was the best possible thing I could build. And then over time I just kept on building it better and better, hopefully becoming more obvious to people. But the truth of the matter is, even if people would want to, so much of the ecosystem is already locked in. Even if you could picture perhaps that every aspect that I’m telling you today improves on what you’re used to in every possible way, I know that won’t be enough.
This is one of those things that you know it’s unfortunate, you know it’s like a David and Goliath type thing… We just continue doing what we’ve always done, which is to innovate. And the more people who come on, slowly, surely, as long as they’re enjoying what they’re building and they’re getting what they want out of it, that makes me happy… Because as long as I get to keep on doing this, as long as I get to continue to push the boundaries… What we’ve done as a community, the way that Solid has impacted the frontend, I would say this changes Signals. We haven’t seen something so revolutionary since the virtual DOM first showed up 10 years ago. And this wasn’t coming out of Meta, or some large company. This was completely grassroots. And it went on to change the whole shape of the frontend ecosystem. So we did that. And even if big corporations will take their time and be careful, because they should, that’s just the kind of reality.

Because for a while there, I was thinking – you know, there’s always that checklist… And I worked in b2b for a while, so I’m familiar with that on like the enterprise - or I was in the education side - of where there’s just this neverending checklist basically to keep the big players in. That checklist never finishes. When Solid first came out, it was like “Oh, maybe when it’s 1.0. Maybe when it has this feature”, or “Maybe when there’s a meta framework”, or “Maybe when it can do mobile, or universal rendering.”

[01:20:12.17] And the truth of the matter is we’ve checked out all the boxes, one after another, as things have come on, and people will be able to move to do new things, exciting things when they can, or they won’t. So yeah, I think the biggest thing for us in the community was it’s never been about that. It couldn’t be. We showed up way too late if we were going to win people over on popularity. But if our ideas succeed - well, that’s something.

Yeah, it’s a huge form of success. And there’s so much growth that’s happening with Solid… We don’t have time to get into it today, and we’ll hopefully have you back in the future… But Solid Start is a meta framework that you all are releasing. 1.0 is gonna be out soonish, or in the near future… Can you just give folks just a quick preview on what it is and what problems it’s solving?

For sure. Yeah. Solid Start - this is one of those things on that list. Everyone’s like “We need a meta framework.” We’ve been working on it for almost three years now. I wasn’t happy with it on several iterations, but we’re finally getting there. It’s just one of those SSR frameworks, like SvelteKit, like Next, Nuxt, you name it; there’s tons of them. But it’s Solid-focused, built with Solid primitives in mind. We really like our data loading, it keeps our granular story… We have really cool features, like single flight mutations, we even are working on – we have experimental support currently for islands… There’s a lot of features so you could create the type of Solid.js app you want… But yeah, I guess the truth of the matter is for us it continues that philosophy based on primitives. It’s less about the polished product, and it’s more about just having the building blocks you need… Because you can build everything from a single-page app, SPA, Create React App kind of style, with no server, all the way to server rendering, all with the exact same APIs. And you can incrementally add every feature as you want. And it actually doesn’t ship with most of its own libraries, it actually just uses the existing libraries in the ecosystem. It’s actually Solid router-agnostic; you could bring your own router. It’s a different type of meta framework that really focuses on what’s important to us with Solid. So yeah, I’m very excited, and I’ll be excited to talk about it more in the future.

Oh, a meta framework without an opinionated router? This is revolutionary, Ryan. You’re setting some new boundaries here. This is like “Whoa”, you know? And also, it’s not just server-side rendering; it handles like static site generation, and client-side rendering as well… So yeah, that’s cool.

Yeah, so hopefully, we’ll have a whole show on Solid Start in the future. It’s pretty cool. I think Ryan is being very humble about it, because it’s actually very, very full-featured, and so very cool for anyone who’s thinking about adopting Solid and were kind of leveling up their implementation of Solid.

So anyway, so we covered a lot of ground today… I feel like I have like 17 more things that I’d love to discuss, but we’re kind of already out of time… So I don’t know, Nick, any final questions or thoughts from you before we –

Yeah, I feel in a lot of ways the same as I did a few years ago when you were on, Ryan. You’re just blazing trails, and changing this environment for the better. And I’m really excited about all of these primitives coming – or this primitive coming, and the ecosystem built around it, and just the changes that are going to impact everyone. I’m really excited about it.

[01:23:42.15] I’m glad to hear it. I hope everyone can get involved with this. It is really exciting.

Yeah, totally. And so Brian, I’m gonna ask you a big philosophical question to end with… Because you know, we haven’t talked enough today already… Which is “What’s one thing you want everyone to walk away from?” If you could talk to every single person writing JavaScript on the planet, and imagine they all spoke English - because they don’t; but you know… So what would you want them to know?

That is a big question. Just give me one second to think about that one.

It’s okay. We’ll put the Jeopardy music on… [laughs]

Yeah, okay. I guess I’ll go with this one. I mean, what it comes down to in the end… The tools don’t actually matter that much. I think that the important part is that we can successfully get our projects out to people. So I want to make sure that we can continue to progress, that we can continue to learn and expand on how we do that… So that’s what I’m hoping we can accomplish here more than anything. So yeah, if there’s something that you think is a good idea, try it. You never know. That’s all I did when I started, I just built something because I wanted to, and then it became this.

Wow. That’s a good mic drop, Ryan… Good job. Good job talking to all the JavaScript developers. And with that said, I just want to say thank you so much for coming on the show today, thank you so much for educating us. You really are paving a very cool path forward for the future of JavaScript, and impacting so many people’s patterns and thought processes… So it’s just really very humbling to listen to you and just to see the impact of your work and the work of the Solid.js team. So thank you all so, so much. Where can folks connect with you? How can they join your community, and all the things?

Yeah, definitely. Discord is the big one for us. The Solid.js Discord is where we do most of our conversation. Obviously, GitHub and GitHub Discussions as well, and you could follow me or Solid on Twitter. And if you really like nerding out on stuff, I do stream almost every Friday, about various topics… I don’t just talk about Solid, I talk about all stuff across the web, and web technologies. I have lots of guests on, and we get really into the details, in the way that I would, if you could tell from the stream, if it’s any indicator… Yeah, so check it all out.

Yeah, definitely. So we’ll link to all those things. Many thank yous again. Thank yous with a z, or s, I don’t even – anyways, thank you, Ryan… And that’s all for this week, everyone. We’ll catch you next week. We have a really fun show… I’m not going to spoil – actually, Jerod will probably spoil the surprise for you all, so I’ll let him do it. Alright, cheers, everyone. Bye-bye!