SolidJS for React Developers with Erik Rasmussen
===

[00:00:00] Hi, 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. Try it free at logrocket. com. I'm Tejas Kumar, and returning to join us today is Eric Erasmussen, creator of Redux Form, Final Form, and here to talk about his latest talk, SolidJS for React developers.

Eric, welcome back.

Thank you, Tejas. Good to be here.

Absolutely. It's so good to see you again. You start off your talk by saying you're not a solid developer would you tell us a little bit about yourself, and let's go from there.

historically I have been a Java developer and then I got into JavaScript and Angular and those things. And then when React was released 10 years ago I immediately saw the value of React the just JavaScript nature of it really appealed to me and I didn't really care about all the HTML in my JavaScript.

I was cool with that. And. I [00:01:00] have loved React from the very beginning and I have been building things in it. And part of that early Adopter experience was running into the bits that , the React as itself did not provide like in the same way, like Angular and other things that are frameworks, not UI libraries.

Provide ways to fetch data and to cache data and to keep form values and things react didn't do that. And so I experienced a lot of that hardship and as such created those form libraries that you mentioned. And. it wasn't until just in, within the last five years that I've actually had React at my day job.

I was previously doing open source with React, but still working in JavaScript and Java land and Angular but I became interested in solid because I've been in the industry for long enough, I've always known that whatever is cool now won't be [00:02:00] eventually, and something is going to replace whatever is the main thing now.

And so I've always kept my eye on the horizon for what that might be. And there have been attempts to replace React that have never clicked with me. But solid was the first time that I was like, Whoa, this is a totally different beast. 

You mentioned a lot of things came and went trying to almost usurp React. I'm curious if you could speak to some of those if you tried any, what the experience was like and why you think they didn't quite approach solid territory.

The ones that I tried there's clearly the big guys that are Vue and Svelte. That I looked into enough to, I don't know, the whole template and solid is a is a template engine, but the the whole template nature of those gave me [00:03:00] bad Angular vibes.

And the fact that it wasn't just that it was this sort of magical JavaScript reminded me of. You know, Your NG ifs and all that

Gave you throwbacks to Ude

yes, exactly. So , I looked at all of them, but I never really tried many of them because , it just didn't. Click with me personally,

Yeah, no, I fully understand. Full disclosure, it's not to say, views, velt, et cetera are bad. But I like how you put it, they didn't click with me, and indeed they don't click with me as well because. There's quite a bit of I'd say friction in my mind when I try to write specifically Vue templates, Vue single file components.

I don't know. I just, I try and it never sticks. I do write Svelte in production to hundreds maybe more users. I can get selt, I get behind selt. Quick. No problem. Solid. No problem. And a big part of that about quick and solid, I feel like is because it really [00:04:00] is very close to react, isn't it?

The a p i is near identical.

In fact. Right. 

in your talk, , you had this pop quiz. What's react, what's solid? I love that. I wonder if you could speak more to the syntax similarities and differences between these two.

right. When I was looking into solid I realized, wow, this looks just like react. And I thought that would be a clever introduction to if you're a react developer, don't be afraid of solid because look at this component. It's actually a valid component in both. Because until you start doing state management or I guess referencing props or something, then the syntax looks very similar.

And in the same way that JSX was such a winner with React because it felt so much like HTML. I think sticking with however horrible, XML is as a way to represent data. It's so reminiscent of what we're used [00:05:00] to that it is an easier cell to, easier to adopt.

Yeah, this is not I feel like this is indeed anecdotal evidence from you But man, I've had this conversation so many times with engineers from react where they all say yes JSX feels natural because it's close to HTML But it gives me things like expressions in JavaScript.

It gives me things like CSS and JS if I so choose where that feels natural and then You know, the natural progression is, something like solid or quick. And this really points me to another conversation that I had with Minko from the Angular team here on, on PodRocket, where we discuss when is Angular going to adopt JSX?

