A proposal to add signals to JavaScript

Am I the only one that thinks the vanilla js example is actually easier to read and work with?<p>- &quot;The setup is noise and boilerplate heavy.&quot; Actually the signals example looks just as noisy and boilerplate heavy to me. And it introduces new boilerplate concepts which are hard for beginners to understand.<p>- &quot;If the counter changes but parity does not (e.g. counter goes from 2 to 4), then we do unnecessary computation of the parity and unnecessary rendering.&quot; - Sounds like they want premature memoization.<p>- &quot;What if another part of our UI just wants to render when the counter updates?&quot; Then I agree the strawman example is probably not what you want. At that point you might want to handle the state using signals, event handling, central state store (e.g. redux-like tools), or some other method. I think this is also what they meant by &quot;The counter state is tightly coupled to the rendering system.&quot;? Some of this document feels a little repetitive.<p>- &quot;What if another part of our UI is dependent on isEven or parity alone?&quot; Sure, you could change your entire approach because of this if that&#x27;s a really central part of your app, but most often it&#x27;s not. And &quot;The render function, which is only dependent on parity must instead &quot;know&quot; that it actually needs to subscribe to counter.&quot; is often not an unreasonable obligation. I mean, that&#x27;s one of the nice things about pure computed functions- it&#x27;s easy to spot their inputs.

When they added Promises to JavaScript, I bristled at the thought that I might have to start writing `new Promise` everywhere.<p>In practice, I can count on two hands the number of times I’ve written `new Promise`. What <i>did</i> happen, though, is I started to write `.then` a whole lot more, especially when working with third party libraries.<p>In the end, the actual day-to-day effect of the Promise addition to JavaScript was it gave me a fairly simple, usually solid, and mostly universal interface to a wide variety of special behaviors and capabilities provided by third party libraries. Whether it’s a file read or an api request or a build step output, I know I can write `.then(res =&gt; …)` and I’m already 50% of the way to something workable.<p>If this Signal proposal can do something similar for me when it comes to the Cambrian explosion of reactive UI frameworks, I am in favor! What’s more, maybe it will even help take reactivity beyond UI; I’ve often daydreamed about some kind of incrementally re-computed state tree for things other than UI state.

Why does it need to be a part of the language? This could be a library. There <i>are</i> such libraries. They are small, so including them in your code is no big deal. Adding this to the language <i>should not even be a goal</i>.<p>Thinking that the current crop of JS UI libraries designed their signals in such a good way that it needs to become a part of the language is hubris. Signals have many possible implementations with different tradeoffs, and none of them deserve to have a special place in the JavaScript spec.<p>Before these libraries used signals, they or their predecessors used virtual DOM. Luckily, <i>that</i> didn&#x27;t become part of JS, but how are signals any different? They aren&#x27;t. The argument for making them standard is even worse than for virtual DOM.<p>Are we just going pile every fad into a runtime that basically has no way to dispose of no-longer-wanted features without breaking the web? That is quite short sighted.

