Why I still choose React with Chance Strickland
===

[00:00:00] Hello and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics. You can try it free at logrocket. com. I'm Noel, and today we're welcoming back Chance Strickland here to cover his latest conference talk, Why I Still Choose React chance is a software engineer and educator. Welcome back to the show chance.

Noel, good to be here. Thanks for having me.

Perfect. . Where did you give this talk? What's the

Yeah, this was at React Alicante in Alicante, Spain. So that was , a couple of weeks back. So yeah, I had a great time.

Nice. What was the perception? Like where people were like, People were surprised, or did you get any like pushback at all?

overall more when you did well than when you didn't, or when they appreciated your talk more than if they didn't. People are nice like that. I think overall the discussion seemed to be good. Obviously, I don't think everyone's always going to agree with me. It was an interesting time to give this talk.

[00:01:00] Something that I've noticed that a few recent React conferences I've been to is that there have been as many, if not more talks about other frameworks. Which is I just think very fascinating given that it's at a react conference But I mean it I think also to we've reached a point in time where?

React been around now for 10 years and in the software space. That's basically eternity. So you It's just a natural progression of things where as things mature We start to really feel certain pain points It's natural for people to look for alternatives and to look to maybe other models of ways of thinking about their software.

So I think that to a certain degree it's expected, but I do find it very interesting and I think it made the, it provided some good contrast for the rest of the conference.

Nice. Yeah. It seems almost like your talk is a, rebuttal to how much time we should be spending on , looking at react still, but it doesn't sound like that's necessarily your view.[00:02:00] , why do you feel like this talk is essential or what was a pertinent.

A pertinent topic to cover.

Yeah. So I think as the winds do shift and as chatter is about as far as other frameworks are concerned or other alternative models. I think people naturally get this sense of, am I being left behind? Am I thinking about this wrong? Is React no longer the right choice to build software in 2023?

Am I going to need to shift gears in terms of my skills to stay employable? Are there just better ways to do this and I'm not thinking about them? Am I missing out on something? And so I think it's good to, to provide those folks with some some background and thoughts from a person who's been doing this for a little while and who has seen a few of these season changes before.

And for me, at least I just get the sense that either there's like hype and then there's legitimate discourse and [00:03:00] it's hard to distinguish between the two of those. And I tried to break it down in a way that was not dismissive of other approaches or other frameworks. In fact, I was I think I was pretty complimentary of other frameworks and I still maintain that a lot of the alternatives we have today are actually very good.

And React conversely is not perfect. There's a reason that we're all itching for maybe something else. I wanted to show some of the strengths and weaknesses of different approaches and come around to, despite all of this, knowing all of this, having this background. I still think this tool is really fantastic and it's a choice you can't really go wrong with if you are deciding what stack to use for your app in 2023.

Okay.

Yeah, I think historically at least it feels devs, I think have a tendency to just always want to do the new thing, especially if they see a. A critical mass forming around behind something else, even if you don't have everything down on paper, just because I think that, instinct has been nurtured over time because it seems to generally prove true, if we [00:04:00] are, if there is a bunch of support behind something, all of a sudden, like the old tech does start withering on the vine and the new thing is getting all the attention and eventually the job market shifts there and all that.

But it's I think hard to step back and Empirically look at what these frameworks and tools are giving you or giving up when you make the switch a lot of the time. I guess in that vein, what are the fundamental differences just to contextualize this a bit between maybe react and some of like the predecessors, what are the biggest features that react is still giving us today that would draw one to it.

Sure, yeah, to me, It's a number of things. So if you like go back in time for a moment and if you weren't around in the early days of react, I wasn't either, to be fair, like I was not one of the early adopters. And I tried to make that clear too. Like I was still slinging a lot of jQuery code back in the day when react was on the scene.

And at the time there were a number of new tools out that are new to me. I had not actually explored them too much. Ember, Angular, I think were a couple. I [00:05:00] have looked at them since, but, it's interesting talking about like things withering on the vine because Angular is still pumping out strong.