It, Angular is adopting signals, but it still has this... I'd say tarnished reputation because of the Angular 1 to Angular 2 move. And I feel like JSX could solve that, right? So I asked Minko and he mentioned, yeah, it's still a really long discussion. But do you think that could help things like Angular move in terms of adoption?

I would [00:06:00] think so. In fact, I swear I've heard rumors of like JSX becoming like just supported by browsers at some level. Like to become part of what JavaScript is. But again, that's a little more complicated because JSX, like what solid does with JSX is not anything what React does with JSX.

And you could write like your config files in JSX rather than, JSON or YAML or whatever. And you could parse that JSX and do whatever you want with it. So it's an extension of XML. In a weird way, but I think that it just clicks with everyone that's ever, built a div and put a header tag inside it, like it just clicked, like it 

Right. Yeah. You mentioned that, even though the APIs, by APIs I mean JSX, the syntax looks identical for some, if not most components between Solid and React especially stateless ones. I wonder then what the differences are, , so you mentioned two things.

One, the syntax is identical, [00:07:00] but two. They're both very different. How is that? What's happening in Solid that is so different than React?

the component in React is designed to rerender a bunch of times to be called a bunch of times and every time it gets given some props and. Potentially has some internal state and then spits out a bunch of JSX. And of course, JSX can call other components and other things, but that's the general gist.

Like the whole brilliance of React was, Hey. Anytime anything changes, just , redraw everything and don't worry about speed. We're going to handle the speed with this VDOM, virtual DOM magic behind the scenes. And when React first came out, everyone was all upset about their HTML and their, in their JavaScript.

And no one realized that the real genius was the virtual DOM. And then , as the dust settled, we realized, Oh wait, this virtual DOM thing is magical that we can render. It's [00:08:00] just render and forget, like we don't care how many times we re render. And that is amazing for 99 percent of components.

It's just crazy that you can think about here's my state. Here's the HTML that I want to be shown. And that's good to go. However there you run into, the 1% of your components where re rendering can cause trouble and you can run into performance issues.

And what solid does differently is that the component only runs once. The what is the component function. And for React developers, that's the hardest hurdle to get over mentally because we're so used to being able to, Oh, no matter what prop changes, this is going to run a bunch of times.

No. In Solid, no. Solid does this... It's magic and by magic, it breaks the just JavaScript ideal that React notices which [00:09:00] bits of DOM depend on which bits of data. And when those data change, it updates only that bit of the DOM and that's how it gets away with not having a virtual DOM at all, which makes it super fast.

I was told, though, that given, React has the Atom as its logo that, that was what React does. It only computes, it only diffs of the virtual DOM against the real DOM and then applies a minimal subset of changes to the real DOM. 

That's the plan. Yes. And that's what it does, but it still has to do that diff.

ah, and the diff is the expensive piece that Solid doesn't have to do.

Solid makes a note of this is the div that depends on this data. And then when that data changes, it only changes that, that div in the DOM, as opposed to here's the whole app again in the virtual DOM, and then you have to calculate, Oh, this is the bit that changed.

So it's not necessarily that virtual DOM is slow, as many people have said, it's just that this diffing algorithm can be a lot slower than just having some [00:10:00] piece of UI subscribe to an updater somewhere saying, hey, when you change, let me know so I can change myself.

It seems necessarily slower to. Iterate through a tree as opposed to, Oh, I'm calling this one listener to this data change.

Yes, I wonder if there's been diagrams and runtime complexity, big O's around this where, in a virtual DOM tree, if n is the number of elements you need to iterate through, then it's that, but I, since you don't need to iterate through a number of elements in solid, I guess you'd, instead of, and if n is the number of elements in both cases, then in solid, it wouldn't, Be that right it would be some other variable that is the number of signals or reactive values you have so Components aren't even a factor anymore in computation cost

It's just what depends on what signal.

