Stick with SolidJS, or switch to React?(twitter.com)
twitter.com
Stick with SolidJS, or switch to React?
https://twitter.com/samuelstroschei/status/1643305843360686081
3 comments
Now that Preact supports signals as well, it serves as a nice middle ground between SolidJS-like performance and semantics and the React ecosystem for when you really need it.
I've been thinking about this. I'm surprised it's not being talked about more. Preact's signals library even supports React, though from what I last heard not with its current (concurrent) rendering mode.
I've seen Jotai mentioned in the thread and now I wonder: Is it exactly what signals also do? Is it just the same thing? It seems to take state out of the component in a very similar way.
I've seen Jotai mentioned in the thread and now I wonder: Is it exactly what signals also do? Is it just the same thing? It seems to take state out of the component in a very similar way.
Everything around signals is a bit ambiguous...
The decision for SolidJS, and likely the differentiator to Jotai et al., is simplicity. The reactive system (signals) are de-coupled from rendering. SolidJS is not doing a good job communicating that fact. The de-coupling leads to a simple reactive model that works in plain JS and thereby JSX too.
I recommend this video https://www.youtube.com/watch?v=J70HXl1KhWE
The decision for SolidJS, and likely the differentiator to Jotai et al., is simplicity. The reactive system (signals) are de-coupled from rendering. SolidJS is not doing a good job communicating that fact. The de-coupling leads to a simple reactive model that works in plain JS and thereby JSX too.
I recommend this video https://www.youtube.com/watch?v=J70HXl1KhWE
If speed is your primary concern, sticking with solid is a good idea. But given that there main issues are with state, Vue would be a better middle ground with better ecosystem than solid, but much more performant than React
The primary concern is performance. The editor is anticipated to become a VSCode for content (documents, video, audio, etc.).
The state issues we have right now are non-issues with SolidJS. They don't trigger re-renders and thereby don't degrade the user experience.
RE Vue JS: The nice thing about Solid is that state is de-coupled from rendering. I thought that building complex state with Solid will be easier than frameworks that couple state to rendering. I haven't evaluated VueJS in depth though. Here is an RFC I wrote about choosing Solid https://github.com/inlang/inlang/blob/main/rfcs/tech-stack/R...
The state issues we have right now are non-issues with SolidJS. They don't trigger re-renders and thereby don't degrade the user experience.
RE Vue JS: The nice thing about Solid is that state is de-coupled from rendering. I thought that building complex state with Solid will be easier than frameworks that couple state to rendering. I haven't evaluated VueJS in depth though. Here is an RFC I wrote about choosing Solid https://github.com/inlang/inlang/blob/main/rfcs/tech-stack/R...
> The state issues we have right now are non-issues with SolidJS. They don't trigger re-renders and thereby don't degrade the user experience.
This is because of fine grained reactivity which is same for solid, vue and svelte.
>The nice thing about Solid is that state is de-coupled from rendering.
Are you referring to the part that solid components "disappear" at runtime? Or that solid signals can be used outside of components?
First part is unique to solid. But vue and solid both share the second part. Vue's composition API can be used outside of vue. Alpine.js uses vue's reactivity internally
I looked at that RFC and i found it interesting that Svelte was considered, but Vue wasn't, even though Vue is more mature, more popular, and more performant in js framework benchmarks.
That being said, it is not that important.I believe even if you did consider Vue, you would have still gone ahead with solid. Because Solid is more performant focused, and to make best of Vue performance, you would need to switch from jsx to template
This is because of fine grained reactivity which is same for solid, vue and svelte.
>The nice thing about Solid is that state is de-coupled from rendering.
Are you referring to the part that solid components "disappear" at runtime? Or that solid signals can be used outside of components?
First part is unique to solid. But vue and solid both share the second part. Vue's composition API can be used outside of vue. Alpine.js uses vue's reactivity internally
I looked at that RFC and i found it interesting that Svelte was considered, but Vue wasn't, even though Vue is more mature, more popular, and more performant in js framework benchmarks.
That being said, it is not that important.I believe even if you did consider Vue, you would have still gone ahead with solid. Because Solid is more performant focused, and to make best of Vue performance, you would need to switch from jsx to template
>> The nice thing about Solid is that state is de-coupled from rendering.
> Are you referring to the part that solid components "disappear" at runtime? Or that solid signals can be used outside of components?
My mental model of Solid's reactivity is "plain JS". Components are also "plain JS" with a bit of syntactic sugar that auto injects one effect on render. No hook rules etc. That should make reasoning about Solid apps easier (in theory) and we might use the reactivity system outside of UI. In particular, we need to develop a filesystem implementation for the browser that could benefit from Solid's reactivity system.
> I looked at that RFC and i found it interesting that Svelte was considered, but Vue wasn't
I started my web dev journey with Svelte (coming from Python + Flutter). The first prototypes were built in Svelte. It became clear that Svelte might be too restrictive for a complex SPA. Solid felt/feels like a baby of Svelte + React.
> Are you referring to the part that solid components "disappear" at runtime? Or that solid signals can be used outside of components?
My mental model of Solid's reactivity is "plain JS". Components are also "plain JS" with a bit of syntactic sugar that auto injects one effect on render. No hook rules etc. That should make reasoning about Solid apps easier (in theory) and we might use the reactivity system outside of UI. In particular, we need to develop a filesystem implementation for the browser that could benefit from Solid's reactivity system.
> I looked at that RFC and i found it interesting that Svelte was considered, but Vue wasn't
I started my web dev journey with Svelte (coming from Python + Flutter). The first prototypes were built in Svelte. It became clear that Svelte might be too restrictive for a complex SPA. Solid felt/feels like a baby of Svelte + React.
My firm has stopped using an outsourced asian React development company due to massive budget cuts. It was great having 24/7 project movement. Project leads, business developers, analysts, ui/ux could all work 9-5 European/American Times, and then as the slept, the Asian workers would develop the frontend. Most questions they would have, would have already been thought about by the Project Developer Leads.
But now we have major budget cuts and layoffs, so we need our existing backend developers to do more. Really everyone needs to do more with less.
We've been looking into HTMX over Javascript frameworks. It's actually looking good since a lot of our business apps expect the business to have a high speed internet connection.