10 years of SolidJS with Ryan Carniato

Ryan

~probab~

Noel

~yeah.~

Ryan

probably solid start. Probably. It was probably like just before solid start came out around that, so, so, yeah, just about a year. Yeah,

Noel

Yeah, yeah, yeah. Yeah. Very cool. Um, yeah, this, this blog post is an interesting one. It's kind of a, like a, a reflection on your journey and, you know, solids, solids path here and kinda your relationship with it and the framework, community and open source in general, and all this stuff. Um, why did you think now was kind of a good time to, to push this out and get this out there?

Ryan

Yeah. Yeah. I don't know. I mean, to be fair, uh, it, it hasn't quite been. years yet. Um, it'll be 10 years, like this summer, but, uh, I, it was, it, it had been exactly seven years from when I open sourced the library. That's

Noel

I

Ryan

got me thinking about

Noel

see.

Ryan

Like when most people, not most people, but some people started becoming aware of solid. But I, I'd started working on solid. Before that, uh, seven years still marks a long time. Uh,

Noel

Yeah.

Ryan

sitting, uh, in, it was actually on my birthday earlier in the year in February and realizing that it had almost been seven years,

Noel

Mm-hmm.

Ryan

since I open sourced it and that it was like my birthday was the day that. The gap between when I first open source, solid till present day, um, was the same, had finally exceeded. Um, the gap between when jQuery was re-released

Noel

Oh yeah, yeah.

Ryan

React was released. Um, like that's a long time in web development.

Noel

That's, that's wild. Yeah.

Ryan

because you know, people picture jQuery and then they picture react and there was like a whole error in between.

Noel

Mm-hmm.

Ryan

and. Uh, this year, solid's been around for that long,

Noel

Yeah. Yeah, that is always, that's always like an interesting exercise personally. But yeah, I hadn't, I hadn't done this, done this in like the, in the web tooling framework world. 'cause you're right, like jQuery feels so, so much, so much older than like, you know, react in that and that way of, um, I. It's interesting to think like, do you think that there's this, this kind of, this kind of slowing of, of the tool landscape at large is, is a, is a like a product of kind of the, the maturing, the ecosystem maturing?

Um, or do you think there's something like that kind of was really struck there with react that's kind of caused this, this era to be a little bit more stable.

Ryan

Yeah, I, I think it's, it's mostly a function of maturing, right? Like there was a lot of stuff back when I was getting into this and, you know, web development and even like, you know, I. Getting into re getting into JavaScript. I spent some time on the backend after, like in the early two thousands when I got back into the JavaScript around 2009, 2010.

Noel

Yeah.

Ryan

we, we had new libraries, new frameworks all the time. And even after React the first few years, it was still very fast. I think

Noel

It was, yeah.

Ryan

naturally were looking for, um, something they could trust. The, the thing is as applications and requirements get more, um. I'm not gonna say just complicated, but like, like the whole quality expectation goes up,

Noel

Mm-hmm.

Ryan

to want to, expect more out of your tools and you don't want to keep on shifting it. Just bigger projects, you know, more at stake there. was kind of natural that things would slow down. Um.

Noel

Yeah. Yeah. I, I, I, I, I, I don't, I don't find it super surprising either, I guess. But I do, I do think it is interesting now because I think, I think that there, there was kind of a point where we were churning through things very quickly and then, then something happened. And like now, now there are still several paths, but they seem to all kind of be, I. Running in parallel and there's like still a big react community, there's a big view community, you know, there's a big S felt community and there's a solid community. Like what, why do you think that these like kind of are all, are all running with such steam behind them when before it really felt like devs were kind of ju more eager to jump ship and like find the new thing to clinging to.

Ryan

I mean, part of it is that desire for maturity. I think what part of it came in too is like. lot more new web developers over time. Um, and this continues to grow. And I think that like we saw a whole generation of people on the web whose entry point was at a different place, right? Like when I started, um, you know, back, uh, we had HTML, um, we had like no one. kind of used JavaScript maybe for something novel, but you had like Scripts and CGI bins and like,

Noel

Yeah.

Ryan

like it was kind of really rough and um, you know, things. We, you kinda expected to put things together? I think there's been a whole generation, um, you know, since declarative frameworks where people came out and react was that first introduction to the web.

Noel

Mm-hmm.

Ryan

so even if you were gonna pick a different solution, it's still gonna kind of resemble I. That somewhat, like you're just like, that's kinda the expectation. And then know, it, we went from that being like an app framework, right? React was built for apps.

Noel

Mm-hmm.

Ryan

for, you know, highly interactive things to people going, okay, well this is the web. How do I build my static site? And they're just like, I, I know react and like, it it, you know, this kind of universality continued onwards. And I, I think that's kind of why, um. Like, that's not why there's like camps per se, but that's, that's part of that kind of slow down. And where there's not that as much expectation on, uh, exploration because like the baseline, the bo the, the, the ground floor, the abstraction has already been set. People aren't, weren't really peeking under the hood anymore. Um, that's why I think a, we went from that phase where it was a lot of different frameworks and stuff all through 2009 through 2000, I wanna say 14,

Noel

14 would. Yeah, 14 was gonna be my number too.

Ryan

Right, because React came out in 2013. It did take a, a year or two after React for the com completely cement over, but to like the focus of frameworks being on like different things. It's like instead of being like, oh, here's all my different, you know, I. do things this way or these novel things. It was a real DX focus kind of

Noel

Mm.

Ryan

only new frameworks coming out, um, after 2015 for at least the next three or four years. It's felt like we're ones that focused on a different developer experience. We offer something different than React because we have templates or we have, you know, our HL with our CSS or what, like

Noel

Yeah.

Ryan

it was like very much a developer experience focus,

Noel

Hmm.

Ryan

like. The, the vibes you get off

Noel

Yeah.

Ryan

as Rich Harris would, would, would go later on to say, and I think, um, that was because people didn't want to like, think about something like too different. It was kinda like JavaScript, JavaScript fatigue came in where people were

Noel

Yeah.

Ryan

of different libraries and stuff. But 2016 people were like, were not interested in new frameworks anymore, really.

Noel

Mm-hmm.

Ryan

even though. continued to be built and you know, a few of them were lucky enough to be successful. Um,

Noel

Yeah.

Ryan