That's amazing. And I guess , when people listen to things like this and , they see a lot of hype around signals, the fact that Svelte has runes and Angular is adopting signals and Quake has signals, et cetera, this is [00:11:00] the reason, right? They allow applications to be reactive, first of all, actually reactive, and second of all, in a very performant way.

Is that accurate?

Yeah. Oh, should we define what signals are?

I think we just did by explaining the mechanism, but let's do a formal definition too,

Yeah. I couldn't come up with a really good I couldn't find an official definition. So like in my talk, I just came up with a thing that I said a signal is a value that remembers. Whoever reads it and like by reading it, you're implicitly subscribing to it. And whenever that value changes, the reader is being told, Hey this thing that you depend on has changed, which is very elegant.

And we've done this in several different places with like observables and even my final form library has that sort of concept as well. But , that's what gives solid its powers.

right? That sounds a lot like the PubSub pattern in a way, right?

right. Exactly. subscribing to a value. Yeah.

well, You [00:12:00] don't subscribe necessarily to a value, you subscribe to some publisher somewhere. So Solid probably has an implementation detail that keeps an array of everything that depends on a signal and... At some point iterates through it when the signal receives an update.

I assume it must work like that but what's crazy is that you can then have what are called derived signals where any function that consumes a signal or seven whenever any of those change that. Whoever consumes that derived signal is also notified, which 

Wow.

So it's signals calling signal. Yeah. So it's like signals all the way down at this point. I also heard something around solid stores, which is still signals, but with deeply nested objects. I'm curious if that's even accurate, if you could speak more to that and how. It affects this whole reactivity pattern we've been discussing.

I haven't gone so deep into stores, but yes, that's the general idea is that say you have [00:13:00] An array of items that you're looping through and then you click it, we'll use the old favorite of a to do list, right? So you've got this array of to dos and you check one of them is done.

You can update that value in this store. That is this array of these to do's and through some hand wavy bits of signals that I have not actually dug all the way into then solid knows that it's just that one. Row that needs to be updated in your DOM.

So it sounds like the name of the game is it doesn't get more fine grained than this. 

Exactly.

so if I understand correctly, the reason that React and Solid Code Can look the same while both systems are doing entirely different things.

So it doesn't even have a virtual DOM is because of declarative programming on social media. There's, I saw a recent post where somebody, I think it was Ryan Florence saying, I still don't get what react, what [00:14:00] declarative. Programming means, and then a bunch of people showed up to mansplain it to him.

I'm wondering if we could get you to do that to me here on the podcast, which maybe not mansplain, but if you could break down declarative programming and then, contrast that with imperative programming, just for our listeners briefly, that'd be really helpful.

So, imperative programming is where you tell the computer how to do a thing, how to do a calculation how to like in, in my talk, I talked about how Back in jQuery land, we would used to have to say, when the document is ready, then, find this button and register a click listener on that button.

So that when that's clicked, then you go and you find this other thing and you add a class or something like that. Whereas with declarative programming, you're telling the computer what to show based on what its state is. So \ if this to do is marked as done, then render it with this background or [00:15:00] whatever, rather than when the user clicks, mark this done, go and change the background.

And , that's what react gave us with this. No, just change the state and we'll re render everything. Don't worry about how it renders. We're about how it renders based on the state, but that's all you have to do. \ so that's, what declarative programming is.

And the reactive programming with solid is that, but taken to the next level Of just, this is what to render based on states, but then also connecting the state to what is rendered,

this sounds a little bit actually like two way data binding from the angular days is it both? Are we seeing a resurgence in that?

It does feel a lot like that. And I remember the first time I saw the Angular 1 demonstration. Where he was just like, just mark this input with NG value and then look it magically the JavaScript value and [00:16:00] the input are in sync. , I never really understood who owned the value there.