Like I know several folks on the team working on Angular. And I know I actually recently gave a talk in an Angular conference. It's just another interesting experience, but that ecosystem is still thriving. And as React developers we've got this like narrow scope of vision where we we lose sight of the fact that things even older than React are still around and thriving and people are still getting paid handsomely to build things and these other tools.

I think that's some good context to have as well. But as far as the contrast between React and. Things that may have come before. I think there were a few different pieces that that drew people to react. The obviously having a component model, I think it's like a pretty well established thing that most folks in our space find some sort of component model really ideal for for [00:06:00] building UI for being able to ship different pieces of your app and these small little contained.

Units that we call components. I think we've all generally coalesced around that idea. No one's really pushed back on that in quite some time or at least none of the tools that I've actually taken off. So that was not really revolutionary though, because Angular had components, Ember had components, like we had ideas of components, they were just structured a bit differently.

One of the things that React questioned was this idea of separation of concerns, or I like to say, it's like how you separate concerns things that we would normally call like controller responsibility suddenly. Set right next to your view responsibility, right? So that was a paradigm shift for a lot of folks that actually made a lot of people uncomfortable.

But I think, Oh, I think we've come around to that side as well. Cause a lot of the newer frameworks have also embraced this idea of of coupling to a degree. More responsibility at the component level and separating things by concern of components [00:07:00] rather than view layer controller layer models, that sort of thing.

But also I think really, to me, the core thing that set react apart, and this is the point I made in the talk is just that underlying mental model that I think still provides a lot of value and it's a UI as a function of state, right? That's, that was the core selling point for me. And I still haven't found an alternative that can make that promise the same way that React does and gives me confidence that no matter what happens to the state of my application, my UI stays in sync.

And that really was what React solved for Facebook developers back in the day. That was their main pain point was they, they have this very complex web application with a lot of state, a lot of moving parts. You had messages, you had notifications, you had all these tools that all had to rely on a lot of the same data, but might show you different user interfaces to to deal with that data.

[00:08:00] And they had all these synchronization issues as almost everyone did who was building web applications at the time. And as these things got more complex, that the appeal of that and the underlying motivation for that was, Hey, what if we just updated everything when the state changed, right?

Thank you. That to me was the thing that made it clip and the thing that still makes it clip to me. And a lot of the alternatives that we're seeing come about today they, I think they tried to meet you in that mindset, but they don't make the same guarantees or the same promises the same way.

And I think that comes with a lot of trade offs. Yeah, that's the core thing to me that set React apart from the beginning and still as long as other frameworks are, can't find ways to make those same guarantees the same way, then I'm, I don't know, to me, React, just the mental model makes the most sense.

It's the simplest way to think about my application code. Of course.

Yeah, interesting. I'm going to, I want to dive in there a little bit because I feel a lot of the advocates for [00:09:00] these other tools, frameworks would say that no, like whatever their framework of choice also has the UI being a simple derivative of state, like maybe asterisk, unless you do something weird, right?

Like ever, like it should all in view or Svelte or even solid, like this should, it should always feel like core react has always felt, then I think that there. They're, there is edge cases in all of these, but there's also edge cases in react now, like react is a little bit more complicated than it used to

Of course.

Why do you think that react is still the, I don't know, king is maybe an overly strong word, but like the simplest tool to have this just like UI emergent from state as a paradigm.

Yeah, and that's a great point. And I. I, I dedicated a good chunk of the talk in the middle of the talk to explaining a lot of those trade offs and nuances and the things that you can do wrong in, in both react and I use solid as an example, just because that's the newer framework that I'd say I'm most familiar with, at least the underlying mental model.

And yeah, there, there are a number of trade [00:10:00] offs in either direction, right? We all have written the world's gnarliest use effect. I've got one in my code base at work that like gives me nightmares. And it's, stuff like that, I think really is what motivates people to start looking for other alternatives and I get it.

I've been there. I've worked on them. I'm, I work on them today. , we've all got to deal with this code and it can be very complex and. And hard to stay happy with your underlying framework of choice when it's it presents you with these sort of gnarly situations. What I argue is that You know, like a lot of people think that, oh hooks were to blame for all of this complexity.