speaking, the, the maturing had started, this whole kinda shift had happened and, uh, frameworks started targeting like the entry funnel. They started looking at like, how do I get adoption? How do I get people to like, you know, look at this and want to use it.

Noel

Mm-hmm.

Ryan

was much, I mean, that's already a much more mature place if you, it's not just a bunch of people with their technology. It's like marketing.

Noel

Yeah. Yeah. It's like, yeah, that we were, we, we hit it, we hit an arrow where you could really like market at the dev experience, right? And like make it like target the developer to convince them. So this is, I feel like this is as good a as good of kind of a. A framework, a foundation for our conversation is anything then, so stepping into this, like whatever, seven and change years ago, what, what was like your mo your main motivation to kind of, and, and, and, and you know, like what, what, what, what made you optimistic enough to kind of get this out in front of the world and open source it?

When, when everybody was so, you know, kind of entrenched in, entrenched in React.

Ryan

I mean, at first, I, I wasn't, I, it took me a long time. That's why I, I wrote, like in this article, I, I'd been playing around with stuff like this 2015. I mean, for me, like I actually had tried to build some stuff with. Other framework tools and like use web components like back as far as like

Noel

Yeah.

Ryan

14. So I spent a lot of time doing web component, open source stuff, like nothing really popular, but I made a few libraries and did some stuff in my, my company I was working at at the time. But like, it was around 2015 when I realized that React, um, had won, like, it was kinda obvious and I was like, it wasn't about marketing or adoption

Noel

Yeah.

Ryan

for me. I was like, um, I don't like this. I mean, I, I, I react is right. I had to like. Admit that there was a lot of mess in like knockout, which was my favorite tool at the time.

Noel

Yeah, yeah. Yeah. I, mm-hmm.

Ryan

like, and no one was updating it anymore. Like it, it, it kind of died out. And I, I like, they were right. There was a lot of things that were unpredictable and magical. Perhaps

Noel

Yeah.

Ryan

which is hilarious by modern standards because,

Noel

Yeah.

Ryan

everything is magical now by modern standards.

Noel

the level of magic we're okay with is much higher now than it was then. Yeah. Yeah.

Ryan

it was because for a while I thought it was, um, yeah, I, I thought it was 'cause people understood stuff more like I thought that we'd grown as a community and matured and understood our technology more and the magic was gone and that's why we could go to higher levels of abstraction. But sometimes these days, I actually think it's just like, the expectation now is just that the magic is there and I don't need to understand it

Noel

Mm.

Ryan

It just all goes, you

Noel

Yeah. Mm-hmm.

Ryan

for me, uh, looking back at that time, I really like, there, there's gotta be another way. I, I, I remember I, I mentioned this in the article, but I watched some like performance benchmarks, uh, especially one, uh, created by Ryan Florence. Um. Many people know, though, one of the co-creators of, uh, react

Noel

Mm-hmm.

Ryan

remix, it was a performance demo, um, around like ding, uh, like a stock ticker. And I just, I looked at this and I was like, I, no offense to Ryan, but I'm like, this is not a real app. Like, I, like it

Noel

Yeah.

Ryan

ludicrous to send like just tons and tons of data, like spam the page as fast as possible. And yeah, I mean React was pretty good at that, but I'm like. There was a whole bunch of things that I didn't picture react, you know, being as good at potentially, like, it just, there was no way that it was going to, if it's gonna re-render everything. I know this is a very mechanical thing, but I, I just like, I'm like, there were other options out there before and I, like, even libraries like that had some reactivity like view that were coming out at the time we we're like, yeah, we got a v Om we're we, we got, you know,

Noel

Mm-hmm.

Ryan

plus v Om and I'm just like. Why V Dom? And was like, I felt like I needed to like do a sanity check. You know,

Noel

Yeah.

Ryan

the, I guess I start on the web too old, you know, before react, before you know, the modern thing. And I was just like, this, this is insane to me that, you know, we can just like accept that this is the, you know, only way. And yeah, so I, I, I made benchmarks, I did tests, I looked at every example. I tried to see if I could build a system that had. Was performant and ergonomic, had all the things that I liked,

Noel

Mm-hmm.

Ryan

you know, using knockout without, you know, some of the bad sides, you know, knock out the good parts. But more than that, actually having learned from stuff from React, like unidirectional flow, you know, things that may apps more maintainable. I mean, you, you don't need react, uh, to hit these kind of problems when you're building apps. React was popular for like introducing things like flux, like better data

Mm-hmm. but these best practices weren't. They reacts, design helped support them, but they weren't always encoded into React Like, like React did not ship a flux module.

Noel

Right. Right.

Ryan

it was just like best practices. React was always about best practices. And I'm like, well, why can't we have, you know, best practices that fit around other paradigms? They just

Noel

Mm-hmm.

Ryan

to be as well defined. React was really good at defining like. Um, sort of it's rules or it's mindset. Let you come in and be like, look, this is like, think immutable, think you know, functional, like think a, like this is how you wanna approach the problem. Not everyone does when they approach react, but

Noel

Yeah.

Ryan

creators at least had an idea and a direction, which is different than the frameworks before. 'cause the frameworks before were just like, look, the DOM updates

Noel

Yeah. Right,

Ryan

know, they didn't

Noel

right, right. Yeah.

Ryan

about, they were like, they were very mechanical,

Noel

Mm-hmm.

Ryan

like. Any, uh, product evolution standpoint, you know, starts with some kind of technology and then someone, you know, makes the, uh, the, the Apple product, you know, they, they

Noel

Yeah,

Ryan

the iPhone and they're like, look, you guys may have had a touchscreen before, but this is a touchscreen

Noel

yeah, yeah. Mm-hmm.

Ryan

of like, like that for front end.

Noel

Mm-hmm.

Ryan

I immediately, I was like, I mean, yeah, I, I get it, but that doesn't mean that that's the only way to do it.

Noel

Yeah. Right, right. Yeah. I think, I think this, this, this notion that like react kind of, I, it, it feels like even, even in the early days, react was very much, I. The, just the way in which it was, um, kind of, kind of built the way, the way that it felt intuitive to interact with it, very much pushed developers into these patterns that I think made it easier to work on, like larger teams that were collaborating on larger projects versus like going into every piece of your front end, like, oh, someone worked on this component.

The way in which they handle like state management and everything was vastly different than some other part of the app. And I think react kind of like smoothed that over in a way that felt very nice.

Ryan

