Solid 2.0, AI Coding, and Building for Agents with Dev Agrawal

Yeah, they've been going pretty well, actually.

I would say that when AI coding kind of got popular, there's definitely been some air of almost like pessimism, where people feel like they don't want to think or they will eventually not need to think about frameworks and languages.

And I feel like a lot of it is kind of like, carry over from framework hell and JavaScript fatigue.

People were actually tired of thinking about JavaScript frameworks a lot.

And AI kind of gave them a reason to stop having those conversations and instead focus on something else.

But I think frameworks are probably more important than ever.

And I think my conviction in Solid and Solid 2.0, which we're working on right now, I think it's higher than ever.

Because I've spent a lot of time building apps with AI.

And I want all my agents to use Solid, because it's just better.

And we can get into all the specifics, but yeah.

I think there is a big school of thought from people out there where they're just like, hey, Dev, why should I use SolidJS when my LLM just spits out React and it all worked perfectly fine? I'll say I'm a React developer, so I would ask myself this question.

What would you want to tell me, man? Why would I want to give SolidJS a try when I've been using React now for going on like six years? And honestly, I'm kind of touching the code a little bit less these days than I used to be.

Anyways, here, we'll kind of mark it again.

And Dave, what was it we were getting into? I mean, like I was kind of throwing you the question.

I was like, you know, I'm a React dev, why should I try Solid? You were saying you like to see both sides of the argument.

Yeah, so there's the camp of, like, I'm not going to care about the code much.

I'm not touching the code much.

Why should I care what language or what framework is it using under the hood? And that's a completely fair point.

A lot of times I'm coding and I don't really care too much about the implementation details of the code.

But I think as usual, there is a spectrum of how much the implementation details actually matter.

On one side, if you're building something kind of like as a prototype or as an internal tool, implementation details have never really mattered much in those cases.

They have mattered when we were the ones writing all the code by hand, so obviously we had to care.

But to the end, like users, it never really mattered much.

Now on the other side, if it's like a serious production application, the choice of framework or language doesn't directly impact the user, but indirectly it impacts the user in a bunch of different ways, because between your tool and the user there is the developer, and the developer has to do the job of converting the user intents into the programming language or into the framework correctly.

And if the language of the framework doesn't make that easy, the developer's going to have a hard time, which means the user's not going to get the kind of experience that they want.