I don't think that's true. I think we've forgotten how gnarly some of our component lifecycle is. Used to be and the different workarounds we've, we came up with to deal with those sorts of things, like these higher order components that inject this behavioral like magically inject this behavioral component into your UI component from like a different level of abstraction.

And those got really out of control to the point where oftentimes you had, a component wrapped in five or six of these life these higher [00:11:00] order components, and you didn't actually know where the props came from, or you had these like conflicts between. Higher order components. And so there was a lot of complexity before we've moved around the complexity a bit and I think not just willy nilly, like there was a reason for this, right?

Like we wanted to think about our code a little differently and the hooks model gave us an opportunity to compose pieces of specifically behavioral pieces in a way that made a lot of the foot guns before, I think a little easier to control, but they came with their own trade offs and their own foot guns.

And now we have rules. And yeah, it's a part of the the talk also, like I had mentioned, how a lot of us, myself included, used to argue that React was great because it was just JavaScript. And I've made the case that I don't think that's true anymore. And I don't think it's actually been true for a while in the strict sense that oftentimes you write code that in just JavaScript, you would expect to work.

But there are a lot of these magic rules, like you [00:12:00] can't do early returns if you call a hook later, those sort of things where it doesn't feel like just JavaScript anymore because you have React rules that you have to follow that fall outside of the normal idea that, oh, I can just write a function and call it in JavaScript and it's fine, right?

You can't really do that anymore. I don't think that argument is quite as strong as it used to be. But I do think the, I think the newer models like the Hooks model and especially with React server components now, we're sort of extending the underlying mental model of front end React components to the back end, which I think is also like a lot of really cool potential there.

I think what the React team is doing now is digging in deep to the fundamental core model with React server components, especially they're doubling down, they're betting on that model and saying we can extend that to the full stack of the application and make these composable parts extend to the server.

There's a lot of power in that. And it worked for us for years on the front end. I think it can be really powerful for the backend and really. Start to [00:13:00] melt down this wall that I think has been falling for quite some time between the front end and the back end in ways that we haven't fully explored yet.

And I'm really excited about that possibility. Yeah, to me, I guess that's a long winded way of saying the core mental model still makes a lot of sense to me. I still think it provides a lot of value. The other frameworks, like you mentioned they try to capture the spirit of that.

But contrasting solid, for example, your components are only called once. Your component functions are called exactly one time, never get called again. Think of some of the foot guns with that, if you express some value that is not reactive and your your component is called and then it's never called again, but that, and that value updates, but it's not reactive, so your component doesn't update as a result, like you broken that promise there, right?

They have workarounds for this. They know this like solid embraces that shortcomings and has workarounds and tools to deal with them. But, like those are things you need to acknowledge and, this is also just because I've never built a large scale application with solid.

I think [00:14:00] a lot of us, when we see new tools in general, we see the promise and the potential but a lot of these gnarly edge cases, you don't really know until you start building things with them.

Yeah. Yeah.

My friend Ryan gave this talk when they introduced hooks. Back in, I think 2018 and he, I think the name of the talk was it's 90 percent cleaner code with hooks.

And I think having the the gift of hindsight now, I like to say that it's more like 90 percent of your code is probably cleaner. And then 10 percent is like a really tangled, gnarly mess of use effects that you just have to deal with. And that, that 10 percent is what makes us. Look elsewhere, and I don't know what solids 10 percent looks like because I've not had to build that sort of thing, but I know it's there.

I know everyone has like dirty clothes in their closet. And like maybe I can be proven proven otherwise, but I'm, I haven't seen a framework yet that doesn't have its own shortcomings and foot guns and potential for giant messes.

[00:15:00] Yeah. I think back to our earlier point about like developers eagerness to always jump on the new thing. It's like all humans do. I think we have that. I feel this pain point with this given thing. I won't have that if I switch here, but you don't yet have the context to know what all the pain points will be there.

Cause you haven't spent hundreds or thousands of hours, like working yourself into those corners yet.

