Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Solidjs: Simple and performant reactivity for building user interfaces

solidjs.com

Post reply on HN
Print view View original

171–180 of 190 posts

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

#171

Post by exceptione »

erikerikson wrote: post #146
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.

https://suid.io/ is MUI for SolidJs

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

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

#172

Post by exceptione »

Sammi wrote: post #163
exceptione wrote: post #125

Earlier quoted context omitted.

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…

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.

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

#173

Post by exceptione »

nartho wrote: post #167
exceptione wrote: post #132

Earlier quoted context omitted.

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/ 1. https://mui.com/x/react-data-grid/features/

If you're interested in data grids specifically, Svelte has https://vincjo.fr/datatables/examples/client/hello-world

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

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

#174

Post by jorroll »

ryansolid wrote: post #86
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…

I'm curious which part of laziness are you concerned with? Is it delayed execution in events? It is just most lazy things run almost immediately during creation anyway, and on update everything is scheduled anyway. The only lazy thing we are looking at is memo's which while impactful isn't that different as the creation code runs. I guess the push/pull propagation is harder to follow on update then simple multi queue…

I'll admit that hearing that "laziness" was something being explored for Solid 2.0 also made me uneasy. Like the OP, in my case I know it's because I'm worried that it will complicate working with Solid state in the same way that React's "concurrent mode" complicates working with React state. Really, I just hate React's "concurrent mode" and I really like the simplicity of working with Solidjs' state by comparison (if Solidjs has a similar concept to concurrent mode I haven't run into it yet).

All of this is to say that my own worries aren't based on any concrete objections, but a general fear of change since I like the current approach (and haven't run into any performance issues with it). Also, without knowing exactly what you plan on changing, the idea of introducing "laziness" seams like it could be a euphemism for "async" which feels like it would definitely make things more complex. Anyway, reading your comment makes me hopeful that my ambiguous unease is misplaced.

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

#175

Post by ryansolid »

exceptione wrote: post #171
erikerikson wrote: post #146

Earlier quoted context omitted.

https://suid.io/ is MUI for SolidJs

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

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.

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

#176

Post by math »

math wrote: post #57
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…

I'm using SolidJS for Infumap ( https://github.com/infumap/infumap ), which is getting pretty big. Two main comments that come to mind: Because the state -> DOM mapping is non-trivial for my application, I ended up writing my own virtual DOM diffing code, a primary facet of React. I appreciate the ease of being able to circumvent this where it's not necessary and performance considerations dominate, though I admit i'…

I was not expecting to loose karma for this comment!

I have a couple of years familiarity with SolidJS and thought the two key insights that came to mind from building a large project in it would have positive value.

Apparently not!

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

#177

Post by halfcat »

imiric wrote: post #83
loxs wrote: post #69

Earlier quoted context omitted.

Funny. To me JSX is a much superior language compared to HTML templating. And I would say it's provably so. You can do JSX-in-JS-in-JSX recursively in a way that is "natural" and "safe" and "maintainable". And with TypeScript you get great IDE support, ability to refactor and whatnot. No need to trust my word, just look at the huge amount of code in JSX that the world is maintaining at the moment. I would say the onl…

JSX is a huge conceptual mistake, IMO. Sure, it gives you expressiveness, flexibility, and templating for "free", but this comes at the expense of the separation of concerns principle, which is a bad tradeoff. HTML is concerned with the content and structure of the page. JS is concerned with behaviour and interactivity. Using JS, or any programming language for that matter, to control how HTML is rendered introduces…

> practically impossible because you need to keep all the layers in mind…

> …with the MVC/MVVM approach. Every layer has a specific concern…

Do we need to keep all the layers in mind, or not?

Separation-of-concerns is not a virtue. It’s a trade off between separation-of-concerns and locality-of-behavior. SoC can be a benefit, if it matches your team structure. But also, any abstraction has a cost of increased cognitive load (and even worse is premature, wrong abstractions).

If I have to look at 5 files instead of 1, the 5 files better pay for itself in some way (and in a small team, there’s almost no room for that to happen).

I can’t prove this obviously, but if I were betting, I’d expect more businesses have failed due to lack of velocity from over-engineered SoC apps, while the LoB monolith that’s easy for a small team to reason about found the right abstractions and won the market share (and later got rewritten as a SoC app, e.g. Instagram).

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

#178

Post by steve_adams_86 »

erikerikson wrote: post #145
steve_adams_86 wrote: post #65

Earlier quoted context omitted.

Is laziness intended to offer primitives for suspended UIs? I haven’t used Solid for a while and can’t recall if there’s a Suspense counterpart already. If not, this seems like a reasonable feature to add. It’s a familiar and pretty intuitive convention

Looking for this? https://docs.solidjs.com/reference/components/suspense

Ha! I’ve used this, too. I guess I’ve reached the senility phase of my mid life. Thanks for pointing me to that

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

#179

Post by arkaic »

technion wrote: post #17
chabska wrote: post #14

Earlier quoted context omitted.

> I personally don't like that direction so looking forward to exploring new frameworks. Why? React core has been exactly the same as it was ten years ago. Building a React SPA has not changed significantly, other than the growth in third-party libraries that complement the Core. Recent developments in React has been about enabling its usage in wider problem domains, but not at the detriment of its previous use cases…

Much of the official documentation now refers to server components as the "right" way to do certain things. Cra is end of life, with the replacement nextjs being heavily biased towards server components. Your tooling certainly has changed in that you won't use cra any more, and I wouldn't agree that this direction does not detriment previous use cases.

Vite all the way....until that gets deprecated and forced to move to nextjs

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

#180

Post by 0xblinq »

owebmaster wrote: post #142
chabska wrote: post #14

Earlier quoted context omitted.

> I personally don't like that direction so looking forward to exploring new frameworks. Why? React core has been exactly the same as it was ten years ago. Building a React SPA has not changed significantly, other than the growth in third-party libraries that complement the Core. Recent developments in React has been about enabling its usage in wider problem domains, but not at the detriment of its previous use cases…

> React core has been exactly the same as it was ten years ago Are we not considering Hooks core yet?

Hooks were introduced in 2018. We're in 2025.

It's not 10 years yet, but we're pretty close to that.

Yes, time flies.

Post reply on HN