EPISODE 1686

[INTRODUCTION]

[0:00:00] ANNOUNCER: SolidJS is a popular JavaScript framework known for its reactive and efficient rendering system. Instead of using a virtual DOM, it compiles its templates to real DOM nodes and updates them with fine-grained reactions. Ryan Carniato is the creator of SolidJS, and he joins the show to talk about the framework.

This episode is hosted by Taylor Nodell. Check the show notes for more information on Taylor and where to find him.

[INTERVIEW]

[0:00:39] TN: Hi, Ryan. Welcome to Software Engineering Daily. Can you share a little bit about your background and how you got into web development and programming?

[0:00:47] RC: Yeah, sure. I mean, I got into programming, because I wanted to make video games when I was really young. I got into web development, because I was trying to make websites for my band. I played in a punk rock band, and I wanted to advertise it. This was the early days of the web, like '96. I've learned HTML and some rudimentary JavaScript back then.

[0:01:11] TN: Was it just like a basic static site that was like, "Hey, here's my band. Come see our shows"? Or, what was it like?

[0:01:17] RC: Yeah. I'm talking tables, just all tables with images in them. I did a little bit of fancy programming. There was a CGI bin and I wrote a Perl script for our guest book, so people could add comments and then show up.

[0:01:31] TN: That's pretty cool. For '97? Yeah, yeah.

[0:01:34] RC: I mean, it was a good introduction to this stuff. I'd been the local computer fix electronics guy when I was a kid. It was very natural with the dawn of the web for me to start making websites. The next thing I know is local businesses and friends of mine stayed in that contracting thing, but I was too busy with school and my band.

[0:01:59] TN: Okay. Fast forward a couple of years. In 2018, you create SolidJS. Can you give us a high-level introduction to SolidJS? What specific problems, or challenges did you aim to address when you started the project and how have those motivations evolved over time?

[0:02:13] RC: Yeah. In order to get there, we have to go back a little bit before 2018. I was doing web dev through, I'd say, professionally through most of the 2000s. I got back to this JavaScript-centric, single-page app thing right off the gates around 2010ish. For me, there was a library called Knockout that was my tool of choice. I felt refreshed. Again, I've been doing .NET. I've been doing all this heavy, bulky server rendering partial thing. It was really nice to just go write JavaScript into Notepad++ editor and just get back to the web as I remembered it when I was younger.

I was really into it. I liked the patterns. I'd make games for fun, like little Sudoku and different types of puzzle games, because the reactive model that Knockout had presented was really powerful. I'd just set the rules once and then the program would run itself, basically. It was based on this idea of reactivity, where you had these reactive atoms, like data that you could set up, and then you could listen to it and react to it simply by just accessing those values inside another function. You could just write your whole thing out in front of you and you could just see it and then it would just run.

It was very different at the time and I just fell in love with this pattern. Unfortunately, the library fell a bit out of the wayside. Other libraries came out, like React. I was never quite onboard, and I wanted to bring back these patterns. Around 2015, I started my exploration there. Made the first version of what would become Solid. At summer 2016, kept on tinkering away, looking at benchmarks, wanting to prove that this was a viable direction, because people really gone into this whole virtual DOM, re-render everything on every change mentality, and this was not that. This was where you just ran once and then just little things updated fine-grained exactly as they needed to.

Yeah, 2018 was an important year for the project, definitely, because that's when I open sourced it, but it was mostly because I'd finally gone to a point that I wanted to put in public benchmarks. I wanted to show that the performance was good and that it was an option. Yeah, I think April 2018, I open sourced it, entered the benchmarks. JS Framework benchmark, probably the most popular one, the one with all the colors, splotches people might have seen before. Rest is history. We got pretty much to the top of that benchmark almost immediately and we've been up there ever since. I guess, it was, yeah, quite a while ago.

[0:04:50] TN: Yeah. Can you compare the paradigm of fine-grained reactivity to the virtual DOM refreshing everything on the page and why that causes an increase in performance?

