Standardizing Signals in TC39

I'll be talking about standardizing signals in TC39. To introduce myself, I go by LittleDan on the internet at Bloomberg. I've been working in TC39, the JavaScript Standards Committee, since 2016. And some of the bigger things that I work on include BigInt, the arbitrary size integers that you have in JavaScript, and Private using the hashtag. A couple of years ago, I moved from coastal Catalonia, where you can see my town's tiny coastline. It's sort of shaped like going to a point. And now, dark New York City.

So the Bloomberg terminal is, my job is to work on that, and standards is, you know, ties into that. The Bloomberg terminal is a big application suite that's all based on Chromium on the inside. So it's kind of like an electron app. And so frontend is written in JavaScript, generally. And this is why it's really important to us to push forward the JavaScript language, as well as HTML and CSS, all the web technologies. So going back to basics of why signals, let's think about why we use UI frameworks. So the old model, which maybe many of you aren't familiar with, was PHP on the server, or something different on the server, that has your templating, then you ship something to the client, and that has a little JavaScript script in it, with maybe jQuery or maybe just vanilla JavaScript. And generally, the model was, you have one way of doing the initial way that your page gets rendered, and then you make fixups later on the client. And one of the patterns was the state in the DOM. I have an example on the next slide. And the new model with React and its descendants, sort of all modern frameworks, follow this model where you do templating the same way for initial renders versus subsequent renders, and state rather than being trapped in the DOM or random global variables, can be centralized with one-way data flow.

So here's a simple example. In the old model, you might have a page with a button and counter, so this kind of canned example of reactivity. It's very simple with the vanilla.html on the left, to make it so you have a button, and whenever you click it, you get the content of the span, you increment it, and you write it back into the same place. It looks very terse and clean. But the problem with it is, if you need to do something more complicated when the state changes, for example, persists the fact that the counter incremented on the server, now you have to be kind of reacting to changes in the text content. Because the state is just distributed into the DOM, it becomes really complicated to organize your subsequent computations. On the other hand, in React, you can create your state separately, and your template can be based on that state, so the span includes the count. You never update the span directly, you update the count, and then that's reflected. This allows for different kinds of uses of that, and different dependent computations. This is what signals facilitate solving. So, the key job of UI frameworks is to keep the DOM up to date with the data. That lets you separate the data from the DOM, and then, you know, the framework puts it back.

One way to talk about this using old words is the view is a pure function of the model. Maybe you've heard of model view controller, and don't know what it means. This is an old way of talking about the view being the UI, the model being kind of the data under it. This applies completely to the paradigm of React, if you think about it this way.

So, eventually, everyone arrived at kind of a common point in frameworks. If you look at ten years ago, there was a lot of diversity in how to handle this templating situation. But at this point, most frameworks have this signals concept. And React has a similar programming model where you're still basing everything that you do on what you want the final thing to look like, and doing it as a function of that. There are different algorithms for reaching that, but it's ultimately the same kind of pure function model.

Once you have your user interface as a function of the state, there are multiple ways to try to evaluate that. Immediate mode is every time something changes, you wipe out the whole screen, and you write a completely new thing on. So, these are terms used back in the day in game development. Retained mode is different. In retained mode, you're not describing how the whole screen is painted. When some piece of the state changes, you figure out exactly what to change in the UI to get the right result. So, that's a little bit more like my vanilla JS example before. What you get with signal based reactivity is immediate mode behavior with retained mode performance. So, the programming model is you describe how the model, how the data state is converted into the view, the DOM. But when it actually runs, it only updates what's needed. And only if it's needed. It even only does the calculations if they're needed. So, this is also the programming model of React.

Signals represent a cell of data which may change over time. So, you have a mutable base cell called state, which you can create it, get or set values, and then a cached derived computation called a computed signal, which is created by passing in a function, and then you have a way to get the value of it. These are the APIs used in the standard signal proposal. I'll show some examples later. But let's talk about how they work. There's a lot of common behavior across current frameworks. One is auto tracking.

One is auto tracking. When you have a computed signal, it watches in that callback that you pass into it which signals are read. And those become dependencies that are automatically tracked in the signal dependency graph. Then when one of those dependencies changes, they become automatically invalidated. So, then it knows that it can't cache the computed value. Ultimately, computeds are kind of like use memo. They're a cache. Signals are also evaluated lazily. So, when you have a state signal that's used by a computed signal and the state changes, the computed is not recalculated immediately. Instead, the computed signals are only evaluated when they're read, not when one of their dependencies is updated. This is really important for, well, for one, for a certain level of debouncing, but also to avoid this problem called the glitch problem that I'll explain in a minute. And these things together create this property of from scratch consistency. As long as you're using pure functions in your computeds, everything works just the same as if it reevaluated everything from scratch.

