Live data from Hacker News

Solid.js feels like what I always wanted React to be

typeofnan.dev

91–100 of 444 posts

Re: Solid.js feels like what I always wanted React to be

#91
post #63

I've used React for ~3 years, primarily with function components and hooks. I think that hooks were a wonderful addition and I think the framework has made smart choices with checking object equality to decided if components re-render. That said, I think that easily the most difficult aspects of react revolve around how re-renders are triggered. Maintaining referential equality to stop unnecessary renders gets tricky…

> Solid takes these problems and just vanishes them. UI state knows what its dependencies are automatically and only updates when they change – even in a sub-component level!

I haven't looked at Solid but I've used MobX extensively, and this sounds a whole lot like it. It integrates well with React, so you might give it a look if you've got an existing React codebase.

Re: Solid.js feels like what I always wanted React to be

#92
We've used React with Mobx in commercial apps for 5+ years now. React has been good for us BUT Solid is so much cleaner (and leaner).

Porting most React code to Solid is pretty easy - mostly involves deleting things that are no longer required (useCallback, useRef, etc) and moving prop access into the JSX to enable just those specific attributes to be updated when state changes.

It has come to the point where I really begrudge going back to working in our React code. Unfortunately those apps will still be around for a long time - but we won't be using React for green-fields projects.

Re: Solid.js feels like what I always wanted React to be

#93

This article hits on something I've felt for a long time. The idea that "hooks are superior" to me is ridiculous. If a linter is required to tell me when I'm writing a bug that is not immediately obvious, that is a failing in the framework to round those edges. Lints are not rounded edges! Solid is nice and _seems_ to fix the issues with hooks, but as another comment mentioned, the challenge is with building at scale…

I have the same complaint about hooks. Most people seem to ignore that tidbit, but to me it's really frustrating. Plus I recently hit more hook issues when putting a setInterval inside a useEffect. There's no way to do a normal didMount/willUnmount workflow without other hacks (i.e. useRef) just to set up a simple timer. Maddening!

Edit: after writing this I went and read the article. Same scenario I was bitching about lol

Re: Solid.js feels like what I always wanted React to be

#94
post #68

What feels like complete insanity when it comes to React is that it needs compilation to work: render() { return The count is: {this.state.count} ; } This is not Javascript and it will need to be compiled into Javascript before it gets executed. But you can do the same in Javascript: render() { return ` The count is: ${this.state.count} `; } Using regular Javascript makes my life a thousand times easier than having t…

This is another area where Solid has an advantage over React. With React you could use Hyperscript functions so the above JSX would be

React.createElement('div', null, `The count is: {this.state.count}`).

With Solid you get the choice, you could use JSX, Hyperscript functions or template literals like in your example. Solid does recommend using JSX because there are some tradeoffs to using template literals without compilation, but it still maintains almost all of its qualities AFAIK and in the big framework benchmark Solid with template literals is the fastest template literals implementation.

With Solid you don't even have to use any templating languages, you can take care of rendering yourself using the tools that the framework gives you. Solid at its core is more of a capable state management library similar to MobX but designed to be used as the only reactivity engine unlike MobX which is usually used on top of React.

Re: Solid.js feels like what I always wanted React to be

#95
post #42

Earlier quoted context omitted.

> Hooks allow you to bundle code together by functionality, and consequently allow you to easily extract and share said functionality in a very composable way. You’re using React. The mechanism that enables code reusability is through composing components. There’s nothing wrong with class components even for the most complex logic. The only downside is the community has moved on and mostly adopted hooks and functiona…

> The mechanism that enables code reusability is through composing components If you think that this: return ( {({ apple }) => ( {({ sliced: slicedApple } => ( ) } )} ); is more desirable than this: const apple = useApple(); const slicedApple = useSlicer(apple); return ; Then go for it I guess. Although you'd have to somehow ignore the fact that you'd end up with an even bigger mess if you want these intermediate fun…

Thats interesting. So in your 2nd example, am I right in saying the variables 'apple' and 'slicedApple' are react JSX that you are ultimatly passing through to to render on the screen? If so, yes, that is fairly intuitive.

Re: Solid.js feels like what I always wanted React to be

#96
post #20
post #10

I swear we're just going around in circles because people only have a surface level understanding of these front-end frameworks, and the challenges with building at scale. react isn't about 'hooks', 'jsx', 'top-down-state', or 'component-driven architecture'. All these frameworks are component-based, can have top down state only (or do bottom up in react), can use things like jsx/hooks because it's just syntactic sug…

The thing is that While react is against side effects, javascript is not. Which result in these impedance mismatch where what devs want is against react itself. Vue/svelte/solid do not fight against js, hence they do not end up in similar situation

i'm finding a hard time articulating what you said, if React is against side effects then useEffect wouldn't have existed and we wouldn't have data fetching.

React is unique in that everything in the component is within the render path, while the rest of the frameworks (that you've mentioned) doesn't.

you might be mistaking "side effects during render is bad" for "side effects is bad", the two statements are not the same.

Re: Solid.js feels like what I always wanted React to be

#97

Earlier quoted context omitted.

This is just iteration on the awesome groundwork that React laid, and shows that things can still be much better. React has some very peculiar patterns that don't really jive well with javascript as a language, or its ecosystem. If the setInterval example is fundamentally against what React is, then IMO that really hammers the point the author is making. I have a few React projects under my belt, and often times stil…

In my personal opinion when there is a lot of complicated state in a component and there is no real benefit to splitting it up into smaller components then hooks are inferior to the older lifecycle methods (in creating understandable, maintainable code), however in my experience whenever I come to place nowadays this would be considered heresy and everything needs to be in hooks even if you have 10+ and growing numbe…

When you have multiple hooks in a component it usually makes sense to put them in a function with a good name - a custom hook. It's easy and almost always usually gives simple code.

Re: Solid.js feels like what I always wanted React to be

#98
post #10

I swear we're just going around in circles because people only have a surface level understanding of these front-end frameworks, and the challenges with building at scale. react isn't about 'hooks', 'jsx', 'top-down-state', or 'component-driven architecture'. All these frameworks are component-based, can have top down state only (or do bottom up in react), can use things like jsx/hooks because it's just syntactic sug…

I keep my sanity by ignoring all of them, focusing on mastering pure Web standards only, and delving into such frameworks only when I am required to collaborate with Web FE devs.

Re: Solid.js feels like what I always wanted React to be

#99
post #73
post #16

Earlier quoted context omitted.

> we get a construct like that reinvents a concept that's already in the language Isn't this optional? Can't Solid use regular JSX loops?

JSX doesn't have loops. When using React, you use regular not-React-specific Javascript tools to do loops and create lists of React elements.

If this is true, why do you need unique item keys? React cares about loops a lot more than it may seem at a first look.

Re: Solid.js feels like what I always wanted React to be

#100
post #63

I've used React for ~3 years, primarily with function components and hooks. I think that hooks were a wonderful addition and I think the framework has made smart choices with checking object equality to decided if components re-render. That said, I think that easily the most difficult aspects of react revolve around how re-renders are triggered. Maintaining referential equality to stop unnecessary renders gets tricky…

"UI state knows what its dependencies are automatically and only updates when they change" - you should check out [valtio](https://github.com/pmndrs/valtio).
Post reply on HN