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

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

typeofnan.dev

Post reply on HN
Print view View original

141–150 of 444 posts

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

#141

Post by egeozcan »

I find Solid.js a "better" React as well. In a new project that needs to be used by a lot of team-members, however, I still chose React.

Why? Because of the ecosystem! Do I need accessible, headless components? Use React-aria from Adobe! Do I need state management? There are many established ones, I just need to follow their best practices. Everything supports React, every hire speaks React, and it works, not like "just works", but "... works" and, disappointing to the engineer inside me, this is not something I can trade in big projects.

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

#142

Post by DougBTX »

lhorie wrote: post #112
preommr wrote: 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…

> react is fundamentally about 'inputs changed, render this' I mean, pretty much all frameworks these days have that fundamental declarative model, react wasn't particularly innovative on that front (e.g. the declarative model already existed in angular, knockout, etc) What the setInterval example highlights is that newer subsystems in React like useEffect and Suspense are bolted on top of earlier iterations that wer…

> react wasn't particularly innovative on that front (e.g. the declarative model already existed in angular, knockout, etc)

React was absolutely a breath of fresh air when it was released.

Knockout was similar to Solid.js in that they both have functions that you call which then log a data dependency, then when the data changes the UI updates. This led to lots of pain, because instead of a plain value, you have functions which return values, and you need to be very careful about when those functions are called, otherwise the data dependency might not be tracked properly.

Angular had a similar issue, as its state-based observation relied on special scopes. Updates in the wrong scope could be lost or delayed.

React’s approach of only diffing the rendered UI rather than trying to drive updates based on diffs of the input data was vastly simpler, it was much easier to understand the data flow through explicit state and props.

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

#143

Post by kevinmcconnell »

rk06 wrote: post #126
benatkin wrote: post #122

Earlier quoted context omitted.

> View = F(data) That's just how templates are meant to work. Underscore.js templates don't allow making an AJAX call before calling render() either. https://underscorejs.org/#template

Consider following scenario: User is entering an account register form. When the user has entered a value in nickname, your app must check if it is in use and display error message if the nickname is already in use. Sounds good, and ubiquitous right? Well, that also require an ajax call to server for validation, so it breaks the pure function assumption right there. Now, you what do you do?

> so it breaks the pure function assumption right there

There's no pure function assumption being broken here. React is a framework for rendering UI from state and coordinating updates to that state. That's why we have things like `useEffect`, contexts, and so on. The only part of React that is expected to be free of side effects is rendering.

Put another way, given your example, React just says that you shouldn't issue your Ajax call in your rendering code. Instead, you should do it in response to an appropriate action, such as a change event on your form controls.

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

#144

Post by yazaddaruvala »

ihateolives wrote: post #132
benatkin wrote: post #105

Earlier quoted context omitted.

Don't forget about having to pass key to each element in React. The simplicity of using map() is an illusion. SolidJS splits it between and . is equivalent to passing the object as the key and is equivalent to passing the index as the key. https://www.solidjs.com/tutorial/flow_for https://www.solidjs.com/tutorial/flow_index

> Don't forget about having to pass key to each element in React. The simplicity of using map() is an illusion. That's one of the design decisions I don't fully understand. It knows that there should be a key there so why just not put it there silently and let me override it when I need, instead of screaming at me when I omit it.

It’s a performance pitfall. The warning is trying to make sure the dev correctly tells it how to and when not to re-render.

Could it silence the warning? Yes. However, the React devs choose not to. I think it’s the correct default, but likely needs a more educational warning message.

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

#145

Post by egeozcan »

peferron wrote: post #137
riwsky wrote: post #37

Earlier quoted context omitted.

React lets you build DOM with normal JavaScript loops and .map; solid requires its own For element. How do you define “does not fight against js”? Because the above feels likes solid fighting against js.

Fully agree. With React, "plain JS" works just like I expect it to. If I have an event handler that does `x = foo` then I don't expect my component to re-render. Why should it? I'm just changing the value of a local variable. If I want to re-render, there's no way to express that in plain JS, so I'll use React's API and write `setX(foo)` instead. Now it's clear that it's not just changing the value of a local variabl…

