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.

  > You just make whatever it is you want in HTML and make it reactive 
  > ... instead of spending time mastering the API of some component,

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:

  data-heavy, enterprise systems, business software  => react
  webshop etc, "simple" consumer oriented            => svelte, solidjs etc

Solid, Vue, Svelte all have capable SPA frameworks and component libraries

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.

For tables though, I haven't used this in Solid, but it's pretty nice in general https://tanstack.com/table/latest

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.

https://primevue.org/

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).

___

0. https://primevue.org/treetable/

1. https://mui.com/x/react-data-grid/features/

https://www.skeleton.dev/docs/get-started/introduction

https://flowbite-svelte.com/

https://www.melt-ui.com/

Unfortunately they seem not to match mui in breadth and depth.

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

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.

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.

For example, wrapping https://datatables.net/ if there were no React adapter.

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.