Also some examples in the polyfill README [0]. Certainly looks interesting.

I wonder some years down the future, if there will be no need for JS frameworks since a lot of what they offer will be integrated into JS itself.

https://github.com/proposal-signals/signal-polyfill

Calling hooks "traditional" in relation to signals seems fine, lest that word be relegated in time to whatever you in particular care about at this juncture.

I'm sure some 80 year olds before us thought the same of us using that term.

It's not merely calling React traditional, it's calling React hooks traditional. They didn't exist for the first 6 years of the framework.

I’m confused by your comment. Signals do reduce manual render management.

By default, usestate causes unnecessary rerenders which signals avoid (all automatically).

> The whole point of React was to react to state changes automatically.

It isn't, given that React requires you to provide an array of dependencies when using useMemo and useEffect. The point of React is to automatically update the DOM when a virtual DOM tree gets modified.

that's the theory, but it's quite easy to end up needing to micromanage react to avoid pathological rendering scenarios

Yeah, I'm interested to learn more about signals, but the article seems to miss the whole point of brute-force state updates -- less cognitive complexity.

Immutable does not mean you have to copy the whole structure. You can store only the changes. This is how immutable data structures work in functional languages such as Haskell.

  > Also I don't like that React requires installing Node and compilation tools, this is a waste of time when making a quick prototype. Vue can be used without Node.

[1] https://react.dev/learn/installation#try-react

  Vue can be used without Node.

> it seems that with signals you must use immutable values only. Imagine if you have, let's say, a text document model, and you need to create a new copy every time the user types a letter.

Too small. Imagine if you have a 2GB mutable file. Each keystroke in the middle of the file has to move the whole 2nd gigabyte backward.

> Imagine if you have, let's say, a text document model, and you need to create a new copy every time the user types a letter. That's not going to work fast. And there will be no granular updates, because the signal only tracks the value (whole document), not its components (a single paragraph).

Funnily enough, back when storage was slow enough that saving a text document involved a progress bar, one of the big advantages Word had over competitors was lightning fast saves, which they accomplished by switching to an immutable data structure. That is, while others would update and save the data, Word would leave it untouched and just append a patch, skipping lots of time spent rewriting things that an in-place edit would shift.

The “copy everything” mental model of immutable programming is really about as wrong as a “rewrite everything” mental model of mutable programming. If it happens it’s bad code or a degenerate case, not the way it’s supposed to happen or usually happens. Correctly anticipating performance requires getting into a lot more detail.

React is crazy because someone thought this was too complicated for developers:

    event.listenTo(render);
    event.emit();

    property.listenTo(render);
    property.set([property.get()[0]]);

There’s a difference, see https://www.builder.io/blog/signals-vs-observables

Can you expand a bit on what you mean? To me (extremely amateur game programmer), that's what, event buses? more explicit state machines?

Both approaches are valid and applicable in different circumstances. To extend your example further, you often end up needing to do:

  function MySubComponent({ disabled }: { disabled: Signal<boolean> }) {
    // ...
  }  

  function MyComponent({ disabled }: { disabled: Signal<boolean> }) {
    return <MySubComponent disabled={disabled} />
  }

Where signals offer an important benefit is in localizing re-rendering. If you use context with regular, non-signal values the entire VDOM tree has to be re-rendered when the context value changes (because there's no way to know what code depends on its value). With signals you can change the value of a signal in the context without changing the context itself, meaning that the only part of the VDOM tree that gets re-rendered is the one using the signal.

With performance considerations out of the way context becomes a really interesting way to provide component composition without having to specify the same props over and over as you make your way down a chain.

ContextProvider is for when you have some data that any random component might need, and you don’t want to clutter up the system by passing it through every component (this is called “prop drilling”). Or maybe you can’t pass it through some container component that you don’t control.

That consideration is orthogonal to what the useful data is. It could be a signal, or not. In other words, signals are not an alternative to context.

Could you explain why?

I can't say as I'm not familiar with Preact signals, but I do know the Angular team brought on the author of SolidJS to implement signals in Angular. Though I think I remember reading at some point that Preact signals were essentially directly ported from SolidJS, so they're likely similar if nothing else. (Someone correct me if I'm wrong)

I was about to mention this too.

Compare: "import a specific lightweight library and wire together as needed" vs "write the whole app in terms of a bloated framework".

I've been out of the frontend game for a while, but what does react give you that knockout and maybe some url management logic do not?

I guess components are supposed to standardize modularity, so you can easily import some random widget?

Rich Harris of Svelte often mentions Knockout when talking about Svelte’s signals.