Yeah. And that's a great example, by the way, like that was another thing when we got hooks was, Oh, thank God. I never have to deal with this anymore. Cool. But now you have to deal with closures. So have fun with that. So yeah, there's a, it's you're trading off things all the time and it's just important to be aware of what they are.

Yeah. Is I guess I'm curious on, on a couple of points you touched on there mainly on like pain points and hooks right now, maybe for people that like aren't big front end devs or aren't thinking about this what are some of these, like, when we're talking about these gross 10 percent of cases, just like to help people understand what do those look like right now?

You typically in a react [00:16:00] code base

Yeah. Honestly, I think it comes down to, I'd say two things. First of all, is a shift in a mental model that I think when we move from lifecycle methods to hooks, people were still thinking in life cycles. And they were writing in hooks, but thinking in life cycles. And what I mean by that is they saw a use effect and they thought, okay, I get it.

When you call the effect, that's like your component did mount and also component did update if you have dependencies, but then when you return a function, that's like component will unmount. And that I think actually got a lot of people into a lot of trouble because that's not like the whole idea of hooks was to think about it a little differently.

It was to think about like side effects running as. An effect of some state changing, like we, we go back to UI being a function of state, like if your state changes and you need to shoot off some sort of effect in response to that state changing so that you can update your UI so that it's always in sync, right?

Like [00:17:00] to me, it comes back, it comes down to synchronization. Like you're trying to keep your UI in sync with your state. And if you can think in terms of synchronization, rather than my component mounts now and unmounts now and updates here, and instead of thinking about the life cycle, I think you're going to find ways to deal with a lot of the shortcomings and skip out on patterns that would would get you into a lot of that trouble.

The problem is I don't think a lot of us made that shift, or I don't think it was communicated in such a way that it really clicked with folks that, Hey, these are actually very different ways of thinking about side effects than all of the life cycle methods. And the new React docs, I think do an excellent job.

There's a page on use effect. It could be a book in and of itself. And it's really, it's really helpful, but I wish we had that back in the day when hooks originally came out, because it was just not how I don't think people made the mental shift along with the, they thought of it more of was like a stylistic change or an API change, really, it was [00:18:00] like a mental model shift to a degree.

Yeah, go back and look at the docs and it was like, here's the old way, here's the new

yeah, exactly. And it was.

have that,

Overly simplified in a way. And it works for a lot of cases, but like I said that 10 percent a case that at the edge case, if you will where you've got like a really complicated behavioral piece or, maybe you were trying to do some some coordination between data fetching and.

Some other side effects in your system or something like coordinating a lot of that stuff can be really challenging. And even if you do make that shift, it can sometimes be challenging, but I think that mental. Shift was the first big hurdle that a lot of people didn't overcome.

And that made the code harder to deal with and it necessarily needed to be. But also, I'd mentioned like the rules of hooks, if you're not familiar with the reactor hooks or what we're, anything, what we're talking about, essentially what we're talking about are just functions, like hooks or functions, right?

They're, they all start with the word use their and they do that intentionally because they're special [00:19:00] functions that have to be treated specially in the context of a component. What I mean by that is you've got the primary rule of hooks is that you can't call a hook conditionally.

Which means if I want to filter out some expensive logic at the top of my component, and I say, Oh, if this condition is not true, bail, but then call a hook later. You can't do that. Because React depends on hooks being called in the same exact order on every single render. Otherwise things can go awry.

So that's sort of a first gotcha. And there are ways to deal with that, right? You can wrap up a hook inside of another component and call that component conditionally. But. Within the context of a single component, you've that's the primary no, don't call a hook conditionally.

And that can be a challenge in certain circumstances. You've also got, like I said, closures to deal with, like you're wrapping up stateful values inside of this closure function. Where if you don't pass the reason we have to pass these dependency arrays and the, for unfamiliar folks, the dependency arrays, you're telling react explicitly.

Hey, you're wrapping up [00:20:00] this value inside of this closure. Here's the value. Here's the dependency so that we know when to recreate this closure so that we have that fresh value, right? Like it has to be able to figure that out. And JavaScript's not quite smart enough to to the point where this function can magically know which values are supposed to be reactive.