So, the glitch problem is if you implement signals the naive way, where when you have a state and you change it, that reruns the computed, you know, that's how a lot of the previous generation of frameworks worked. When React came out, its innovation, well, a big piece of its value was that it didn't do this. It only evaluated things when they were needed. But previously, you know, AngularJS and Ember, when something would change, it would figure out, okay, I have the things that depend on it, so I'll update those, and that kind of becomes a mess.

In particular, if you set a signal, and then you have some effect that's based on reacting to that signal changing, you might observe intermediate states of the computation. So, in this case, t.get should always be greater than seconds.get, because it's one more than it. But if there's a search that goes on the left before going on the right, when visiting the updates, it might log false because it might see one of them updated and the other one not updated. And this image is from Wikipedia's great article about reactivity.

So, the solution is a little bit complicated, but historically, frameworks tried to, you know, implement parts of this, and at this point, everyone realizes, no, we just have to do the correct solution, which is to topologically sort dependencies and evaluate them in a coherent order. So, this is a directed acyclic graph, if there's a cycle, that can cause an error when the cycle is created. So, that can be detected. But you can sort the nodes so that you're never running a computed before all of its things that came before it have already run. And pull-based evaluation is also crucial to this. Because you do this sort when a get occurs. There are multiple algorithms for evaluating this. This is a blog post by Kristen, formerly from the EmberJS team, about using revision numbers. Another algorithm, this is from an explanation from Milo from the solid team, is to use these kind of pushing forward dirtiness and then re-evaluating nodes based on that. Anyway, I don't have time today to go into the algorithms. But even though there are multiple algorithms, they have the same observable behavior. They do the same thing, they run the computed in the same order.

And ultimately, what's happened with the frameworks, it can be compared to carnicization. So, the phenomenon where a bunch of different animals all had convergent evolution towards the body plan of a crab. Because for certain lifestyles, it's very effective. And I think we've seen that within JavaScript frameworks. It's not as if solid invented signals and everybody copied them. Historically, other frameworks were kind of approaching it from other sides and seeing different pieces of the problem and have all kind of both influenced each other directly and also solved the same problem and gotten to the same place.

So, when we at Bloomberg are thinking about how do we want to construct our front end, what kind of framework to use, well, so far, our software development has been largely based on standards. As I said, the core terminal is based on Chromium. So, HTML, CSS, JavaScript. Also, for software supply chain security to detect and remediate outdated pieces of software, we use OAuth, Cyclone DX, S bombs, which is standardized in ECMA as well, just like JavaScript.

Making a company wide standard is good, but it's even better if you have a standard that's common for everybody. That really makes sure that these systems are long lived and stable. So, we're working on this at ECMA TC39. ECMA is a standards body based in Geneva, which governs kind of various different groups. And TC39 is the 39th technical committee of ECMA. And I worked with Jatin from Google and from the Wiz team and Yehuda Katz from EmberJS, working at Heroku, on presenting this to TC39. But actually, this was preceded by months of work with many different framework vendors to, you know, framework maintainers to come up with an API that could back their various different reactivity concepts. And this is implemented in a polyfill that you can use.

What we did was wrap Angular's signals in this API, which is just a slightly different API surface, and open sourced it. And you can try it out. I would recommend trying out signals, the TC39 signals in a development branch, because these are still early. So, for example, you can just get it on NPM. And the benefit of this is that standard signals mean that we can share code across frameworks. That we can build common infrastructure that can be reused.

So, at the application level, if you're using this signals in a way that is implemented across frameworks, we could have a reactive data structure, which is independent of the framework. This just represents the data and the way that it's calculated from itself. So, if you have a UI with a counter that you can increment, but in this case, it's also displaying whether the counter is even or odd, in a way that's kind of cached. This is a toy example, but if those two computations were expensive, it might make sense to cache them. And then it could be used in different frameworks, like React or Vue.js, just by accessing that model.

