very few apps actually need reactivity.
Solidjs: Simple and performant reactivity for building user interfaces
51–60 of 190 posts
Re: Solidjs: Simple and performant reactivity for building user interfaces
#52Earlier quoted context omitted.
Really? So class components are still first class citizens and play well with existing ecosystem code?
> So class components are still first class citizens Yes https://react.dev/reference/react/Component > play well with existing ecosystem code? That's not something the React team has any control over so it feels like an unfair complaint. However, besides external libraries that are specifically designed to work with hooks, I'd say quite a lot of things would still work. And you can always just use older versions of t…
> That's not something the React team has any control over so it feels like an unfair complaint.
Sure it is — they could let you run hooks from within class components. Not only do they not allow that, they actively discourage you from writing class components in the documentation.
Even if they didn’t have control over that, though, how does the complaint feel unfair? When I buy into a tool, I’m buying into the ecosystem as well. If the ecosystem moves in a direction I don’t like, that’s a strong disincentive to using that tool!
Re: Solidjs: Simple and performant reactivity for building user interfaces
#53Earlier quoted context omitted.
> Having used Solid on a largish web product for over a year I am curious about your experience in this regard. I've been aware of Solid for quite a while (and plenty of other non-React alternatives that on paper seem "nicer") but the problem I usually quickly run into after exceeding the complexity of a contrived demo app is the ecosystem not yet having a number of components, library wrappers, integrations, etc. th…
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 lot to writing things like virtual list components because at the time they were not available. (I see Solid has a few of those.) Not ideal for a tiny team or as a solo dev trying to make a dent in something in my off hours
> Luckily integrating vanilla (or "headless") JS libs is dead simple once you have enough experience.
Good to know. I expect to need to write my own wrappers for certain things that are more niche, but some frameworks definitely make it easier than others, and I do tire of wrapping the same 153 events and properties and such for some component yet again when [framework of the month] has an annoying way of doing this
Re: Solidjs: Simple and performant reactivity for building user interfaces
#54I love Solid so much. It has feature parity with React and is faster. However, most importantly, it's just 1,823 well organized commits (1,329 of which belong to the creator). That gives me confidence to keep it around long term. React is unreadable and bloated with 20,368 commits and seemingly unstable with the maintainers always pivoting it around. I like it's semantics, but don't want to deal with updating it long…
Sorry, but number of commits don't say anything about the quality and direction of a project.
React has been around for much longer than Solid, and also much much more popular, with many more contributors. It's also the pioneer of virtual DOM reactivity, when you're a pioneer there bound to be some trial and error.
It can also be argued that SolidJS has a higher bus factor, as it's still very dependant on the creator (Ryan Carniato).
Sharing my experience... A while ago, I wanted to build an app using SolidJS 1.4 but got stuck because of a list mapping bug, ie. child list not updating IIRC. I reached out to Ryan, he said that he knew about the bug and had a fix coming in the next release. I couldn't wait, so I had to port what I had to React and call it a day.
Re: Solidjs: Simple and performant reactivity for building user interfaces
#55Having 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…
[flagged]
Re: Solidjs: Simple and performant reactivity for building user interfaces
#56I love Solid so much. It has feature parity with React and is faster. However, most importantly, it's just 1,823 well organized commits (1,329 of which belong to the creator). That gives me confidence to keep it around long term. React is unreadable and bloated with 20,368 commits and seemingly unstable with the maintainers always pivoting it around. I like it's semantics, but don't want to deal with updating it long…
Sorry, but number of commits don't say anything about the quality and direction of a project. React has been around for much longer than Solid, and also much much more popular, with many more contributors. It's also the pioneer of virtual DOM reactivity, when you're a pioneer there bound to be some trial and error. It can also be argued that SolidJS has a higher bus factor, as it's still very dependant on the creator…
> When you're a pioneer, there are bound to be some trials and errors.
The higher number of commits is, to some extent, empirical evidence that trials and errors were encountered.
> SolidJS has a higher bus factor.
For me personally, the higher bus factor is a feature, not a bug. Ryan has brought the project to a state of relative "completion." I can rest easy knowing that SolidJS would only need to be maintained, not "developed," if he were to leave.
Re: Solidjs: Simple and performant reactivity for building user interfaces
#57Having 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…
I'm using SolidJS for Infumap (https://github.com/infumap/infumap), which is getting pretty big.
Two main comments that come to mind:
Because the state -> DOM mapping is non-trivial for my application, I ended up writing my own virtual DOM diffing code, a primary facet of React. I appreciate the ease of being able to circumvent this where it's not necessary and performance considerations dominate, though I admit i've not felt the need to do it anywhere yet.
The AI training data set for React is much larger. The models seem to do fine with SolidJS, though I suspect there is meaningful benefit to using React from this point of view.
Overall, I'm happy with where I'm at and I prefer the SolidJS way of thinking, though if I were to do it all over again, I'd probably just go with React for the above two reasons.
Re: Solidjs: Simple and performant reactivity for building user interfaces
#58It’s been an absolute joy to write Solid the last few years. After a workday of writing React, it always feels so liberating to come home to my personal solidjs code. When used with solid-primitives it feels very expressive and powerful. But mainly I think reactivity just jives with my mental model better than React’s top-down “rerender everything unless it’s a memo” approach. All that said, concerns about the solidjs ecosystem are valid. For example, if you want to use trpc your options are either to use v10 with an unmaintained adapter, or use v11 but not have the built-in support for tanstack-query that you would get with an adapter. Similarly, if you want to use framer motion, you’ll be a few versions behind the React folks. As someone who loves building my own stuff, usually ecosystem limitations don’t bother me too much, but it can feel frustrating to not get to use all the latest things available in the react ecosystem.
Re: Solidjs: Simple and performant reactivity for building user interfaces
#59Portions of the react community are excited about how it's starting to feel more like PHP with the movement towards server actions in "client" code etc I personally don't like that direction so looking forward to exploring new frameworks. What I've generally liked about React/Next setups is that the code is generally explicit and less magic (I also have gripes with hooks feeling like magic). Things like Vue/Svelte wh…
Yep. Solid js stays true to js. A div is literally a div. And you can use Solid without jsx, and used tagged templates if you so desire.
You can use React without jsx too. JSX is just a very thin wrapper over React.createElemental
``` const h = React.createElement
h('div', { id: 'foo' }, [ h(MyComponent, props) ])
```
Of course the props to divs are a bit different and event listeners/styles can be written inline, but none of this is JSX specific.
Re: Solidjs: Simple and performant reactivity for building user interfaces
#60very few apps actually need reactivity.
A shockingly underrated statement these days. Couldn't agree more.