Standardizing Signals in TC39

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Modern web frameworks work with one-way data flow. What is displayed on the screen is a function of the application state, and updates to that state only update the particular part of the DOM to which it relates. Through their own paths, many other web frameworks have arrived at solutions which are analogous to each other, often called “Signals.” Now, a group of signal library authors and maintainers of front-end frameworks are working together in TC39 to standardize some of the core data structures and algorithms that will be required for JS implementations of Signals, and we could use your help pushing JavaScript forward.

This talk has been presented at JSNation US 2024, check out the latest edition of this JavaScript Conference.

FAQ

LittleDan, also known as Daniel, has been working with the TC39 JavaScript Standards Committee since 2016, focusing on projects like BigInt and Private fields using the hashtag.

Signals in modern JavaScript frameworks facilitate reactivity by allowing state to be managed separately from the DOM, enabling a one-way data flow and reducing the complexity of updating UI when state changes.

Signals help in maintaining the DOM in sync with data changes by separating data from the DOM, making it easier to manage state updates and ensuring that only necessary UI components are re-rendered.

Traditional state management often involves distributed state across the DOM or global variables, while signals centralize state with a one-way data flow, allowing for more efficient and organized reactivity.

The TC39 signals proposal is currently at stage 1, indicating it's an early proposal under discussion, with no final agreement on its adoption yet.

Signals use a dependency graph to track state changes, and only re-evaluate computations when necessary, avoiding issues like the glitch problem by using pull-based evaluation.

Developers can join the public chat room, participate in bi-weekly meetings, try out the experimental signals library, and provide feedback by filing issues or commenting on GitHub.

Bloomberg actively contributes to JavaScript standards through its use of web technologies in its applications, aiming to ensure stability and longevity in its systems by adopting common standards.

The signal utils repository provides tools to make signals easier to use, such as decorators for reactive fields and proxy objects for auto-tracking in JavaScript applications.

Standardized signals allow for shared code across different frameworks, enabling framework-agnostic business logic and reducing the need for framework-specific code.

Daniel Ehrenberg
Daniel Ehrenberg
29 min
18 Nov, 2024

Comments

Sign in or register to post your comment.
Video Summary and Transcription
I'll be talking about standardizing signals in TC39. Immediate mode wipes out the whole screen and writes a new one, while retained mode changes only what is necessary. Signals represent a cell of data that can change over time. The correct solution is to topologically sort dependencies and evaluate them in a coherent order. Standard signals allow for code sharing across frameworks and the creation of reusable infrastructure. The signal API is designed to be wrapped by different frameworks. Standards can achieve more portability and reduce the need to lock into specific ecosystems. The API includes a watcher, a set of signals being observed, with a synchronous callback made when the first member becomes potentially dirty. The speaker discusses how signals relate to state management libraries in React and mentions the potential for signals to become a web standard in the future.

1. Introduction to Signal Standardization

Short description:

I'll be talking about standardizing signals in TC39. I work on BigInt and Private using the hashtag. I moved from coastal Catalonia to New York City. The Bloomberg terminal is a big application suite.

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.

2. Understanding Signal-based Reactivity

Short description:

The view is a pure function of the model, which applies to the paradigm of React. Most frameworks have the signals concept. Immediate mode wipes out the whole screen and writes a new one, while retained mode changes only what is necessary. Signal-based reactivity combines immediate mode behavior with retained mode performance. Signals represent a cell of data that can change over time. There are common behavior patterns across frameworks, such as auto tracking.

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.

3. Auto Tracking and Signal Evaluation

Short description:

When you have a computed signal, it watches which signals are read and automatically tracks their dependencies. When a dependency changes, it becomes invalidated, ensuring the computed value is not cached. Signals are evaluated lazily, only reevaluating when read. This ensures from scratch consistency if pure functions are used in computeds.

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.

4. The Glitch Problem and Dependency Sorting

Short description:

When implementing signals, the naive way can lead to the glitch problem where intermediate states of computation are observed. The correct solution is to topologically sort dependencies and evaluate them in a coherent order. Frameworks have converged on similar approaches, solving the same problem and achieving the same result. Bloomberg's software development is based on standards, including HTML, CSS, JavaScript, OAuth, Cyclone DX, and S bombs for software supply chain security.

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.

5. Standard Signals and Reusable Infrastructure

Short description:

Making a company wide standard is good, but it's even better if you have a standard that's common for everybody. We're working on this at ECMA TC39. We wrapped Angular's signals in an API, open sourced it, and created a polyfill. Standard signals allow for code sharing across frameworks and the creation of reusable infrastructure. The signals can be used in different frameworks like React or Vue.js, and common infrastructure has been developed to make it easier to use signals.

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.

6. Signal API Integration and Call to Action

Short description:

The signal API is designed to be wrapped by different frameworks. Existing framework APIs would use signals under the hood. Integrations have taken place in Lit and Ember. We need your help to continue the effort of evolving signals. Join the chat room, try the signals library, and provide feedback. Get involved by filing issues, commenting on GitHub threads, or joining ECMA in TC309. Stay in touch on BlueSky or email for more information. Bloomberg is also hiring.

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.

7. Signals and Language Standardization

Short description:

Being able to write framework agnostic business logic and share it across frameworks excites me. Standards can achieve more portability and reduce the need to lock into specific ecosystems. Signals can be useful across different UI frameworks and are part of modern build systems.

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.

