Brian Kardell: All right. Hi, I am Brian Kardell. I'm a developer advocate at Igalia.
Eric Meyer: And I'm Eric Meyer, also a developer advocate at Igalia. And in this episode, we're going to do a recap, sort of a look back on a recent TC39 meeting. And for that we have a couple of special guests. NIc, could you introduce yourself please?
Nicolò Ribaudo: Yeah, hi, I'm Nicolò. I work at Igalia in the compilers team. Mostly do JavaScript standard stuff and I've been doing that for many years now
Eric Meyer: And Ujjwal has also joined us. Ujjwal, please introduce yourself.
Ujjwal Sharma: Hi, I am a colleague of Nic's working on JavaScript standards on ECMA TC39, ECMA-402, all of these various standards that sort of define the language that we all have a strong opinion on.
Eric Meyer: Are they strong opinions weakly held or strong opinions strongly held?
Ujjwal Sharma: Absolutely. I don't think any strong opinion should be very strongly held.
Eric Meyer: Okay.
Brian Kardell: Are they typed or untyped?
Ujjwal Sharma: They're definitely typed.
Brian Kardell: You know I was wondering if just to start us off, I remember way back when we were like, oh, are we going to get an ECMA-2? And then eventually that became years, So we get ECMA 2016, 2017, 2018. I haven't personally heard a lot of the same referring to that in that way. I'm just curious, do you find that that's still a thing, and if so, why is it a thing? When do you sort of determine what's going to be in and what's going to be out? Or are you kind of mostly living standard at this point?
Nicolò Ribaudo: It's true, it's not relevant anymore because we basically have a rolling rule. Features get added to the language, browsers ship them, and then every year we just take a snapshot of whatever state we have and put a year on it. And we need to do that because as part of building a standard, it's not just writing down the document on the web page but we'll need to have some process. We need to have a little PDF that says this is ECMAScript 2026, for example. So we need to do that, but it doesn't really affect just developers, and actually transpilers also move to not care about that anymore. Some like TypeScript still have you say, oh, I want to target ECMAScript 2019, but then other transpilers, somebody might argue they're doing this better, they just let you define what browsers you want to target so you don't have to care about year at all.
Brian Kardell: Cool. So I actually have never been to a TC39 meeting. I've looked at minutes, I've looked at presentations, I've heard sort of inside baseball about personalities, I guess and interesting things about politics and things like that. But I'm kind of curious how does one work even? I know how CSS working group meetings work and they're pretty much the same as how MathML working group works, which is pretty much the same as what working group meetings work. Yeah. So how does one of these operate?
Nicolò Ribaudo: Ujjwal is a chair of TC39. He's one of the people responsible for running those meetings. So he might have a completely different view from everybody else actually attending those meetings. From what I see during those meetings, we just all get around, well, a virtual table, and multiple, there are maybe 30 to 40 delegates participating in these meetings and everybody has their own goals. But the good thing is that we can only progress if our goals somehow align, which means that we basically have long structured discussions where some delegate gives a presentation about how they want language to evolve, some features they want to add, and then everybody else replies to the presentation with their opinion and saying, 'yes, this is a good idea'. 'No, this is terrible', or 'you should tweak your thing in this and this way'. And it's very much a collaborative process. Over time, we actually got better at talking, collaborating with each other. It used to be that you had to be the one shouting the loudest in the room for your opinion to be accepted. Now we have tools that make sure we all have a civil discussion. We have when first ordering whose turn needs to speak now and everybody speaks on it's their turn and we make sure that everybody can always reply and there is not nothing like having the last word on some topic. The discussions don't last forever, they're all timeboxed to make sure there is space for every single presentation that needs to happen to actually happen during the meeting. And sometimes we just do not agree on something within the timebox. And then maybe we have to come back to future meeting, which is fine, the language doesn't need to evolve super-fast. Yeah, it's like a bunch of friends sitting around the table, right?
Ujjwal Sharma: Well you'd expect so. Well, I have to say, I mean there's really many levels to it, however. The work that we end up doing is a large spectrum, and on one side of the spectrum you have the deeply technical work. So this is the kind of work that when we're talking about TC39 meetings, these sort of every two months, six times a year, therefore three of them in person, these meetings are, while intense are not the vast majority of the work that the committee does. One side of the spectrum is deeply technical work that goes on, figuring out certain details, working on the specifications themselves, the editorial work to improve the lives of everyone writing and reading these specs that is done in the opposite direction. It's quite decentralized, it's done by individuals either editors or champions of certain proposals and it goes on in the shadows so to say. And then there's the non-technical quote-unquote 'Work' where you have to basically solve these difficult problem of collaboration because we have to all align a single, somewhat cohesive vision of what the language seems to sort of evolve into words. And we don't have any clear idea, JavaScript is like it's well understood that it's overly ambitious language that has sort of prepped into everywhere. So the concerns are numerous and the stakeholders are all convinced that they're all on the right page. So it's a very difficult problem to solve to create these meetings in a way that it's completely collaborative, that it's very respectful of all the individuals times. Some of the proposals we've worked on have taken tens of years and still haven't reached the point where they should have. So it's definitely a difficult problem. I feel like it works best when we're sort of on the same page regarding something like usually smaller features or quality of life improvements that nobody has strong opinions on basically.
Brian Kardell: So let's talk about specifically what happened in this meeting. This was the 109th meeting of TC39. It's funny for something's been around as long as JavaScript, it doesn't really sound like that much. That's always interesting to me when I pull that up. I would think there would be several hundred meetings by now, but I guess not.
Nicolò Ribaudo: Yeah, fun fact, that's also meaningless number. We don't exactly know how many meetings we had. It's like roughly 109, it's probably a little bit more, but at the beginning we're just not very good at keeping track of all the meetings.
Eric Meyer: And how frequent are the meetings again?
Ujjwal Sharma: Six times a year.
Eric Meyer: Okay. So every two months.
Brian Kardell: I think a good way to do this would be to sort of give a quick recap of the sort of social media size, these things presented or advanced or didn't advance and then we'll dig into some specific ones maybe?
Nicolò Ribaudo: Yeah, sure. So I'm going to split this by day just because you have to remember what's happened each day. And we start the meeting with the more, well this always happened in the beginning of the meetings where we don't actually work on proposals but more like language bugs or problems we found. And we spent maybe the first morning talking about those. And at this meeting we've discussed about some problem with the way `Function.prototype.toString` stringifies getters and setters where apparently some browser tried to adhere to the spec and it ended up breaking some websites of some consulates somewhere in the world. And so they had to come to the committee to figure out what to do next because that was clearly not web compatible. And we found a couple of the spec bugs. We talked about one with the order in which some promises related to modules are evaluated, are settled, where the spec says one thing, but all of the three browsers have three different behaviors. And so again, we discussed how do we align with this? We would like everybody to behave the same so that programs all work one way. And then also we discussed about a bug with typed arrays. Now that we have resizable array buffers that can shrink and grow and there was a bug in one of the typed array methods, it was `copyWithin`, it was not properly keeping track of when often the underlying buffer was shrinking. And this can be dangerous because like typed arrays are very security sensitive because you have access to raw memory data, so you need to make sure that things are working properly. And then we had one last bug, but in the ECMA-402 specs about the Intl things where that was actually presented by Ujjwal, where there was some function, it was missing the function `.name` property. And then continuing on the list of things that are not actually proposals. We also talked about some potential changes to language to make it easier for browsers to optimize some common actions. So it's about freezing the array iterator prototype so that when you do array destructuring or array spread, so we actually read the array destructuring syntax, its syntax sounds very, very simple, but there is a lot going on there. There is this whole iterator protocol that the browser has to call, can trigger user code and there are a bunch of side effects. And so we're discussing about how to make it easier for browsers to optimize, at least for built-in arrays. And similarly, actually it was maybe the day after we talked about how to make thenables easier to use in the browser. Thenables are things that behave like promises but are implemented in userspace. They're basically objects with a `.then` method and that can cause, it can both make it difficult to optimize things, it can also cause security issues in browsers, because every object that has a den method could behave unexpectedly and maybe your object itself doesn't have this den method, but it's installed somewhere in a prototype. If you do `Object.prototype.then = function () { … }`, you're going to cause a lot of problems for a lot of browser internals that do not expect to call user code, but then actually they end up calling your function up there. And I believe for both of these discussions, we didn't reach any conclusion yet, it was just like, well there's this problem, it'll take a while before we figure out what to do. And then after these things we go to the actual proposals. We had one stage 4 advancement in this meeting, the `Math.sumPrecise` thing that does the sum of bunch of numbers trying to avoid floating point errors. And I think we also actually got a second stage 4 for the `toHex` and `toBase64` methods and also `fromHex` and `fromBase64`, so you can easily convert bytes to the Base64 string. We had a bunch of stage 3 proposal updates, like Temporal had again some fair amount of changes brought by implementation feedback and we had the map upsert proposal that advanced the stage 3 and the `Iterator.concat` proposal that tried to advance to stage three. And then again, we had some updates about this in context and then there was day two.
Ujjwal Sharma: Day two we had how to make thenables safer. That was briefly mentioned. Basically how to improve these objects that have the then method. Also, `Error.captureStackTrace`for stage two
Nicolò Ribaudo: Because all browsers ship something and then they're all different behaviors and so most are less trying to align them.
Ujjwal Sharma: The next one was to disallow adding new private fields to non-extensible objects. That seems like an oversight. And then after that there was immutable array buffer for stage three. So basically, adding these immutable array buffers that can be more reliable for cross-agent communication using array buffers. Then we had iterative chunking for stage 2.7, so basically splitting up iterators into windows or slides. These are both words that they use, but yeah, basically chunks of given size or up to a given size, that was part of the discussions. Then there was keeping trailing zeros in Intl methods. So Intl.NumberFormat and through rules, both of them that deal with numbers in the opposite ways to keep the trailing zeros that are provided as the input. And we have this related to some of our ongoing work and followed up by amount. So this was the measure proposal that was renamed to amount, which pretty similar concept, but the idea is to represent these hybrid values, these compound values. And this was presented for stage two.
Brian Kardell: Wow. That's only day two. How many days does the-
Ujjwal Sharma: It's four days.
Brian Kardell: Four days, wow.
Nicolò Ribaudo: We're two thirds through the content at least. Well three-fourths through the content.
Eric Meyer: Okay.
Brian Kardell: Okay. So NIc.
Nicolò Ribaudo: Yeah, and just to clarify, when a proposal is added to the agenda for trying to reach a given stage, it doesn't mean that it'll get to it. For example, this amount proposal was first for stage two, but as a committee we did not reach consensus on actually advancing it stayed at stage one. But then moving on, we had another full day of discussions like during day three. We talk about the Intel Error Mount Code proposal that actually maybe Ujjwal was working on, that improves how Intel and Temporal work together with different error and mount codes, well as Intel says. And then we had a proposal about module import hooks and global constructor module import hooks would be a way to customize how module loading works with a shared API across all JavaScript environments like today, like in Node you have loaders or browsers you have service workers and `Global` was like well a constructor to build a new global. And this proposal was presented for stage one and got stage one, which means we're going to talk about it more. And also we had the 'import buffer' proposal, that's now been renamed to 'import bytes', that lets you import some raw memory. That was on the agenda for stage one, but due to some last minute luck it actually got stage two already. And then in the afternoon we just continued talking about some of the previous things we talked about, because as I said, all discussions are timeboxed, so maybe something in the field is timeboxed. And then we had this free time, we just continued discussions. And then finally, on day four we had four proposals all from the same champion working Node.js That were all about adding more methods to introspect objects. We have object keys for example to get the keys, the string keys. And the question was, well, how do we get the symbol keys? Or how do we count the properties of an object? Or how do we get the properties of an object that are not valid array keys or how do we check if an array has holes, and a bunch of these proposals that Node.js would like to use for their internals, which are written in JavaScript and they were all for stage one or two. Some of them reached stage one, some didn't, but don't remember which ones did.
Eric Meyer: So that's basically the list of things that got discussed?
Nicolò Ribaudo: Yes, which took four days for all this content.
Eric Meyer: Right. It seems like there's a fair number of things that are just about arrays, like making a arrays better or immutable or being able to put arrays in other things. Is that a fair characterization or am I just sort of seeing the word array and imposing a pattern that's not really there?
Nicolò Ribaudo: And maybe it's not arrays, but things related to arrays also. You mentioned you heard a lot of word arrays because we also talked a lot about typed arrays. There are a bunch of proposals about iterators like the iterator chunking, the iterator sequencing proposal that they not really like arrays, but they're used in many places where arrays would also be used and well, everybody uses arrays, it make sense. We just want to make them better.
Brian Kardell: I don't know if you have any favorites or ones that are particularly interesting to you. I am keen on a few of these, but I don't know, Eric, do you have any that you particularly would like to talk more about or?
Eric Meyer: I mean, I always want to hear about Temporal, but yeah-
Brian Kardell: What is the story with Temporal?
Eric Meyer: My understanding is that not much changed with Temporal the spec itself, it's more that it advanced or am I wrong about that?
Brian Kardell: It's about time for Temporal.
Eric Meyer: Hey.
Ujjwal Sharma: Yeah, temporal by far the most popular TC39 proposal out there from what we have seen from different surveys and so on, but also obviously the most popular one that we've worked on. It's going well, actually fingers crossed, touch wood, whatever sort of superstitious thing. But yeah, basically like Temporal is in one of the final stages of engine implementation in V8 basically they've been doing a lot of hard work putting Rust into their bill chains to basically do it via Temporal RS, which is a fantastic rate that does implement Temporal. And because of that they raised a number of comments basically around the tiny details that don't directly affect the average developer, I would say. Things like the order of reading properties and such, and that was addressed, but the more I see these topics, the more I can't help but feel that Temporal is, it's a matter of time and I know that we keep saying that, but-
Eric Meyer: It's a matter of time.
Ujjwal Sharma: Yeah, it's almost here, no pun intended. But basically yeah with the error mount code proposal as well, adding some of the details that we're missing. I think we're very close to closing the picture route on Temporal or at least finishing what things look like from our end. But Nicolo actually presented that topic.
Brian Kardell: I think it's really interesting. We've seen some things where Skia as the 2D library is just one, there's just basically one implementation that they all use. And I mean, I don't think that it's totally not the case with other things. I think when it comes to parser generators and things like that, they're just common ones that everybody shares. What does that mean for how you think about interoperable implementations? Because there you have some requirement for a stage advancement?
Nicolò Ribaudo: In the context of TC39, we never really had this thing where implementations were sharing an underlying library for core language features. It happens for regular expressions where both Chrome and Firefox I believe use the irregexp library, or whatever it's called. But we always just count the number of browsers when it comes to our requirements. If this sharing code becomes more common in future, we probably will have to adjust our process that if two browsers just share the same Temporal implementation maybe should count as one, but there is still value in multiple browsers shipping the same library because they have different user bases so they can find different web compatibility problems.
Ujjwal Sharma: Yeah, I think one notable exception to this, however it's not part of the core sort of ECMAScript language, is the Intel side of the language, all the browsers have some flavor of ICU powering it, mostly ICU for C, in these cases ICU4X. And I think we're starting to see a pattern here. Earlier, I think two years at this point ago, Firefox was slightly, by Firefox, I mean SpiderMonkey was slightly slower than the rest in terms of shipping out this new feature at the time, which was segmenter. The reason for that was that they spent a lot more time than the others setting up ICU4X in their build tool chain and everything. And the benefit of that is that we can see some things like Nicolo said, like Firefox is the only browser that ships Temporal and flagged at this moment. So I think we can see that some of the efforts that they had made back then paid off, and I can see a similar thing with Temporal RS, it might be very specific, but it's sort of essentially forced V8's the hand at answering some of these difficult questions regarding basically shared code and embedding these libraries to implement certain features. So I think we're going to see basically good examples of this hopefully moving forwards and just more shared work, especially through ICU4X because we can already see that multiple stakeholders are quite interested in the proposition of ICU4X as a more dynamic way to do internationalization than the existing solutions.
Nicolò Ribaudo: I don't think we defined what ICU4X is, but it's the Rust library that contains all the information used for the Intel APIs, all the locale information and how to use this information together and to generate the right localized strings.
Brian Kardell: Some of the ones that I am personally really interested in, chunking I think is really interesting. If you have an array and you want sort of, maybe it's got 10,000 items but you want to handle them 10 at a time or something, these are things that in my engineering career, chunking is something I had to do so many times and having a nice iterator method like this seems to me really nice. I'm curious, can you, I don't know what are the thoughts around it? Yeah, what do you think?
Nicolò Ribaudo: The proposal actually includes multiple methods because when you want to get the chunks out of a list, well you go look at the details and there will be multiple ways in which you want to get chunks. Maybe you have, as you were saying, an array of 10,000 elements and you want to process 10 at a time, so you want to get first the first 10 and then the second 10s, from the 11th to the 20th and then from the 21st to the 30th. And so the proposal will obviously do that, it adds chunks method, that does exactly that. We can define the size that we want. But then you might also want to have a sliding, kind of a sliding window over all the values. Let's say you want to work on all the pairs of your list to check if your list is sorted or to complete some sort of rolling average. Then you want to do separate chunks, but you want to just have from the first to the 10th and then from the second to the 11th and so on. And so this proposal also had a `.windows()` method for this. And then during the last meeting, during this meeting, there was actually some sort of controversy about what `.windows()` does because the question was what happens when your list of values is shorter than the window size that you ask for? Let's say you have a list with 10 elements and you want windows of 20, then there were two options there. One was to just give you no windows because well, there is no way to give you a windows of 20 if you only have 10 elements. For example, if your use case is to get all the averages of every pair and you have a list with just one element, you just cannot do it. And then the other approach would be to say, well, in that specific case we actually do not respect your size and give you a smaller window. And we had lots of discussions about this. We ended up, the proposal was presented again with a third method to do this, two separate fallback behaviors for the case in which you don't have enough elements. They were called `sliding()` and `windows()`. We had some discussion about developing bad names because it actually tell you what difference is. And I think what we settled on was that we're actually going to have a single method called `.windows()` that takes other than the window size, it takes an options back or maybe a string parameter like an enum or something that tells you what to do in case you don't have enough elements. And the proposal was going for stage 2.7 I think, but did not reach it because we first need to have the spec text for this updated approach that we want to go with.
Eric Meyer: You said that it advanced to a stage 2.7?
Nicolò Ribaudo: It actually didn't because of this last minute changes, but maybe Ujjwal you want to explain what the stage 2.7 is?
Eric Meyer: Yeah, why is there a stage 2.7? Are there like 10 stages-
Brian Kardell: Yes.
Eric Meyer: ... throughout the whole process or?
Ujjwal Sharma: This is not unusual or whimsical at all, I promise. But no, basically this is a relatively new change to our stage process. To go over it real quick, we have stages zero till four, where zero implies something is pretty nascent, pretty new, it's not been presented to anyone seriously, but something that sort of resembles an idea, nothing more than that or a problem statement to be more precise, because we try to address problems more than bake up solutions out of thin air. And stage four being this is universally accepted part of the language, if you don't support this, then you're not consistent with the language spec. All of these different stages have different implications regarding what kind of work we do, how ready the proposal is. And the issue that we had was that stage two is when you do the big-brain philosophizing and designing of the proposal. And large changes happen at that stage and you write the spec out basically. And stage three is when the engines are supposed to be implementing your proposal. So you stop designing things and you start actually putting things to code. The problem is that there's this awkward interstitial stage between these two where you're writing tests, right? Because you can't write tests before things are sort of settled down, but you can also not do any implementations while there's no reliable tests or well sort of accepted tests that you can verify your implementation using. So that's what stage 2.7 aims to do. I believe it's 2.7 because of E, but in general, we just had the most chaotic open brainstorming session and people came up with all sorts of proposals, 2.9, 2.5, everything was discussed and in the end we picked 2.7. So yeah, it's adding a bit of whimsy to our workflow, but the core idea is quite practical, is to give people this tiny bit of time to settle down the big semantic and syntactic details of the proposal while not pushing people to do the implementation and giving you sort of a no pressure environment to write the test and then go for stage three.
Eric Meyer: Okay. I have another question.
Ujjwal Sharma: Go for it.
Eric Meyer: What's an upsert? Because I look at it-
Brian Kardell: Oh, that's one of the ones I'm most excited about-
Eric Meyer: I look at it-
Brian Kardell: ... so I'm glad you asked.
Eric Meyer: ... and it looks like they set up for a joke. It's like, 'What's upsert? I don't know what's up with you, sir?' Wait, what? So what's upsert?
Ujjwal Sharma: I would've lied if we kept it at upsert. The joke that you just made was hilarious. But yeah, I think a lot of people had this issue where they were like, it's not quite clear what upsert means. And so if you see the actual function is called get or insert, and yeah, basically that's the idea. Some languages I think call it upsert as is, I don't think it's a bad name at all, but it's not very descriptive and the idea is a very common operation. I think when I write JavaScript, I do this as many times as I have maps, basically. Anytime you have a map, you have to do this kind of dance where it's like, oh, does this property exist? If not, insert it or replace it with a default value or replace it with the result of the calling this function. And basically that's what this proposal provides us. Either get or insert or get on insert computed where you instead of passing it a value, pass in a callback and the result of that callback is actually what's inserted at that key.
Nicolò Ribaudo: And this naming here was again a controversy point in the committee because there are two camps, two different types of delegates. One that thinks that the name should keep reflecting what the proposal actually does, the functions, the proposal. So this proposal should have been renamed according to that ideology to maybe 'proposal-map-get-or-insert'. But then there is another type of thinking that is no, people already know this proposal as the upsert proposal and by renaming it's just everybody's going to get confused, because well, where did the old proposal go, it just disappeared when it was stage two? So the proposal actually 'upsert' is a different operation. It's like update or insert and not get or insert, but we just kept the name because we thought the proposal was maybe five years old, at least, at that point. And we thought it was just too late to rename it without causing extra confusion. And to be clear, the name only matters for people that follow the process. Because once the proposal goes to stage four nobody talks about the proposal anymore, they just talk about the API.
Eric Meyer: So the general idea is I'm sending a thing, if it already is there, then I update it, then it gets updated. But if it doesn't exist then it gets added or inserted.
Nicolò Ribaudo: I mean that's what `.upsert()` would do. But what we do here is that you basically are getting with a fallback, but the fallback gets inserted in the map.
Eric Meyer: Oh, okay.
Nicolò Ribaudo: Think if you have a cache, your map is a cache, you might want to either get the value from the cache or if it's not there, put the new value in there and still use it.
Eric Meyer: Right. So why does this look like you, Brian?
Brian Kardell: Ah, because this is a thing that you need to do constantly for caches and things. It's really common patterns where you need to do this and it would be nice to just have one very recognizable, very concise way to it. So yeah, I think upsert, I'm down for it.
Eric Meyer: You're down with the upsert?
Brian Kardell: I'm down with the upsert. I would say the one that maybe excites me the most is early, but also way overdue in a way. So let me explain. So there's a proposal that's currently called Amount. It kind of came from something which I think you could argue kind of came from something else and so on. We're working on this and I think also Mozilla before I continue, is that correct or? Yeah. Okay. So part of the reason that this excites me is that there is also a proposal, is very early, it's just an explainer by, as authored by Tantek, our friend from Mozilla. And it covers some history, which I helped write some and fill some in. But microformats did a bunch of stuff in the mid-two thousands. There was then another thing in 2010 to try and put measures into markup somehow. Then also, a couple of years later there was a thing proposed in Discord. We had a Discord where we were trying to do early incubation called Specifiction that was similar to that. 2019 this thing that Eric and I and Stephanie from Igalia were all involved in this Web We Want. And part of when that started, it would go to events and there would be a kind of a judge's panel and they would get submissions from the audience. They would come up and pick a few and present them, and then we would recognize certain ones of them as a judge's pick. So I don't know, sort of like that shark tank, basically something like that but for standards. It was a nice way to sort of listen to the community and include more people and stuff like that. But what comes of it, and then again in Open UI somebody proposed an M or a measure element. So anyway, there is this long, long, long, long history of people wanting to do these things where you say this number represents 12 pounds or 12 kilograms or $12 or whatever.
Eric Meyer: 12 teaspoons if you're-
Brian Kardell: Right, exactly. And for it to be possible to do useful things with that, that is difficult for you to do without, for example, localization. So maybe part of the reason that it really excites me is that when we wrote this Extensible Web Manifesto, we had this idea of a platform that was explainable that you would have this, oh, we want this element, but then we also want this lower level thing where the same guts are exposed to JavaScript. And I like that they're trying to coordinate and do it together. I don't know if it'll work, it might not work, but I'm glad that Tantek was getting involved with the TC39 thing to see if we can work that out.
Nicolò Ribaudo: So just to tell everybody what this 'amount' proposal is, it's basically an object that holds a bunch of properties like a number and then a number of significant digits. So the precision of the number, so you can say, oh, this thing is one meter long or this thing is 1.00 meters long, so that's actually more precise and then well, obviously the unit. And the idea is that well, in JavaScript you can already just have three variables that hold these three pieces of information and pass them around wherever you need them. But it's just very annoying to have to do it manually. Because you just need to pass all of these things over the place, and then if you create some custom object, you need to make sure that the different libraries that need to work with these amounts need to understand the shape of your custom object. And for example, you'll need to translate this custom object back into what the Intel API needs if you want to show this values to the user. And so by just defining this options built in, well everybody would just understand it and you can have this single thing that represents 1.00 meters and you could pass that to Intl.NumberFormat for example, and it'll localize properly 1.00 meters in the language of your users and giving all this very nice single way of doing one thing. And the amount proposal was actually not born really in collaboration with the people working on that `` HTML element, it just happens to map very well,
Brian Kardell: No, they're parallel evolutions. Yeah, definitely parallel evolutions. But the need has been expressed in both ends of that and over and over.
Nicolò Ribaudo: And I'm hoping that's one they will get the more declarative and semantic way of doing so. It's a good HTML element because well, it actually has more semantic meaning than just having the string 1.0 meter embedded in there. I don't know, maybe.
Brian Kardell: I think part of the thing that would be really helpful about that is that, today I can pull up a page in Spanish and my browser can say, 'Hey, this appears to be in Spanish, do you want us to translate it for you?' And you can hook up even which translation services you prefer. If I could identify that this is an element, and maybe when I hover it or I select it, it could give me the ability to make it make sense to me. Because I live in America and for some reason we don't use the units of measurement that everybody in the rest of the world does. And so when I see this journey is 32 kilometers, I really have no idea on a lot of these things and it's probably saying a lot about me, but I think that it's the same when you're reading something written by an American. Fahrenheit to Celsius is really common. I just want to do that all the time. So today, now if a lot of browsers, if we select a word, there's a like 'Hey translated or look it up in a dictionary.' Because those are really common actions that people take on a word. Or we run some regular expressions over it and it looks like a phone number. We can say, 'Hey, you're on a phone, did you want to dial that phone number?' Or it's marked up like an address. Then your phone can say, 'Hey, did you mean to ask for directions to this? Do you want to see it on a map?' So I think really that's the advantage that I see a lot to the semantic adding of these things, is that for a user, like an end user, I can imagine this would be really, really useful if people start marking up those because browsers then can add lots of affordances that help us understand one another better.
Ujjwal Sharma: Yeah, I think that I would describe it as sort of a evolution also in terms of just the fundamental mental model that we work with with internationalization. I think over the years we have gradually worked our way through some of the bad practices. We've done a good job, but when it comes to things like number formats, number formats allows you to hypothetically, well to actually plug in any unit and format things with a unit. Now you have a constructor for the number format, you can give it a bunch of options like okay, I want to format this number like a currency and this currency should be euros. But the end result is that you have the flow of data is not ideal here. The reason for this is that if I say something like 1.45 euros or something for a product, let's say, removing euros and removing the fact that it's a currency from that number actually makes that number completely meaningless. So it's important context that should be part of the number rather than the formatter itself. And the formatter should consume the number and the unit in the relevant context by itself and then it would be able to do some smarter things like converting it to a different unit that is more relevant for a locale, it can convert it to a different unit that might be relevant for the amount that it is for a certain distance. Inches might be more relevant than feet or miles. So all of these things I think is part of the overall movement in the Intel space where people are realizing like, oh, okay, we can actually address this problem a lot better by changing what we call a unit of information, basically.
Nicolò Ribaudo: There is also related proposal in TC39, it's called 'smart units', that our colleague Ben Allen was working on where basically you'll be able to say, 'Look, I have this quantity, it's like 1.78 meters and it represents the height of a person and my user's locale is set to`en-US`. Please convert it to the right amount in the right unit to represent the height of a person in this user's locale so that then my website can just directly show the right thing that the user would understand.'
Brian Kardell: One thing that gets a little bit tricky with any of them is that some of these are, I think it's Temporal in that we, from our point of view in time you're just inclined to be like, well, there's 12 months in a year, this many days in each month and there's this many hours in each day. And it's like, well, it's a little bit more complicated than that. It's not actually really simple. There's a lot of things that changed and changed over time and if you're trying to calculate backwards in time, you have to account for all these weird anomalies. And one thing that seems really common and would be really useful is to do with money and money feels like it would be hard to convert like that, you know what I mean? Because it's not fixed in time, it's variable, you would want to do it sort of at the time of consumption or something like that. But it also feels like it would be really hard to build some of those conversions like monetary ones into any system. Has there been any on your smart units, does it account for money? Because the amount thing, definitely money is one of the things in there, right?
Nicolò Ribaudo: I'm frightened money is explicit out of scope because as you said, there isn't well, not only browsers cannot hard code a conversion rate for example, between euros and dollars, because that changes all the time. But even at any point in time if your thing costs $10 and you're selling it to some European user, how much the European user pays actually depends on their own bank for example. So there is no way you can actually predict that and show it properly. So we just consider it to be a too difficult problem and people will have to solve this problem, probably not in the browser, but very close to where their payment system is implemented.
Ujjwal Sharma: I think converting between currencies is impossible, but sort of keeping all that information together allows you to actually, at least have the context that like, okay, I think it's a different currency than the one that I was expecting and therefore I need to keep the conversion angle in mind and not assume that it's going to stay unchanged.
Brian Kardell: Eric, do you have anything else?
Eric Meyer: I don't know, NIc and Ujjwal, have you put forth the things that you were sort of most excited about?
Ujjwal Sharma: Well, we discussed Temporal. I guess, I'm still quite excited about Temporal. I am cynically excited about Intel Error Mount Code in the sense that it's a lot of work and it's a difficult proposal to get through. So I guess, that's the selfish part. But the best part is actually that it's doing something quite impactful. I think this is going to be one of the first few times that we actually have a very featureful version of different calendars, non-Gregorian calendars available to this large set of software users. So I think it's going to be quite interesting to see where things go from there. What people are going to do once they get a hold of let's say Hebrew calendar and they can do calculations in the Hebrew calendar, they can add a month to a date in the Hebrew calendar and know like, okay, it's a leaf month so things are going to behave in a different way. I'm quite excited to see where things go from there because one thing that's easy to sort of forget is that since the days of dates and times basically on computers, we've always only really used one calendar. Practically speaking, we've used one calendar for everything and then we've gradually sprinkled others as end user formats. You can keep a date sort of in the ISO format, but then display it to a user with the corresponding in the Hijri calendar let's say. And now the ability for people to actually work with these calendars to express their state in the terms of these dates, I think it could be quite interesting.
Nicolò Ribaudo: We're talking about favorites, actually, one of my favorite proposals we presented during this TC39 meeting that we didn't really cover today was the AsyncContext one. It's like another proposal that, well, another colleague of us, Andreu, is working on, and it basically lets you preserve some state through the logical async flows in your code so that if you have some state at some point and then you `await` and then you have a `setTimeout` and then need to read that state and you have some other code doing the same thing in parallel with some different initial state, each of them can very easily keep track of what their async context was. And this is very useful for example, for frameworks where whenever we write components in React or Svelte, or any of those, there's some implicit state being tracked about what the current component is. In React, for example, you have hooks that need to be properly connected to the component. And all of them have different ways of doing this that relies on global state, and all of the ways that they do it just breaks when you use async code, which is why most of these frameworks do not let you use `await`in components or if they do is under very strict restrictions. And AsyncContext just makes it possible for this tool to work without the user of the framework having to worry about it. And also, it's very useful for things like performance tracing where maybe you have a large app, it doesn't matter on my small personal website, but if I'm developing, I don't know, Google Maps where there's a ton of JavaScript interacting and running all the time, and maybe something is slow and I need to figure out why it's slow, and I need to get metrics from how people interact with the page to figure out, okay, you press this button and it took more than half a second to respond because it goes through all of this pipeline of code that likely includes some async steps like a network request. And with AsyncContext, I can use tracing libraries that actually build this tree of how code causes other code to run and then takes some time and then at the end there is something shown to the user. And right now it's very difficult to do this performance instrumentation on the web because you can only do it for synchronous code because you lose the context across async points, which are just very common on the web platform. And so yeah, hopefully AsyncContext will happen and will help solving all of this. It's at stage two right now, the TC39 part is mostly done, but it had to slow down because there is a lot of work we need to figure out exactly how it interacts with all of the asynchronous web APIs.
Brian Kardell: Yeah, I really like that one too, came from Java and it's a lot like ThreadLocal, so I'm keen to see what happens there.
Eric Meyer: Yeah. So NIc, Ujjwal, thank you for joining us and maybe we'll do it again in the future.
Brian Kardell
Eric Meyer
Nicolò Ribaudo
Ujjwal Sharma