[0:04:59] RC: Mostly, it's the old comparison. Again, I'm a graphics programmer background. There's this idea of retained mode versus immediate mode. One model is meant to be viewed as being more simplistic in that this immediate mode, where every single frame it re-renders everything. Then you don't have to worry about any persistent state. You don't have to worry about anything. It just handles itself, because you know that anything changes. It's just going to redo everything. As it turns out, redoing everything is not the cheapest thing to do. Even if you can make it cheaper using a virtual DOM instead of a real DOM, you're still going through and constructing these objects in a first pass and then diffing it and then seeing what changed.

Whereas, the DOM, interestingly enough, is a retained mode API. It's something that sits there and you mutate it. It's a very natural fit for reactive systems, where you basically, as I said, set up the relationships, set up the rules, like a spreadsheet. Then when one cell changes, well, you know which other cells depend on it and you just do the work there. In the case of something like the DOM, it means that you update some text, maybe an account somewhere. I know this is a trivial example. Then somewhere else, the text in the DOM updates and nothing else reruns.

Yeah, there's some overhead there on constructing the graph initially, the memory. But on the update performance is really fast. A lot of my early work into Solid was figuring out how to make that creation cost also very fast. That's when we solve that problem, that's really when we could show it's viable from a performance standpoint. Keep in mind, it wasn't performance why I got into it in the first place. I just really liked the patterns. It was clearer for me. I know not everyone agrees with this necessarily, but it was clear for me to actually just set up these rules, make the data special, and then just let it run.

[0:06:59] TN: Yeah, for sure. That's like, React has this virtual DOM model. When you're coming from a React, or a virtual DOM model, JavaScript framework, and then you're looking at Solid, what is the change in the developer experience when you're coming from this other world and you're looking at Solid for the first time, what problems do developers, or issues, or things to look out for for developers coming into Solid, what should they look out for?

[0:07:21] RC: Yeah. I mean, the biggest result of this change is that components aren't special in Solid. They are just a function that tends to run once. This is very different. Where in a virtual DOM library, the components are the universe. They own state. When you set some update on it, it'll cause it to rerun that function again. You don't see it necessarily with hooks as clearly as you do with the class components, but there's this mentality of these units that own their own state that rerun. Whereas, in a reactive framework like Solid, you can create reactivity in the process of running the component the first time, but the component generally never runs again. It's the specific interactions inside.

This is a thing that does catch React developers off guard, because they'll do something like, I don't know, try to put an early return, like an if statement in the middle of the component. It's like, no, this doesn't run again. If you want something conditional, it's more that the thing you return has to be conditional. For example, that could be just JSX, right? If you return some JSX, that is conditional, then it can change. But an early return with an if statement, it's only going to run once. Yeah, it is definitely a departure in mental model. I'd say, it's more declarative, right? React tends to run things over and over again, so it is a very this, then this, then this, then this.

Even with hooks, which look declarative, there's still this in order. That's why order matters. That's why the hook rules exist. Whereas in Solid, you actually don't have any of those hook rules in the same way. Component runs once, but it does come off with that trade in terms of understanding that, because it runs once, things are different than React, or a virtual DOM library.

[0:09:13] TN: Yeah. I think you've explained how reactivity works in SolidJS. There's also this other component signals, one of the main parameters is in Solid. Can you explain how signals have existed within the history of front-end web development? Because this is not the first time that we've heard about signals, but they're a prime feature of Solid.

[0:09:29] RC: Yeah. I gave them a rebrand, I guess. I got that from my own inspirations, like SJS called them signals. It's mostly that early libraries that basically had the same reactive patterns called them observables. Unfortunately, for everyone, observables is also the name of RX, or RXJS reactivity, which is a completely different thing. I didn't like the ambiguity there, so I was started pushing it as a new name, even though it is the same reactive atom primitive that I was talking about that you found a knockout, basically. It's been updated over time. We have better patterns now, but essentially, knockout had it.

