[exceptione]

That is really interesting, thanks for sharing. Sounds almost too good to be true.

I saw however an open issue [0] about performance problems that seems to indicate that component libraries in Svelte suddenly becomes really slow?

  Another update. I wondered whether this was really unique to SUID or if other component libraries also have this problem. So I included Park UI and Kobalte (which seem to be the only other mature options besides SUID).

  Kobalte runs in ~168ms, and Park runs in ~382ms. Even that seems too slow to me. Is there something inherent to component libraries that makes them slow in Solid.js? (Next up, I should probably benchmark the same setup in other frontend frameworks.)

___

0. https://github.com/swordev/suid/issues/208

[ryansolid]

Yeah it is an interesting one. There is definitely a slowdown due to the amount of wrapping that happens. These sort of libraries tend to put component in component in component etc.. so there is a lot of prop iteration, Object.keys calls in Object.keys calls etc which when used with proxies can add up a bit. The tricky part is no one actually knows how slow these libraries are in say React. My suspicion they are slow there as well but maybe not as stark of a difference because of how fast Solid to begin with comparatively.

People who use Solid tend to measure stuff like this where as those who use React might have already reconciled themselves to performance issues.

[exceptione]

Thanks for chiming in.

React doesn't win speed races, but the mentioned slow-downs are rather extreme and would be noticeable.

I agree that one should benchmark against React-MUI as the baseline. In fact, that would give Solidjs a meaningful (less synthetic) benchmark, as in this case we have a wide range of non-trivial one-for-one components to compare with. A goldmine for performance testing.

If SolidJS could outperform React in these kind of workloads you would have a great proposition.