The way that this works is because these getters, they call the dot get, and via auto tracking, it will notice that there's a dependency. So, the framework has to tie into this just a little bit in order to make sure that when evaluating these expressions, it will hook into the signal system to react when something changes. So, to make it easier to use signals, we've developed common infrastructure that could be reused in different places. The signal utils repository is one where, for example, you could have decorators to have a field of a class that reacts based on signals. And this is using the new TC39 stage 3 decorators. So, you can decorate private fields as well. Also, if you want to have an object that's reactive, like the view reactive function, this signal object function makes it so that you have a proxy around an object, so that all access is mediated by signals. So, then, when you include it in a template, it just will cause the same auto tracking. The signals don't have to be directly used in the expression, as long as somewhere deep in the call stack, it's accessing it. So, you can use signal utils on NPM. But although it's possible to adopt signals directly, in this potential future where we have standard signals, applications would not need to change.

And that's because the signal API is designed to be wrapped by different frameworks. It's not especially pretty to use by itself. But so far, it's our current best guess for what would work efficiently when other things are layered on top, like signal utils, but also like the way that other frameworks work.

The idea is that existing framework APIs would use signals under the hood. One integration that's taken place recently is Lit, being a web components based framework. And another integration was in Ember. So, this person, Life Art, integrated it, found bugs in the signal polyfill, significant ones. This bug was fixed. But overall, we have a lot to go. So, I would say this crab is cooked, tired. We're not done yet. We can continue going, but we need your help.

So, please join the effort. We have a public chat room that you could join and regular meetings every two weeks to discuss evolving signals. Trying out experimentally using this signals library and reporting back on your experience would be really helpful. So, there have been some early experimental integrations into frameworks, but we really need to try that out more to see how well it works. And in applications. You can also file issues or comment on GitHub threads or join ECMA in TC309. So, please come talk to me if you want to get involved. We can stay in touch on BlueSky. I'm at littledan.dev or by email. And in Bloomberg, we're hiring. So, please, you can come to the booth that we have on the side, get some swag there, and also look at our jobs website. So, thank you, everybody.

BEN HONG: I do want to say the first thing is, like, this is super exciting for me. Like, what I envision is, like, being able to write, like, framework agnostic business logic.

JASON LENGSTORF: Yeah.

BEN HONG: And then you can use it in a framework or share it across that. So, not a question, but that excites me. This idea of being able to share code without being, like, framework specific.

JASON LENGSTORF: I'm glad you like the idea. I think this is what standards can accomplish. More portability, less need to kind of make choices to lock yourself into one or other ecosystem. We can see this in other places, like, with ES modules having less and less configuration over time, less and less configuration for build tools, partly because of how we're evolving the module system to fill in feature gaps. That's what I hope to accomplish with Signals.

BEN HONG: Actually. And I think you might have mentioned about what stage is this in, and, like, what's next or what would it take to get it to that stage?

JASON LENGSTORF: I forgot to mention.

BEN HONG: Okay.

JASON LENGSTORF: Yeah. This proposal is at stage 1. It's a very early proposal. TC39 has not agreed that we want to go ahead with it. It's just on the table for discussion.

BEN HONG: Okay. And I guess on that point, a lot of people are, like, I guess wondering, like, should this be a thing? And, yeah, so the current question we have from Andrew is, why should it be a language standard? It looks very browser or UI specific and not applicable to the back end. So I guess, yeah, I'm imagining using it on a front end with a front-end framework. But if it's in the standard, that's something that's used by engines as well. So can you talk to, like, how would it be used there? Why does it make sense to be in the standard?

JASON LENGSTORF: So there's I think there's kind of two questions here. One question is, does it make sense to be in browsers? And another question is, does it make sense to be in the language? Does it make sense to be in browsers? I think it is it's very useful across different UI frameworks. So there are all kinds of features that are in browsers that aren't useful outside of browsers. For why it should be in the language itself, it wouldn't be the end of the world, in my opinion, if we decided this should be a browser standard rather than a JavaScript standard. But it is useful outside of the websites. For example, signals are part of modern build systems. The algorithms underlying signals in order to calculate the fewest number of rebuilds that have to happen.

Also, implementing a feature in the JavaScript engine often makes it possible to optimize further just based on how browsers are architected. That's not 100% necessary that what's in browsers corresponds to or sorry what's in the JavaScript engine corresponds to the JavaScript spec. But historically that's how it's been done. So I think it will be important to optimize this feature well in real implementations.

Interesting to see. Because I guess it doesn't make it the language, then maybe it's a browser standard. Even then, I could just stay a polyfill. I could imagine building something on top of this and just be like regardless if it gets supported, I might still use it.

Yeah. It could. I mean, the current NPM package is not stable enough for that to be a good idea. But there are real issues with, for example, NPM ending up duplicating packages. Auto tracking depends on this global variable, which is what is the current signal. You have to be able to append to that list when you find a dependency. So if the signal library gets duplicated, you've broken the compatibility. There actually are a couple of other global variables that frameworks tend to use, like the current kind of owner or component that are also really essential. So it's not, this might not be the end of the story. Or maybe we'll just get better as an ecosystem at managing and eliminating the duplications. Yeah, we'll see.

