Updates around this proposal

[WebReflection]

This issue would like to be a placeholder for the state of this current proposal, as nothing really changed since a year ago and beside some documentation amend, it's not clear:

• how optimized is the current polyfill
• if TC39 is actually interested in this idea
• what change (or issue) is being tackled or not ... nothing so far, issues are just piling up

To whoever would like to close this already, can we have some sort of clarification around those 3 topics? Thank you!

[littledan]

• The current polyfill is not optimized. @linusg is looking into improvements.
• The proposal is at Stage 1, so TC39 agrees that it is interesting to discuss, but has not decided that it's something that we already expect to be in the language. Several delegates want this to happen, but we don't have a joint decision yet.
• @jkup recently wrote up a list of actions which would be good to post here. In my mind, the most important thing is to get experience in frameworks and iterate based on experience. And second, to make the definitions more rigorous and write more tests. Unfortunately I haven't seen much work in either of those two, beyond Lit's release and a couple other early experiments.

I apologize for the slow progress here. To be transparent, several of us in the champion group have been working on our own companies' or frameworks' use of signals in order to get experience in this area and justify/guide further work. I hope that we'll move faster and farther in 2025.

[tomByrer]

current polyfill is not optimized
get experience in frameworks

Unfraternally both are comingled. I'd like to release with it, but performance isn't there.

How about starting with an existing fast Signals library, then ensuring the API matches?