So you have to tell it explicitly. Hey, , here are the values when these values change, I want you to recreate this function, recall the function that sort of thing. So that can also be really tricky because sometimes you might write, let's say a side effect and you want it to fire under a given circumstance.

But then a value that it depends on changes, but you don't actually want the function to, to. Be called in response only to that value changing. You just want it to have a fresh reference. And then it's it can be confusing to work around that. I'd say there's like the two primary examples where hooks get difficult to deal with.

Other examples are memoization. So let's say you've got a function being passed down from, four levels of components [00:21:00] and that function is used in a, in a. A use effect somewhere down the tree and, oh, like now it's a dependency, but also that function identity is recreated on every render. So you have to go back up the tree and memoize it everywhere.

But then, oh, that function also has values. It depends on that come from four levels of that tree. So then all of those have to be memoized. And then just to do this one thing, you've now you've got a PR with 90 files that are updated just to memoize the value. That I think. Is also a really big pain point for a lot of folks, myself included.

That's actually, I'd say probably my biggest pain point today. That I think the React team is aware of this and they're working on a solution to that problem specifically called React for Git, which I'm even more excited about that than I am server components. So hopefully I'm begging for them to hurry up and ship it because it makes us a lot happier, I think.

Made me a lot happier anyway.

yeah, I feel like that that third problem is the one that's, it's less of an understanding problem and more of just like a fundamental [00:22:00] problem. tricky like corner case. It's just ah,

yeah it's really easy to get into that situation. And it's really annoying to get out of if you've a lot of that can be solved with with composition patterns, but like that's you can say Oh, you should compose your app differently, but if you've got a team of 20 people who are working on something and it's, you know, I I work at a startup, so we ship things really fast.

And I don't have an opportunity to review everyone on my team's code. Things just happen and your code ends up the way it ends up and now you have to deal with it. , when you do end up in those situations, it can be challenging and really frustrating.

for sure. In the talk, you mentioned signals as an alternative to hooks. What problem, what of these, which of these problems do signals solve?

Signals specifically with this idea of dependency arrays, like you're not going to see that in solid. And the reason for that is that the whole idea of a signal is that it's basically like an event emitter system where if a value changes, do they, [00:23:00] the, I think they use getters and setters internally to basically emit changes to the application so that it knows when to update things in response to some state changing, right?

So if I had a counter and a count state in React, that count state is just a value. And React, because React tracks those value changes internally and recalls the render function when those values change. , you don't have to have any sort of special semantics to make the component aware of that value changing.

Render is just going to get called and everything's going to get updated, right? We're going to say UI is a function of state. That's what I mean. Everything in your render function is a reflection of what your UI looks like when specific stateful values change, no matter. Like, Yeah, there are ways to break that.

I totally get that. But if you follow the rules that they lay out, then that is a guarantee that React makes and it works pretty well. With signals. Those values are no longer values. They're functions because they're going to internally call [00:24:00] a getter. It's gonna retrieve that value, but also in addition it's going to when the setter is called, it's going to emit a change so that getter function can update.

The value in response. So if you, so you no longer have that closure issue I talked about where you're not closing over a value. You're calling a function that can then go and get the latest version of that value. So you don't have to deal with the closure problem. You don't have a dependency array to, to add so that the, you have to manually track these dependencies.

Like it can deal with that internally. 'cause it no longer has to track dependencies, it just has to listen for events emitted by that, that setter function. uh, Yeah, think it does simplify a lot in terms of specifically in terms of side effects and dependency arrays, that last pain point.

I think it certainly helps with a lot of those issues. And again, I've not built anything at scale with solid. So I just like a really big caveat there for anyone listening and anyone who has this experience, you can say, no, you're wrong. I, maybe I'm wrong. That's, I'm totally like upfront about that, just to be clear.