Was it the JavaScript or was it the DOM? And that was always confusing to me. But here the data clearly lives in the signal object itself and. And yes, it is it is it's only two way, it's not really two way data binding because what React did, and React's big thing was, this is not two way data binding, this is one way data flow.

Remember, they were very emphasized, no, you set the value and then it re trickles down to, to render your your input or whatever. Whereas this is, That this is the react way of you have to call set and then it will update with whatever the value is. So it's more one way flow than

Because ultimately all the signals are owned by [00:17:00] solid. And their values and their subscriptions trickle down.

right. They're owned by the components. Actually the crazy thing about solid is that you, the signals don't have to be owned by components like state does, because you can just like have a global signal.

What? Okay, I need to dive into this. But before that let's do a quick ad break. LogRocket offers session replay, issue tracking, and product analytics to help you quickly surface and solve impactful issues affecting your user experience. With LogRocket, you can find and solve issues faster, improve conversion and adoption, and spend more time building a better product.

Once again, try it for free today at logrocket. com. Wait, okay, so you mentioned, signals can just casually be global without having to be co located inside a component like, like React. I wonder if you could speak a little bit more about that.

Yeah. So in react the use state hook is bound to the component that it, that contains it. Whereas ironically, a signal is just [00:18:00] JavaScript. Like , it can be outside of the component and can be used. . It can subscribe to in any components.

, you don't have to pass it down or put it in context or anything, it's just a thing that exists. I hesitate to call it an atom, but because of the React's logo, but it feels like that. It's just a thing, a bit of state.

Does this mean then you don't need context? Like, like you have in React and Solid? Because technically you could just hoist a signal at module scope and export it and go like, here's my signal.

I suppose so because I haven't built a big enough solid app yet. I can't really confirm, but I think in solid where context is going to come in handy is for. Things that you just want to pass down to descendants components without the, all the prop drilling like, my mind goes to form data, but that's me. Uh, But your typical example of context is like your theme for [00:19:00] your, dark light theme or dark theme. But that could also be global too. I don't know why that needs to like,

Wow. Okay. So it sounds like you actually don't need context and solid because you can just have global.

I'm sure there are good reasons, but I am a solid noob and I don't know them.

That's fair. We will put links in the show note captions to the solid documentation and other things once we check them. What is flow control? You had some slides around flow control things like I think it was switch was the component or show.

there are several. Yeah.

I wonder if you could talk a little bit about that.

So flow control in the terminology of the solid docs is it's controlling how you output your JSX in react. We've grown accustomed to all these ternary expressions. Like if logged in, then show the logout button colon show the login button or whatever. And that's just the [00:20:00] way we've grown accustomed to doing things in react.

But solid has other ways of just helper components,

like To get around these ternary issues where, and you could totally build these in react, but no one does like there's this show component that where , you give it a win prop. And when that is truthy, then it's going to render the children. Otherwise, it's going to render whatever you put in the fallback prop.

And then there's a switch that is for doing multiple if else sort of logic. And it's just some JSX sugar that JSX look a little bit nicer and more readable. And it feels more like the... Component composition that's react told us we're supposed to be doing, but I don't know.

It's just a bit nicer. And they have a four component for looping over things that is nice because it's due to the magic of signals. Like you don't have to specify a key prop, like you do in react and things like that, [00:21:00] that just some nice sugar for your JSX.

So there's things like for, there's things like show. I heard there was also an index. I don't know what the difference is, but again, we'll have links in the docs, links in the show note captions to the docs for these things. But I think this is exciting, but to be fair, if I'm fully honest with you, this makes me feel.

, like it's almost like React and I think Svelte or Vue had some type of love child, right? Because like these kinds of flow control primitives exist in Vue and in Svelte. For example, in Svelte you have slots. You don't have children, you just have like a slot implicit component that is children.

Why? I don't know. It does look more like component composition. And so I guess. But coming from React I ask myself, why don't I just put children in here? And so, I don't know it's interesting because fundamentally they do the same thing, right?

