Comparisons

[xania]

QUESTION: I wonder how it compares, because I saw that right now preact and react have signals support which may be trivial to implement, but preact says that it weighs 3kb, so taking this to account, what would you say is the best choice right now
xania, solid, react + signals, preact + signals ?

[xania]

Issues with React, and inherently with Preact, like stale closures, unnescessary reruns, are not solved by the use of Signals.
React has been the best choice for a very long time, at this point while everybody is on board with the great benefit of using React we also started to find, in my opinion for the first time since 2013, better theoretical alternatives.

React is still the obvious choice, if you want to build a end-user product based on well known tools and patterns. The alternatives only matters in advanced scenario's, typically if you are building a generic library.

It is also a tradeoff of risks that highly depends on your use case.

• Choose an alternative to React and risk missing out on community support
• or choose React and risk accidental complexities in advanced use cases

[xania]

Now, is signals support trivial? absolutely not! signals and observables share the same complexity when it comes to change detection and propagation, scheduling, etc.....

And are signals purely for performance? also no, observable pattern could be faster, proven by this benchmark.
https://xania.github.io/state

The truth is, the performance of this implementation does not come from the fact that it is based on observable pattern, but rather because the amazing graph algorithm that helps achieve this performance.

To proof my point, I started building Signals on top of this graph algorithm and soon I will send my contribution to
https://github.com/modderme123/js-reactivity-benchmark

[xania]

I've succesfully used xania in a large scale project, currently the core of xania rendering engine is stable since dec 2022. It needs some refactoring and cleanup but any additional work won't involve changes in the structure / behavior of the engine.

Today, when xania is compared to solid then solid clearly wins because of established solutions like ui libraries, routing, ssr story. In the long run the feature set won't be the differentiator of interest, eventually xania will be able to catch up.
Let me first state I am in no way entitled to have an opinion about solidjs. But I'll share my naive thoughs on solid anyway ;) please correct me if you see fit.

if we ignore the feature set then, simply put, there are three main differences between xania and solid,

1. xania view state is built on observable concept, solid is built on it's own specific implementation of signals
2. xania's components are template, solid's component's are (dom) elements
3. xania is not a compiler, solid is a compiler.

1. state: observables vs signals

On the surface there is (soon) not much difference when it comes to the use of signals in both xania or solid.
As I mentioned before, xania will (soon) have official support for signals (a week or two). The trick is to make signals also implements the Observable interface. Xania's doesn't care, it is totally decoupled and agnostic, allowing the use of all kind of solutions as long as state object implements the Observable interface. We can use e.g. rxjs naturally without wrappers or adapters, state-adapt which I follow closely, or xania's own implementation @xania/state
Solid on the other hand seems to be highly coupled with the signals own implementation. Apparently they even have / had issues with differnt versions of signals. This makes me wonder how solid deals with external libraries that comes with baked-in version of signals.

2. Component as templates

The expression Component/> in xania represents a template object. only after calling render(template) the final dom element is created. this property is important for runtime optimizations.
In solid, the expression represents the actual dom element. Optimizations are done by the solid's own compiler (babel transformers).

// xania
const template = <Button />
render([template, template], target) // wil render two elements

// solid
const element = <Button />
render([element, element], target) // wil render one element, that's why solid instead uses call back to render elements
render(()=> <Button />, target);

3. No need for a compiler

Xania depends on out of the shelf compiler of typescript. The same concept as React: <Component /> compiles to jsx.createElement(Component, null, null), that's all the help xania needs.

Solid on the other hand, when used with JSX, then a solid's own compiler is needed to translate to normal javascript. Using the power of a compiler sounds tempting to generate highly optimized code from declarative JSX, but, thanks to krausest benchmark where xania is the absolute fastest (excluding the ones that are not playing a fair game), we can conclude that that is not the case. Don't get me wrong, solid is blazingly fast, difference with xania is neglitable to be a deciding factor between the two.
But we should care however about how xania was able to perform as it does without the use of compiler optimizations. The key idea is actually very simple.

const a = 1;
const b = 2;
const c = 3;
function slow(x: number) {
    return (a + b + c) * x; 
}
function fast(x: number) {
    return 6 * x;
}

The functions slow and fast behave the same. It is easy to see why fast is faster than slow.
Xania applies the same concept when we merge two views. To be able to do this, the views need to be template objects instead of final elements (as described in point 1).

So why is it important whether or not a compiler is used?

A compiler must have higher maintenace cost resulting in slower progress and innovation going forward. Integrations will be generally more complex (takes more effort and time) because of the use of the compiler. I belief integration with Bun is such an example.
oven-sh/bun#414
Whether this is still the case at the time of reading is not the point. The point is really the amount of effort is required to have the desired integration.