Vue's had it hidden behind their option API. Then a couple of years ago, they released it separately as a composition API. Different versions of it, even Felt's predecessor. Reactive had a version of this. They've existed throughout front end in one form or another. It's just, they've been serving different purposes. Reactive system doesn't really care what you do with it. It's just like, okay, it's like an event system. If I told you I had an event system and you wouldn't know what that did. You just knew that it would fire events. It wouldn't tell you what my application is. Signals is like that too. It's just a pattern. It's what you do with it that matters, and that's one of the biggest differences.

The earliest signal libraries, back in 2010, like Knockout, actually are more similar to Solid than what people have been doing with signals for the last decade. Knockout used to do it fine-grained. They used to go this update updates this one thing in the DOM, for example. What's happened with Vue and then most of the other libraries that have done pretty much all the other libraries that have done reactivity over the years, even MobX and React and all this, is they fed into those systems, virtual DOMs, or into their re-render models. It's not until very recently pushed a bit, I guess, by what we've been doing here with Solid, that we're seeing people going back to actual fine-grained rendering again.

When we came out, none of the major frameworks were taking that approach back in 2018. To this day, none of the major frameworks have taken up this approach yet, but they're all saying that it's in their roadmap. This is Felt 5 with ruins will be probably the first to launch with the same rendering that Solid does. There's also Vue Vapor that is coming out that also is the same rendering that we do. I expect to see more of this in the future.

[0:12:02] s 1Yeah, it's definitely looking at the actual DOM now and updating that directly, instead of having this virtual DOM idea. That's interesting. SolidJS has these three core primitive signals, memos and effects. Effects and memos are pushed onto a global stack before they're executed and any signal that is red checks if there's a listener on the stack and then adds the listener to its subscriptions. This makes sense in a synchronous environment. But a lot of the web depends on getting data from somewhere else. How do you handle asynchronous code?

[0:12:30] RC: Yeah. This has been one of the most interesting explorations for our work in Solid the last couple years. Getting V1 out was all about just using the patterns that I'd been familiar with. Then the last couple of years has been a lot of SSR. Once you get into SSR, async even pops up more. 

On a simple level, finding reactivity does solve async in a funny way in that you view async stuff data, fetching is data coming from outside the system being brought in. The old use effect trick on React that everyone's like, "Oh, don't this is awkward, because the re-render and all that." Well, we don't re-render. You don't even need the create effect, really. If you went in a component and created a signal and then went promise, then write signal, you'd have an async solution. Yeah, you'd obviously have to check if the signal had a value yet. You'd have to do null check.

If you think about it, it's not blocking your system until you get to that point where you do the check. Essentially, and because we only render once, wherever you read that signal, well, that's it can render all the way up to there. Then when the signal completes later from the promise, it'll just continue where it left off. That is always been super, super powerful. There's nothing to do with components. No re-render. Just literally render as much as you can, then render more when you get more. That's good. I wanted to take it a bit further. 

A lot of work that we did with Solid was looking at if we could build more interesting async models invert control. One of the more interesting things I think that React showed us was possible with the concurrent rendering wasn't all those spinning radar demos with 3D stuff, or all that performance stuff there to talk about it. But actually, the fact that like, wouldn't it be great if you're on a current page interacting with it and then went to go navigate to the next page and be able to actually start loading and running the next page before the current page unmounted.

There's ways to do that with signals, or any system by hoisting at top level, but it was really interesting to try solve that problem from a inversion of control pattern. That's what Suspense does in React. I have to admit that when I first saw that, I was like, "Wow, this is what I've always wanted." we implemented Suspense with data fetching back in 2019. For the last four years, we've been using Suspense on the client and the server doing these patterns. What this allows us to do is basically, let the way you layout your UI determine where the loading indicators are, and even be able to do things like, as I said, keep the current page active while the next page is going with stuff like transitions. Yeah, I have to admit, took that pattern from React, but I was able to apply it the same way, because while we don't have a virtual DOM, we have a reactive graph. As it turns out, the reactive graph and data propagation is not that different than the virtual DOM, funnily enough, in that most - in the way that has all three primitives, signals, derived signals, or memos and effects.