But, they just look different, and for some, this is a deal breaker.

Look, that's always the case when you change frameworks or languages, like the syntax is going to be like, Ooh, gross. That's not the syntax I'm used to.[00:22:00] But if that is your deal breaker, then you're going to be stuck in the same framework forever.

Again, which I need to emphasize just by the way, which if that's React, it's not bad. I feel like now that we have like shiny new toys, a lot of people go, oh, React's bad. And... Sure, it's slower than solid, absolutely. That's, I think, unquestionable. But, is it bad? Should we not use it? I don't know.

I don't think so.

No I use React in my day job and probably will continue to do so for the foreseeable future. But. To say that we haven't learned anything in the past let's see, React has changed like three times over in the past 10 years, but to say that the way that we're used to doing things is the best way is not a good way of thinking about life.

Like you should always be looking at better ways. And that's the way, that's the way things grow. Like. Look at how we changed [00:23:00] this landscape of JavaScript because Babel came around and was like, let's actually be able to use these these ideas. And it's good that we have this competition for people to copy each other from like, that's that's better for the whole ecosystem.

Yeah, it's it's, I fully, I can't like disagree with that. I think it's really valuable exploring insights and I really need to shout out Ryan Carniato, the author of solid JS, because a lot of it has been his single handed effort, like writing the code, making sure it works, taking inspiration from things like Marco doing the benchmarks, doing the education.

I had the privilege of being at a conference with with. This is Belgium JS earlier this year. And the dude like goes hard. And I mean that in the best possible way, like he does not stop talking and educating ever. Just unbelievable that this one person effort, which is, it's grown now, but a lot of the groundwork being from one person [00:24:00] has become so large that it actually challenges react on a global stage through talks like yours and others.

I think that's just really impressive and worth mentioning. 

Yeah, that's cool. That is an inspiration to anyone that if they want to. Put in the hours, they can potentially, lean on the lever of change.

You mentioned this twice now, where, you, you saw React emerging and you're like, oh, that looks good. I'm gonna adopt this. And now you saw signals emerging and you're like, oh, that's good. I'm gonna adopt this, all the while knowing this isn't going to be the be all end all, but sensitive to the idea that this is going to change things for the better.

I'm curious, practically for our listeners, , how do you do that? Because it sounds like, to quote, Wayne Gretzky you skate to where the puck is going to be instead of where it is right now. How can our listeners, how can our audience leverage some of that for the benefit of their day to day work?

You got to learn to skate first. And then it's.

Intuition from watching things come and go in the past wisdom of being an old guy, but Yeah. Evaluate and listen to what the [00:25:00] community is saying. However, the community can be very hype driven as we know, and just get a feel of does this feel like the right abstraction or whatever, and you're not going to be right all the time, but Yeah, I wish I could give you a, checklist of three things to, to look at to know does this new technology suck or not, but but no, it's just a sense of, oh, I've seen abstractions like that before and they worked or they didn't, 

So it's a lot of, reinforcement based on experience, mistakes. You develop this type of intuition, this type of discernment where you go like, Ooh I think this could work. And indeed it does.

Yeah, and, listen to PodRocket

Ha. Brilliant. Okay, just to bring some balance, because I think , a lot of people are fan personing around Solid these days. We were just at React Alicante and like two thirds of the conference was Solid talks, right? So , I want to bring some balance by way of [00:26:00] talking about things where Solid isn't the best.

Trade offs. So, we're well familiar with React. The biggest trade off being that it's... It's quite slow because of this virtual DOM component. Solid surely has to have some trail. There is no perfect alternative, at least yet anyway. I'm curious if we could outline some of those.

Yeah. So like, as I said in the conclusion of my talk Solid is still a new, infant in this space. And whereas we know all of the pros and cons and pitfalls and things of React, we don't yet know those about Solid because there's not enough of us using it yet. And surely there will be because.