It would fix the particular global variable issue. I think it might be more optimizable in browsers by a constant factor. It might be a little bit faster. It's not going to be like asymptotically faster or anything.

Pool-based evaluation. Oh, pull-based evaluation. Right. So there's a piece of this interface that I didn't show called a watcher, which is a set of signals, which could be state or computed signals, which are being currently observed. And the idea of the API is that there's a synchronous callback that's made when the first member of that set becomes potentially dirty due to something that points to it having its state change.".

So there's a piece of this interface that I didn't show called a watcher, which is a set of signals, which could be state or computed signals, which are being currently observed. And the idea of the API is that there's a synchronous callback that's made when the first member of that set becomes potentially dirty due to something that points to it having its state change. So then when that occurs, you can later schedule reading those signals. One important thing is we do not permit you to synchronously read those signals during that callback, because it ends up causing that same glitch problem that I started out with.

So this next one, I think, is just kind of like a general question about how this might relate to libraries in React. Balaji asks if it is a surrogate or close to state managers like Imr for React. Imr is the immutable state library often used with React. The speaker acknowledges the importance of state management libraries and mentions that signals are similar to useState and useMemo. While you can use signals directly, centralizing state management is often desired, especially for routing. The speaker believes that signals and state management libraries should compose well, even though they may be implemented differently. They encourage further exploration and integration of different state management tools with signals, and invite people to join their Discord for discussion and feedback.

The next question is from Vladimir, who mentions WebSockets and MQTT, a scaled messaging queue. The speaker explains that signals only exist on one machine and don't cross a network, but you can put signals on both sides and connect them via WebSockets. They mention that Solid 2.0 is addressing the complexity around signals and async, and express interest in people experimenting more with this feature. However, they clarify that it won't be part of the built-in proposal.

Yeah, that's exactly the exercise that I'd like to do during this early stage of the evaluation with the proposal at stage one. So if anybody's looking for an open source project, just take whichever state management tool you like and see if it works to port it to signals. And you could join our Discord to chat with us and get ideas or feedback.

That's awesome. I'm probably going to do that, honestly. This next one's from Vladimir. I actually don't know what the question is. Maybe you can figure it out. So Vladimir says, WebSockets, MQTT, which is like a scaled messaging queue thing, signals.

So I have an idea of what it could be about. I mean, signals only exist on one machine. They don't cross a network. But you can put signals on both sides and hook them together via WebSockets. So this is potentially a promising thing. There's some complexity around signals and async. I mean, a lot of the work going into Solid 2.0 is about that. And it would be great if people experiment more with that. It's a very frequently requested feature. It's not going to be part of the built-in proposal.

Cool. Yeah, I guess I didn't think about that. But yeah, what if you could sync two browsers over signals and then you have this nice signal API, but behind the scenes, it's like communicating real-time over WebSockets or something?

Yeah, that's the idea. I mean, signals are an abstraction and you can hide different things behind them. So it could be eventually maybe a web standard, but it wouldn't be a TC39 standard, because we don't do any networking in the JavaScript language.

Right. Let's see. A couple more coming in. And go ahead and upvote questions if you see any so I know which ones you'd like to see. We'll choose the one at the top here. So considering the proposal recommends engines to leave a lot of stuff to framework authors to implement, why not coalesce around a userland package?

We could do that.

We'll see how it goes. I think, as I mentioned before, there's this global variable problem, and there's also the potential for further optimization. Also, I think the standards process itself helps things coalesce sometimes in an ecosystem. So, yeah, I don't know. We'll see if that's one possible outcome of this process.

Cool. And there's this question here. It's kind of just like, how does this all work? You mentioned you're on the TC39 committee. So they're asking, what does it take to join the TC39 committee?

Oh, okay. So TC39 is open for members. To become a member of ECMA, it's done at an organization level. And for universities or non-profits, like the OpenJS Foundation, you can join for free. We also invited experts to come for free. For companies, there are certain membership fees. In all cases, you have to sign a particular legal contract to make sure that you are licensing the things that you contribute before the standard, like a CLA, except stronger.

So if you're interested in joining the committee, please get in touch with me. Awesome. All right. That's all the time we have for questions here. But if you have more questions, if you head out to the glass room, you can ask more questions there. But yeah, thank you so much. Let's give it up again for Daniel. Thank you, Daniel. Appreciate it.