Live data from Hacker News

Solidjs: Simple and performant reactivity for building user interfaces

solidjs.com

151–160 of 190 posts

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

#151
post #38

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.

It's not that it's way too entrenched, it's just that people grew tired of constantly shifting frontend frameworks. Personally: I really didn't care who "won" that war, I just wanted to have a sane well-supported default without having to learn a new pattern every year to store page state or update an icon.

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

#156

The annoying thing about solid coming from react is that every prop for every component needs to be a function that returns a value instead of just a value, otherwise that prop can never be updated.

That's not quite right! I made the same mistake in a Solid project.

The deal is that your `props` parameter is reactive. If you use `props.x`, and the value of `x` later changes, that bit of your component will update.

The catch is that you have to access it via `props` -- if you extract it, e.g. "const { x } = props", subsequent uses of `x` aren't reactive. Sometimes that's actually what you want, sometimes not.

Like you, I ended up turning lots of props into accessor functions -- `props.x()` -- so it's clear exactly when they're being used. This isn't necessary if you're careful to access via `props` and not extract fields prematurely. But sometimes I like being explicit about it, so I still sometimes use function props.

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

#157
post #76

Genuine question: Why would you use Solid instead of Svelte? I'm coming from React and most alternatives seem quite similar to me. Only Svelte does things very differently with its compiler. Vue and Solid just seem to be a different flavour of React.

I've tried both and I much prefer Solid. The key advantage for me is that it's just JS/JSX -- you can use it in both your UI code and JS utility functions and it works everywhere. Svelte seems a lot more magical; your UI code is in a special language that looks different and works differently from JS utility functions.

Edit to add: if you dislike JSX I'd guess you would probably prefer Svelte over Solid.

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

#159

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…

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.

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

#160
post #6

Portions of the react community are excited about how it's starting to feel more like PHP with the movement towards server actions in "client" code etc I personally don't like that direction so looking forward to exploring new frameworks. What I've generally liked about React/Next setups is that the code is generally explicit and less magic (I also have gripes with hooks feeling like magic). Things like Vue/Svelte wh…

> I personally don't like that direction so looking forward to exploring new frameworks I personally am becoming dissolutioned with React because of this, as a former strong advocate. Next.js and Remix - or whatever the hell it's called this week - are both over-engineered messes. Yes, I'm aware that I don't have to use them, but they are where the momentum and energy of the community is being spent in recent years.…

Hard agree. It’s all complexity and for what? SEO? So many products don’t need SEO. API proxies with secrets? These are not super common use cases.

The default should be SPA and purely static.

Post reply on HN