[00:25:00] But You know, like there are some other trade offs that in response to that so the fact that your value is no longer a value means that if you try to, let's say you've got some, like this counter state that comes through via props somewhere and you try to destructure your props. You are when you are doing that you are declaring a new value that is then separated from the its parent object so that getter function, no longer has the context necessarily necessary to have the greater object it's no longer attached to that state so to speak so When you try to call that function to get the latest value it's not going to work quite the same way.

And so you can't just destructure props, for example you can't destructure any sort of reactive value as far as I, I can tell. So that's one potential issue. They've got utility functions to help you with that which I think is really nice. Like the thing I really love about solid actually is they've, they really own up to a lot of the trade offs and they try to model [00:26:00] solid in a way that makes it easy specifically for react.

Developers to understand. And when there are issues that result from a difference between the two mental models they do provide tools and documentation for dealing with that stuff, which I think is great. But so that's one example. I think another example is like early returns. If you early return for a function, everything after that function, it just doesn't get.

evaluated ever because the function is only ever called once. So if you return early and you have all this other logic, then you can't deal with that. So they have utility components to, to deal with that. They have utility components for loops and for if statements and stuff like that. Those are I wouldn't say they're necessarily shortcomings.

They're different trade offs and they're trade offs that I think Going back to the, just that core mental model of I can just write this function, I can express it the way that I can express any of my other JavaScript code. And I can trust that react is going to call [00:27:00] this function again, in response to values changing, it's going to reevaluate these things so that my UI is always a function of this state.

And that's still the core model that I think solid is missing to a degree. Even if it does try to emulate that it's not the same mental model. It is a very different way of thinking about I guess it's semantically more reactive in this way where they call it fine grain reactivity where the different pieces of the the component might change and we're only going to target and update those pieces, but something about saying, we're going to.

Always guarantee that all of this UI is updated in response to any state changes. I think that's what makes react really special. And still, like I said, just to me, it comes back to being the simplest way of thinking about the code that I write.

Yeah. Yeah, I think I agree. And I appreciate your your nuance here in like how tricky this can be because like, it almost feels like a spectrum there's like this, like what is what you get, maybe kind of way of thinking about it, like super simple react, [00:28:00] especially like react prior to hooks really felt that way at the opposite end of the spectrum, there's like much more manual state management where you as a dev have to be much more explicit about what's going on.

So I think it's, I think it's interesting because it almost feels at one end there's you just have to be very explicit and always know what this framework is doing for you and think about it. One might argue, I think I would even argue that then you do end up with less like weirdness, like down the road, like these kinds of weird little edge cases that can be hard to understand what's going on, like with react and hooks, for example, if you're always very explicit and everything's manually, and you're using something like signals, I think it's easier to be like, Oh, I know what went wrong here.

Cause I. Like I know everything I'm being explicit about everything that's happening versus react is doing it for me, but then your code ends up being like much more arduous is probably an overly strong word, but you have to do a lot more just thinking about it when you're setting it up originally and then your code base may end up just being more like.

Complex to think about. And there's a lot more mental [00:29:00] overhead there. So it's just where does your brain fit into this spectrum of what framework works for you is a good kind of way of framing this. I think I got one more question here. We have like a softball one, but I'm going to make it a little bit more tricky.

So I think a lot of people listening are thinking of we've talked about how angular, there was a lot of people using angular still. I think angular is still great for a lot of problems, but also. Postulate that a lot of react devs are very happy. They made the switch early to react. They're like, that was the right move to make.

I like using react now. It's great. What is different now about maybe like reacts relationship with like viewers felt or solid versus like angular's relation or relationship with react in 2016 or 2017. Do you think that is like a false dichotomy or do you think that there is some kind of there's weight shifting and people are moving around.

Yeah and this is a lot of my answer, I think, is just my perception. Thank because I, I'm active in a community of JavaScript and React developers. I see [00:30:00] what a lot of the quote unquote thought leaders are saying. And then I also work with people who don't ever get involved with those sort of discussions or pay attention because they're just busy building and shipping.

And so I think there's two different audiences here where the answer to that question is slightly different. But in general, I'd say in that first audience, that the quote unquote thought leaders, the people who were talking and active and exploring alternatives and who were responsible for a lot of this chatter in the background of, oh, React is dead sort of thing.