When I need to signal something across my application, I use events:<p><pre><code> window.dispatchEvent(new Event(&#x27;counterChange&#x27;)); </code></pre> And every part of the application that wants to react to it can subscribe via<p><pre><code> window.addEventListener(&#x27;counterChange&#x27;, () =&gt; { ... do something ... }); </code></pre> Anything wrong with that?

I’ve been trying for decades to understand why people find it so hard to keep track of state and update the DOM.<p>Sure, it requires a bit of discipline, but it’s vastly simpler to me than whatever solution comes up every few years (Backbone, Knockout, Angular, React, modifying the language itself, etc). There must be something profoundly different with the way I think.<p>It even expresses itself in the function naming. They call updating innerText “render”. You’re not rendering anything. At most, the browser is, but so is everything else it does related to painting. It feels like a desperate attempt to complicate what is one of the simplest DOM functions. It really baffles me.

Promises are a nice success story, but without async&#x2F;await it wasn&#x27;t really necessary to standardize<p>&gt; The current draft is based on design input from the authors&#x2F;maintainers of Angular, Bubble, Ember, FAST, MobX, Preact, Qwik, RxJS, Solid, Starbeam, Svelte, Vue, Wiz, and more…<p>Would be interested what existing library authors think of this proposal. Interesting that React is not in that list<p>Signals are a bit like channels, except they&#x27;re broadcast instead of single receiver. It&#x27;d be neat if this could somehow be leveraged to allow web workers to communicate with channels instead of onMessage callbacks. Specifically being able to `select` over signals&#x2F;channels&#x2F;promises like in Go would over a syntactic benefit over having to try manage multiple concurrent messaging mechanism with callbacks (maybe by allowing signals to be included in `Promise.any`)

I didn&#x27;t understand the example in the linked README.<p><pre><code> &#x2F;&#x2F; A library or framework defines effects based on other Signal primitives declare function effect(cb: () =&gt; void): (() =&gt; void); </code></pre> What library? What framework? I lost here. What&#x27;s effect?<p><pre><code> effect(() =&gt; element.innerText = parity.get()); </code></pre> How does effect knows that it needs to call this lambda whenever parity gets changed? Will it call this lambda on any signal change? Why this talk about caching then? Probably not.<p>Anyway I think that signal idea is sound, if I understood correctly what the authors tried to convey. My main issue with those decoupling architectures is that once your application is complex enough, you will get lost trying to figure out why this particular event being emitting. Ideally signals should fix this by modifying stacktrace, so when my callback is being called, it&#x27;d already contain a stacktrace of the code which triggered that signal in the first place.

Related is S.js: <a href="https:&#x2F;&#x2F;github.com&#x2F;adamhaile&#x2F;s">https:&#x2F;&#x2F;github.com&#x2F;adamhaile&#x2F;s</a><p>I love signals. I prefer them when making UIs over any other primitive (besides, perhaps, the cassowary constraint algorithm). I try to replicate them in every language I use, just for fun.<p>I also don&#x27;t believe they belong in the Javascript language whatsoever. Let the language be for a while, people already struggle to keep up with it. TC-39 is already scaring away people from the language.

This looks very much like mobx, which is my favorite JS effect system.<p>Here is the mobx version:<p><pre><code> import { observable, computed, autorun } from &#x27;mobx&#x27;; const counter = observable.box(0); const isEven = computed(() =&gt; (counter.get() &amp; 1) === 0); const parity = computed(() =&gt; isEven.get() ? &quot;even&quot; : &quot;odd&quot;); autorun(() =&gt; { element.innerText = parity.get(); }); &#x2F;&#x2F; Simulate external updates to counter... setInterval(() =&gt; counter.set(counter.get() + 1), 1000);</code></pre>

&quot;let&#x27;s bake my current framework du jour into the standard library!&quot;<p>It&#x27;s a bit like tattooing your girlfriend&#x27;s name onto yourself.

I don&#x27;t think signals will help move development away from further complexity, and that&#x27;s really what we need today.<p>There&#x27;s a fundamental question of why modern sites&#x2F;apps reach for patterns like signals, memorization, hybrid rendering patterns, etc. I wouldn&#x27;t begin to claim I have all the answers, but clearly there are gaps in the platform with regards to the patterns people <i>want</i> to implement and I&#x27;m not sure that jumping to signals as a standard helps better understand whether its the platform or our mental models that need updating to get back in sync.<p>Personally I&#x27;ve found code much easier to maintain when the frontend is only responsible for state that truly is temporary and doesn&#x27;t live on the back end at all. For me any persisted state belongs on the server, as does any rendering that depends on it. This largely makes signals unnecessary, very few apps have such complex temporary state that I need a complicated setup to manage it.

Looks useful, but what baffles me is.. Why is every framework setting state or their &quot;signals&quot; using &quot;setX&quot; functions? What&#x27;s wrong with the built in getter and setters that you can either proxy or straight up override?<p>This feels arguably cleaner: something = &quot;else&quot;;<p>Than: setSomething(&quot;else&quot;);

Back in the days there was an effort to put observables in the language because they were popular (and rxjs was, too).<p>Glad that didn&#x27;t happen. And I think everybody else is, too. Maybe we should keep that in mind when standardizing features of frameworks.

Surely it would be better to fix the interoperability issues of the language? &quot;Lets just add a single implementation of everything to the standard!&quot; seems like quite a strange response to &quot;users of the language are having trouble with interoperability due to false coupling.&quot;

The examples only show simple values. What happens when mutating nested objects and arrays?<p>Other frameworks usually struggle a lot with this. With workarounds like having to override equality functions in useMemo() or call .set after a mutation even if you pass in the same instance as before.

Oh man. This sounds complicated.<p>The hard part of signals is similar to over complicating events.<p>It’s hard to debug what is going on and what to fix when things go wrong.

Hmm, if we can optimize the reactive state management in all web apps, that sounds cool.<p>If this is to be a base for VueJS, it should handle deep changes. They have a note about support Map and Set, but being able to to control depth is nice in VueJS. (I&#x27;d say watch() should be deep by default, since non-deep is an optimization that can lead to accidental inconsistent state.)<p>Streams. Generally, I find RxJS backwards. Usually you just need &quot;state&quot;, so that should be the easiest thing to implement. But I can&#x27;t deny that the programming model is beautiful. Standardizing &quot;state&quot; without also considering streams seems odd to me. The &quot;computed&quot; creates a pipeline of updates, very similar to one you&#x27;d do with a map over a stream. If RxJS didn&#x27;t already exist, I probably wouldn&#x27;t have cared about this duality.<p>Async. Sure, signals can be synchronous, but Computed should definitely play well with async functions. This is a big shortcoming in VueJS (that people work around on their own.) That also implies handling &quot;pending computation&quot; gracefully for debuggability. I see there&#x27;s a &quot;computing&quot; state, but this would have to be surfaced to be able to debug stuck promises.<p>Exceptions. I like the idea of .get() rethrowing exceptions from Computed. VueJS is a bit vague on that front, and just stops.

Is dependency tracking problem statically solvable (without calling effect once and subscribing to all .get&#x27;s)?<p>I don&#x27;t think this needs to be a language feature, rather abstraction of existing features. In other words, can&#x27;t this be a library?<p>I know that SolidJS is able to figure out dependent signals, but probably doing so on the first execution.

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.<p>React boilerplate for this case looks so much better in my opinion, take a look<p>```<p>function Component() {<p><pre><code> const [counter, tick] = useReducer(st =&gt; st + 1, 0) useEffect(() =&gt; setInterval(tick, 1000)) return counter % 2 ? &#x27;odd&#x27; : &#x27;even&#x27;</code></pre> }<p>```<p>Three lines, declarative, functional, noice.

This article is missing a &quot;What are signals&quot; section. And yes, this does not do the job:<p>&gt; Within JS frameworks and libraries, there has been a large amount of experimentation across different ways to represent this binding, and experience has shown the power of one-way data flow in conjunction with a first-class data type representing a cell of state or computation derived from other data, now often called &quot;Signals&quot;.

This looks sufficiently advanced to warrant some language support.<p>This could be a much more powerful feature if signal-dependencies were discovered statically, rather than after use in runtime.<p>If you’ve reached the point where you agree that the library should be standardized, why not take it even further to integrate it even more?

&gt; The current draft is based on design input from the authors&#x2F;maintainers of Angular, Bubble, Ember, FAST, MobX, Preact, Qwik, RxJS, Solid, Starbeam, Svelte, Vue, Wiz, and more…<p>This is primarily the only handful of consumers of this stdlib.

really looking forward to get nice dev tools out of this work

The lack of signals isn’t remotely the largest issue with JS, and adding them has minimal impact for most users of JavaScript. The biggest issue is the lack of a standard library, resulting in npm hell in most projects.

Off topic, but I’m wondering if anyone attracted to this topic could help me understand why JavaScript doesn’t have macros.<p>I’m aware of much conversation around dismissing macros, often in the context of bad dev experience — but this sounds like a shallow dismissal to me.<p>At the end of the day, we have some of the results of macros in the JavaScript ecosystem, but rather than being supported by the language they are kicked out to transpilers and compilers.<p>Can anyone point me to authoritative sources discussing macros in JavaScript? I have a hard time finding deep and earnest discussion around macros by searching myself.

I don&#x27;t quite get how these signals intend to be efficient while using pull-based evaluation. A pull-based model potentially requires touching the entire object graph to check if one value needs to be recomputed on get(). It makes for a simple but inefficient implementation.

Signals only made sense in the past of desktop programming languages, because the ones on mainstream lacked lambdas and closures.<p>Smalltalk, and Lisp derived ones did just fine without them.<p>Modern JavaScript already has them as well, no need for what is basically a closure with a listeners list.

I like the quality of this proposal, which reminds me of JSRs. It does make a lot of sense.

The first and only question that matters: is this useful as a primitive?<p>Im inclined to say no. Signals seem like they are a UI concept, primarily. Just use any signal lib you want. Utility libraries dont really need to understand signals.

I&#x27;ve been enjoying &quot;signals&quot; in the form of re-frame subscriptions for many years now.<p>They solve a neat subset of problems in front-end developments. But they don&#x27;t solve all of them.<p>Adding it to JavaScript as language construct is unnecessary.

I’m in favour. Mobx is great. This will focus efforts on making better devtools.

From a first look, signals seem to parallel event&#x2F;behaviour-style functional reactive programming (FRP). Hopefully some useful ideas from the FRP world can be brought across.

Looks bad. It adds what looks like more nonsense complexity. Also, &quot;Signals&quot; as a name is not descriptive to what is proposed (see e.g. Qt Signals).

Curious, what about using Proxies for handling state?

But the vanilla code is much cleaner and nicer to read and reason about than the proposal?!<p>Seriously the JavaScript ecosystem is so strange..

Sorry but I’ll be a little bit mad if this Preact&#x2F;Angular inspired thing is approved and made part of the spec, while Observable was deliberately ostracised.

What does this buy me over events?

Oh God why.

This is a horrible idea. Instead of building some dependency tracking into this niche feature of the language, JS should come up with a generic way of enabling framework developers to clean up resources without putting the burden on users of their API to manually do this.

Cool. My least favorite, cumbersome and brittle aspect of using Ember becoming a core aspect of JavaScript functionality.<p>No fucking thank you.

Not a bad thing at all… but this is the same mental model provided by the so-called atom-based state management systems in React. I believe Jotai is the most popular.

Easier to port react to vhdl or verilog?

Looks like Svelte 5 only somehow worse?

“Lets make my random UI state tracking framework part of the JavaScript spec”

Is this like QML property binding?

I am amazed at the ability of the JS community to consistently make things more and more complicated.

FFS there&#x27;s already something named signals, since c. 1972.

Socials:<p>- Reddit: <a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;javascript&#x2F;comments&#x2F;1bsgnf5&#x2F;tc39_proposal_for_signals_reactive_primitives_is&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;javascript&#x2F;comments&#x2F;1bsgnf5&#x2F;tc39_pr...</a><p>- X&#x2F;Twitter: <a href="https:&#x2F;&#x2F;twitter.com&#x2F;nullvoxpopuli&#x2F;status&#x2F;1774496900915327100" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;nullvoxpopuli&#x2F;status&#x2F;1774496900915327100</a><p>- Masto: <a href="https:&#x2F;&#x2F;mastodon.coffee&#x2F;@nullvoxpopuli&#x2F;112191605019758002" rel="nofollow">https:&#x2F;&#x2F;mastodon.coffee&#x2F;@nullvoxpopuli&#x2F;112191605019758002</a><p>- Blue Sky: <a href="https:&#x2F;&#x2F;bsky.app&#x2F;profile&#x2F;nullvoxpopuli.bsky.social&#x2F;post&#x2F;3koz4npobok2o" rel="nofollow">https:&#x2F;&#x2F;bsky.app&#x2F;profile&#x2F;nullvoxpopuli.bsky.social&#x2F;post&#x2F;3koz...</a>

Can&#x27;t we just call javascript &#x27;done&#x27;?<p>We keep adding things to the language, and never subtract anything, which means learning it as a language is getting harder and harder.

I&#x27;d be much more comfortable if they were standardizing around react or something. What is the advantage of this being a built-in feature compared to a lib for folks to actual use first hand before proposing it upstream?

- They’re saying ”<i>the community</i> wants less boilerplate”<p>- They introduce what is effectively a black-box system<p>- The new system is expected to handle all application state<p>- They try to push it for frontend folks while also remarking that it would be useful for <i>build systems</i><p>This has the same red flags the xz saga had.<p>Have we learnt nothing.<p>Lots of ”users” here vouching for the pattern and hoping it gets adopted. I bet this gets some nice damage control replies because there’s social engineering going on here right now and most seem to not be aware of it.