Well, you can look at basically, the derived signals as the pure part of the execution, the same way React has the render phase. It's possible for us to basically get all the data we need and derive it in a completely non-side effectful way, completely pure. Basically, I know this is crazy, when we do writes in a transition, fork the reactive graph like get and then merge it back together without running any of the side effects until we actually consume it and update the DOM. This works and it's super powerful.

I've been having a lot of fun with this. The biggest challenge we've had with this async approach is that we, I wouldn't say jumped the gun, but we released our version fully with data fetching primitives four years ago. We've learned a lot during this time. React didn't release these primitives until about a year ago. Then people really haven't been using it until the last six months. They went a slightly different way. I appreciate some of the differences that they've gone on, because, yeah, I could have used some of their learning as well.

With all 2.0, probably the biggest thing that we're working on is refinement to our async patterns. I think we got it mostly right. It's really incredibly powerful when we can make a single primitive, in our case, called create resource, which basically turns a promise into a signal. It handles literally everything from streaming, caching, serialization, so that when someone takes something like, Solid query, 10 stack queries, like Solid adapter, all they had to do was literally wrap our create resource primitive. Now when you use it in a Solid app, it basically works as if it was native.

You could just replace anything else we wrote, just dropping a solid start, suspense streaming transitions. Everything works out of the box. Not only does the developer not have to do anything. They don't have to worry about the serialization, it's handled automatically. Even the guys who created the library, they're just like, "Yeah, we didn't have to do anything different. We just literally wrapped this thing." Now it works in every mode Solid it operates in now and in the future. That's super powerful. It's part of why I'm happy that we did release Suspense and these primitives so long ago. Yeah, there's some goodies coming in Solid 2.0 to address async even better.

[0:17:51] TN: Yeah, that's awesome. It's great to hear that you guys have that support all the way down at the Solid level. Then the other developers can just hop on top and go, "Oh, this is great. This pattern works exactly the way we want it to. We can just put a little wrap around it." That's awesome.

I know you've said before that you didn't initially get into this for the speed for the optimization side of Solid, but SolidJS is known for its speed, and a lot of smart compiler optimizations are needed to ensure that the framework delivers this exceptional performance. What code optimizations are being used to achieve the speed?

[0:18:22] RC: Yeah. It's interesting, because we rely on the runtime stuff more than people would realize, because I think early days, we got compared to Svelte a lot. It wasn't ironically obvious until Svelte actually has been working on the Svelte 5 thing that's more similar to Solid that people actually realized that Solid's approach wasn't really about the compiler as much as you'd think, but there is a few things.

Mostly, yeah, I guess the first thing is high level, the compiler only compiles the JSX in Solid. Just like in React, we only compile the JSX. The reason we compile the JSX is so that we can run once. Most standard JSX transforms basically create these objects, or these functions that return this object that's all resolved at that time. But reactivity is based on read, so we need everything to be lazily evaluated so that it gets run under the right context. For that reason, we need our JSX compiler to basically wrap everything in functions.

This, funnily enough, yeah, none of the standard JSX transforms can do that. But we can actually keep the same JSX from a consumer standpoint using it, you can actually keep the same TypeScript works. You can keep all the same functionality of JSX, even if the compiler is doing all these function wrapping. A lot of our optimizations come in to figuring out how to determine what needs to be wrapped in the function and what doesn't. It's optimizing the compilation. If Solid at its basic level is handwritten, you could just, without the JSX compiler, just literally write a bunch of creative effect calls with signals and have an update one place in the DOM.

It's almost impossible for us to ever compete with the most handwritten thing. But people don't want to write that. They want to write JSX. They want to write stuff that's easier to move around. As I said, ironically, the compiler is, mostly optimizations are trying to make sure that the compiler doesn't add too much overhead. When we see that something is a function call, maybe we can remove one of the functions right away. Or if something is just passed and it's a variable, we know that it could never be reactive, because reactive have values that we call as functions.

