A proposal to add signals to JavaScript

> In practice you rarely need to explicitly go “new Promise” yourself

However you do quite often need to use Promise.all, even when using async/await.

Because there's no rule that says signals should ever be created at the top level assigned to a const variable. You could create signal objects dynamically based on user input, no current proposal or implementation prevents this. So there's no way to do static analysis on signal graphs.

> But frankly, I doubt it, if it was that similar, why are there at least a dozen frameworks with their own version?*

To answer this specifically: signals are a relatively low-level part of most frameworks. Once you've got signals, there are still plenty of other decisions to make as to how a specific framework works that differentiate one framework from another. For example:

* Different frameworks expose the underlying mechanism of signals in different ways. SolidJS explicitly separates out the read and write parts of a signal in order to encourage one-way data flow, whereas Vue exposes signals as a mutable object using proxies to give a more conventional, imperative API.

* Different frameworks will tie signals to different parts of the rendering process. For example, typically, signals have been used to decide when you rerender a component - Vue and Preact (mostly) work like this. That way, you still have render functions and a vdom of some description. On the other hand frameworks like SolidJS and Svelte use a compiler to tie signal updates directly to instructions to update parts of the DOM.

* Different frameworks make different choices about what additional features are included in the framework, completely outside of the signal mechanism. Angular brings its own services and DI mechanism, Vue bundles a tool for isolating component styles, SolidJS strips most parts away but is designed to produce very efficient code, etc.

So in total, even if all of the frameworks shared the same signals mechanism, they'd all still behave very differently and offer very different approaches to using them.

As to why different frameworks use different implementations as opposed to standardising on a single library, as I understand it this has a lot to do with how signals are currently often tied to the component lifestyle of different frameworks. Because signals require circular references, it's very difficult to build them in such a way that they will be garbage collected at the right time, at least in Javascript. A lot of frameworks therefore tie the listener lifecycle to the lifecycle of the components themselves, which means that the listeners can be destroyed when the component is no longer in use. This requires signals to typically be relatively deeply integrated into the framework.

They reference this a bit in the proposal, and mention both the GC side of things (which is easier to fix if you're adding a new primitive directly to the engine), and providing lots of hooks to make it possible to tie subscriptions to the component lifecycle. So I suspect they're thinking about this issue, although I also suspect it'll be a fairly hard problem.

Fwiw, as someone who has worked a lot with signals, I am also somewhat sceptical of this proposal. Signals are very powerful and useful, but I'm not sure if they, by themselves, represent enough of a fundamental mechanism to be worth embedding into the language.

To be as a long-time react.js user – these examples look like a kinda weird mix of declarative with some bitter imperatives. Like, foo.set depending on foo.get and having to manually set element innerText inside the side-effect, eww, I can only imagine how messy it can get for a somewhat more complex application.

React boilerplate for this case looks so much better in my opinion, take a look

```

function Component() {

  const [counter, tick] = useReducer(st => st + 1, 0)

  useEffect(() => setInterval(tick, 1000))

  return counter % 2 ? 'odd' : 'even'

}

```

Three lines, declarative, functional, noice.

I've literally never needed to do that. What's a real world use case?