Signaling the End of React
Backs, what are signals? Signals.
Speaker 2:Okay. Let me see if I can explain this because I don't think there's an official definition. I think there's a lot of interpretations of what signals can be, but it's actually pretty simple in some ways. A signal is just a thing that you can observe and get notified when it changes. So it's not any different from, you know, like looking at a traffic signal.
Speaker 2:Like, you can look at it, it's gonna flip, and then you know that something has changed. And that sounds kinda simple and, like, why would that be useful? But it is it has become the foundation for a lot of the innovation happening in the front end world, and that's why I it's been coming up a lot more.
Speaker 1:Okay. So the SolidJS is sort of
Speaker 2:the they're
Speaker 1:probably not even the pioneer of signals. I guess Ryan would probably say it was something before that, which was a thing before that. What what is the, like today, signals matter and people are talking about them a lot because SolidJS sort of is gaining in popularity, I guess, and React doesn't use signals. Is that
Speaker 2:a good framing? Yeah. Exactly. And I think there's a lot of frameworks adding signals or having signal like concepts in them. I think for this discussion, it's probably easiest to scope it just to Solid, mostly because I think for this wave of signals and, like, thinking about reactivity, that is Solid was the one that kick it off.
Speaker 2:And I also personally think that they have the best maybe implementation is the wrong word, but signals are just one piece of what you need. And I think the way everything comes together in solid and exposes signals to you, I think for me, I think it's the best implementation so far. So, yeah, if you're looking to get into it and understand what's going on, I think it's good to look at the way it's used in Solid.
Speaker 1:So could you sort of juxtapose just talk about the trade offs. So React does something different. It has a virtual DOM Mhmm. And it's like the UI is a function of state, and that's different from the way Solid works and the way signals work. Could you kind of just, like, lay that out for me so that my dumb brain will understand the difference?
Speaker 2:Yeah. So I'll give it a shot. So I think first, we need to think about how React works. And I think a lot of us are obviously super familiar with this because most of us have been doing React for years and years and years, and we're we kinda take a lot of how it works for granted. But it's good to lay it out to understand how, you know, it compares to Solid.
Speaker 2:So in React, you have the concept of components. And I think that's why a lot of us use React. We like breaking our application up into components. And the way you define a component in React is you you define a function. And the job of this function is to say, given some input properties, what should the UI look like?
Speaker 2:So the function is a it's not right to think of this as like, oh, this is a way to do components with functions. It's really the way React does components with functions. They make you define it as, like, every anytime we need to know what this should look like, we're gonna call this function and your job's spit up spit out the like the like the JSX tree that it should display. Then React is a hard work of saying, okay, given you're saying the UI should look like this, let's look at what the UI already looks like on the screen and figure out what's actually changed and we'll diff it and we'll patch the UI so it it matches. And anytime there's any kind of change in your application and your system, it re triggers all the render functions across your whole app, figures out what the UI should look like, and then it repeats this this patching process.
Speaker 2:And this works incredibly well. It seems like it would be slow. It seems like a waste of of computation, but it does work really well and it was kind of a huge, like, burden, ease of burden. When React first came out, it was way easier to reason about than the way we're doing things before where we had to think explicitly about, okay, this thing happened, like, let me go find the element in the UI and go change it manually. So that was a big innovation and and and it made a lot of sense.
Speaker 2:I think as React change over time, and honestly, as UIs change over time, there's a we're doing a lot more complex crazy stuff on the web now. There's been some challenges with with this model. It still is pretty performant, but there are cases, especially, you say you're rendering, like, a large table or, like, doing anything with a lot of elements on screen, these render functions start to get kind of expensive. And there's a question of, one, can this be more performant? And two, there are a lot of cases in React that are, like, tricky and hard to reason about, especially when the hook stuff came out, like use memo and passing dependency arrays, like, free in to pass that in.
Speaker 2:You know, use effect was a thing that came out that we were all using, and then eventually realized, oh, we should actually never be using this. So there's been a lot of history with React and as great and successful as it's been, I think a lot of us when we're using React, despite us having years and years of experience with it, it's been kind of like, why do I still not feel good at React? I still feel like I'm struggling. That's what got me excited of looking at something an alternative. And I found Solid JS about maybe two years ago now, and it looked a lot like React, but the model is completely different.
Speaker 2:So I just talked a lot, but does that make sense in terms of how React works?
Speaker 1:It it does. But that last thing you said, the model is completely different. When I look at Solid stuff, and I'm just very new to it, but it doesn't look that different. I mean, I know I know it's JSX. But even, like, the difference is, like, you have to call the function of your thing instead of just like placing it in the brackets.
Speaker 1:That it all seems very similar. Is it mostly just the underlying way it works is so different, but it feels very much like writing React
Speaker 2:or no? Yeah. I think that what you're describing is accurate and it's a pro and a con of Solid. So a pro is when you're moving a Solid, you immediately are like, oh, I know how all this works. I can, like, build UIs, and you you will.
Speaker 2:Like, you start to use Solid in your first day, you'll be shipping a lot because it looks a lot like React. But it's kinda deceptively the same. It's same in the in JSX and it's all familiar. I personally went through a phase where I
Speaker 1:was like
Speaker 2:I basically built a pretty complex app over the course of a month. And then I was looking at stuff, and I was like, wait a minute. I actually don't understand anything that's going on. And I just kinda recreated all this complexity for no reason because I was just bringing React patterns over.
Speaker 1:So That sounds like every time I build anything with any technology. But go ahead. Yeah. Exactly.
Speaker 2:So I think it took me, like, a month or two to kinda untrain my, like, React brain to really think in terms of Solid. And there is a little bit of that learning curve, and it's deceptive because you don't expect it. Usually, when you find something that has a learning curve, you just are completely unproductive, so you know you don't know anything. But with SOD, you kinda think you know something, but then later you realize, oh, no. This is how it actually should be.
Speaker 2:So let let me let me get into the you're right. It looks similar, so let's talk about what actually is different. So Yep. I said earlier that in React, component function is a render function. Like, this is the job of this function is to compute the HTML that comes out of it.
Speaker 2:And Solid, it looks very similar because a component function, again, it receives props, it returns some JSX, but it's not a render function. It's a setup function. So the way to think about it is when a component first shows up on screen, your SolidJS component function is called once. And its job is to return a template, and it's never run again. So everything in the body of your SolidJS function only ever runs once.
Speaker 2:So there's certain things that you do in React that make a lot of sense. Like, you can do a conditional and return null. And if that condition changes, it it's fine. Right? Because it's the function's gonna run again, and then the next time, it's gonna return an actual thing.
Speaker 2:That actually makes no sense in Solid because your component only ever runs once. The job is to return it. It's gonna set up the component, and from then on, it disappears. And even at runtime, the constant to a component doesn't really exist in Solid. When it's running, Solid doesn't see your HTML, like a bunch of different components.
Speaker 2:It just sees it as one giant HTML document. And so this has, like, a bunch of so this is fundamentally like very different. Right? And the way this works is when you return the template, Solid looks at the template and sees it kinda like creates holes in the template. It says, okay, like this part of the template, let's say your template is like you return a div, it says, hello, my name is and then the name is like a is referencing some signal.
Speaker 2:Right? It punches a hole in the template saying, okay, here are the static parts of the template. Here's a part that changes. Let me look at let me observe the part that is changing. So basically, it creates a subscription of, like, my name.
Speaker 2:And then whenever that changes, it'll then, like, surgically go into your DOM and then, like, replace that hole with the new value while the rest of it remains static. And the benefits of this is one performance. Right? There's no diffing process. It basically like, your app renders once and it basically keeps track of the parts of your app that are static, the parts that are dynamic.
Speaker 2:And whenever something of the dynamic parts change, it can just go it knows exactly where in the DOM to go, make that update. That makes sense?
Speaker 1:So you have to use yeah. It does. So you have to use signals for any part of your UI, the actual template that changes over time. If it's if it's going to change, you can't just do the way you described was very much stuff I do in React where you just like you you just count on the fact that this is gonna run every time anything changes and you can compute like kind of like derived properties from other pieces of state. Yep.
Speaker 1:Can't do that in Solid. You do everything you need to change in the UI needs to be sort of driven by a signal. Yeah. Is that Yeah.
Speaker 2:And and ultimately, the primitives are actually very similar. So a signal is effectively a piece of state, and you can, you know, change that state over time. It can be a number. You can
Speaker 1:add Similar to used state.
Speaker 2:Exactly. Similar to used state.
Speaker 1:Just like that. Okay.
Speaker 2:Then the next level is, you know, derived state. So let's say you have a signal that's count, and then you have something that's, like, double count. So this is count times two. Mhmm. So that second piece of it is, like, kinda it is state, but it's, like, derived from another piece of state.
Speaker 2:And then you have effects, which are, okay, when something changes, I wanna run this logic. An effect is kinda just like observing a signal. Those are the three primitives. It's honestly very similar to React where you have use state, you have use memo. The thing that's different in Solid is you don't have this dependency array concept.
Speaker 2:So in React, when you say use memo, you have to pass in, okay, here are the things that that we're gonna watch. If any of these things change, then rerun the memo. In Solid, there's something called auto tracking, so you won't ever pass in. It depends your array. It knows what signals you're referencing in your little callback, and it knows that whenever any of those signals change, it needs to rerun the callback.
Speaker 2:So it's kinda that's really nice because you're not, like, debugging, oh, why is this why isn't this memo rerunning? Oh, I forgot to pass in something in dependency array. And it's one of the nice things about Solid. The downsides of it are you might you know, it's it's maybe a little on it's a little less explicit. Right?
Speaker 2:Whenever you have auto tracking, it's a little less explicit, which means you might run into situations where you accidentally, like, track something. You've got created a pen you didn't mean to. But, you know, these are my this is kinda like blowing up on Twitter as, this is a huge deal. I think in practice, it's one of those things where you, like, mess up, and, like, three seconds later, you realize you messed up and you just fix it. And over time, you get better at this, and it feels entirely normal.
Speaker 1:Yeah. I wanted to talk about that too, just kind of the discourse right now. Like, Dan from the React team has been calling out, like, here are the real trade offs and and sort of framing React as making the right choices. Could you maybe better explain, like, from a practical standpoint, because you build real stuff with these things. Could you explain, like, what are the real trade offs you're making if you choose Solid over React?
Speaker 2:Yeah. So I'm gonna give my unfiltered opinion right now. So so get ready.
Speaker 1:Please do. The juicy stuff.
Speaker 2:The thing that's a little bit frustrating for me with what's happening on Twitter is I think the conversation has kind of evolved into, like, not really a great place. I think I actually think all this is good for Solid, and I'll explain why. What you're starting to see is people are posting examples from Solid that make it look silly or confusing. And we know given any framework, there's always examples like this. Right?
Speaker 2:Like, I can go make funny examples in React of being like, look. This creates an infinite loop or, like, look. Like, this you know, isn't this like, you can't call a hook in an if statement. You can make anything look kind of dumb just in without context. And not lot of not a lot of people have, like, experience building real applications with Solid.
Speaker 2:So it's hard for people to tell when they look at the snippet of, like a snippet that looks obviously dumb. By the way, the snippet that was being shared on Twitter, the linter there are some linting rules you can turn on in Solid. It would have actually caught that. Similar to in React, there's linting rules that catch, like, the rule of hooks thing. But, you know, people don't have that context.
Speaker 2:So when they look at it, they're like, oh, this looks really bad or, like, this looks really intuitive or this looks confusing. But in practice, you know, having built like, I have a I mentioned this on Twitter. Like, I have a production solid application. That's probably the most complex application I've ever built that I've been building for over over a year now. So me looking at that snippet, I'm like, yeah.
Speaker 2:That's kinda you kinda posted broken code that doesn't really make sense. And, yeah, technically, it doesn't work. But in practice, this never really bothers you that much. Just like with any framework or any language, there's some things you kinda have to learn initially. And you learn it and you never think about it again.
Speaker 2:So it definitely fell into that category. But it started to blow up more where, you know, people from the React team were quoting it being like, this is the exact problem with signals. This is why the React team never went down this route. And they were a little defensive. I think I think what Dan said was, I think they're getting a lot of people saying to them like, oh, you guys are dumb.
Speaker 2:You never even thought of signals, which definitely isn't true. Like, they they spent a lot of time thinking about this. I'm sure they thought about this model. And for whatever reason, chose not to go to it. So they're defensive saying, yeah.
Speaker 2:We did think about it. This is why it sucks. This is why we didn't use it. And here's a trade off we made and why React is better. So one, that's great for Solid because now it's they have never put Solid at the same level as React before.
Speaker 2:It's always been like, oh, Solid, like, cute little project that, you know, Ryan works on. But now they're saying, like, oh, they are, like, the diametric opposite of what we what we you know, what they're claiming they did, which puts them at the same level. Simultaneously, it's kind of a bad move on their part because I don't really think I know they're saying this. I don't know if I fully buy the React team story that this was a very explicit decision because these are two trade offs they saw. Because it's not entirely accurate because it's based on this idea of, like, there's some fundamental trade off in Solid that's not really there.
Speaker 2:So if people do buy into the story of these are two equal trade offs and they start to explore the trade offs, they're gonna find that, oh, it's gonna look like the Solid trade off was always the right choice because there's not really that gotcha is not like a real gotcha. Yeah. So it's interesting. I don't know why they've ramped up they've ramped up in this way. It might not be super intentional.
Speaker 2:It might just be because a lot more people are annoying them about this. But to me, it's like, this is this is really great for the Solid community.
Speaker 1:Is the the bundle size I know you don't really care about this because it's like, users are well, maybe you do care about it. But, like, users are using apps like this, these single page applications for long sessions. It doesn't matter if. But, like, does it matter? Because to me, the 200 kilobytes or whatever of uncompressed JavaScript that React is just sort of, like, speaks to how old and large it is in my mind.
Speaker 1:Yeah. And it just feels like if if React if Solid can give me even 90% of what I enjoy from productivity with React and it does it with five kilobytes of JavaScript or whatever it is, like, it just feels like that feels better.
Speaker 2:Yeah. Exactly. That's so there there's that and there's kind of what the bundle size represents. My feeling when using like I said, remember when I was first using Solid and what I created was really over complicated. And then when I fixed all that, I'm like, wow.
Speaker 2:What was all this stuff I've been doing? Like, web development is so easy. So that that, like, the extra bundle size also kinda maps the more complexity that's in in our brains. With Solid, I kinda feel like I'm using I kinda feel like I'm back to using jQuery plus, like like, a nicer component framework on top. I'm back to using stuff like, you know, query selector.
Speaker 2:I'm back to, like, grabbing elements and, like, mutating them. I'm I'm not in this, like, ref nightmare that you have with React where you're, like, anytime you need to touch a DOM element, it's, like, the worst thing ever is you avoid doing it. So there's just so much
Speaker 1:Or you wanna use a library that needs to interact with the DOM. Like, you you gotta find React versions of everything, which granted it's a huge ecosystem. There are React versions of most everything.
Speaker 2:But There's just like a mismatch with the way the browser operates and the way React operates. So you're always, like, in the caught in the middle of that where with Solid, it all really feels like it disappears. It barely feels like a web framework. It more just feels like here are a bunch of useful React to primitives, then you can kinda just go use, like, the normal web stuff that that has gone a lot better since, like, when React first came out.
Speaker 1:So can we talk, like, big picture, zoom out? Like, everyone on Twitter's sort of, like, at a fever pitch these days around new things coming out and that's always been the case. And a lot of people will say, well, people have been saying like React was we're gonna see the end of React for years and it never happens. Do you think things are fundamentally changing in favor of the field versus React? I know it's not a competition, but it kind of is.
Speaker 1:I mean, like, people are choosing new things for greenfield projects, and the the mind share has been largely in favor of React for a long time.
Speaker 2:Do you think that's changing at all? I think what people need to remember is there's like the absolute truth and there's a truth within a bubble, and they both actually matter. The absolute truth is most websites are on WordPress. Right? Like, that's a fundamental stat.
Speaker 2:Yeah. Bunch of like like you said this morning, a bunch of them are using jQuery. And forever till the end of our lifetimes, there's gonna be a ton of React websites. And this is all fundamentally true. So, of course, you can always people can always say, like, oh, it's dumb to say it's under React because, like, you know, the cool stats.
Speaker 2:But then there's stuff if you scope that down to a bubble, stuff starts to look a little bit different. Right? The best engineers that are out there, the ones that are the most into what they're doing, what are they getting excited about? When they look for their next job, like, what are they gonna be excited about? When the company is starting a new application and they have the opportunity to, like you said, greenfield that opportunity to to, like, start fresh, What are they gonna be excited about?
Speaker 2:Where are all the opportunities for actively maintained apps versus apps that are, like, kinda on life support being phased out? I think that's why, yeah, there's always new stuff coming out. There's always a lot of energy around it. And I think people are frustrated because they're like, oh, this stuff is so small. But it kinda represents, like, a majority of the future.
Speaker 2:So for me, I am never gonna be starting a new React app again, except for that React Native app we just started. Because, you know, React Native is still still dominant, at least for now. Yeah. But I I'm never gonna be starting one again. I don't think I'm really gonna be willing to work anywhere that is using it.
Speaker 2:So, yeah, for me, it's like it's dead for me. And I think for a lot of people that are
Speaker 1:Yeah.
Speaker 2:Starting new stuff or, like, kinda really excited about this stuff, like, they're gonna see it as a benefit to be able to work somewhere that, you know, is using some of these new patterns.
Speaker 1:Yeah. And I mean, these people, it does matter to the React maintainers, I'm sure, that, like, the topic on Twitter might not always be React. Like, even if it's still a small bubble of, like, power users, the discourse does seem to be shifting away. And it it from the outside, I don't know these people, but it does seem like it's bothering them a little bit. Yeah.
Speaker 2:I I I would I wish I could just remind them that they were insanely successful way beyond anything else by comparison. Like, one, there's I was saying the other day, there's a whole documentary on React. Yeah. What? Yeah.
Speaker 1:Framework has ever gotten a documentary.
Speaker 2:Like, that's that's incredible. They've been around for so long. They've gone through and they've I think they've kinda so for me, if if if a product can cannibalize itself, like, that's really impressive. React used to look a lot different. Class components, like and now it looks completely different.
Speaker 2:They basically launched two successful frameworks. Been around for, you know, ten ten or so years. So that's that's really impressive. Anything in tech lasting ten years. You know, I work on SST.
Speaker 2:I would be shocked if we last ten years. So, yeah, it's it's it's impressive, but, you know, nothing can really last forever.
Speaker 1:Yeah. So it's it's not the end of React. React will be here forever, but it is it's kinda the beginning of the end for React, at least in a bubble.
Speaker 2:Yeah. I think so. But it's funny because that stupid cliche quote, the one that's like the reason I hate it is because there's that really cringey video of Elizabeth Holmes saying it. So I think she, like, killed the quote, but it's the the whole, like, first they ignore you, then they laugh at you, then they fight you, then they then you win thing. I feel like Yeah.
Speaker 2:Solid just entered the they fight you phase. Because because, like, they were kinda like, mean, Ryan's been working on Solid for five years. Most of Solid's history, he's been ignored. Yeah. Then it was kinda like, oh, like, you know, it's like a, you know, a cute little thing.
Speaker 2:And then now it's they're at the same level. So you can see where this is heading.
Speaker 1:Cool. Well, I'm I'm definitely excited about it. I'm I I thought I was gonna use it. I guess one other question kinda getting in the weeds. This is not a thing to wrap up the podcast with.
Speaker 1:But from, like, a progressive enhancement standpoint, if you're building, like, mostly a site I know sites versus apps is, like, a dumb generalization. There's a lot of nuance. But if you're building something that's mostly a site, but you have little bits of interactivity, do do Solid and other sort of SPA first, like, frameworks make sense to, like, progressively enhance your site? Or are they more like it needs to be
Speaker 2:a SPA? I feel like Astro had just made this question really simple.
Speaker 1:I'm using Astro.
Speaker 2:Yeah. Exactly. It's just like just use Astro when you don't feel like you're gonna build in a single page application, and then then the interactive bits are just like whatever framework you like.
Speaker 1:So Yeah. I've done it. So it's just the island Yeah. Exactly. Thing.
Speaker 2:So I've done a few things in Astro, and I've always used Solid with it because that's the one that I like. But it kinda doesn't matter at that point. It, like, kinda solves all those problems for you.
Speaker 1:Okay. That was a terrible terrible question to ask.
Speaker 2:Well, I'll take it. We'd wrap
Speaker 1:this up. You had, like, gotten into philosophy with, like, an Elizabeth Holmes quote and all this. And then and then I asked that question. Okay.
Speaker 2:Gotta bring it back down to Earth always.
Speaker 1:Gotta bring it back down. Yeah. This has been fun. It's fun doing this podcast again. I enjoy it quite a lot.
Speaker 1:Alright. Alright. See you, Dax.
Speaker 2:See you.