The other interesting thing that we do, for example, is when we see similar things that update, we group them together into a single effect instead of multiple effects. It's these heuristics around our compilation that basically help make it so that it's closer to how you would have handwritten it within a legit JavaScript. Essentially, the compiler today doesn't actually make Solid faster. We're just trying to make it less slower. Solid's actually really fast if you just did it by hand. Not that everyone would want to do that.

[0:21:05] TN: Yeah, awesome. That's super cool. Users coming from other frameworks are going to expect a certain number of features, things like routing, server-side rendering, which we've talked about, compatibility with different bundlers, things like toast in the UI. What is the ecosystem surrounding SolidJS like?

[0:21:21] RC: Obviously, we have not been around as long as other frameworks and the adoption curve has been relatively slow. I mean, but most of the core pieces are there if you look for them. Some of it from the core team, some of it from the more extended ecosystem. Stuff like routing, server-side rendering, built into like, we have solutions that the core team provide hot module reloading. A lot of the templates come with that setup. There's been third-party routers that other people have written as well. We are working on our first-party Solid start, which is an SSR work, but there's also a vite plug-in SSR, which supports Solid, and you can use it in astra and whatnot.

Component libraries are interesting. We don't obviously have as much of a selection, but I've been told that Cobalt UI, or cobalt.dev is one of the best component libraries that people have seen in any framework. I've never been in the market to shop for component library, but I believe it's set up to do all the modern stuff in terms of headless and, yeah, I'm not thinking of the talk about that side.

[0:22:37] TN: Sure.

[0:22:38] RC: But yeah, we have ports of a lot of common, like Next.js libraries. Usually, Next.js, there's Solid auth. I mentioned earlier, we have all the TanStack stuff, Tanstack query, TanStack, I'm trying to think of what the other ones are offhand. That's the big one.

[0:22:54] TN: That's the one that I use. Yeah.

[0:22:57] RC: Yeah. I think we have ports of a few other component libraries as material UI. Yeah. It's smaller, but I think what we've been seeing a lot of, which is interesting is a lot of people making libraries at a little bit more generic these days, and then those can basically be used with Solid anyways. 

I've been actually really stoked to see a lot of the work in the headless realm around this. Obviously, you can pick up stuff like Tailwind and be off to the races. I'm trying to think of some of the other big areas of what people are looking for. There's even native solutions, technically. We work with stuff like Tori quite well and native script, so you can build mobile apps. We have custom renderers, which helps support that. We have Solid three, which is like 3.js wrapper to make video games with Solid. Yeah. It's interesting.

A lot of the cool thing about our reactive approach is it's relatively low on memory, so which makes it really ideal for a lot of these embedded device type situations, like television apps and stuff like that. We've had a lot of interest from even some larger companies on that side with our custom renderers. Yeah. I know that if you go out there and look for stuff, you'll probably find stuff that's missing, but there's a lot more than you would think, I guess.

[0:24:18] TN: Yeah. The community that's there seems very passionate about what they do, so it has the support there. It's very cool. Yeah. We've talked briefly about asynchronous code a lot, and that that's a feature of Solid 2.0. What else is on the horizon for SolidJS?

[0:24:33] RC: Yeah. I mean, 2.0 is the big one. We're looking at how the streamlines simplify the async pieces. Mostly, I love if you wouldn't have the null check. I want to do stuff similar to how React Suspense throws, but do it along the reactive graph in a non-blocking way, which is insane when it all gets pulled off. More than that, Solid Start is a big milestone for us getting it out of beta. We've been doing a lot of work on the SSR side, and I'd love to see it all come together. It's funny, we've been working on this so long that we've had the opportunity to pioneer a lot of approaches in our other frameworks that are released, but we haven't actually been able to release, things like server functions. They compiled, I guess, it's use server and react now and stuff. We released all that stuff over a year ago, but we've been very careful trying to get all the pieces together and creating a meta framework is so much more than just having the mechanics.