Also a really good question that I hadn't really considered that much was someone came up to me after the, after my talk and said, so one of the amazing things about react is that no matter what you want to do, there's a library for it. What does the solid ecosystem look like for libraries?

And to be honest, because [00:27:00] as I stated upfront, I'm not really a solid developer. But there's no way that the solid library ecosystem, there's not 15 calendar picker components as there are in react. Like it's too, just too young. So a lot of those common problems that. Anyone that's worked in the front end for long enough has needed a calendar picker.

You're gonna run into things that haven't been developed yet in, in solid, so you have to be willing to go to, stub your toe on those boulders on the way up the hill. Whereas with react, . Any lock you need to pick, there's a key for it somewhere.

That's a great statement. Interesting. So it needs to prove itself because it hasn't as improve itself on mass. I agree. And then the second one is the ecosystem just isn't mature enough is what I hear, which, this is framed right now as somewhat of a weakness, but. If you look hard enough, I feel like this is a huge opportunity [00:28:00] for people wanting to get into open source.

That's your come up. You just made a form library for React. And look at you now. 

Know, right?

look at you now. Self proclaimed not a solid developer. Whether you use SolidJS or not, Eric, I think you're a solid developer. But... But there is, so I guess there's a call to action here as well, huh?

If people want to get into open source, use Solid, find the holes, fill them. That will help people individually in their career, but it will also help the library achieve some of that maturity. That's fantastic. Wow.

Yes. A lot of people ask me how do I get people to use my open source library? How do I achieve the success that you've achieved? Success, as in having lots of people using my... Open source libraries. And I always tell them, look, I don't know, man. It was just the right place at the right time. Like , I was there on my surfboard when the wave was cresting.

And this is another one of those situations where if you wanted to really, paddle hard to get on the solid wave, you could totally write it with a open source library. [00:29:00] Boy, I'm using metaphors all day today.

Yeah I love a good metaphor. I want to quickly ask you one, one, one more question about solid that I don't quite have the answer to. And, you mentioned you're a new solid developer, so you might not, we can respect that. But I'm curious, I haven't seen hooks in solid. So I haven't seen things that start with use.

I've seen create signal. Cool. But in react, we use hooks. To hook into React's rendering lifecycle use effect, use layout effect, use sync external store. These literally use effect is just like when you mount, when you hydrate, do this on the client side. What does solid have in the way of like, in the way of lifecycle hooks?

Lifecycle hooks are just anything when you want to run something on mount you call There's like an on mount Function that just you import from solid and you run that Again, you call that in your component, and that's only going to be registered once because your component only renders once.

And then there's an on cleanup thing that you can, that [00:30:00] you do for cleaning that up, but what's beautiful about this is that you can pull those out into reusable in the same way that the power of hooks and react are really , the composable custom hooks. Where you can have a thing that tracks the mouse position or whatever and gives you that.

And then you can write that once and then use it in a hundred different components. And then all those components get that capability. In solid, you can do that exact same thing. You just abstract it into a function. A lot of the solid things that I've seen actually do use the word use something.

Use this, use that just to get the people coming from react, but also it's not a bad verb. But you can have these functions that, that call on mount and on cleanup that will go and listen to some Dom thing.

And give you back a signal. And then you can reuse that function in all your different components. If you wanted to track the mouse position or whatever in a bunch of different components. So they do have custom hooks, , [00:31:00] and those hooks can have their own signals and crap. So \ it's almost like you state and use effect, but not because it's only run once.

Yeah. Yeah.

And I only 

all that, all the power of custom hooks that React has solid. Provides that as well in my experience,

And I guess the benefit is also that they do indeed run once, even if you leave off the second dependency, Which, that's a huge, that's a huge one. That's fantastic. That, that alone is such a motivator. I'm curious you know, a big trending topic within the React spaces.

