Solving the diamond problem. We can make guarentees on execution propagation. The core team was talking to me a bit on stream about this problem of over fetching from APIs at times. Also it removes the need for the special mechanisms around Direct Pipe to my understanding. The auto tracking form is easier for templating as you can just drop expressions in.
The diamond problem and sync vs async are tangential. Sync vs async can be a stylistic implementation choice, and although Solid has synchronous effects by default, primitives can be built on them that are totally async, including createAsyncSignal and/or createAsyncEffect (implementation left to the imagination).
Personally, my stylistic choice, were I to implement something from scratch, would be for JavaScript microtasks (queueMicrotask) to be the smallest unit of reactivity time, therefore making reactions (effects) always "async" (from the perspective of JavaScript code in general) by default: modify a signal, the effect for that signal is always in the next microtask. I would pick this as an out-of-box design because it inherently prevents too many things from running. In essence it would be similar to timing of ResizeObserver, MutationObserver, etc, which are async, and the purpose is to avoid unnecessary extra work.
Solid does have its own microtask-like timing within a Solid component, where it will not execute effects until synchronous code of a Solid component tree is done running. It is very similar to microtasks, but scoped only to Solid.js component execution. When integrating Solid.js code with external libraries, it becomes apparent that Solid.js runs effects "async" relative to its component tree, but not relative to JavaScript code in general.
These things are stylistic choices: a hypothetical like Solid.js alternative, with the same essential developer experience of signals and effects, can exist but be completely async based on microtasks. Signals and effects moreso decribe the DX pattern, but not the timing of the pattern.
As a parallel example using event emitter patterns, it could very be possible that one implementation of an event emitter runs event handlers synchronously (right when events are emitted) and some other event emitter implementation may always run event handlers in a future task (f.e. in a JS microtask). This doesn't fundamentally change the fact that either way we have an event emitter pattern. We have the same pattern, implemented with different timing semantics.
It's basically Solid with different opinions - looks like you'd agree with this one.
Unfortunately it's a one man project, and not really built to complete with Solid - although it could have been. I think we need more competition in this space to explore the pros and cons of various ideas and opinions.
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
If you have async reactivity already, why do you need sync reactivity? What is it for? When does it matter?
What's lacking with RxJS in the context of Angular for example?
Solving the diamond problem. We can make guarentees on execution propagation. The core team was talking to me a bit on stream about this problem of over fetching from APIs at times. Also it removes the need for the special mechanisms around Direct Pipe to my understanding. The auto tracking form is easier for templating as you can just drop expressions in.
The diamond problem and sync vs async are tangential. Sync vs async can be a stylistic implementation choice, and although Solid has synchronous effects by default, primitives can be built on them that are totally async, including
createAsyncSignaland/orcreateAsyncEffect(implementation left to the imagination).Personally, my stylistic choice, were I to implement something from scratch, would be for JavaScript microtasks (queueMicrotask) to be the smallest unit of reactivity time, therefore making reactions (effects) always "async" (from the perspective of JavaScript code in general) by default: modify a signal, the effect for that signal is always in the next microtask. I would pick this as an out-of-box design because it inherently prevents too many things from running. In essence it would be similar to timing of ResizeObserver, MutationObserver, etc, which are async, and the purpose is to avoid unnecessary extra work.
Solid does have its own microtask-like timing within a Solid component, where it will not execute effects until synchronous code of a Solid component tree is done running. It is very similar to microtasks, but scoped only to Solid.js component execution. When integrating Solid.js code with external libraries, it becomes apparent that Solid.js runs effects "async" relative to its component tree, but not relative to JavaScript code in general.
These things are stylistic choices: a hypothetical like Solid.js alternative, with the same essential developer experience of signals and effects, can exist but be completely async based on microtasks. Signals and effects moreso decribe the DX pattern, but not the timing of the pattern.
As a parallel example using event emitter patterns, it could very be possible that one implementation of an event emitter runs event handlers synchronously (right when events are emitted) and some other event emitter implementation may always run event handlers in a future task (f.e. in a JS microtask). This doesn't fundamentally change the fact that either way we have an event emitter pattern. We have the same pattern, implemented with different timing semantics.
The same applies here.
You might want to have a look at Voby -
github.com/vobyjs/oby#effect
It's basically Solid with different opinions - looks like you'd agree with this one.
Unfortunately it's a one man project, and not really built to complete with Solid - although it could have been. I think we need more competition in this space to explore the pros and cons of various ideas and opinions.