You have to worry about all the different deployments, adapters, have all the pieces, which is a lot. We've been working on a re-base of that onto Nitro, which is the engine underneath use Nux framework. And this will help us a lot, just the pieces that are lower level that not really in our purview, we can now use a general layer and get the support that comes that Nux and others using it do. This will help unlocks all at start, which is the other big one for us. Beyond that, we've been fortunate enough to get funding for R&D from Google Chrome team, and we've been looking a lot at doing things around partial hydration and with client-side navigation. 

We have done a few demos over the last year showcasing that, but again, generalizing it on this new rewrite and getting things to where it's just could be mature enough to be the standard way people build apps is really the ultimate goal here. A lot of things up in the air right now as we're approaching the next year, but it's all really exciting stuff, because we've been at the precipice of real change in the way we approach web dev and all the pieces seem to be coming together quite nicely right about now. I'm very excited for what the next six months or so have to bring.

[0:26:48] TN: Yeah, a lot of exciting stuff on the horizon for a Solid. Super cool. I want to shift gears just a little bit now and talk a little bit about open source. You've been involved in open-source software for quite a while now. Your current role is principal engineer for open source at Netlify. Can you elaborate on what that means and how that works with Netlify and your role also in Solid and how that all works out?

[0:27:09] RC: Yeah. I mean, it's interesting. Netlify has always been big on raise the water, all boats rise. I don't know the saying. You know what I mean.

[0:27:18] TN: A rising tide lifts all boats. Yeah, yeah. 

[0:27:20] RC: Exactly. Yeah, yeah. They saw the work that I was doing, because I also do a live stream and I look into stuff. As part of my work, I realized and this started my early days in Solid. I had this problem when I when I started Solid, I had signals and this reactive model that basically, React or the React core team and made very clear that this was a bad pattern and it should be discouraged and no one should use it all through the early years. Coming into an environment, especially when everyone's JavaScript fatigued, like this 2006 to 2017 period, everyone's like, "Ah, a new framework." They're tired.

It was very difficult when I come in and be like, challenge those norms. What I realized after the first few Twitter interactions where people basically called me a liar like, "Who are you? You're just this guy." Because no one knew who I was back then when I joined Twitter. I just get laughed on and they tag other people whenever I disagreed with them. They tag the framework creators. I wasn't wrong. It was just the common knowledge said otherwise. I realized that it was futile. Every time I tried to get into these discussions, even if I wasn't trying to push my own stuff, I just tried to widen the perspective of people.

Unfortunately, it would lead to - it sounded like, maybe self-promotion, or whatever. It's like, no. There's more than one way to do something. That made me realize that education was the only way that I was going to get out through this. I just kept on writing and writing articles and blogs and streams and videos and just kept on pushing educational content, so that people could understand, or see the web development the way I do.

That meant that I worked a lot of frameworks. When MPAs and islands started coming in, like Astro and this new stuff with presumably with quick, people don't understand what it is. Again, it's very often that people in the status quo using the popular frameworks are very quick to dismiss it. They'll say something like, "Oh, if we thought that was a good idea, we would have already done it." No, that's not the thing. I was like, "No, no, let's talk about the tradeoffs. Let's talk about what this looks like." I spent a lot of time with them. When they released the first versions of their apps, I'd be like, "Oh, let's talk about it on stream."

I built the first router for Quick for part of a stream. I mean, it wasn't a fully functional router. It's not something I wouldn't release, but it was something that I needed to do to show capability of the framework. I worked a lot with these guys. Like, how do we explain how these MPA frameworks are not the same as NextJS, or Spellkid? Through that time of educating and stuff, that's what Netlify saw. Yeah, really interesting, because as Netlify has changed over the last year or so with enterprise focus and a little bit less on the hobbyist focus that they've had in the past, it's still valuable to have engineers working on the problems around understanding what the frameworks need, what this looks like, infrastructure.

