So is Solid kind of like React but easier to use?
[dead]
Solidjs: Simple and performant reactivity for building user interfaces
71–80 of 190 posts
Re: Solidjs: Simple and performant reactivity for building user interfaces
#72Has anyone used both Solid and Vue? How do the two compare?
Both use signal-based reactivity, both are heavily optimised at compile-time to ensure only the parts of your app that need to well change at runtime. Vue uses single-file components, SolidJS uses JSX. That has a surprisingly large influence on how you develop with the frameworks, because it's a lot easier to create new components if those components are just regular Javascript functions, as opposed to being new file…
As someone that likes Vue and prefers templates that lost me at JSX.
Which is of course entirely a matter of preference.
Re: Solidjs: Simple and performant reactivity for building user interfaces
#73Earlier quoted context omitted.
Low count suggests that the project has an intentionally built core and doesn't undergo churn or feature creep. It's also a good sign that commits per week have decreased substantially over time. Contributions being mostly from a single developer lends further credence to that idea, because it implies everything is fueled by one person's relatively opinionated vision and taste.
This conclusion is deeply divorced from reality. A single(-ish) author is the strongest smell for a library. I've been burned countless times by a project's "BDFL" moving on to something else. Sometimes a new maintainer will take over, but it's rare. Low commit count also suggests unresponsiveness to issues that are filed, especially for a TypeScript or JavaScript project. This thread single-handedly convinced me not…
>Low commit count also suggests unresponsiveness
SolidJS (Ryan mostly) is very responsive, so the low count is more a sign that there are not many issues which require code changes in the first place. Which is good!
>Sometimes a new maintainer will take over, but it's rare.
SolidJS really doesn't need a full-time maintainer at this point. One or more community members fixing severe bugs and keeping it up to date is plenty enough.
Re: Solidjs: Simple and performant reactivity for building user interfaces
#74Having used Solid on a largish web product for over a year, I am thoroughly convinced and will not be returning to React in the future. This is somewhat of an aside: I am aware that the creator of Solid has long been experimenting with adding laziness to the reactive system. I think it would be a mistake. That everything is immediate keeps state changes intuitive, fairly easy to debug, and is one of the strong points…
React has lived long enough to become the villain, and it's way too entrenched. It was certainly a very important step forwards in webdev, but it now probably has more gotchas than vanilla JS does.
[dead]
Re: Solidjs: Simple and performant reactivity for building user interfaces
#75Earlier quoted context omitted.
Both use signal-based reactivity, both are heavily optimised at compile-time to ensure only the parts of your app that need to well change at runtime. Vue uses single-file components, SolidJS uses JSX. That has a surprisingly large influence on how you develop with the frameworks, because it's a lot easier to create new components if those components are just regular Javascript functions, as opposed to being new file…
As someone that likes Vue and prefers templates that lost me at JSX. Which is of course entirely a matter of preference.
> As someone that likes Vue and prefers templates that lost me at JSX.
Thank you very much. I once said, "I cannot stand JSX", and two front-end engineers went silent for the rest of the meeting.
Re: Solidjs: Simple and performant reactivity for building user interfaces
#76Genuine question:
Why would you use Solid instead of Svelte?
I'm coming from React and most alternatives seem quite similar to me. Only Svelte does things very differently with its compiler. Vue and Solid just seem to be a different flavour of React.
Re: Solidjs: Simple and performant reactivity for building user interfaces
#77Earlier quoted context omitted.
I've found the ecosystem to be perfectly serviceable for every complex piece of functionality I needed to bring in: remote state, forms, tables, and routing, come to mind. Complex state management can easily be handled using the library's standard reactive primitives and the community "solid primitives" project has a ton of well made utilities so you don't have to reinvent the wheel for common use cases. I'm not goin…
Cool. I am a bit of a minimalist (one reason I've never felt the most comfortable with React compared to some other things) and equally not interested in bloat and differing opinions/principles from using component libraries for everything (and I almost never use them for UI) but, yeah, I also don't want to have to write my own high-performance basics. A few years ago when using Vue for something, I had to detour a l…
[dead]
Re: Solidjs: Simple and performant reactivity for building user interfaces
#78Genuine question: Why would you use Solid instead of Svelte? I'm coming from React and most alternatives seem quite similar to me. Only Svelte does things very differently with its compiler. Vue and Solid just seem to be a different flavour of React.
[dead]
Re: Solidjs: Simple and performant reactivity for building user interfaces
#79Genuine question: Why would you use Solid instead of Svelte? I'm coming from React and most alternatives seem quite similar to me. Only Svelte does things very differently with its compiler. Vue and Solid just seem to be a different flavour of React.
I haven't used Solid yet, but it is commonly said to have "fine-grained" reactivity, compared to React, and better performance.
I also think that Svelte, having a compiler, seems like that it would have an edge in theory.
Re: Solidjs: Simple and performant reactivity for building user interfaces
#80Earlier quoted context omitted.
Low count suggests that the project has an intentionally built core and doesn't undergo churn or feature creep. It's also a good sign that commits per week have decreased substantially over time. Contributions being mostly from a single developer lends further credence to that idea, because it implies everything is fueled by one person's relatively opinionated vision and taste.
This conclusion is deeply divorced from reality. A single(-ish) author is the strongest smell for a library. I've been burned countless times by a project's "BDFL" moving on to something else. Sometimes a new maintainer will take over, but it's rare. Low commit count also suggests unresponsiveness to issues that are filed, especially for a TypeScript or JavaScript project. This thread single-handedly convinced me not…
Low Commit count suggests nothing other than maybe lower traffic. I've been able to keep issues the main repo under 50 issues most of its life. I admit work towards the next major version has let this slip upwards. Also effort is split among multiple repos. Repos where I'm far from the biggest contributor. The core is small and manageable. Which is a good place to be 9 years in (7 of those open to the public).
Yeah exactly 7 years tomorrow. Wow time flies.