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?

[tomByrer]

Work in progress if you want to check it out @WebReflection
proposal-signals/signal-polyfill#44

[WebReflection]

@tomByrer you made my day with that PR, I hope it'll land but also, to keep this issue on topic, I wonder if showing great performance too would help TC39 moving this forward around its current Stage, thanks!

[tomByrer]

on topic

Likely a bit more on topic than you'd assume, an earlier version of alien-signals was merged into VueJS, so both that library & signals are in production in many sites.

Personally I think Signals can overtake a few use-cases of Promises, & is easier to reason about IMHO.

[hkochniss]

so both that library & signals are in production in many sites.

Not quite. The signals approach will be in Vue 3.6 (https://x.com/youyuxi/status/1879373091480166597), and given Vue's release cadence this might not happen in a while. Also needs proper testing "in the wild". Current Vue release is 3.5.13: https://github.com/vuejs/core/blob/main/CHANGELOG.md

[CarelessCourage]

Not quite. The signals approach will be in Vue 3.6 (https://x.com/youyuxi/status/1879373091480166597),

I think that tweet is referring to Alien Signals 1.0? But I think an earlier version of alien signals (0.4.4) was already merged into vue core earlier (vuejs/core#12349 (comment)).

Edit: nevermind, you're probably still correct as the author himself refers to that same 0.4.4 PR as being scheduled for release in Vue 3.6 aswell. (https://github.com/stackblitz/alien-signals)

Anyway, this might be a bit nitpicky but Vue 3 has always had a "signals" approach. Its just that signals are called refs in vue. Also interestingly enough the underlying vue reactivity has also always been framework agnostic. I guess it will be easier to get that across to people now that the underlying reactivity is named a bit more familiarly to other developers though.