I don't know if you've seen it all recently, but Netlify has been just releasing tons and tons of primitives, really blob storage, new cache APIs, new image content stuff all in the last couple months. A lot of this stuff comes down to integrations with frameworks and tooling where people already are at. In so, I can serve as a conduit, both between these framework developers and also, just in terms of rounding out the education and the understanding there. Yeah, it's a good setup from that perspective for them. It's a good setup for me because they gave me a pretty open mandate, which means most of my time I do work on Solid. But I constantly spend time educating and providing feedback and keeping the pulse on what's going on.

It's a little bit different than the standard dev rel position, because instead of being dev rel, it's like framework dev, rel. I don't know what else to call it. Yeah, it's been pretty cool, because it gives me an opportunity to have that space that when Astro comes up with a Vue transition API, I get to make a demo and maybe deploy it to Netlify and see what it looks like. There's a whole R&D thinking there. There's a chance to try all the new features, map build in, tap me on the shoulder occasionally and be like, "What do you think about this, this cool thing that I was hacking in the weekend?" I'm like, "Yeah, let's try it. Let's build the AI demo using Solid or whatever." It's a very beneficial relationship for both of us. It keeps my tie is very close to open source where I came from.

[0:31:46] TN: Yeah, that sounds like so much fun. It sounds like a mutually beneficial partnership. Yeah, now that you're working closely with Netlify, what strategies and practices do you recommend for businesses and developers to engage with open source, both in terms of consumption and contribution?

[0:32:03] RC: Yeah. I mean, I understand this one's always tricky and this is something I see often with Solid, because it's like, we actually rely a lot on the donations and the sponsorship of others. Especially dev tool companies, if there's a specific area that they care about, and then it aligns with open-source projects, there's often a really good avenue to advertise, or promote that thing. If you're working on dev tools help a project with their dev tools, or getting someone onboard.

The hardest thing is, and I think knows this is being able to actually constantly fund people to actually work on stuff, right? There's a lot of volunteers, which are great. But bigger projects are harder and they require a bigger investment. That's harder to make with just people coming in occasionally. It's basically, contribute where you can is the thing. I know a lot of projects are all like, "Yeah, we love using Solid. We want to also support this and contribute." As I said, it's a tricky balance, because there's also, sometimes as I say, grants or sponsorships through Open Collective can do a lot, too. Biggest challenge is getting the money then to get the manpower.

It's funny sometimes, because people are - yeah, I get a lot of offers to do things for money and I'm like, "I'm too busy. But if you can help me enable other people in our community, then you'll get what you want." That's the key here. It's challenging. We've been in a world recently where a lot of VC money funnels into open source, which is good from the perspective that stuff gets built that's worth building. But the challenge there, obviously, is that you're in a very different place when you have a company behind it and you can hire people versus relying on the generosity of others. There's a shelf on everything, right? Almost, there's a clear trade off. Companies that are formed around open source VC, they need a clear business plan after a couple of years, otherwise the money runs out.

Yeah, we've taken definitely more on the open-source side. Netlify does not own Solid. There's no the Solid company. But they are a very generous patron. Very appreciative of them in that case. For the most part, that's why I've been looking for more patrons. Google's Chrome gave us enough R&D funds to fund people working for six months or whatever on this new R&D stuff. We've had a lot of other things. Erasure, they make one of those online drawing things, they help us. They put money towards our docs. Then now we have people be able to give people money towards working on our docs. There's lots of examples like that, where these alignments make sense. That's really how things get done. I know, there's always a scary moment when you realize that there's this project used by every large company and then no one's paying for it anymore and it's one developer.

We've seen stuff like that happen with Babel. We've seen stuff happen like that in a few other places. It's scary. But then, I've also been on the other side. I've worked at a larger company when I was working at eBay. There's an open-source committee and it was like, okay, how do we use this tool here on every build? How do we convince the higher ups that this is one of those things that we should be putting money towards? There's committees and stuff, but it takes a different point to actually push that through.

I guess, it's hard to see the results of that contribution all the time. That's why there's a lot of foundations that help handle in the middle, like OpenJS and whatnot. Luckily, we're at least the size Solid is right now. You can almost see the direct contribution. It's almost like sponsoring a developer. You help one developer do the work they do. We've seen this even with not the larger companies, but some companies that just use Solid and being like, "Hey, we really care about internationalization. Can we put X amount of money forward and put it towards a fund to work on a solution for internationalization?" Yeah, we'll look at how we put those resources to use and see what we can get out of it.

