3 ms·

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

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. --- 0. https://mui.com/x/react-data-grid/row-grouping/ https://mui.com/x/react-data-grid/row-grouping/

voat 1y ago
Most of the modern front end frameworks can handle those use cases. Solid, Vue, Svelte all have capable SPA frameworks and component libraries
- exceptione 1y ago
  I don't want to be obnoxious but can you link some that have the range of MUI? It would be nice to have options.
  - erikerikson 1y ago
    https://suid.io/ https://suid.io/ is MUI for SolidJs
    - exceptione 1y ago
      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 https://github.com/swordev/suid/issues/208
      - ryansolid 1y ago
        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 1y ago
        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.
  - fkyoureadthedoc 1y ago
    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. For tables though, I haven't used this in Solid, but it's pretty nice in general https://tanstack.com/table/latest https://tanstack.com/table/latest
    - exceptione 1y ago
      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.
      - fkyoureadthedoc 1y ago
        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.
        exceptione 1y ago
        Good to hear, thanks for sharing.
  - ericyd 1y ago
    We are using PrimeVue at my work and are very happy with it. I'm not super familiar with Mui so can't directly compare. https://primevue.org/ https://primevue.org/
    - exceptione 1y ago
      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). ___ 0. https://primevue.org/treetable/ https://primevue.org/treetable/ 1. https://mui.com/x/react-data-grid/features/ https://mui.com/x/react-data-grid/features/
      - nartho 1y ago
        If you're interested in data grids specifically, Svelte has https://vincjo.fr/datatables/examples/client/hello-world https://vincjo.fr/datatables/examples/client/hello-world
        exceptione 1y ago
        Interesting! I need hierarchical data grids indeed (but they also seems to be the kind of shibboleth only the large libraries are able to speak).
  - nartho 1y ago
    https://www.shadcn-svelte.com/ https://www.shadcn-svelte.com/ https://www.skeleton.dev/docs/get-started/introduction https://www.skeleton.dev/docs/get-started/introduction https://flowbite-svelte.com/ https://flowbite-svelte.com/ https://www.melt-ui.com/ https://www.melt-ui.com/
    - exceptione 1y ago
      Thank you! I have skimmed them, they look pretty and feel fast. Unfortunately they seem not to match mui in breadth and depth.
jmull 1y ago
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.
- division_by_0 1y ago
  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.
- exceptione 1y ago
  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: data-heavy, enterprise systems, business software => react webshop etc, "simple" consumer oriented => svelte, solidjs etc Correct me if wrong.
  - division_by_0 1y ago
    I think the best case for using Svelte or Solid over React is when performance is critical, e.g. in big and/or fast data contexts.
    - exceptione 1y ago
hombre_fatal 1y ago
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. For example, wrapping https://datatables.net/ https://datatables.net/ if there were no React adapter.
- exceptione 1y ago
  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.
WuxiFingerHold 1y ago
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.

voat 1y ago

Most of the modern front end frameworks can handle those use cases. Solid, Vue, Svelte all have capable SPA frameworks and component libraries

exceptione 1y ago
I don't want to be obnoxious but can you link some that have the range of MUI? It would be nice to have options.
- erikerikson 1y ago
  https://suid.io/ https://suid.io/ is MUI for SolidJs
  - exceptione 1y ago
    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 https://github.com/swordev/suid/issues/208
    - ryansolid 1y ago
      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 1y ago
        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.
- fkyoureadthedoc 1y ago
  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. For tables though, I haven't used this in Solid, but it's pretty nice in general https://tanstack.com/table/latest https://tanstack.com/table/latest
  - exceptione 1y ago
    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.
    - fkyoureadthedoc 1y ago
      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.
      - exceptione 1y ago
        Good to hear, thanks for sharing.
- ericyd 1y ago
  We are using PrimeVue at my work and are very happy with it. I'm not super familiar with Mui so can't directly compare. https://primevue.org/ https://primevue.org/
  - exceptione 1y ago
    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). ___ 0. https://primevue.org/treetable/ https://primevue.org/treetable/ 1. https://mui.com/x/react-data-grid/features/ https://mui.com/x/react-data-grid/features/
    - nartho 1y ago
      If you're interested in data grids specifically, Svelte has https://vincjo.fr/datatables/examples/client/hello-world https://vincjo.fr/datatables/examples/client/hello-world
      - exceptione 1y ago
        Interesting! I need hierarchical data grids indeed (but they also seems to be the kind of shibboleth only the large libraries are able to speak).
- nartho 1y ago
  https://www.shadcn-svelte.com/ https://www.shadcn-svelte.com/ https://www.skeleton.dev/docs/get-started/introduction https://www.skeleton.dev/docs/get-started/introduction https://flowbite-svelte.com/ https://flowbite-svelte.com/ https://www.melt-ui.com/ https://www.melt-ui.com/
  - exceptione 1y ago
    Thank you! I have skimmed them, they look pretty and feel fast. Unfortunately they seem not to match mui in breadth and depth.

jmull 1y ago

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.

division_by_0 1y ago
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.
exceptione 1y ago
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: data-heavy, enterprise systems, business software => react webshop etc, "simple" consumer oriented => svelte, solidjs etc Correct me if wrong.
- division_by_0 1y ago
  I think the best case for using Svelte or Solid over React is when performance is critical, e.g. in big and/or fast data contexts.
  - exceptione 1y ago

hombre_fatal 1y ago

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. For example, wrapping https://datatables.net/ https://datatables.net/ if there were no React adapter.

exceptione 1y ago
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.

WuxiFingerHold 1y ago

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.