Can a SolidJS or an other non-React user chime in to explain what their experience is when using a more `modern|unorthodox` framework for a data-heavy SPA that uses lots of components?
For react you have got Mui(x). Especially the datagrid with the myriad of options is something which I cannot fathom to rebuild myself. I mean, look at this [0], which just is about the grouping options.
When I see other component libraries I think: nice, this is only 10% of what I need.
So I am curious if and how people use non-React stuff to build `heavy` SPA applications. Maybe I can learn something.
For me the selling points for React are:
- functional: components are pure functions
(with caveats 1. as much as possible; 2. from a dev experience)
- large component libraries. High quality, battle tested, and well documented.
With Svelte anyway, a third-party component just gets in the way.
You just make whatever it is you want in HTML and make it reactive (put it in a file with the right extension and add the svelte-specific reactivity you want).
It's simple/straightforward, does exactly what you want, and instead of spending time mastering the API of some component, you mostly spend time using the HTML/JS/CSS you already know.
Yes, and you will probably get a little better at HTML/JS/CSS if you do not have to spend time learning a third-party component's API. Third-party components can also become unbearable if you have a very clear idea of what you want to archive.
Thanks. If that is the common approach in Svelte to third party components, than I learned something.
> You just make whatever it is you want in HTML and make it reactive
> ... instead of spending time mastering the API of some component,
I am not sure if that would be a win. The API of the component is actually a selling point, because the component gets used in many different ways across the application. Possibly under influence of user configuration.
If I were to achieve a reasonable amount of flexibility, I would have to redo the work of that library: create a flexible component from scratch with a good api. That is my concern at least.
So when I see the other frameworks libraries, I get the impression that possibly the target audience differ in needs, like so:
The reason you don't see Svelte versions of common libraries as much as you do for React, is that with Svelte you can just use the vanilla js/html/css version and they work great. React has a hard time using vanilla approaches because the virtual dom and hooks aren't vanilla and don't work like vanilla. React is it's own world and therefore needs to have a React version of everything.
I think I do not completely grok that, maybe I have to experiment with Svelte a bit more. As GP mentioned, in Svelte one does not reach for third party components, so you might be on to something.
Not much is going to compete directly with React's ecosystem maturity.
But, of course, there's the option you have when using a non-React library in React: on mount, you instantiate the library in a ref, and then you use effects to turn reactive state updates into library invocations.
Wouldn't you mean that the other way around? So you have a Svelte/SolidJS application, and you use some React components like from MUI to fill the gaps.
Vue has a large ecosystem. A lot of very good component libs like PrimeVue, Vuetify, Quasar, NuxtUI, ElementUi ...
I have used agGrid and eCharts with Svelte. Doesn't get any simpler. With Solid, Vue and Svelte you can integrate vanilla JS libs easily.
I tend to use Svelte without component lib or DaisyUI. After all, those libs are technical debt. Also, the native HTML 5 elements / browser APIs are pretty complete these days (dialog, popover, ...). If I was to chose one I'd probably go with Vue and PrimeVue.
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.
For react you have got Mui(x). Especially the datagrid with the myriad of options is something which I cannot fathom to rebuild myself. I mean, look at this [0], which just is about the grouping options.
When I see other component libraries I think: nice, this is only 10% of what I need. So I am curious if and how people use non-React stuff to build `heavy` SPA applications. Maybe I can learn something.
For me the selling points for React are:
---0. https://mui.com/x/react-data-grid/row-grouping/