I think a challenge for new javascript libraries/frameworks is that, for many developers (including myself), we're evaluating the whole architecture. The question isn't, "Which library has the best API and is most performant for rendering components?" It's which choice gets me to "usable app" quickest and most pain-free? Included in the calculation is the ecosystem, the build tools, the documentation, the deployment strategy.

For all these reasons, while I do really love Solid's API, React + Nextjs + Vercel (or another React stack like Gatsby, etc) ultimately provides a smoother development experience for the time being. It isn't enough to build a better React, someone needs to provide an easy to use build and deployment process for it as well.

I ended up giving up on my Solidjs experiments because I spent too much time debugging the build process and porting React libraries. It's still not obvious to me how I could deploy a Solidjs app to, e.g., a Cloudflare Worker and provide a `/api` callable functions endpoint for the application. I have no doubt that I could figure all of it out, but I'm not interested in spending the significant amount of time necessary to do so. I love the fact that Nextjs just gives me all of this. All of this is to say that, while the core Solidjs library is really "solid" (pun intended), I still don't think Solidjs is ready for new projects (unless you really like doing things from scratch).

>Having used Solidjs for some pet projects, I've come to strongly prefer Solidjs over React. It's an evolution of react, so I've found my existing skills/knowledge transfers. This being said, Solidjs is brand new and the ecosystem is minuscule compared to React. For this reason, I plan to continue using React for the foreseeable future. One of the biggest weaknesses of Solidjs is the lack of a "nextjs" like framework. It appears work is being done in the solid-start[1] repo, but it looks like it's still years away from being fleshed out. I want Solidjs to succeed, but I'm not interested in being an early adopter.

The chicken-and-egg ecosystem problem for new frameworks is tough. I've been working on Svelte stuff lately which has a similar problem but less extreme--the ecosystem is still much worse than React's, unsurprisingly, but it's also much better than Solid's right now.

I think Solid's primary branding is around performance and Svelte's primary branding is around it being easy. For getting things off the ground, I think "easy" is a much more successful approach.

Solid has done some branding around performance but the promotion is shifting to be more balanced, as Solid really isn't about performance. Solid's biggest priority has been to give the best DX for building performant applications that stay maintainable at scale and after years of work on the same project. Solid might seem harder than Svelte or Vue to get started with (although this is arguable IMO) but due to it's simplicity I think that it's much easier to master and understand what actually is going on.

Compare this to Svelte which has the goal of creating the perfect high level abstraction so that you never need to understand how things work and was originally created for smaller one off projects with much smaller complexity and no maintenance burden.

This is where I’m at, too — it’s faster and simpler than React, and less magical than Svelte, but it’s just too immature. As another commenter pointed out, there’s basically one contributor: https://github.com/solidjs/solid/graphs/contributors

> Like the author of this post, I appreciate Solid's API because component's only render (i.e. run) once by default and then you define which sections of the component should re-render on changes by using "signals" provided by the library (e.g. `createSignal()` and `createEffect()`). In react, the entire component re-renders on every change and you need to specify which code should _not_ re-run. This was necessary because of the way react was created, but strikes me as fundamentally flawed.

I don't particularly like React, but this strikes me as the one thing it got right; the only "always correct" thing to do is to rebuild the VDOM on any change, so that's the default.

Then you can be more selective about which parts as performance dictates.

That would be true if all a react component was dom output. But since it has side effects (rest calls, mutating state, effects), rerunning everything is the wrong thing to do in almost all instances.

Sure, if you put side effects in your react components, you're gonna have a bad time <insert South Park meme>.

Interesting. I guess it just boils down to different preferences.