As far as that group is concerned, I'd say I see a lot less hostility than I used to,

Yeah.

When React came out, first of all, when React first came out, people were. Not happy with it. Like they, they thought it was the wackiest idea they'd ever heard. Lots of people who are big react influencers now were totally dismissive of it.

And there were, but there were a small group of people who had an open mind who like really [00:31:00] pushed the community forward and then, convince people and people convince themselves by just using it that, Hey, actually, there's some there's some merit to this idea. Let's give it a shot.

So I think first of all, like that, that in of itself, I think was a big difference. You had a lot of people who are really skeptical that this whole idea was even feasible or smart. And. Tools like like solid and I think even a lot of developers or react developers would say, despite the shortcomings, like the fundamental idea makes sense.

We get why you might want to use this tool. But I think, a lot of people also are aware the shortcomings the whole idea of signals is not new by the way. Like signals, as a concept have been around for a long time. And other, frameworks of from many years ago had a con, like a similar concept.

Like even MobX is modeled similarly to, signals which you can use that in React today. The actual concept, the idea is not new and so a lot of people who have worked with that concept or in that framework in the past already understand some of those trade [00:32:00] offs and some of the complexities that you get as a result of that.

So while they might express that and try to make it clear that, Hey, this is not the silver bullet you might think it is. I don't see a lot of the same hostility that I saw, in early React days where people were just completely shitting on Angular for lack of a better word instead of realizing that, Hey, there's a different way of thinking about this.

Which, I get it because if your framework bites you and enough times you, you start thinking, Hey, maybe this thing's not worth dealing with anymore. So I'm going to go and trash it and move on to the next thing. Maybe that's happening with React. I don't know. But from what I see a lot more openness.

I see a lot more nuance than I did back then. So I don't know maybe React changed the paradigm enough to give people confidence that there's not only one way to think about software architecture, and maybe there's different ways to model things. And we don't have to be married to ideas as hard as we think we do.

And maybe it gave them that openness [00:33:00] to explore new options. Or not, that's just my perception. As far as the people who are actually just in the code, not paying much attention to what's going on in the outside space. I think they just want to ship software and so whatever enables them to do it the best and with as few headaches as possible, they are going to be happy with it.

So it's a much more practical mindset and I think that's probably always been true for a lot of those people that you know, and I'm straddled the line myself. I think of myself as a very pragmatic developer, but I'm also. Very active in this social space. I have to rein myself in sometimes and realize that what we're actually trying to do is just make good software.

Cool. Yeah. What a good closing point, is there anything else you want to, do you want to touch on briefly or kind of encourage devs to think about when, making the choice on if they should be using react for a new project?

What makes sense to you and your team, evaluate it based on that. And I think you're going to be in a winning situation. I, I definitely, [00:34:00] personally, I avoid anything too bleeding edge. I think a solid has actually been around a little while now and. I think the ecosystem is picked up in a way that I, it would give me a little bit of confidence to, if my team decided they wanted to use it, I wouldn't be totally afraid of it.

But like I said, it's just, to me, it's about that, that underlying mental model. It's about the simplicity of the way that I think about the code that I write, the expressiveness of the code that I write. I think React still wins for me there, you might think differently. Your team might think differently.

And I think that's okay. There's also a lot of other tools where, we talked a little bit about solid, but Vue's been around almost as long as React has at this point and is still a very viable alternative. Svelte is. Kicking its way through the noise and trying to set itself apart as a viable option.

I, full disclosure, I don't know anything about Svelte other than like its basic APIs, but so I have no, no input into whether or not you should choose that. But I know Rich Harris is a smart dude I trust him with leading my team. So who knows? But yeah, whatever makes sense [00:35:00] to you whatever clicks with you and your team.

There's other strong arguments, I think, like ecosystem strength and diversity of tools out there. And I think React is very clearly still way ahead in that space. But you have to choose what makes sense to you and what helps you build and ship better software faster.

Cool. Thank you. Thank you so much for coming online and chatting with me chance. It's been a pleasure.

Yeah. Happy to.