8. Optimization, Duplication, and Evaluation

Short description:

Implementing a feature in the JavaScript engine can optimize further based on browser architecture. It may be a browser standard or used as a polyfill. However, there are issues with duplications in the current NPM package. Putting it in the language or browser could fix the global variable issue and potentially make it more optimizable. In pull-based evaluation, a watcher set of signals is observed, and a callback is made when the first member becomes potentially dirty.

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.".

9. Watcher and Synchronous Callback

Short description:

The API includes a watcher, a set of signals being observed, with a synchronous callback made when the first member becomes potentially dirty. Synchronously reading those signals during the callback is not permitted to avoid the glitch problem.

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.

10. Signals and State Management Integration

Short description:

The speaker discusses how signals relate to state management libraries in React, acknowledging the importance of centralized state management. They encourage integration and experimentation with different state management tools and signals. The speaker also explains that signals don't cross a network but can be connected via WebSockets. They express interest in further exploration of this feature but clarify that it won't be part of the built-in proposal.

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.

11. State Management and WebSockets

Short description:

The speaker discusses the possibility of porting state management tools to signals and invites the audience to join their Discord for feedback and ideas. They explain that signals can be connected via WebSockets and discuss the complexity around signals and async. The speaker expresses interest in people experimenting more with this feature, although it won't be part of the built-in proposal. They also discuss the idea of syncing browsers over signals and the potential for signals to become a web standard in the future. The speaker mentions receiving more questions and encourages upvoting for preferred questions. They consider coalescing around a userland package in response to the 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.

12. Outcome and Joining TC39

Short description:

The speaker discusses the potential outcomes of the process, including addressing the global variable problem and further optimization. They mention the role of the standards process in helping things come together. The speaker also explains the requirements for joining the TC39 committee and invites interested individuals to get in touch with them. They conclude by thanking Daniel and mentioning the opportunity to ask more questions in the glass room.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Future Features of JS?!
JSNation 2022JSNation 2022
28 min
Future Features of JS?!
Top Content
Welcome to the future features of JavaScript, including proposals for array operations, throw expressions, records and TPUs, pipeline operators, and more. The talk covers the introduction of type assertions for imported files, non-mutating array operations, and the simplification of error handling. It also explores the concept of immutability with records and TPUs, and the use of the pipeline operator to simplify code. Other proposals include Map.implace, IteratorHelper, slice notation, type annotations, Array UNIQBY, number ranges, and the Function 1 proposal.
Temporal: The Curious Incident of the Wrong Nighttime
JSNation 2025JSNation 2025
25 min
Temporal: The Curious Incident of the Wrong Nighttime
Speaker's involvement in Temporal proposal and TC39 meetings for JavaScript standardization. Date conversion challenges faced in development. Addressing time zone discrepancies with Temporal to prevent bugs. Exploration of Temporal types and design philosophy. Usage of Java's time zone serialization in JavaScript Temporal. Challenges in implementing Temporal proposal and its transformative potential in ECMAScript.
ES?.next()
JSNation Live 2021JSNation Live 2021
31 min
ES?.next()
The Talk discusses various proposals for the next version of ECMAScript (ES Next) and the TC39 process. It covers features such as binding syntax, shorthand property assignments, pattern matching, async match, operator overloading, and more. These proposals aim to simplify code, make it more readable, and introduce new functionalities. The Talk also addresses questions about the committee's decision-making process and the experience of being part of the TC39 committee.
Temporal: Modern Dates and Times in JavaScript
JSNation US 2024JSNation US 2024
22 min
Temporal: Modern Dates and Times in JavaScript
I'll speak today about the Temporal proposal, which adds modern date and time handling to JavaScript. Temporal is an API that'll be available in browsers soon and will add a built-in library for dates and times, avoiding the need for external libraries like Moment. It offers strong typing with different types for different data, such as calendar dates with or without time. Temporal objects are immutable and designed to work with JavaScript's internationalization facilities. It addresses deficiencies in the global Date object and introduces types like instant and plain types for accurate representation of time and dates across time zones. With the old Date, representing a date without a time can be problematic, especially in time zones where midnight is skipped due to daylight saving time. Temporal introduces types like PlainDate, PlainTime, PlainYearMonth, PlainMonthDay, and ZonedDateTime to accurately represent different scenarios. Additionally, there is a type called Duration for arithmetic operations and unit conversion. Now that I've introduced you to the cast of characters in Temporal, it's time to show how to accomplish a programming task. We'll start with an easy task: getting the current time as a timestamp in milliseconds using the instant type. To convert between Temporal types, you can either drop or add information. The toZonedDateTime method is used for conversion and requires adding a time zone and a time. Although Temporal objects are immutable, you can create new objects with replaced components using the with method. Migrating from the old Date object to Temporal offers a more reliable solution and avoids potential bugs. Check out the documentation for more details and enjoy using Temporal in your codebase!
ESNext: Proposals To Look Forward To
JSNation Live 2020JSNation Live 2020
9 min
ESNext: Proposals To Look Forward To
ES Next proposal stages include straw person, proposal, draft, candidate, and finished. Optional chaining and null coalescing operators are solutions for handling undefined and null values. Logical assignment and null coalescing operators are seeking advancement to stage four. Decimal type is introduced to address floating point math issues. Cancellation API and abort control are solutions for canceling promise execution. Pattern matching allows matching the shape of a vector and performing actions based on it.