And again, we're just drawing parallels with React here, because React is the most widely used UI library. We could just as easily talk about Vue or Quick or Svelte if we wanted to, but just for the sake of brevity. React is a UI library. It exports a bunch of functions like createElement and you use them.

But then there's the framework, like Next. js. And also React has been going pretty hard on server components and server side rendering and so on. What's Solid's answer to that? And specifically, does Solid have server components? Does Solid want to go down [00:32:00] that path? Or how's that looking?

All

at solid has a next like thing with the brilliant name of solid start. That does server side rendering and static site generation and. A lot of the stuff that Next. js does, I haven't gone too deep into that, but I have definitely run a project \ to host a solid site on localhost and it feels very Nexty.

, you got your, I think it's even like file based routes and things and handles all the routing and things like that. So they are copying from the best of the best. And , as the beauty of open source is that the good ideas get copied and improved upon. So you can definitely build a website with solid that is solid all the way back to the backend, exactly how much server side.[00:33:00] 

I haven't actually done a lot of rendering on the server, but I imagine. It's going to somehow pass those signal values and rehydrate or something on the front end. But I'm not, again, I haven't done too much of that.

Okay, we're about to wrap up, but I think it would be remiss if we didn't ask you this question, right? You've used solid considerably, although you still identify as a pro as a new, excuse me. So, that said, I think, the best people who adopt. Tools, especially libraries are people who have this like emergent experience, right?

Because like we develop, like, for example, you and I have been writing React for close to 10 years, if not 10 years. And I feel like we have some tunnel vision with React. , it's automatic to us. . Given that solid is relatively new and so are you too solid, what are , pain points you've encountered and what do you want to see from solid in the future?

So I gave my talk as this is an intro to solid from the point of view of a react developer which is. [00:34:00] What I am and my point of view. And so I outlined what I call these different foot guns, like ways you can shoot yourself in the foot when you're trying to write solid code.

And those were things like, you have to remember that signals are not values. They're actually. function that you have to call to get the value. And you have to do that in order to have the reactivity so that the signal itself can know who is accessing it. And then the craziest thing for React developers is that the component is only called once.

There's no concept of re rendering at all. And I was onto my 12th solid component before I really. Got that into my head. And then you need to know that because of the way signals bind to your JSX, to your DOM specifically you need to only use signals in your JSX. You can't use what feels like a value.

It needs to be an actual signal. So that solid [00:35:00] knows what DOM depends on what. And the other really hard thing was to understand that you can't destructure props that come into your component for a long time. I was unsure. Like, are these values? I had like this, like pass by reference, pass by value, sort of confusion.

And then I, finally, I realized that no, all your props are actually signals. If you gave them as a value, then they will be a signal that gives you that value. But if you gave them as a signal, they will still be a signal. And that was tough. Because just have it. Like you say it's ingrained in us to destructure our props.

But if you do that, your solid component will not update. And so things like this, what I want better from solid already. I think there are like linting rules that will catch you if you're trying to output a signal without JSX. Like, I think that's there already to stop you.

And I don't know if there are linting rules to catch some of the other things. Like. What do you think you're doing with these props? Like that'd be [00:36:00] a great rule. So yeah, again, I'm not deep enough into solid to really have felt any of the pain points, but I'm sure they're there and , I also feel pretty confident that the solid team is invested enough in making it a good product.

I'm glad you said I haven't used it enough to have. A lot of pain points, but then you voiced a lot of pain. I love it. That's it's perfect. 

Those are pain points coming from react.

I think once you get in the solid mindset, I think there's a whole other talk of coming back to react from solid, but that'd be fun.

Yeah. Yeah. Listen, Eric, it's been an absolute pleasure having you on the podcast and getting your insights as a self proclaimed noob solid developer. And I think more importantly, as somebody, moving from React to solid and what the pain points look like, what the differences are, what the noticeable performance improvements feel like from me and everyone else at the podcast.

Thank you so much for making the time to come and talk to us today at PodRocket about it.

Thank you for having me.