Yeah. At least, at least in theory. I mean, it was, it was one of those interesting things. 'cause like Angular also sought to solve that problem. And, and they did it by saying like, look, we have a library for everything. You

Noel

Mm-hmm. Right?

Ryan

a service, you wanna do this, here's a service. React wasn't quite as prescriptive in that sense, but

Noel

Mm-hmm.

Ryan

at least a philosophy, they had a direction and, you know, they're

Noel

Yeah.

Ryan

the, which is more than what a lot of solutions had at the time. It's, it's,

Noel

Yeah.

Ryan

ironic now that when we step way further in the future,

Noel

Mm-hmm.

Ryan

The fact that people did, you know, react had almost fashion because like even though it

Noel

Yep.

Ryan

principles, best practices change,

Noel

Right.

Ryan

this is what helps things evolve, that now when people look at React, they call it a mess. But it was actually very, I. You know, it was very freeing at the time to be basically, you know, be, have limits. I know that's kinda weird, but to actually be like, look, this is kind of like the rules. People wanted to be told what to do

Noel

Mm-hmm.

Ryan

it's, it's, it's, it's, as I said, it's very ironic that, um. On one hand, react was like, this is how you do things. On the other hand, they were still flexible enough that best practices would continue to change over

Noel

Right, right.

Ryan

it's, it's, it's, it's, it's a weird, um, conflict. But on the other hand, I don't actually personally find it conflicting. I, that's like my favorite part about React and it's the thing that I, um, wanted to. Capture in solid. It was part of actually, um, that design philosophy, um, really guided me in terms of focusing on primitives. Like React for React is the components, but for me it was like, okay, let's make this about the signals or the reactive system,

Noel

Yeah.

Ryan

and see how far we can take that. 'cause then we have, um, these guidelines and we have these building blocks that we can

Noel

Mm-hmm.

Ryan

to expand on top of, um, in a predictable way. ~Uh,~

Noel

~Yeah. Yeah. Yeah.~ I think, I think that that's well said. Yeah. The um, like, and like, I think, I think that there was a lot of. Difficulty, uh, like an angular always felt, I think, I think it was so regimented that that was a lot of the pain that people felt working on the, on those projects and then react was like, just unopinionated enough or like it didn't really get in your way. I think it was also to your point of like new users ramping up, it was way easier just like. Get some, you didn't have to understand like react. It was intuitive to look at. It was kind of Dom like, um, but then it, it pointed one in the right direction. So there was like, yeah, some, some guidance, but it wasn't as much, it wasn't this like kind of whole new API that one had to understand to write in it.

Um, so yeah, it's interesting to think of those as a spectrum. You mentioned, you mentioned that this kind of like moving away. Um, I guess building with primitives maybe is, it was kind of more something that we've been talking about here in a couple of instances, and that was a lot of your motivation was there, like why was this the thing that you felt was the missing piece? Like you mentioned the vdo with view and like that kind of not really being the thing. Like why, why was your big sell

Ryan

Y

Noel

com, like composability from the bottom up?

Ryan

Yeah, I mean view at the time actually had, uh, something called the, uh, options, API, which was

Noel

Yeah.

Ryan

objects. It's 'cause everyone was scared. Of composition at this

Noel

Mm-hmm.

Ryan

everyone was like, our state should look like plain objects.

Noel

Right.

Ryan

angular did it. Um, and in that, their case in a very fairly inefficient way, I should say like zone js, they just like wait for every single like event handler, async, anything that happened. We were like, okay, did anything change after that,

Noel

Yeah.

Ryan

reacted a little bit different where they had at least had like a set state where they're like, okay, this component owns the set state. When you call set state and you update something, we'll rerun the component,

Noel

Yeah.

Ryan

Um, and view is like, okay, we'll just make these big getter, um, like, it's almost like a proxy, but we didn't have proxies

Noel

Yeah. Mm-hmm.

Ryan

this big getter blob. And the thing I loved about Knockout was that, um. You, you just made these like little like signal effect computer. You, you just like, to be fair, you could do this with views, objects, but they, they weren't quite as portable. Like in, when I use knockout, like basically a component was a function.

Noel

Mm-hmm.

Ryan

was a whole other, it wasn't quite components like we know today. 'cause the view was like. a separate module, like they used to call this MBBM or something,

Noel

Right. Yeah.

Ryan

uh, view. So it wasn't quite the same as a modern component, but effectively you started kind of building up the, this kind of. E femoral state,

Noel

Mm-hmm.

Ryan

was associated, you know, like there's the model that persists and then there's, you know, the view that you, you know, update and see in the templating. But

Noel

Mm-hmm.

Ryan

was, there was this real kind of like middle ground ephemeral state in the view model

Noel

The view model. Yeah.

Ryan

which, which is kind of like a component. It was like this, the early ground, the differences, it's a separate tree than the view tree where the components. Mix, uh, view model and view together, but like generally still had this kind of building of pieces and we would just, you know. Have a component as a function, and then like it state be functions and then have functions, call functions that wrap functions.

Like it was

Noel

Mm-hmm. Yeah.

Ryan

it all up like a bunch of blocks and then you'd be like, oh, I have this piece over here. I grab that and call it in here as a function like, composition was like. You know, uh, we always see this now as like a basic example, like used local storage or whatever, but that kind of hook like composition existed in the knockout model because you, like, it was very similar idea. You'd be like, oh, I have a, um, they call them observables, but basically a

Noel

Yeah. Mm-hmm.

Ryan

be like, oh, I wanna signal the rights to local, uh, storage. Well, I'll just wrap that in a function and then call, you know. Create my own local storage signal. Like that kind of composable ness had been in that model right from the beginning. And when I looked out at the JavaScript e ecosystem, not there. So there was a DX thing that I wanted. And then

Noel

Yeah.

Ryan

hand, conceptually knowing that when I update this one thing, it updates this one other

Noel

Mm-hmm.

Ryan

no diffing, no, none of that it. It just all seemed like there's this, all these extra systems being built in that were all completely unnecessary.

Noel

Right.

Ryan

like. Yeah, and as I said, I, I was kind of like, okay, well, you know, maybe I just think this, maybe I'm crazy. But then like when I started seeing like, you know, conference talks where people talking like the performance of React, I was like, okay, no, this doesn't make

Noel

Mm-hmm.

Ryan