It's tricky, as I said, because someone just tried to pay me to solve internationalization for Solid. Again, I'd have to say no. But if we can find a way to bring others and then that's where we can get to hopefully a point that's sustainable. I think the Vue community, especially is a prime example of how that can work in practice. Vue has somehow walked that line where they've never been owned by anything, never worked for a large - even run by a company. Evans managed to produce one of the biggest teams of people working off funding that I've seen between the Vue project, the beat project, even certain degrees, even though it's more tertiary, like Nux and stuff, just having people working in open source almost basically full-time purely off the money coming in.

It's tricky. It's hard, because there isn't that many options. At a certain point, there's a pinch of the money drying up, so nothing's ever assured. But everyone uses this software, so what are you going to do?

[0:37:11] TN: Yeah. This relationship between companies using open-source software and the nature of open-source software being open source, it's so interesting to me, because people need to eat and that requires money, but the nature of open source is that we want anybody to contribute at any level. Yeah, that relationship is super interesting to me. How do you believe that that relationship will change over the coming years? What will the key drivers to those changes be? How do you hope to see open source and the relationship between companies moving?

[0:37:38] RC: Yeah. I mean, I love stuff like the deal that I'm set up with and even - more of these sponsorship deals. We were seeing a lot of them during the growth period before the more recent economic clamp down. I have some concerns that we're not going to see that as much with the short term. I do have concerns myself for longer running projects that are already used everywhere.

Like I said, I would to see more of this patron type model, but I don't know if we're in a economic situation where that really lends to it. A lot of the smaller contributors started - the last of a while, I've seen less in those donations, times they're getting a little bit tougher. That's where the cuts happen. Yeah. I mean, longer term? Yeah, I want to see more of this. I don't think every single open-source project makes sense as a VC project. I think we've done that. Sometimes a front-end framework, for example. I got offered a few times. People are like, "Oh, start the Solid company." I'm like, what am I selling? Because it's something that everyone expects to have for free. Everyone expects to be able to just build on the web. You can build services, contract, do other things, hosting, which is saturated.

I think that there are certain things that should be businesses and they can use open source and leverage it. There's other things that aren't businesses and it makes it challenging. As I said, I'd love to continue seeing this patronage model. I realize it's difficult and it's quite often, that's when the resources drive up over time. But it's no different than when people take the stuff on internally, right? Even maybe even worse, I don't think any developer works on flow at meta anymore. There was only one or two, but then flow ended up just shrinking, shrinking down to just one guy working on it part time. Yet, people are still using it outside of meta, which was scary.

Most part, people moved to TypeScript. New tools come around. Sometimes those shifts are not easy. I think that there's going to be a few things where almost like, open-source bankruptcy that happens, I think in the next few years, where people are going to be like, "Ugh." I'm hoping that it gives us a path forward after, but the truth of matter is like, some software isn't - people aren't going to pay for it and it still needs to exist.

[0:40:02] TN: Yeah, that's the fundamental conflict. Thank you so much for your insight, Ryan. It's been a pleasure speaking with you. Thank you for coming on the show.

[0:40:11] RC: Of course. No, this was a lot of fun. Thank you for having me.

[0:40:13] TN: Yeah. Thank you for listening to Software Engineering Daily. If you're interested more on signals and the reactive model proposed by SolidJS, I recommend reading The Evolution of Signals in JavaScript and a hands-on introduction to fine-grained reactivity, especially that last one by Ryan Carniato. Those were fundamental to my understanding of how solid JS works. Ryan, is there anything else you'd like to plug?

[0:40:32] RC: Not really, other than say, come by the website, get in the Discord. That's where everything really happens. We're always talking. We're always working on stuff. If you want to be part of it, come join the Discord. It's a great place to be.

[0:40:45] TN: Thank you.

[END]