Struggles with SolidJS (from a ReactJS dev perspective)

[KrischnaGabriel]

Disclaimer: I'm used to using German punctuation so sorry if this text thus reads a bit weird.

Prestory:

I started a new Project and for the front-end I wanted to try out using SolidJS, instead of ReactJS, as working with React showed some design pattern that i dislike like how hooks must be called always in the same order and I wanted to see how other frameworks / libraries check out.

The first part I started building is a graph drawing module from scratch. While creating this, I learned Solid.
All the weird issues I ran into are documented here.

Here a link to the SolidJS app and also a ReactJS app. The React app is there to compare functionality between SolidJS and ReactJS.
https://github.com/KrischnaGabriel/critics-on-solidjs
To initiate the dependencies npm i must be run in both apps.
I will be referencing files of these apps in the upcoming points. It‘s recommended to have a IDE in split view open with the mentioned files.

---

Points of argument

rerunning of functions that use signals

Solid‘s documentations claim that all functions using a signal will be rerun.

(https://www.solidjs.com/docs/latest/api#createsignal)

Crucial to automatic dependency tracking, calling the getter within a tracking scope causes the calling function to depend on this Signal, so that function will rerun if the Signal gets updated.

but that is false. Only functions that provide a value to a JSX-element get updated.

Example

See /solid-app/src/test/SignalUpdates. Focus on line: 45-51

In this example the Main function uses a signals value to return a JSX component.
Upon clicking the button the signal value gets updated. Purpose is to observe if the main function gets called upon a signal update.

Relevancy in real projects & components.

Components that use the value of a signal and dynamically create, arrange and/or modify HTML-elements need to be called/rerun when the signal's value gets updated.

A example would be my graphing module, where the entire graph needs to be recalculated when the dimensions of the containing element changes (these size changes are being observed by an ResizeObserver, that calls a signals setter with the dimension values).

Result:

In the first three ways/methods of returning the elements from the Main function, the signal getter that is wrapped inside a parameter (the "children" property) of another component (a div element), will update upon a signal update.^{[see "incomponent"]}

The first return method does not cause the function to be rerun upon a signal change.
Fair enough, (https://www.solidjs.com/docs/latest/api) defines a "tracking scope" as

... a JSX expression or API calls that build "computations" (createEffect, createMemo, etc.).

A simple function call is not a JSX expression nor a hook, so it's technically compliant to the specs, but it definitely is non-intuitive.

The second return method is a JSX expression, but still the method does not get rerun.
What the hexk!

Only the third option, where the return-value of the Main function is used as the "children" value of the fragment JSX component, the function will be rerun upon a signal change.

This inconsistency is a great way to introduce bugs, caused by unexpected behavior and to ruin a persons common logic.

About the results of 4 to 6 (calling the signal getter and giving it's return-value to the Main2 function as an parameter, instead of calling the getter inside the function itself), I don't even know what I expected here.

hooks

React has some hooks that i don‘t use and don‘t know, but solid,...
i tried reading and understanding the hooks, but i had big issues understanding what they actually do and what they are useful for.

Maybe it‘s just me so don‘t take this argument too serious.

Solids not smart way of rendering & updating element constructs

React has a virtual DOM to which the new elements get compared.
Even when inserting elements ReactJS does a good job at tracking them and only updating what's needed ^{[*see upcoming example]}.

Solid does an even better job which theses atomic changes from signals, EXCEPT if you need to construct complex element-structures dynamically. There, SolidJS falls face first on the ground.

When dynamically created content should be rendered (aka put onto the DOM), it does no comparisons to the existing DOM and replaces everything.
SolidJS makes the task, of optimizing to prevent unnecessary updates, the designers responsibility.

Relevancy in real projects & components.

This would not be too bad, (just results in bad performance) except that when replacing the entire DOM struct also all references to elements are cleared (as those elements are now replaced).

I encountered this in the form of a bug in my Graph module, where a ResizeObserver holded a reference to a, on the next render, not anymore existing element.

Example:

This behavior is shown in */src/test/ElementReferences by having a function that conditionally gives out different amounts of elements (as a simplified metaphor for dynamically created elements). To prove the replacement of the element, I take a reference to a element and change the innerText, after the first render. (Such practices are not recommended in both SolidJS and ReactJS. It is just to prove or disprove an override of the original element.).

Result:

In ReactJS the text of the element remains the newly set value even when rerendering the element, proving it‘s the same element. Also when changing the order of elements React keeps good track of which elements it needs to add, replace or can leave unchanged.

In SolidJS upon a rerender all elements are replaced, as if there was no attempt of optimizing the rendering process at all. Proven by that the text element gets it's initial value "blank", when a rerender occurs.

Positives about solidJS

SolidJS is really fast. When comparing the time it takes to start the app in development mode, of ReactJS and SolidJS, SolidJS with a time of under a second crushes React (about 5s).
Also when hot-reloading, SolidJS beats ReactJS greatly and also the app size of SolidJS is super small too!

But these speed and size differences are unfortunately also the only good things I can name about SolidJS.

---

All in all, I'll likely switch back to using ReactJS, not because it's perfect, but because it does a lot of thing right and is as such the lesser evil.

[ryansolid]

We acknowledge we are nothing like React. And I think trying to force it was basically the source of everything that happened afterward. It is difficult to even really argue against these points because they aren't wholly relevant when using Solid as intended. Rather than wasting time on the details for the moment, it might be easier to summarize your post as:

"Solid makes re-rendering components really hard and inconsistent"
"When I finally make it re-render it is really inefficient"

You attempted to use Solid incorrectly and then complained that it didn't do good stuff. Half of that is on us and documentation, but the other half is on you trying to work around it.

If you are interested in learning Solid in earnest I suggest just working through the tutorial for a bit. Almost everything you brought is addressed there. We wouldn't be super performant in real applications if we didn't have solutions and best practices for the things you encountered. We can do structural stuff without elements all being replaced, you can do incredibly dynamic things without re-running components. And that responsibility on the designer isn't even much of a consideration when you just use the primitives as intended since they will just behave that way.

And if you have questions come by the discord. Strongly recommend it. Tons of people are willing to help. I think if we get you on the right mindset you'd be amazed how different and powerful Solid's approach is for doing exactly the type of heavily graphical stuff you are interested in.

[Jutanium]

Hey, thanks for checking out Solid!

It's my job to improve the documentation and the onboarding experience. Your points are incredibly valuable for us as we work to rebuild our docs. And to be clear, that's how I view your points here: nothing you've laid out is a problem with the framework itself, but difficulties in teaching it.

Will it be helpful to you for me to address each of these points directly? From my perspective, it makes more sense to direct you to specific resources and gather your feedback on them, because it seems like there's a more holistic gap here. Our rendering and state system work completely differently to React, and your experience and expectations from React present a block to learning Solid. Luckily, this is a block that we have a lot of experience helping people overcome.

If your goal is to learn Solid, check out:

• The new tutorial we're working on. This includes asides for folks coming from React, and we'll be working on a special React -> Solid migration page.
• An explanation of tracking
• A video guide to reactivity
• Our Discord, where you can ask the core team any and all questions as you learn!

You title the post "struggles with SolidJS." I'm saddened that this has been a frustrating experience for you, and I'm committed to helping you learn the framework.

That said, you also seem to be framing this as an argument. And you title your example "critics of SolidJS." If your goal is to argue against the framework, I'm afraid I've got nothing to add, but this is the kind of debate that happens regularly on our Discord in the #off-topic channel. I hope to see you there!

[orenelbaum]

Other than what Ryan said, I want to point out that it seems like you are judging Solid mostly based on surface level mechanics. I personally think that if you don't come from React, and you have the right resources to learn Solid (the docs can still use some work IMO), Solid is way more intuitive than React. People who use vanilla JS and never used a framework (even most people who did use a framework) are much more likely to work in vanilla in an approach that is more similar to Solid, because of Solid's intuitiveness and mental model of "create direct reactivity, create a piece of DOM, hook up the reactivity to the DOM, attach to the rest of the DOM" is the most intuitive and simplest approach to doing frontend with JS.
Either way, I don't think that surface level mechanics are such an important piece to focus on. They don't have to be perfect, even if you don't like those mechanics and think that they are unintuitive, they do their job and they do it well. All of those things that you find unintuitive are things that are not that hard to explain and that you definitely get used to. If you actually try Solid for a while you will see that it's not a real problem.
What's more important IMO, especially when comparing to React, is the total complexity of the system. With Solid it's not that hard to understand things in very high detail and with some work you can achieve a complete understanding to the level where you will be able to reason about every usage of the API. React 18 is way more complicated and doesn't really achieve anything that Solid can't achieve (Solid has concurrent rendering, time slicing, streaming SSR, etc. which are modular parts that don't complicate the core). Good luck with understanding every single React API in high detail and being able to reason about the more complicated cases.

Also as for those higher level mechanics, while you might not like that a JSX expression automatically creates a reactive computation (it creates a render effect with the function createRenderEffect), the simplicity of Solid compared to the complexity of React, in combination with fine grained reactivity, creates a lot of benefits for high level mechanics as well which in practice matter more than you having to get used to Solid's compilation strategy and reactive model. Hook rules are only one example, but Solid is overall significantly more composable than React, doesn't create constant complications in your code like React does all the time, especially if you try to optimize things, and doesn't promote further complexity with the model like React does. Porting React code to Solid is often mostly about just removing React stuff that is unnecessary with Solid, cause Solid just makes you do less stuff, less fiddling around with reactivity, once you get into it, it mostly just works. It's not like React where even if you don't care about perf, the moment you start doing more complex things it just gets more and more about fighting with React.

It's really hard to judge it before you learned it seriously and tried getting used to it. It's true for every framework, but for other frameworks usually it's easier to find obvious drawbacks. With Solid it's much harder, while the drawbacks you have mentioned might seem obvious to you, you are kind of assuming that the patterns don't work well in practice. You aren't really mentioning anything that is very obviously bad like bad performance, huge amount of complexity like in React, or anything that is very obviously weird like some of Vue's shananigans with quotation marks in attributes or Svelte's arr.push(x); arr = arr; thing. There really aren't a lot of those in Solid, so it's even harder to judge it before you gave it a serious try. A lot of people give up even before trying or before really understanding and getting used to Solid because they don't like Solid and they feel like it's complicated, hard to use or just doesn't work well. But if you really get used to Solid and understand how it works through good resources, it's much more likely that you'll realize that Solid is just practical and works. You might still not be a fan or Solid, or think that it doesn't scale, but you'll see that it works at least ok for almost everything you try doing with it and that what you think right now are serious problems doesn't matter as much as you thought.

[KrischnaGabriel]

Thanks for not hating me for what seems to be my fault of not understanding solidjs well enough. I'll try to first learn solidjs property and then rectify the problems I encountered. Thanks

[davedbase]

Solid isn't a community that fosters hate or hype. We're passionate engineers and while we are opinionated on topics related to frameworks we will never hate or judge you for your experience or understanding. If we're introducing you to new technology then we should educate you on how to use it. We will provide the materials as long as you're interested in expanding your mind. 👍

[KrischnaGabriel]

I had two issued arousing and need some clarification on the used practices on solving them.

Issue 1 (resolved):

The <For each={}> component only accepts an interable object and I need to iterate using a normal for(let i=0;...) counter loop.
If I would just use a traditional for loop and push the result to the render, on every signal update all components will be recreated and this is what be don't want.

I made a design pattern that does use the <For each={}> component by first iterating using a traditional for loop in a memo and storing the result in an array, over which the <For each={}> component can then efficiently iterate over.

see: https://github.com/KrischnaGabriel/critics-on-solidjs/blob/main/solid-app2/src/App2.tsx
There is one thing still suboptimal and it's not caused by this iteration method. (issue 2)

Issue 2 (solved, but maybe not in a way I am supposed to)

When updating a single property on a object that is accessed trough a signal, all instances where a property of that object is accessed will be updated/rerun, independent of if the used property actually changed.
Simple Example:

const [get,set] = createSignal({a:1, b:0})
createMemo(()=> console.log(get().a )
createMemo(()=> console.log(get().b )

When I now update just the property "a" set(({a:99, b:0}) also the memo, where property "b" is accessed will rerun.
This is what the createStore hook is for and it does work great, except if working with nested objects.
see: https://github.com/KrischnaGabriel/critics-on-solidjs/blob/main/solid-app2/src/App3.tsx

Why would it need to work with nested objects? A parameter to a component may have subobjects, when describing complicated structures and my graphing module is one such cases. The graph can have multiple axis, multiple grids, an axis can have a label which in itself has a object defining it's layout and properties etc. All this data is best represented with nested objects.

My solution to that is a selfmade hook called "createSignalObject". It takes a object and assigns signal setter and getter to each and every property (nested objects too).

See App3.tsx for a simple comparison and
https://github.com/KrischnaGabriel/critics-on-solidjs/tree/main/solid-app2/src/createSignalObject
for an in-depth introduction.

My question is, is using this selfmade hook acceptable or is it a goddam hell spawn to which there exist a better solution/approach in SolidJS.

[KrischnaGabriel]

Addition to Issue 2:

I figured out that I can use createStore to also update nested objects, but here is my proposal:

Example object: {val: {a:1 ,b:0}}
With createStore you have to update nested objects like this set("val",(val)=>({...val, b: 1})) or this set("val","a",33).
That is not wrong and for certain use cases actually very useful, especially the functionality to update multiple nested objects at once, as seen in the docs.
With my createSignalObject hook I can update a nested object by a simple assignment obj.val = {...obj.val, b:999} or obj.val.a = "hi".
This works because under the hood the assignment calls the setter of the underlying signal.
This way of setting nested states is for certain use cases, where you want to update a deeply nested property, much more simple/efficient.

The proposal is to merge both hooks, to get the best out of both worlds.

[KrischnaGabriel]

And also, my implementation checks all properties and nested properties for changes, making my custom implementation more efficient when updating bigger trees.
See the /// biggeer depth addition in App3.tsx

[ryansolid]

You might be interested in createMutable which works like this. Generally I discourage usage though. As much as passing around nested mutable reactivity seems like a good thing it is very dangerous. Enough that I consider generally something one should avoid which is why you don't see promoting createMutable as much. It is just too easy to undermine unidirectional flow of the application and too easy obfuscate the source of change when passed in parts through props. Mutable APIs like this give any child the ability to intentionally or unintentionally play puppeteer on their parents which especially from even a React perspective would be considered a poor pattern.

There is produce that allows local mutation on stores which I feel is probably better, but also is likely unnecessary. We just need maybe a lens like API to make it easier to intentionally give some partial control.

[ryansolid]

Also stores create signals lazily so you don't need to worry about properties you never access under a context that doesn't track. I suppose that does lead to hyper optimization.. like purposefully access values outside of the JSX (like destructuring) so that they don't track and don't make signals.