I need to vet it myself. And that's, you know, how I got involved and I just wanted to recapture that developer experience and honestly, um. Uh, there were, I wasn't alone. There was a few other

Noel

Yeah.

Ryan

very similar projects at that time. It just, it was kind of, it was kind of funny because like, as I said, it wasn't, there was a DX element, there was a UX element, but it wasn't like, uh, how does this look? It wasn't like an aesthetic, aesthetic thing that necessarily, it was a very mechanical

Noel

Yeah.

Ryan

thing. We wanted, you know, to make things, um, you know, more efficient and easier to use from that perspective.

Noel

Mm-hmm.

Ryan

The truth is we just, it wasn't a world that it seemed that people would be accepting of this because, know, reacted one, even back then we kind of, everyone knew and just were like, yeah, you know, I have my state. That's plain objects very important. 'cause plain objects aren't magical.

Noel

Yeah. Yeah.

Ryan

and then I have my, my templating or you

Noel

Mm-hmm.

Ryan

flavor I choose. And, you know, I just update it and it re renders. And I do the thing like the whole v om spiel

Noel

Yeah.

Ryan

that, that, that was where the world had had gone to and no one wanted, um, these granular composable, state primitives. ~Um.~

Noel

~Yeah.~ Which I, and I think, I think the, I think the impulse towards that like, makes a lot of sense. And I think there's a reason it's been successful. Right. It's like, it's it's kind of it It does, it does, it does. Away with a lot of that like. Wiring up, which I think historically had been very gross. Like it'd been very hard to handle and it had been very error prone. Like you'd always get all these weird front end bugs, like, oh, I clicked the button and X didn't happen and without something they're kind of orchestrating and it was always hard. But it sounds like your real thesis here is that like giving developers explicit control of those signals in a way that's easier for them to grasp and kind of wrangle like that is really the place that you wanted to be Like.

Would you say that that's, that that's accurate.

Ryan

definitely. I, I was not a junior developer anymore. I, I did have a team, but I had a team of on startup that had been using Knockout. So we were familiar with the technology. We understood signals

Noel

Yeah.

Ryan

whatever you want to call that type of reactivity, fine-grain reactivity at the time. And we were so, like, I wasn't worried about ramp up or who was gonna like learn it. I was like. have good technology to build good applications. You know, it's, it's isolated, it's modular. It, it, it gives you all these qualities that are really, really powerful when you want to build, you know, decent size apps, you know, you don't have to worry about everything getting entangled. We, we were never debugging why components are re rendering down.

10 trees there, there were places where you're like, oh, this, this, this thing updated more than I expected. But usually it was isolated and, um, and kind of like within its certain zone, because

Noel

Yeah.

Ryan

you're dealing with signals, you're dealing with a graph, a data graph,

Noel

Right.

Ryan

dependencies talk to each

Noel

Do one another. Yep. Yep. Yeah.

Ryan

it just, it, it made a lot of sense from all the mechanical reasons. It just wasn't nice to look at. Um. Right. So, I mean, and, and as I did more work on the benchmarks, um, you know, it turned out I was like, no, this, this is actually really fast, like insanely fast. Like like with a little bit of modern tooling. That's something Knockout never had.

Noel

Mm-hmm.

Ryan

we aren't just like more performant than, say React, which a popular solution, popular solutions generally are gonna be like, they're, they're not focusing on performance. They got users to worry

Noel

Mm-hmm.

Ryan

We were like more performant than everything.

Noel

Yeah.

Ryan

like,

Noel

Mm-hmm.

Ryan

you know, um, I say we, but like, there's, there's a couple independent projects at the time. There's myself, um, there's, uh, uh, Adam who did, uh, Adam Hill, sorry, he did surplus.

Noel

Hmm.

Ryan

there's a few, there's a couple other, like these kind of like, um, there signals based things. And I like it. Just, this is what finally got me to open source it because I, I, I was just like, I was just like. I want to, I wanna play in the benchmarks. I just want to like, prove it, like from an academic almost standpoint. Like, just like, look, there is an alternative. I get it. You know, it's not fashionable. I'm, I'm, I'm, I'm getting older now. Maybe I'm not fashionable. I don't care,

Noel

Yeah. Yeah.

Ryan

dev, I, I just do what I do, what I like,

Noel

Mm-hmm.

Ryan

I, I mean, I mean, I, I mentioned this in the article, things might have stayed that way if it weren't for the fact that React like, you know, less than a year later was like, we finally solved composition. Here's hooks.

Noel

Right, right. Yeah. Do you, do you think like, I guess. Did you, you, it sounds like you probably didn't, didn't see that really coming, this big kind of inflection point in react. So did that, did that surprise you a lot and I guess were you, were you expecting the amount of push into solid that that likely caused? I.

Ryan

No, like I, I didn't see that coming all. See, the thing you have to understand is reacts like functional roots and its whole like. Almost like a video game. Thinking of like immediate mode. Um, I don't know if everyone knows the difference, but there's like classical graphics. There's like two different TT type models. There's immediate mode and retain mode, immediate mode. This idea that you can like re-render the whole scene graph every time, it's very common

Noel

Mm-hmm.

Ryan

uh, video games 'cause it keeps a constant frame rate. It's, it's basically the thing that powers everything. They just recreate the graph every time and. Redraw the game

Noel

Yeah.

Ryan

it's great because it's predictable. Um, you don't have to worry about weird artifacts happening over time. You just kinda slam it. There's a different model, the retain mode where you actually keep something and you mutate it, um, where you just update only kind of what needs to change. And this is

Noel

Mm-hmm.

Ryan

understanding way more efficient, but it's less predictable because sometimes you change lots of things. Sometimes you change a few things.

Noel

Yeah,

Ryan

enough, the dom. Is retain mode like

Noel

yeah, of course. Yeah, yeah, yeah. Mm-hmm.

Ryan

right off the bat, there's this. Mismatch between kind of like react mentality and like how the web platform works. so like I was like, if we align ourselves more with the platform, you know, we can do better stuff. And, uh, kind of, sorry, where I'm, where I'm going with this is you could just see this kind of two different mentalities, like the separation exist in the ecosystem in general. React was like the very first to come in and be like. not the very first, but like the first popular enough to come in and be like, no, we think retain mode is good. We can just re-render everything. And you know, sorry, not retain,

Noel

Yeah. Yeah.

Ryan

first to think immediate mode is good. We can just

