Solid indeed does not have the same number of options that React has when it comes to UI component libraries. I've only used Solid on small throwaway projects, but I do like it better than React.
However, like you've pointed out, there's going to be things that you have to do yourself that in React you could likely depend on someone else for.
When I researched Tanstack, it looked flexible. But a recurring theme with users was that some options are not compatible with each other, while the documentation is silent about what functionalities are compatible with each other. Did you experience that?
For me such a thing is a red flag: incomplete documentation, feature gaps and unpredictability. Also, how difficult is it too fill the feature gap. Even if one succeeds, how maintainable would it be if changes are not accepted upstream.
No, but my use of it was fairly simple stuff, so I probably just didn't run into that. I do use react query and their router regularly and haven't had any major issues with it.
Thank you. I remember I had a look at that. Made a quick look now at PrimeVue treetable [0], to compare it to MUI datagrid [1].
There seems to be a wide gap in feature scope and depth. For example, column grouping in [0] seems to be not available (it is in PrimeVue datagrid, but that misses support for data hierarchy).
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.)
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.
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.
I'm a big fan of Solid. It's a very influential community, however it's not widely used. All the pieces are there. I just don't see tons of marketing or real app/product/dx focus from them.
Look out for their upcoming 2.0 release, it's supposedly gonna be something special.
I'm confused at all the negativity? I am personally very excited for this feature, it's going to enable one to use less JavaScript,and CSS to accomplish things that should be easy.
The syntax is getting pretty un-CSS like though, so how much of a benefit is it going to be? FE developers would still have to learn another new way of doing something that can be handled with JS.
I appreciate that the author acknowledged that there must exist some reason(s) for the changes that he is unaware of.
I appreciate Svelte's new architecture, it's going to help people make smaller, faster apps, even it requires you to learn about how it's reactive system works.
No one is forcing you to upgrade, Svelte 4 still works just fine? Svelte has had basically no major API changes since 2019, that's a better part of a decade. And with this new architecture change, they released a sophisticated codemod to do most of the work of updating for you.
Great until your dependency scanner picks up a vulnerability in the framework or a dependency that can't be upgraded without breaking v4, no exemptions can be given and the only updated version is 5. [1]
If it's already end of life you can fork it and upgrade the dependency. You'll miss nothing. This is only difficult if you need to maintain changes upstream, but that's not the case here.
Security support lifetimes make sense for a widely used language or runtime, but not really a frontend web framework on the most backwards compatible language you can have.
Solid, Vue, Svelte all have capable SPA frameworks and component libraries