> implement your proposal as a library, AND convince people to use it on its own technical merits. That is almost literally exactly what happened: most major J

> implement your proposal as a library, AND convince people to use it on its own technical merits. That is almost literally exactly what happened: most major JS frameworks (except React) converged on Signals. > Because not having signals in the language was never an actual problem holding back reactive UI development in JS. Oh, but it did hold back reactive development. There are many limitations on current implementations of signals precisely because there's no proper support for many things in the language. > You need to sell why your (or any) signals implementation needs to be in the JavaScript standard. That is why it is: - a proposal that - calls for input from implementers, users, library developers etc. > Unlike e.g. promises that are useful on their own, But the exact same thing happened with promises: everyone had their implementation, there was no need for a proposal to add that specific API to the standard library. Deferred (the precursor to Promises) existed for several years before Promises. Here's the full history: https://samsaccone.com/posts/history-of-promises.html https://samsaccone.com/posts/history-of-promises.html And yet, 15 years later here we are