Noel

Yep. Mm-hmm.

Ryan

of mentality carried out into its ecosystem. In terms of what succeeded, there were a couple people who, who were working on signals or, uh, like reactive fine green reactive libraries in React.

Noel

Mm-hmm.

Ryan

uh. MobX or observable

Noel

Mm-hmm.

Ryan

was, is a signaled implementation as state management react. Obviously the, it didn't always quite perfectly, but it was a very good solution, way ahead of its time. Great technology, um, big inspiration for, you know, what I did with signals later and, um, but it never quite fit with like their mental model. Instead, the biggest comp competitor on the, uh, state management side at the time was Redux.

Noel

Yeah.

Ryan

which was a, you know, you kind of like have this boilerplate, it was very simple in that like everything was functional driven and it was all synchronous and there is no like, you know, event, there's just one store, essentially.

Noel

right.

Ryan

Redox kind of became the poster child. I, I, I thought MobX was a way better solution, like way more powerful, way more capable, but I. Redux Fit Reacts philosophy and re-render model. And in fact, the guys who created Redux became, um, members of the React core team.

Noel

Yeah. Yeah.

Ryan

like there was a definite, like, you know, the, it's funny, after the original criers of React and moved on to different projects, it was actually like the, the Redux maintainers

Noel

Mm-hmm.

Ryan

became React. So

Noel

Mm-hmm.

Ryan

there's a passing of the torch here and that mentality preserved. So you, you have to understand like. React was never going to go this direction, which is why it completely shocked me when I saw hooks. 'cause hooks are not the same. And if you ask them about it, they'll tell you something about some functional programming.

Noel

Yeah.

Ryan

or whatnot and explaining, and they are mechanically different in with hooks, your component reruns then only, and basically it checks the values and decides if the hooks rerun. Whereas like in the signals implementation, your components don't rerun, only the quote hooks rerun. So they, they are like opposites,

Noel

Yeah.

Ryan

they look almost identical. Like there's no way you look at hooks and then go, okay, these are like. Primitives, like, you know, reacts whole, like previous, like, oh, our state is just objects was out the window. Like,

Noel

Yeah, no, absolutely. Yeah.

Ryan

state use memo, use callback, use effect, use, whatever.

Noel

Yep.

Ryan

and it, you can tell they got to it from a different place. If you look at their, like, um, prior art, when they released hooks, they don't mention signals reactively anything, like along that side. They, they, we were not influenced by that all. But you look at it and you're like. Uh, come on

Noel

Yeah. Yeah. Mm-hmm.

Ryan

To be fair, they probably weren't. ~I, it just, it's just~

Noel

~They kind of,~ they arrived at the same po play destination, probably like in a way, right? There's a sim very similar feel to what these things are trying to do. Maybe, maybe by necessity like one could argue, but uh, yeah, it's, it's, it's absolutely there. And it does, it does feel like, like hooks is kind of a roundabout way of reaching this destination. And I think that's part of the reason I still think that like hooks are very tricky to. Gr like, what's actually going on? What's with like, what the framework works for new developers. Even like having a person, being a person that spent a lot of time in hooks, you're still like, I find myself just like throwing console logs at the top of a, a hook to like, wait, when is this actually firing?

Like, it's, it's always, it's, it's, it feels very counterintuitive still. Um, yeah.

Ryan

it's interesting 'cause uh, in a lot of ways, like that was the argument they made against, uh, um, what they called key value observables or essentially fine grained reactivity. If you go watch a Pete Hunt talk or Tom Ccino or like, uh, Jordan walk, any of the original React guys and, and when they're not talking about angular. They're talking about basically ember or knockout.

Noel

Yes.

Ryan

uh, when they, when they, when they're talking about like, what's wrong with that? ~You can, like, there's a great one where, uh, uh, Tom Hunt, uh, sorry. Where he, uh, sorry. Uh, not Tom. I mix their, I put their names together. Uh,~

Noel

~You're good, you're good. You can look up if you need to.~

Ryan

~Yeah. I said his, I said his name a minute ago.~ ~Uh, gimme two seconds. Uh. Pete Hunt. Pete Hunt. Yes. Pete Hunt. There, sorry. Let me just like restart that. ~There's like this great talk where, uh, Pete Hunt went to university, I think, or a college, they call in us here. Uh, and basically gave a talk on like selling React and it was a little bit more technical and he broke into like three ways where React was better than these other frameworks.

And it was very specific about these kinda mechanical things. Like, uh, in terms of like the. What happens about like state ownership and knowing what reruns and all, like, basically, he, he broke it down and I, I watched that video again about, uh, a year ago and I was, I was like pretending he was talking about modern React instead of knockout and the video fit perfectly. Like they basically, their whole positioning on this, like

Noel

Yeah.

Ryan

them, they'll say they haven't, and it's still like, fine because of some academic, functional whatever,

Noel

Mm-hmm.

Ryan

to be fair. As a layman developer looking at this and looking at, like, they're saying you could literally slot the hooks examples in for the say knockout examples, and it would, you'd be like, yeah, I get what he's saying.

Noel

Yeah.

Ryan

so it was a big departure. I mean, in some ways it was necessary. It gave that composition. They needed something smaller than a component. They react was all components and they, they were like, okay, we actually need to compose something smaller than a component. How do we do this?

Noel

Mm-hmm.

Ryan

And the, the, the way of they've solved it was basically saying, we'll make something that. You can look smaller than a component, but it's still actually the component. That's the level of granularity.

Noel

Yeah.

Ryan

component based, but we're going to make something that looks

Noel

Mm-hmm.

Ryan

right? Which is, I said in contrast to like signals where the small thing is actually the unit of change.

Noel

Yeah.

Ryan

I. I think both models make sense. If you can get into

Noel

Mm-hmm.

Ryan

just, I don't think either is actually simpler than the other anymore. I think early React like class lifecycle render,

Noel

Mm-hmm.

Ryan

was dirt. Simple. Simple.

Noel

Yeah. I don't think, yeah, it's really hard to argue otherwise. Yeah.

Ryan

everything since then, uh, especially into hooks, um, it, they, they wandered into a territory, um, that is kind of similar to where these other solutions that they earlier condemned were. And me that was an opportunity I.

Noel

Mm-hmm.

Ryan

only me, but for, but for like, I think, Evan, you or Rich Harris

Noel

