Solid.js feels like what I always wanted React to be • Hacker News Board

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

#21

Post by MiddleMan5 » Tue, Mar 01, 2022, 5:04 AM UTC

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…

Slightly dismissive, but I agree the setInterval function was a little misleadingly contrived.

The transition to functional components was to reduce the coupling between abstract functionality and DOM-related lifecycle events.

React hooks are mostly about expressing where and when you want to memoize a value, with the default being not to.

Once you learn what to look out for, and properly designing and review codebases at scale, these trivial issues don't happen all that often. Additionally, being able to specify memoization parameters explicitly brings extra flexibility and some additional design patterns.

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

#22

Post by cosmotic » Tue, Mar 01, 2022, 5:05 AM UTC

dheera wrote: post #15

Every time I see stuff like this componentDidMount() { I get driven away from React. It looks haphazard. Seriously? What about componentDidntMount() { componentWantedToMountButDidnt() { ... I'm used to clean naming conventions like void Component::on_mount() { .... }

Maybe the name is trying to communicate it happens after the component mounted instead of just before

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

#23

Post by yuchi » Tue, Mar 01, 2022, 5:05 AM UTC

dheera wrote: post #15

Every time I see stuff like this componentDidMount() { I get driven away from React. It looks haphazard. Seriously? What about componentDidntMount() { componentWantedToMountButDidnt() { ... I'm used to clean naming conventions like void Component::on_mount() { .... }

The reason behind this different naming convention comes from the diversity in experiences of the original team. This will/did prefix instead of “on” comes from Mac OS X/iOS patterns and allows the name to convey the “when” of the listener. It is not “during component mounting” it is “after it did”.

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

#24

Post by joeyjojo » Tue, Mar 01, 2022, 5:13 AM UTC

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…

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 still find myself confused by hooks or the mess that I create when I use them.

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

#25

Post by JonathonW » Tue, Mar 01, 2022, 5:14 AM UTC

dheera wrote: post #15

Every time I see stuff like this componentDidMount() { I get driven away from React. It looks haphazard. Seriously? What about componentDidntMount() { componentWantedToMountButDidnt() { ... I'm used to clean naming conventions like void Component::on_mount() { .... }

When does on_mount run?

React's componentDidMount() is a lifecycle method that runs after a component mounts, once it's been inserted into the DOM. This is in contrast to componentWillMount() (now UNSAFE_componentWillMount(), because it breaks when async rendering is enabled), which is called before the component mounts.

This naming scheme becomes even more important for the update lifecycle methods-- in addition to componentDidUpdate(), there's a shouldComponentUpdate() called before it (where you can return true/false to tell React whether or not to proceed with the update) and UNSAFE_componentWillUpdate(), called between those two.

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

#26

Post by ryansolid » Tue, Mar 01, 2022, 5:22 AM UTC

manmal wrote: post #19

KrishnaShripad wrote: post #11

Regarding the example under "Reactivity, not lifecycle hooks": Does the component reference the same outer "count"? So is "count" here global or local to the component? In other words, what is the scope of "count"? Does it change based on where it is placed? If I create multiple components, do they all reference the same "count" or is it different for each component? Sorry this question might seem naive if you are ex…

I think the count variable is quasi an Rx subject, it has identity and any code using it is keeping a hard reference on it. It would probably be GC‘d if nobody referenced it. In my understanding, yes, multiple components would use the same instance of count.

Yeah this is correct. The trick to this is that the subscriptions happen in our JSX and hooks. And really is just a nested tree of `createEffects` if one ever re-evaluates or is disposed it releases its child computations. So while the lifecycle isn't tied to components it is still hierarchically structured. Ie.. places where logic can branch becomes the owning scope, like conditionals or loops. So Signals like count don't really matter where they live and will live as long as in scope or referenced, the rendering still largely defines how long things are around.

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

#27

Post by thatswrong0 » Tue, Mar 01, 2022, 5:24 AM UTC

latchkey wrote: post #18

pier25 wrote: 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?

https://www.solidjs.com/docs/latest/api#control-flow For reactive control flow to be performant, we have to control how elements are created. For example, with lists, a simple map is inefficient as it always maps the entire array. This means helper functions.

This feels like we're trading complexity here for complexity there, and it seems impossible to judge which way is actually "better". I use loops in React all the time but only have used `setInterval` in a component a handful of times..

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

#28

Post by ryansolid » Tue, Mar 01, 2022, 5:31 AM UTC

smt88 wrote: post #2

This is interesting because it's a bit like Svelte, but it doesn't use the Svelte "language" (which looks like JS and HTML but, in some crucial ways, sometimes isn't ). It's a little disheartening to see that it's 3+ years old and has only had a single significant contributor though[1]. It's impossible to avoid single-contributor projects in the JS world, especially with Node, but the alternatives (React, Vue, Angula…

I'd also look at other repos. Admittedly for the core code it has been mostly me. I think there is an intimidation factor. When you create a library this performance oriented it is hard to get people comfortable working on the core.

But things like the site, docs etc.. are much more contributors making more substantial submissions: https://github.com/solidjs/solid-site/graphs/contributors https://github.com/solidjs/solid-docs/graphs/contributors

We would have never gotten the docs translated into 15 languages otherwise. I do agree that one should be cautious regardless. But I don't want to underplay the contributions of many contributors putting in improvements every day.

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

#29

Post by qbasic_forever » Tue, Mar 01, 2022, 5:32 AM UTC

dheera wrote: post #15

Every time I see stuff like this componentDidMount() { I get driven away from React. It looks haphazard. Seriously? What about componentDidntMount() { componentWantedToMountButDidnt() { ... I'm used to clean naming conventions like void Component::on_mount() { .... }

Well, modern react is pushing folks to use the hooks model which jettisons the whole componentDidMount and other class functions. Now you use a side effect hook: https://reactjs.org/docs/hooks-effect.html This is a little more clear that it's for side effects of the component being put in the DOM, but it does require a bit more knowledge of react and hooks.

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

#30

Post by chrismorgan » Tue, Mar 01, 2022, 5:34 AM UTC

lpghatguy wrote: post #13

New JS frameworks always make for compelling hello world examples. Can you branch on state or use loops over data in Solid.js? The reason _why_ React has a virtual DOM is to enable more interesting relationships between your data and your presentation. Anyone can make a framework that makes the source code for an incrementing number look pretty! As an example of this point, check out the "Simple Todos" example for So…

> In React, we render lists by using regular JavaScript idioms like loops, arrays, and array methods like map. However in Solid.js, much like traditional templating languages, we get a construct like that reinvents a concept that's already in the language.

Once you deal with larger amounts of data and need virtualised rather than fully-materialised lists, you start using different things in React as well. The fact of the matter is that if you care about performance at all, the simple ways are just insufficient, and the native language constructs were designed for procedural programming, not reactive interface rendering, which requires fundamentally incompatible semantics. It’s not even fair to claim that React uses regular JavaScript idioms—VDOM, hooks, the entire shebang is all about eschewing regular JavaScript idioms because they don’t scale. (OK, so there’s also the matter of transient state like scroll positions, element focus, and form field values; it’s not fair to say that React does all these things purely for performance’s sake, as the naive immediate mode approach would also break such functionality.)