Sorry for the "+1" chain but I want to express my agreement as well.

Especially when I compare it to Svelte and Vue (not solid, solid.js is just... good), if I look at a component, with react it's way easier to say what's going to happen.

Aren't there gotchas? Yes, but sometimes it's just stuff JS lacks, and so does React.

I'm very excited about Records and Tuples in JS to help with the immutability, for example: https://github.com/tc39/proposal-record-tuple

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

#146

Post by ricardobeat »

DougBTX wrote: post #142
lhorie wrote: post #112

Earlier quoted context omitted.

> react is fundamentally about 'inputs changed, render this' I mean, pretty much all frameworks these days have that fundamental declarative model, react wasn't particularly innovative on that front (e.g. the declarative model already existed in angular, knockout, etc) What the setInterval example highlights is that newer subsystems in React like useEffect and Suspense are bolted on top of earlier iterations that wer…

> react wasn't particularly innovative on that front (e.g. the declarative model already existed in angular, knockout, etc) React was absolutely a breath of fresh air when it was released. Knockout was similar to Solid.js in that they both have functions that you call which then log a data dependency, then when the data changes the UI updates. This led to lots of pain, because instead of a plain value, you have funct…

We also had ractive.js, we had mithril, intercooler.js (now htmx), we even had (fab).js as far back as 2010 with functional rendering. A 'breath of fresh air' pretty much depends on what you had been breathing.

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

#148

Post by toomanydoubts »

rk06 wrote: post #120
intrnl wrote: post #96

Earlier quoted context omitted.

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…

I mean side effects from a functional point of view. Let me explain in more details React’s philosophy is View = F(data) I.e. view is a pure function of data. By “pure”, we mean F() does not do console.log, ajax calls, date time and other stuff which is not consistent every where. This assumption is ingrained in React. You see it when you are told that react can overrender and your code should handle overrendering. A…

I fail to see the purity in react with all that useState, which obviously by the name is tracking state outside the scope of the function(eg: it's actually View = F() and data is coming from outside when calling useState). It's not pure at all. I really would like to see something more akin to Elm, where all your state is explicitly passed into the component, and you have commands that update state and trigger the view again, making it actually "functional". I guess this takes the form of redux in react, but I'd like to see it ingrained in the components themselves.

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

#149

Post by ricardobeat »

seer wrote: post #61
bryanrasmussen wrote: post #45

Earlier quoted context omitted.

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…

Maybe, but in my experience whenever I encounter an incomprehensible mess of hooks it usually ends up because devs were not using all the tools that react provides. For example a flurry of setStates could be wrapped up in one single state. If it gets too complex - into a reducer. Components that don’t benefit much from splitting up could have their business logic wrapped into a context, and let the view code be just…

> For example a flurry of setStates could be wrapped up in one single state. If it gets too complex - into a reducer

You've just deoptimized your app, and your whole component will re-render on every change.

> Components that don’t benefit much from splitting up could have their business logic wrapped into a context

You did it again. More unnecessary re-renders.

> it’s still performant and works

True that 'it works', but it's usually not as performant as you think - we just have really fast computers and phones now.

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

#150

Post by wonnage »

ihateolives wrote: post #132
benatkin wrote: post #105

Earlier quoted context omitted.

Don't forget about having to pass key to each element in React. The simplicity of using map() is an illusion. SolidJS splits it between and . is equivalent to passing the object as the key and is equivalent to passing the index as the key. https://www.solidjs.com/tutorial/flow_for https://www.solidjs.com/tutorial/flow_index

> Don't forget about having to pass key to each element in React. The simplicity of using map() is an illusion. That's one of the design decisions I don't fully understand. It knows that there should be a key there so why just not put it there silently and let me override it when I need, instead of screaming at me when I omit it.

The purpose is well-documented here: https://reactjs.org/docs/reconciliation.html#recursing-on-ch...

And it also goes into why index is a poor key (it's basically the same behavior as with no key).

Using object identity to detect inserts doesn't work either, because the map function is returning new React element objects on each render.

Practically speaking if you know your items won't change, then omitting the key or using index is fine.

Post reply on HN