Yeah. Right, right.

Ryan

like, like they, they announced hooks and people were just like, and people were excited about them. And I think people kind of on the peripheral, on the outside were like, wait a second, you guys made such a big fuss about plane data, re rendering, blah, blah, blah. I mean, react has somehow set the fashion people. I don't know what they were scared or

Noel

Mm-hmm.

Ryan

believe, like I, I was pessimistic. Um, and somehow they were like, no, it's okay to have these kind of data primitives a week. You know, rich is talking about spelt three. Like that's where the compiler idea and like using like

Noel

Yeah. Mm-hmm.

Ryan

the hooks thing. Evan was like, oh, we're gonna pull out our stuff into the composition API for. Solid already was there,

Noel

Yeah.

Ryan

wasn't a shift. I, this is what I had been building.

Noel

Mm-hmm. Yeah. Yeah. Do, do you think that this, this, this kind of push, this push was, um, this is maybe not, I I was gonna say inevitable, but, uh, the, the place I want to get here is, is, is less, less than that. I'm, I'm more, I'm more curious if you think that the, the, the fact that these, there's kind of this convergence, right? Like on this idea that we're, we're talking around of like eventually at some point for performance, the developer has to dictate. When things change and how data should flow when it does like this, the kind of signal idea, the, and giving that back to developers, which I think hooks kind of also encapsulates manually one way or another.

Do you think that that's like, needs to be a more fundamental, like, should that be a web primitive, should the browser be doing that? Like, that just seems like we've, we've all arrived at this conclusion.

Ryan

I mean, that's where it does seem like it is today.

Noel

Yeah.

Ryan

which is. Interesting. Uh, in its own right. I mean, the browsers had proposals for different types of change management being built in for years. So I'm always very hesitant, you know, going to standards, trying to be careful

Noel

Yeah, of course.

Ryan

but yes, it does seem like we are, we are developing a language and I, I do wanna call it a language, um, for reactivity. Um, and this is not a, a language that I think we even invented. If you. Talk to somebody, I'm sure in the academic field there, this language has existed for a while. I

Noel

Mm-hmm.

Ryan

we just kind of self discovered it ourselves. Um, but there is definitely a language and I think for me it was always important because I like control. I like, you know, as things scale up, I need escape hatches. I feel like it's necessary, you know, as senior dev to be able to, you know. Not go too far into my abstractions. You want to have, decide how much you buy into stuff. You know, like how much, at some point things will change. I think it's an even more interesting topic today because when we talk about designing a language for ui, um. You can't not think about AI and like LMS and all that and all that kinda stuff. So like, that alone makes it almost inevitable because we might have built it 'cause I wanted more control, but, uh, I think the machine, so to speak, want, wants more control as well. And giving them a, you know, a primitive that's like one step up is a lot more powerful for them. You

Noel

Yeah.

Ryan

you can argue that something like react is simple, um, because of these constraints and it just kind of reruns and it makes it easier for things to understand it in a certain way and just kind of, but it, it is not at nearly as powerful. Like there's a difference between, know, a lot of times with frameworks you want to restrict power because you give too much to the users, then they'll do bad stuff.

Noel

Mm-hmm. Yeah.

Ryan

I. If we're going to a, a future where we're, you know, building these where we're maybe not building things we're, you know, maybe AI or something, building things, then having power is actually really important because it will empower it to build better stuff.

Noel

Yeah.

Ryan

For me, it was always about empowering people because I. Uh, people like myself,

Noel

Mm-hmm.

Ryan

who knew what they're doing, people who wanted to get the best, you know, out of their tools. But it, it's definitely interesting. Sorry, I didn't mean to veer off into ai. It just, it's, I, there is a certain inevitability here I think, um, that hopefully like. It, it, it's always like a back and forth, right? Like primitives are an abstraction. It's, it's about finding the right boundaries,

Noel

Mm-hmm.

Ryan

initially you might

Noel

Yeah.

Ryan

a really crude abstraction and be like, this is pretty good, and gets you going, and then later you refine it and when you refine it, you can get lower level. It's like the same process when, you know, frameworks build something and then eventually gets into the browser. You like, you kind of do something kind of basic and kind of works, and then hopefully by the time it gets. Into, you know, standards. It's actually something that's well-defined and maybe even simpler or smaller piece, like something that's actually more, uh, extensible. Something, um, more, um, yeah, adaptable.

Noel

Adapto, I think adapt. Yeah. Adaptable is a great word. And I, I, I don't think it's, that's too, it's too far off the kind of off the, off the rails here a notion, because I think, I think you're right. Like I think, I think it's hard for agents, like, you know, whatever, LLMs or whatever, whatever's operating on these things to kind of do, like, be operating at the level that the frameworks in the meta frameworks or op like kind of ask the user to operate at.

Like, it's just like we're so. It's so hard to ha kind of have, have all of the context that a developer has. I think were especially like a, some, someone that really understands the internals of the framework they're using. Like it's just, that's not, not what we've seen with the agents thus far. So I think, I think that that is like an interesting notion. It, it, it does kind of beg one to compare like a junior dev stepping into the space doesn't feel that different than an agent. Right. It's like, okay. These are kind of both, like they're just looking at what's exposed and lots of examples online and trying to do the thing as best they can. So like, there's an interesting kind of discussion one could have there, but I don't wanna send us too far down the, down into the weeds here.

Um, so I guess, yeah, let's just like, kind of real quick and then I want to, I wanna kind of get to our little quick lightning round questions. But before we get there, do you think that in general, this notion of devs, you said that kind of when we began talking that you. We're surprised at how much devs seem to be okay with the magic, right? Like, do, do you think that that is maybe like what's, what's causing this pain or like needing to understand the magic of hooks was kind of part of this problem? Or like, like what, what, what is the thing that's driving devs to kind of have this collective understanding that there is like maybe, maybe I need to actually have control of my tools a little bit more.

Ryan

Yeah, I mean, the problem is you, you can always add another abstraction, right? You can always, um, you know, make things easier and then easier and easier. But then you restrict it and at certain point you have to break. You will break outta the abstraction, which means that My personal opinion is the bigger the gap is between these abstraction and the need of depth you need to get to the underlying system, the more complicated everything will feel.

This is

Noel

Yeah.

Ryan

React, use effect is a problem. This is completely actually why.

Noel

Mm-hmm.

Ryan

