[Fatalist_ma]

There is an interesting debate about React and signals in the comments of this article, between Dan Abramov and Ryan Carniato - https://dev.to/this-is-learning/react-vs-signals-10-years-la...

[pavlov]

I read it until the point where he defends the idea that these two functions obviously do something completely different:

  function One(props) {
    const doubleCount = props.count * 2;
    return <div>Count: {doubleCount}</div>;
  }

  function Two(props) {
    return <div>Count: {props.count * 2}</div>;
  }

It honestly made me wonder whether the article was dated April 1 and I’d been had.

More generously, JS framework design is hard. If you’re ambitious at all, you end up fighting the language and your runtime paradigms will hang like ill-fitting clothes on its syntax. The One/Two example above shows how easily expectations break in this world of extensions to extensions. There’s no way to know what an apparently simple piece of code will actually do without knowing the specifics of a given framework.

[eyelidlessness]

> I read it until the point where he defends the idea that these two functions obviously do something completely different

> [code]

> It honestly made me wonder whether the article was dated April 1 and I’d been had.

They don’t do anything different if your model of components is that they rerun. But that model is only one way to implement components, and JSX is unopinionated about semantics exactly like this. Intentionally, by design.

If you’re only familiar with React and other frameworks with a similar rendering model, of course it’ll be surprising that those two functions would behave differently. But if you’re familiar with other JSX implementations like Solid, you’ll spot the difference right away: components don’t rerun, only the JSX does. The first function will always render the same thing because `doubleCount` is set up on component creation and static for the remainder of the time the returned div is mounted.

You are welcome to prefer React’s model. It certainly has some cognitive advantages. But it’s not inherently the only correct model either.

[__s]

> There’s no way to know what an apparently simple piece of code will actually do without knowing the specifics of a given framework.

Yes. In solid-js JSX interpolation needs to be read as having implicit lambdas. You need to know how a framework works to use it

It's somewhat what the discussion was getting at between Ryan & Dan. solid-js having fine grained reactivity involves a lot of lambdas, in JSX they're implicit, but code outside of JSX has to spell them out explicitly

[recursive]

There are those of us for which this actually makes sense. More sense than react anyway.