Solidjs: Simple and performant reactivity for building user interfaces • Hacker News Board

Re: Solidjs: Simple and performant reactivity for building user interfaces

#121

Post by MrJohz » Wed, Apr 23, 2025, 12:26 PM UTC

fastball wrote: post #33

zuck_vs_musk wrote: post #27

Has anyone used both Solid and Vue? How do the two compare?

If you want to compare Solid to Vue, I think it is easier to just compare React to Vue. If you like React better, then you can compare React to Solid and see which you prefer. SolidJs is 90% similar to React in terms of DX, with only a coupler major differences. Things the same as React in Solid: function-based components with hooks, JSX, overall "JS-first" (vs Vue which I'd describe as "HTML first") Things different…

I disagree, both Vue and SolidJS share the same underlying signal mechanism. Vue hides it a bit more, and has different default primitives, but they're both doing essentially the same thing under the hood. In both, you can think of a component as an entity that exists continuously for as long as it is mounted, and connects sources (i.e. signals) to outputs (i.e. HTML values).

React, on the other hand, is very much focused around the `UI = f(state)` paradigm, where the `f` (i.e. the component/render function) gets called afresh every time the state changes. You can avoid that somewhat via memoisation etc, but this is conceptually an optimisation rather than how the framework works.

The JSX vs SFC aspect is still significant, and SolidJS definitely tries to use some of the affordances that React developed initially. But the core idea in the framework is much closer to Vue than to React.

Re: Solidjs: Simple and performant reactivity for building user interfaces

#122

Post by exceptione » Wed, Apr 23, 2025, 12:38 PM UTC

fkyoureadthedoc wrote: post #118

exceptione wrote: post #111

Earlier quoted context omitted.

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.

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 ge…

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.

Re: Solidjs: Simple and performant reactivity for building user interfaces

#123

Post by hombre_fatal » Wed, Apr 23, 2025, 12:40 PM UTC

zamalek wrote: post #38

mightyham wrote: post #2

Having used Solid on a largish web product for over a year, I am thoroughly convinced and will not be returning to React in the future. This is somewhat of an aside: I am aware that the creator of Solid has long been experimenting with adding laziness to the reactive system. I think it would be a mistake. That everything is immediate keeps state changes intuitive, fairly easy to debug, and is one of the strong points…

React has lived long enough to become the villain, and it's way too entrenched. It was certainly a very important step forwards in webdev, but it now probably has more gotchas than vanilla JS does.

I think it's just the lifecycle of craftsman tooling in general.

When everyone has experience with a tool, everyone can enumerate its downsides in unison, but we can't do that with new/alternative tools.

Whether we confuse that for the new tool having no drawbacks, or we're just tired of dealing with the trade-offs of the old tool, or we're just curious about different solutions, we get a drive to try out new things.

React always had gotchas, but the question is how tolerable are those gotchas compared to the gotchas of what you were doing before. And how tolerable are Solid's gotchas going to be once you discover them. Sometimes it's a better set of gotchas and sometimes it isn't.

Re: Solidjs: Simple and performant reactivity for building user interfaces

#124

Post by ericyd » Wed, Apr 23, 2025, 12:52 PM UTC

hombre_fatal wrote: post #123

zamalek wrote: post #38

Earlier quoted context omitted.

React has lived long enough to become the villain, and it's way too entrenched. It was certainly a very important step forwards in webdev, but it now probably has more gotchas than vanilla JS does.

I think it's just the lifecycle of craftsman tooling in general. When everyone has experience with a tool, everyone can enumerate its downsides in unison, but we can't do that with new/alternative tools. Whether we confuse that for the new tool having no drawbacks, or we're just tired of dealing with the trade-offs of the old tool, or we're just curious about different solutions, we get a drive to try out new things.…

Very balanced response, but in my case it's less about gotchas and more about APIs. I just think other frameworks have more intuitive APIs than react. Maybe this falls in the same category as a gotcha, but I feel it's a little different.

Re: Solidjs: Simple and performant reactivity for building user interfaces

#125

Post by exceptione » Wed, Apr 23, 2025, 12:53 PM UTC

jmull wrote: post #116

exceptione wrote: post #107

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 libr…

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.

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.

Re: Solidjs: Simple and performant reactivity for building user interfaces

#126

Post by ericyd » Wed, Apr 23, 2025, 12:56 PM UTC

exceptione wrote: post #111

voat wrote: post #110

Earlier quoted context omitted.

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

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.

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/

Re: Solidjs: Simple and performant reactivity for building user interfaces

#127

Post by division_by_0 » Wed, Apr 23, 2025, 12:58 PM UTC

exceptione wrote: post #125

jmull wrote: post #116

Earlier quoted context omitted.

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.

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 u…

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.

Re: Solidjs: Simple and performant reactivity for building user interfaces

#128

Post by fkyoureadthedoc » Wed, Apr 23, 2025, 1:00 PM UTC

exceptione wrote: post #122

fkyoureadthedoc wrote: post #118

Earlier quoted context omitted.

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 ge…

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 suc…

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.

Re: Solidjs: Simple and performant reactivity for building user interfaces

#129

Post by exceptione » Wed, Apr 23, 2025, 1:13 PM UTC

hombre_fatal wrote: post #119

exceptione wrote: post #107

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 libr…

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/ if there were no React adapter.

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.

Re: Solidjs: Simple and performant reactivity for building user interfaces

#130

Post by thenewem » Wed, Apr 23, 2025, 1:17 PM UTC

hombre_fatal wrote: post #123

zamalek wrote: post #38

Earlier quoted context omitted.

React has lived long enough to become the villain, and it's way too entrenched. It was certainly a very important step forwards in webdev, but it now probably has more gotchas than vanilla JS does.

I think it's just the lifecycle of craftsman tooling in general. When everyone has experience with a tool, everyone can enumerate its downsides in unison, but we can't do that with new/alternative tools. Whether we confuse that for the new tool having no drawbacks, or we're just tired of dealing with the trade-offs of the old tool, or we're just curious about different solutions, we get a drive to try out new things.…

One of the best responses I have read on this topic. Thank you