first time people realize how React works, and I. I think that as our tools get more complicated, generally the hope is that you don't need to peel the layers. You know, let's build a compiler on top of our framework to, you know, not have to worry about this. And then they

Noel

Yeah. Mm-hmm.

Ryan

you know, and like auto memorization and all like, and a certain point, it's like it. If that abstraction is, has no holes, then you're right. That will be easy and good to go and maybe you won't need that knowledge. But I don't, I haven't found that to be reality, which means that we do have, we are carrying this weight on on us, and the only way to solve it is not to come up with another abstraction on top of the abstraction.

It's to actually remove abstractions. Like go, okay, now that we understand this. better. How do we change the model? Yes, we need abstractions. We need primitives, but how has our understanding allowed us to actually change the foundations? And that is key. 'cause that's, at a certain point, that's the only way you simplify. There's, there's, there's no, you have to take stuff away. You can't just keep on adding, um.

Noel

Yeah. Yeah, yeah. Well said. Well said. I think that that's, that's probably as good a point as good a point to wrap as any let's, uh, let's do some, some quick fire questions and then we'll, we'll wrap properly. Um, I have, I think I have a hunch, but some of the answers will be here, but we'll see. We'll see if I'm right. Um, what's a tech buzzword you wish would go away?

Ryan

Um, I mean, I don't know if I necessarily want to, to go away. I just, I, I'm, I, the, the AI related stuff is just. Too much for me. Maybe I'm just not in the loop, but I, I think I, I think it's an exciting area in a certain sense, but for me, I, it, it, at least it doesn't impact me that much because I'm working on mechanical stuff. So it's, it's, it's this kind of thing that I, I, I just haven't, I am, I'm just. I know it's funny to say, but it's something that I, I don't spend that much time. It's only when I come on podcasts like here that I actually end up thinking about it all that much. Um, so I don't know. I guess anything that's like over-hyped like that at the second, I guess specifically, I think, uh, vibe, coding, you know, the, I, I, I get it's good for prototyping, but it's at a certain point engineers need to engineer, so, you

Noel

Yeah, I'm, yet, I'm yet to be convinced. I've seen like a couple little, like very, very isolated examples of it happening, but I just can't, like I, I'm yet convinced as. On vibe coding specifically. I think AI stuff's there. I'm, I'm here for the day when ai, like we aren't, it's not like advertised. It's just like, okay, this thing uses ai, but like, as the user, you don't really need to know about it.

It's just like how it's getting its thing, its thing done. But we'll see. That's neither here nor there. Uh, what's one idea you had about web dev in 2015 that you still believe today?

Ryan

Yeah, I mean, we talked about it almost this whole, uh, stream. It's the, the idea that like, you do need to put. in, um, you know, people's hands to a certain degree. You don't need to know how to build your tool from scratch, but you at least need to understand what the abstraction is, you know, so I think it's important that, you know, w you know, things aren't too magical. I think, I think, you know, at the base you need to at least be able to have a good mental model of things, and that's what led me to build solid. It was about transparency. It was like, you see, what you see is what you get.

Noel

Hmm.

Ryan

Um, yeah, that hasn't changed in the last 10 years.

Noel

Gotcha. Nice, nice. What's the biggest myth about performance in front end Frameworks?

Ryan

Oh, man. I, I mean, I don't know if it's the biggest, but this one always, this, this one bugs me enough. Like, 'cause I. It, it's the, it's this idea that like, by adding a technology, like say, adding signals to something, suddenly it's faster. It's, it's, it's the same fallacy I was talking about earlier, Rob, but just

Noel

Hmm.

Ryan

more abstractions, adding more things, that makes it faster. The re like the reason signals frameworks are fast is because they remove something. Like if you have signals and you make that your core, then that, and that's all it's doing. Then that can be, you know, really performant. But if you. Say your signals with your virtual dom. Well, you're probably on the overhead of the virtual dom and the overhead of signals.

You, you're kind of getting the worst of both worlds. You know, like just taking your, you know, react and jamming signals into it won't make react faster. It'll probably make it slower. Most definitely. You know, and that, that's why, you know, when people ask the React team if they're gonna move the signals, I mean, no. They have a very clear path and that path. exclusive to this. Like, sure, you can use it for state management, but it, it's not gonna like improve, react. All of a sudden the you, the, there are architectural constraints. Not every feature, it's just something you can nail on

Noel

Mm-hmm.

Ryan

now it's better.

Noel

Yeah. Gotcha. Yep. I, I agree. I agree. Okay. This, this, I'm, I'm, I'm, I'm gonna go slightly off script on this one. Can you think of a specific, like either project or type of project wherein this kind of fine-grained reactivity is necessary and like virtual dom and like diffing, like this doesn't, just doesn't work.

Ryan

Uh, honestly necessary. No, I, the, these, these technologies, I think there's benefits for ergonomics. I think there's benefits for performance, but I. I don't know if there's anything where it's like, you need this because the beautiful thing about the virtual dom is it's like relatively good enough for most things and, and the thing is people were fine reloading webpage for a long time. I think that idea of like what. The need is, is, uh, a sliding scale and people's expectations will rise.

Noel

Mm-hmm.

Ryan

there's places that obviously Fine grain really excels, which is places where you're doing lots of minuscule data updates, things like, you know, large tables or dashboards or, you know, stuff like that. Um, I, I just, I, I, I, it's not a matter of you can or can't, you know,

Noel

Mm.

Ryan

I guess another really cool example is people using it for video games. Like

Noel

Yeah. Games. That was gonna be my point, is to see how like really like up games with a ton of data flowing in and out. Yeah.

Ryan

because one of the interesting things is, uh, we've seen a lot of, we have a, we have like a three js, uh, universal render port, like one of our custom renders in three Js.

Noel

Yeah.

Ryan

if you look at like the React solution, people actually have to opt outta the React state management. Like they use a whole different state library to actually do it performing. Um, you might still want to do that with all, but you don't have to, like the, the signals are performing enough. You don't have to worry about like re-render.

Noel

Mm-hmm.

Ryan

so it, it's, it's, it is actually works quite well. So I, I think like, there, there are situations where it makes a lot of sense. Uh, I, I, I said there wasn't, um, low memory devices are still a thing. Uh, we're very, very attractive on television devices. That's actually where some of our, like bigger

Noel

cool.

Ryan

things like, uh, universal NBC like solids used on television

Noel

Oh, neat. Neat. Mm-hmm.

Ryan

or something like that. Like, and like we had some interest even from Netflix in that zone. It just, it wasn't a plug and place swap from React, so it wasn't as easy to make that move.

Noel

Yeah.

Ryan

But for them, but like generally speaking, like there are places where it makes a lot of sense to have these qualities, but a lot of places like it will be good enough. I.

Noel

Yeah. Yeah. Very cool. Very cool. Yeah. The, the games example is gonna be mine. Exactly. I've got a couple, I've got a couple side projects where I'm very much hitting this, just like, uh, I've got a ton of data flowing in and out that's like changing really quickly, and I'm like, I'm feeling it a little bit as I'm like dragging stuff and moving stuff around. I'm like, I. This is react I'm fighting or react here in a way I don't wanna be. Um, so I'm glad you, I'm glad you called that one out. Um, this is kind of a question more about you. What do you think is the hardest part of maintaining an open source project that most people aren't cognizant of?

Ryan

Um, yeah, I mean, it's, it's interesting. I mean, I don't, I say I don't know if it's not actually that interesting. It's, it's just. There's a lot day to day. I mean, I don't know if people, pe people will come in and they'll see their issue or their thing that they care about. And the truth is, when you're source, your work is always in public. So like, like there are so many different people you're catering to and that you're like, you're directly talking about public. There's, there's no insulation in the way.

Noel

Yeah.

Ryan

I've worked on. Product teams and companies and you know, there's customer success team or whatever, like open source, your, your customer are the developers and you're interacting with them directly. So like, I, I don't know if this is like a hidden thing, but it's just, there is like huge amount of just like bookkeeping in the sense of like, not like money or anything, like just PE people

Noel

Mm-hmm.

Ryan

Capabilities and projects. Um, and I, people generally only come in for their, like, narrow slice, so they don't see the, the, the, the breadth of it all. Um, so

Noel

Yeah.

Ryan

it, it's, it's hard to keep on track of it when you also want to build stuff or you want, you know, you know, uh, try new ideas and, and, and whatnot. So like, it's just like. like, you know, you just get, get a, you know, issue. You always hear, I guess, I guess there's been more visibility on this recently where you see open source maintainers kind of like respond back to, you know, rude people or

Noel

Yeah. Yeah. Yeah.

Ryan

And, and, but it's just like, there's those people in one extreme, but like there's everything in between. Um, it's just these projects end up. Small, but they become massive. Like,

Noel

Yeah.

Ryan

and it often without the infrastructure that you would find it like a funded company. So,

Noel

Mm-hmm.

Ryan

um, yeah, I mean, that can make things, uh, difficult. Uh, at times.

Noel

Yeah, yeah, yeah. There's not, there's probably not a lot of open source product managers that are just like, okay, I'll do all of the product triaging and everything, and then I hand it off to the developers.

Ryan

any chance you can ask me the question you skipped over?

Noel

Oh, yeah, of course. Um, the, the, uh, sorry, hold on.

Ryan

What's one fine, one thing? Fine grain reactivity can do that. The

Noel

Yeah. Yeah. What's one? What's one thing? Fine Grained reactivity can do that. The virtual dom just can't.

Ryan

Yeah, it's funny. Normally I wouldn't say like any technology can or can't do anything. 'cause you can always work around it and find the escape

Noel

Mm-hmm.

Ryan

you know, like find ways to like make it work. So it's like, in your project, I'm sure there's a way you can make it do what you want,

Noel

Yeah.

Ryan

there are benefits, uh, that, that people are only starting to realize right now, especially seeing, you know. Fine grain rendering coming into stuff like, uh, salt five or View Vapor,

Noel

Mm-hmm.

Ryan

start seeing this community start kind of thinking about like how we approach things differently. And I think the thing that people don't understand is by writing your code this way, you are giving your application knowledge of how data flows through your app. Um, and this is incredibly powerful because it does mean you can do things that just don't make sense or don't work in the virtual dom, like for example. You can, you know, fetch some data somewhere in your app and if that data errors out somewhere, you know, deep where it's being used like say rendering and you like hit an error boundary or something. Well, you retry the error boundary. In, you know, a typical virtual dom library, like I think this is why React doesn't have an error boundary component. It doesn't know what to do. You have to kind of fix the error so that the next time it re renders or whatever, it knows it that it will be corrected.

Otherwise, it's just gonna arrogant.

Noel

Yeah.

Ryan

with a fine grain system, 'cause you know the data dependencies, you can be like, oh, let me retry what errored and trace the data graph all the way up to the data fetching and be like,

Noel

Mm-hmm.

Ryan

I'm just gonna re fetch what failed. Like, and this kind of power is incredible, right? So like you can picture, you, you have some data fetching, and then as I said, lower down, you're like, try render something with that data and it fails and you're just like, oh, I'm gonna retry. Maybe the user has a button they can click, can

Noel

Yeah. Mm-hmm.

Ryan

And this is because the program understands the graph. And, um, this is, this is this capability. People, you know, are only starting to realize it's now getting built into applications, um, because of, you know. Solid Js or you know, view vapors felt like when you start writing your code this way, be unlocking other capabilities like this. We've seen advantage to this, like in debugging you can actually be like, oh, like visualize the graph, like. And I'm, I'm looking forward to, you know, these kind of things working their way into more, into like developer tools, like

Noel

Yeah.

Ryan

IDE support and stuff. Because like what if like, you can use the data dependency graph to know, like when you edit code, what, what part of your application could be impacted.

Noel

Yeah. Right, right, right. Yeah. Like what, what, what needs to reload, like what tests need to run all that. All that stuff. Yeah, that, that could be very cool.

Ryan

So for me, that is some huge benefit to using fine grain reactivity that you don't really get with a virtual dome.

Noel

Nice. Nice. That's, I feel like, I feel like that's good as good a note to end on as any, um, yeah. Thank you. Thank you for pulling that question outta me and thank you for coming online and chatting with me. Uh, Ryan, it's been a pleasure as always and I'm looking forward to next time.

Ryan

Yeah, no, it was a lot of fun and uh, I always have a lot of fun. I, this podcast is definitely one of my

Noel

Awesome. Awesome.

Ryan

you guys are, I have something new to share, I will be back.

Noel

Nice. Happy to hear it. Happy to hear it. Thank you.