 Yes, we're live. Yes. Okay. Hi, everyone. We're so excited to be here with you today. My name is Amel Hussain and I'm with my co-host, Danny Blue, say hi to everybody. And we are part of the web platform podcast and we're super excited today to be talking to y'all about all things JavaScript with Mr. JavaScript himself, Jordan Harband. We'll get to Jordan in a bit. But what we're going to be talking about today is really how the language has changed in the past five years. JavaScript is all grown up. Gone are the days of just inlining your JavaScript in a script tag. And so we're going to be exploring all of the ways that the language has evolved and just really how that's shifted our just the culture around how we build modern web applications. So we have a lot to talk about in 40 minutes. So it's a tall order, Jordan, no pressure. But with that said, let's let's let's get started. So welcome, Jordan. Hello. Tell us a little bit about yourself. Hi, thank you. Yeah, let's see. I've been on TC 39, the committee that writes the specification for JavaScript since 2014. It's been a while. I've been an editor for two and a half years or so. I maintain a lot of open source libraries, you know, probably too many. And yeah, been doing JavaScript a very long time. Yeah. And you're really involved with TC 39, is that right? Yeah, I spend, we have six meetings a year that are about, you know, 20 plus hours each time. And there's a bunch of in between meeting work on it. And I've had a bunch of proposals advance. As an editor, I have to review everyone else's proposals. It's definitely a lot of work, but luckily I enjoy it. Yeah. And so for those of you who aren't familiar, TC 39 is the committee that's in charge of steering the technical direction for the ECMAScript language specification, which is, you know, basically the JavaScript standard. And Jordan has been one of the editors of the standard since 2018. So, you know, we're really excited to have him here today. And so I'm going to start with my first question, Jordan, which is, you know, a lot of the new language features since 2015, I feel like are, they fit into a gamut of things. We have syntactic sugar, you know, for things like classes, we have, you know, language extensions to, you know, arrays and strings and all these other cool things. And we have a bunch of things that look like it's, you know, for JavaScript on the server. And so can you just talk a little bit about, like, how, you know, how that kind of has come to be, you know, do you think that node has really pushed the envelope with JavaScript, the language and Yeah. Well, so things changed a lot after ES 2015 ES six, right, the process for getting changes into the language before that was essentially a bunch of smart people in the room who had overlapping and also conflicting priorities would just kind of talk about their ideas and there's a lot of debate and, you know, arguing and bike shedding. And it took many, many years to get a standard together. The previous version before ES 2015 was from 2011, which was ES 5.1. So that's four years between, you know, producing any specification. But the process that that group came up with before I joined to, which would take effect after ES 2015 has a bunch of concrete stages, which include specific entrance criteria and explanations of what's expected during each stage. And part of that is that there has to be shipping implementations before it lands in the standard, which was not the case beforehand. So the there are things that from ES 2015 that virtually no browser has shipped, for example, and that is partially because in the old stage process, that wasn't a requirement. So I think that what that means is that in the current process, the things that land in the language have been vetted to a much larger degree. And with a lot more people and a lot more constituencies. And that includes node node has always been considered in the committee, but has not really ever had any official representation or even any, you know, direct representation from people that have a voice in node until if, you know, a number of years ago. And I think the posts ES 2015 process has helped a lot with that. So Amal mentioned, one, I did not realize, so I've known about the stages and things like that. I did not realize that those were that new forgetting things into the language. That's because we've talked about like specs and that kind of stuff on this show quite a bit. And I guess, I guess just at the point I started paying attention to that sort of thing, they were always there. So that I actually find that very, very interesting. One question I have about, I guess, like the specs and, you know, like needing implementations and stuff like that. Amal mentioned that there are two different sorts of things, right? There are some things that seem to be largely, largely syntactic sugar. And then that might not be 100% accurate, but things like, but with things like classes. And then there are other completely new things that aren't, you know, like really weren't possible before. Is the proposal process different for those sorts of things? Like it does one shoot, like does one slide through, not slide through, but does one get through a good bit easier than the other? So like, is like a major language extension or something like that more difficult to get through standards than, than something that is more or less sugar? So there, there are definitely some things that slide through more easily, right? The one that was a real quick one was optional catch bindings. Because all of us in the room had had that problem where we had this exception variable that we didn't need. And it was gross and ugly. And, you know, we just kind of ignored it. And removing a binding is like, like it was just, it was kind of a no brainer, like it didn't, it wasn't controversial. That went through really quickly. There were some API methods like object dot values and object dot entries that were able to get in pretty quickly because object that keys was already there, there are compliments, there was already a precedent of that triplet of methods from other things. It just kind of moved through pretty quickly. So but the, the difficulty for adding new language capabilities is making sure it's, it's possible to implement it in a performant way, right? And the browser's all of representatives in the room has this note. And so we have to make sure that that's the case. There's also kind of security and encapsulation level concerns, you know, kind of OCAP stuff and other things that, you know, where folks are trying to run untrusted JavaScript code, and they want to be able to maintain the security of that, like Salesforce has a whole platform where anyone can put JavaScript into it and run it on people's web pages. So, but like, but with syntactic sugar, people are still bike shedding about what it looks like. So it's, I wouldn't go as far as saying that sugar is easy, just that it's a different kind of debate than low level primitive features. Yeah, yeah, I know that that makes a lot of sense, Jordan. So I think promise all settled is another one that I can think of as I remember just learning about that a year ago as a proposal, and it's already in language now, it's just, I think that that went super fast. And I think it's true. It feels like you're right, like some some language features are just like common sense, you know, Brandon, I forgot to do this, or, you know, like, just like, duh, and there's there isn't much deliberation about that. But I think I want to kind of get back to a point that you brought up earlier around just performance and implementation and, you know, what the consequences of that are. Like the committee is made up of implementers, right? So implementers being the folks that are writing the compilers that JavaScript runs on. So folks from the VA team, spider monkey, shocker core, JavaScript core. So there's implementers and then there's, you know, just like language nerds, you know, sorry to find a better, better word, you know, the representatives from other, you know, lots of companies. And then then you have kind of practitioners, right? So you have like web developers, you know, these experts seasoned folks. And so there's this interesting kind of like trifecta and like this little tension and push pull between these three groups. Can you kind of speak to that a little bit before we move on from this? So actually, I think that the the tensions you're describing is it's sort of a game theory, right? The browsers for like, the browsers don't have to follow the standard. Right? I mean, there's no like, like the use of force to make them do it. They are choosing to do it. They're choosing to do it because they think that it makes the web better for everyone. And they think that it mean will make their users happier. And it also, I think, frees them up to compete on, you know, other things than what how what's JavaScript, right? They can compete on performance, they can compete on synchronization features and things like that. But there's because they are choosing to comply with the specification. That also means that folks that aren't browsers can't sail into the committee and be like screw you browsers, this is what we want in the language. So it's a it's kind of a delicate dance where the browsers don't want to, for many reasons, they don't want to say to kind of ignore opinions that aren't their own. But neither can anyone ignore browser opinions. And so everyone has to sort of convince everyone in the room, browsers and community folks alike. And there's often overlap between those between that the feature being proposed is good for JavaScript, but also good for the web, because JavaScript is larger than the web. But the web is very, very large. So it's it's tough to find a sort of coexistence sometimes between those things. And that's the that's a lot of the work that we have to do. Very cool. Yeah, that is interesting. Sometimes I feel like I'm realizing a lot of things in this discussion already that I didn't really think about. Like the fact that you just said is like the browsers don't have to do what we say to do. And that makes sense. But I never thought about that before. But it's but it's absolutely true. That's that's very, very interesting. Pretty sure tail call optimization is still only valid in Safari or implemented in Safari. I think it's implemented in Chrome behind a flag, if I remember correctly. I think Chrome is long since removed the implementation. Yeah, I believe Safari is the only browser that ships proper tail calls right now. Yeah, which means technically people might get ready for your minds to be blown. I think Safari is the only fully mature 15 compliant browser. Am I right, Jordan? I believe that that is correct. Yeah, take that Safari, Safari for the win. Actually, another really interesting thing about Safari and please correct me if I'm wrong on this, Jordan. I think folks from the JavaScript core team, if I remember correctly, when when they're implementing new features, they have really strict performance standards. And so, you know, they can't implement something and have the engine be affected negatively at all. And so they're really performance fanatics. And that's really not the case in V8. I think it's a little bit more of the wild wild west there. But is that true? Well, maybe not the wild wild west piece, but the I mean, the the sense I've gotten from speaking to the implementers of JSC and V8 and so on is that they all have different tolerances for impacting performance. But there are a lot of kind of scenarios or code paths where none of them will will work any slowdown of any kind. I mean, one of the big reasons that decorators didn't advance in its latest form was because a number of browser engines were concerned that they wouldn't be able to implement it in a way that would avoid slowing down non decorated classes, right? Like they they might have been willing to accept decorated classes being slow, but not regular classes, like getting slower. So I think that they're all pretty performance sensitive. I mean, this is like I was saying before it's a bit of a game theory, right? The browsers are all sort of competing with each other. They all want people to use them. And that means that they have to work the best on all the web pages somebody likes. And the best is never going to mean slower. For sure. Yeah, I know I've said it a couple of times, but I'm finding this this entire conversation extremely fascinating for reasons that I thought it would be, but not for reasons that it's that I am that I'm coming to realize. So talking more about the the language itself. So the language seems to be used maybe differently by, say, library authors and by end users. And there are certain features that seem like they are might not be used very often by me, for example, just a just a lowly well web developer trying to build a website, not used often by me, but might be used by some of the big framework, you know, like some of the big frameworks or something like that. Do you have any thoughts on kind of the way that those two ecosystem, I guess not two ecosystems, but the way that those two groups kind of interact with the language and why it's different? Yeah, I mean, well, I think even it's hard to predict in advance, right? Like like fetch on the web, that's not that was designed to be a low level primitive only for library authors. But that is not how it's used. Everyone loves to use it directly. But it was not never intended for that. And so like, like there's a lot of features like like symbols, for example, their their primary value is in avoiding name collisions. And that is particularly important for protocols, like promises have dot then, which means if you name a thing with a dot then method, you've just accidentally made a thing that's like a promise, right? But if you use it, if you have a symbol for things like symbol dot iterator for the iterable protocol, you can't accidentally make an iterable, right? You have to be doing it on purpose. And so protocols work really well with symbols, because they have to be intentional. But protocols are often defined on a reusable piece of code. And often those are libraries. They may be inside an app, right? Like, you know, the they there's plenty of companies that have internal like reusable things, but the number of developers in that company even that defines that code is very small, whereas the number that consumes it would be very large. So I think that there's just like there's tension between web folks and non web folks, there's tension between, you know, library use cases and end user use cases, where it's important to make we all want to make them both better. But it's important to try to find a balance where you're not sacrificing the utility for one group in order to serve the other group. And there's something the web has called the priority of constituency is this, I think is really important that is brought up a lot in TC39, but isn't one of our like official principles or anything. And I don't have it pulled up in front of me, but it's something like users above authors, above implementers, above spec writers. And it's basically saying like, never make the spec easier to write at the cost of like making it harder to implement. Never make the implementation better at the cost of making it worse for people who write the code. Never make writing the code easier at the cost of making it worse for people who use the web. Right. Like it's I think that's my understanding of it anyway. And I think thinking about problem about trade offs in that context is really useful, because it makes it clear when you're optimizing for the wrong thing. A thing I say often is like, don't optimize for writing code, optimize for reading and understanding it because you write it once and you read it and maintain it a million times. Right. And but it's really easy to make writing your code quicker and it makes it harder to understand later. You know, so it's the same sort of challenge with language features. Wow, that was very deep. Very philosophical moment right now. I feel like that mantra needs to be put on a t-shirt. It should be like the TC 39 slogan. You should make an acronym. And I feel like that mantra is so powerful because I think I have personally actually always practiced that rule in the sense that, you know, I write codes for other people to read. And it's also for machines to process, but people first, right? So I'm not going to write the one line fancy shortcuts if it makes it more difficult for me or others in the future to read and understand, right? So cleverness is an anti pattern. Exactly. They can, you know, don't be clever be verbose if you need to, you know, because it's a code is really a communication first, right? So I think that's super powerful. But I've had this conversation with a couple people just in the past week where it's like, if you do something and you think it's clever, you probably shouldn't do it. Yeah, because you're going to forget it. And then you're going to shoot yourself in the foot first. Surely you're the first. There's that other quote. It's if if the code was as like, what was it? Something like if it was if it took all of your smarts to write it, then you are like, like by definition, not qualified to debug it. Yeah, no, that's powerful. But but but kind of getting to the, you know, Denny's earlier point around language, I mean, things like symbols for me, you know, they there's just a lot of things I think that are either misunderstood or under utilized. And perhaps that's okay, because maybe that wasn't the intention, but you know, for mass consumption. But I feel it feels like there are elements of the language which are certainly they feel very much oriented towards people that are creating libraries, right? So, you know, proxies is another good example of that. And so, you know, any like, not that I think there's analytics on this per se, but, you know, I mean, does it make sense that there's, you know, 80% of the people are most people are using like 20% of the language or whatever versus, you know, I'm just just curious, like if there if you have thoughts on that. I mean, I think that it's okay if there's features in the language that most people don't use, right? Like proxy is super niche one. And you can do some really clever and hacky things with it. But like it's primary purpose, as I understand it was adding some new previously impossible features to be used in concert with a concept called membranes that you have to build yourself. And it's really hard to build correctly. So like anyone's interested, go look up a library that does it already. And but it's, you can't really use proxy by itself for more than basic things, unless you understand all those concepts which are beyond me. So like, I think it's fine because it's adding a new capability, right? Like shared array buffers. That's, you know, that's not a thing that most people are going to run into. But if it wasn't there, or if it's then there's a lot of cross kind of cross threading speed ups that libraries won't be able to do in the future, right? Like if shared array buffers are around for long enough, then things like React or whatever will be able to speed up, you know, rendering and stuff like that. I don't know. So I think it's okay to do that because like the other thing on the web is we're working on a long timescale, right? Like features that ship now, websites, unless they're fully transpilable websites can't really ship them for many years. There's still plenty of websites that have users on IE nine. You know, yeah, no, no, that's, that's a really good point. I mean, I think we could talk for hours about like the bubble with modern web dev. And like, I think it's, I think someone put up a photo recently where it's like, you know, here's the reality of the web. Most of it's still on jQuery. Here's the reality of the jobs. Most of them want React developers, you know? So speaking of React developers, you know, I think you touched on a very controversial topic, which is like this react rendering speed. So I'm just going to like backtrack out of there and just X out real quick. But it's a really good segue into what Danny and I want to talk about, which is tooling, right? So we have all this like, we have kind of made JavaScript impossible for newbies, modern JavaScript, or the thing that we call modern JavaScript, right? So we, you know, we it's like tooling, it's not even optional tooling required for the most part. And there's certainly a movement and one that I wholeheartedly support and I'm excited about people trying to kind of, you know, say, you know, I don't need, I want to try to build things without bundlers, without transpilers. Like that's great, right? But but ultimately that's just not the reality that you see as mainstream adoption. And so like, what are your thoughts on that? I mean, it's kind of scary and also awesome at the same time. But also I think terribly, terribly terrifying for me. I mean, I grew up on View Source, right? Like that's part of the way I learned how to work on the web. And I see a lot of folks who also did that, and are saying like, are kind of, you know, old man shaking fist at cloud about it and kind of like, well, things were better when I was young. And like, let's bring it back to that. I like that. And that was approachable. And that was great for new newcomers. But at the same time, it made it really like, it was really hard back in the day to ship a website that worked on every web browser. I mean, I had a startup 10 years ago where we had to write CSS hacks to target Firefox to 3.0, 3.1, 3.5. Like, that's insane. That's that's not I'm sorry, that's that's not even the right turn. That is that is just an inordinate amount of work in order to make sure that a web page does not exclude users. And I really think accessibility is the thing that people should focus on here and not tooling complexity. When you're making a website, who are you excluding? Because it's always going to be somebody, right? It's fine if the answer is people without computers, right? Like, maybe you can't do anything about that. But like, you know, that you're never excluding nobody. So you have to decide who you're comfortable excluding. And there's a lot of people who have slow internet, older machines, cheap phones, you know, that just can't afford or don't know how to upgrade things, their browser or their machine. And the if you are handwriting all of your code and not using any tooling, you're excluding a very large number of human beings off the internet. It might be two percent of your analytics, but that's like millions of people potentially, right? And so whenever these conversations happen in one of my jobs, I try and change the discussion from talking about percentages to talking about number of humans. Because, you know, point one percent of the internet is like a very, very large number of people. And these people all are important. And they're all individuals, they all matter. So like the thing that I think we really get about tooling, and it's often missed in these discussions of people trying to reduce the complexity, is build tooling allows you to not have to think about it and yet still support browsers that you aren't even capable of testing, right? It's fine if you don't want to support IE 8, let's say, but like the reason your site doesn't work in IE 8 shouldn't be a trailing comma. That is a completely ridiculous reason for your site to break. There's lots of great reasons for your site to break. Let it be one of those, right? And a build tool and you know, nobody's really worried about IE 8 anymore, but like a build tool that strips trailing commas was a pretty easy low hanging fruit back at that time. And similarly now, like if you're just typing in arrow functions and you're shipping that to browsers, I mean, unless you need the very few parts of arrow functions that aren't syntactic sugar, there's no, like that shouldn't be the reason your website breaks, just transpile them. Like just move on, transpile them and like your site works for people. Can I play devil's advocate? Please. Actually, Danny, do you want to go first? No, no, no, I want to get into more of the tooling stuff specifically. Go ahead. Oh, great. Phenomenal. So I want to play devil's advocate. So what if what if what if what if what if you could only use JavaScript in production that will not product. What if the JavaScript you write and the JavaScript to production matched in the sense that you, you know, you had to wait until browsers implemented things, you know, or you, or you write your code in a way that's protective or whatever, like, but, but, you know, like, do we need to use the latest and greatest and greatest JavaScript like in, in web applications that to be quite frank, like, it's just, you know, you're making REST calls, you know, you're fetching data, you're rendering stuff, like, you know, most people are not doing anything super fancy yet. We feel they need to use stage zero features in production, like, I'm just, you know, I totally agree with actually with that, actually, I maintain over 250 npm packages and I use Babel on two of them. The rest of them I author in ES three, they work in IE six, every single one of them. And that's most of the time it takes no extra effort for me to do that. When it does, I may decide not to do it, but like, it's just easy. And yes, I don't get to use arrow functions and nice new syntax. But I don't have to deal with any tooling complexity either. Now that said, that's not a trade off that most people seem willing to make. Everyone really likes the new shiny and they do not want to be forced to write what they see as outdated obsolete legacy code, you know, because of people who, you know, who should just upgrade their browser, right. And so that's it for me, the tooling seems like a better compromise, where the developers aren't forced to keep in their brains, all of the quarks of the older engines. But the users are not then punished. Yeah, no, that that makes sense. That that's actually like, I think the best argument that I've heard for tooling. So thank you for that. And to be really clear, all of that should be easier, right? It should be easier to start. I'm not saying that the current, like learning curve is acceptable. I'm only arguing for tooling. Yeah, no, no, no, no, no, that that makes sense, Jordan. I just a last joke that I want to say again, I, I'm like, I always have to make really corny jokes on this show because, you know, you know, because anyways, but my corny joke is that, you know, web developers are a really self self select group of people. And they typically lean towards new bleeding edge, you know, so I think it's a lot to ask web developers, you know, people who live their life on the fricking edge of the world to, to, to, to wait, you know, so I think that's context to keep in mind for like the dilemma of today, you know, but yeah, Danny, all you. So this leans in really well to the next thing that, that I wanted to talk about, which is about specific tools. So specifically, I want to talk about Babel. So transpilers have been around for a while. I had it on my tongue. Tracer, Tracer was around before Babel as like, I don't like that, you know, not a ton of people use, but how kind of marrying stuff we were talking about at the beginning with specs and ease of use for developers that want to use shiny new things without impacting end users. How has Babel affected these standards process or has it affected it at all? We were just like before there were, you know, like there were no stages before. Now we now you can just go into Babel presets and be like, I want to use things that are at stage zero or something like that if I want. So can you just speak to that a little bit? Yeah, Babel is, I believe, deprecated the stage presets thankfully, because so I think Babel has massively affected it. I think part of the reason is because folks have been very wanton in their usage of like early proposals. I very strongly encourage everyone to never use anything in production until it's at least stage three. Like you can play with some things before that, but many things have changed drastically before then. But as far as your question, I think, I mean, back when Tracer was commonly used, I don't even know if that's how you pronounce it, but that's how I've always read it. The I actually was vehemently opposed to transpilers. That was my position for a long time. I I did not like it. I didn't like looking at the output and seeing that it was gross, even when source maps came, like it, you know, it isn't it doesn't totally fix it. But I think that the the ability for syntactic features to get feedback before they actually land in the browser and are never able to be removed, right? Because we can never break the web, right? The Space Jam website from 95 has to work forever. Like that is the mantra of the web, right? Do not break the web. So. It's being able to get the sort of feedback on syntax before it's final is really critical. It's not as big a deal for. I mean, Babel doesn't have only really transpiled syntax, right? The rest is, you know, shims and polyfills and you don't need Babel for that. It just can also sometimes do it. But shims and polyfills like are part of the stage process as well for some things they can count as implementations you know, for stage three. But I think that it would have been a real shame if we couldn't have had practice using class fields before it got to its current stage, which is three. That informed a lot of the discussions. In some ways, it also helps persuade detractors because a lot of people have intuitions about how confusing syntax is going to be or how easy it's going to be. And often those intuitions can be wrong in both directions. So for class fields, we had five years of, you know, tens of thousands of developers using it, putting in documentation for public fields anyway, right? And and understanding how it worked. And so when folks said, well, that's going to be unintuitive because it violates this expectation, we had a whole bunch of like use actual usage to show no, it's not actually confusing. Maybe it confuses you, but it doesn't confuse most people, right? And that weighs into the discussion. And you know, without that, that research, right? It's it's hard to know. And like, I mean, we never really know, right? All these are guesses. We're all trying to make the best guess as possible for what's good for the language. And the more feedback and information we have, the better decisions we can make. And I think Babel helps with that. So I'm like and Babel implementers or maintainers are often in the TC 39 meetings. So they're an active part of the process at this point, which I think is very important. So I want to clarify one thing that you said before we move on, because I know we're I said, we're also like, it feels like time is slipping away very quickly. So so you said that polyfills can actually count as implementation in order to get to stage in order to get to stage four. OK, yeah. So. So because when I thought you said implementation, I had assumed that meant, oh, you need like a like a browser implement or a JavaScript engine implementation to do it. But you're saying that is not the case. This is the most contested part of the entire stage process. It's defined vaguely in the process document on purpose because the group could not come to consensus and still can't think about what it means. Essentially, I think the exact wording is two shipping implementations, such as a browser behind it's not behind a flag, right? But it really depends on what the proposal is and I've tried suggesting things like defining risk areas and saying like these risk areas need these kinds of implementations and so on. But it's really tough to get process changes in sometimes. But essentially the like for object values and object entries, nobody was concerned about implementing those. There wasn't like it was just kind of it's going to be easy and fast to implement. So the polyfills for it that I published were able to count as one of the implementations, like one browser and the polyfill covered it. But for like async await, Babel's implementation doesn't count, right? Like in that in that regard, right? It helps inform the design, but it's not sufficient to say, yes, this can be implemented performantly. So I would say generally for syntactic features, it does require two unflagged web browsers, like not in a nightly build or anything, but like shipped to everyone. Yeah, that makes sense, Jordan. So we've only got five minutes left. There's so much to talk about, we'll just have to have you back again to talk about some of the other things. But I'd love to dig into it's just one specific feature that I think is 20 years 2020 global this. So I think this is kind of a fascinating chart. Just was wondering if you could kind of give us an overview of what the context is. And I think for me what's interesting is how I think the growth of JavaScript, you know, in the browser, we're using more JavaScript. So now we need to take things off the main thread. So now we're using web workers and service workers and, you know, we're caching things and in a strategic way. That has kind of led to this need to kind of have like realms. And, you know, I think these are things that I think the average web developer doesn't think about. And, you know, I would really love to just if you can kind of walk us through a global this. And sure, I think it really hit the language a lot sooner than I thought it was. Like I thought it was going to take a much longer. So I was surprised to see it go through that fast. Yeah, I mean, this one is a bit of a saga. So there there has not before this there wasn't any thing in the language that referenced the global, right? Like which in browsers you could get it with you could get it with with window and in node you could get it with with global and in like web workers and frames and stuff you could get it with self. But there was never one consistent way. So you always had to do a bunch of feature checking to figure out which environment you're in in order to get the global. So it seemed like a pretty simple idea that everyone was on board with. Let's just put a thing in the standard that can do this. And there was a bit of a churn trying to figure out some of those security concerns I had mentioned much earlier in the the podcast. But once those had been kind of overcome, the the main concern was the name of it. And unfortunately, the name global, which is the one everyone wanted and was the best, was not web compatible. It broke like Flickr or something because some old version of, I don't know, Moment JS, like, I don't know, it was just there was some some craziness that just broke major websites. So they couldn't ship it. And so Moosh gate. Yes, I mean, it was and you're doing something like HTTP archive to do this analysis, right? And actually, in this case, I think Firefox shipped it and then got a bug report and I don't think they shipped it. I think they was just in like their developer channel or something, but they very quickly got a report that it was broken. OK. And so now I like at that point I had to figure out how do I name this? What do I name it? And so I came up with I mean, but I wanted to get before I tried to ship it again, I wanted to get data as to figure out what was actually compatible. So I came up with a list of names by talking privately amongst the TC 39 delegates. And some folks on the public get every poet throwing some names into that as well. But the browsers didn't want to take my list of 20 names. They wanted like four or something. So I had to just arbitrarily choose which ones to gather data on. And I got that data and then I presented it and we picked one of the names and Global This was the name that we went with. Like a few months after we decided on that some famous authors got wind of it and sort of not maliciously but six their Twitter followers onto a GitHub thread. And so there was a lot of comments and everyone was really angry with me and thought it was a terrible name. And they, you know, the word this is confusing enough. Don't add it in more places. Right. And they're all right. Right. It's a terrible name. But it was the least terrible one that I was aware of. And so what I ended up doing was I met with another TC 39 member who she helped me come up with this naming document, which lists a bunch of constraints like this is a must. This is a should. Right. And all of these constraints suggest certain names and disqualify other names. And when you're done reading this document, it's kind of tough to be all ragey at me because like you understand hopefully why this was the option. So I'm really glad I wrote that document. Yeah, that's super worth reading. Can we get into that in the show notes? I'm just something that's still up on GitHub.com slash TC 39 and slash proposal dash global. And then it's like naming dot md in there. Oh, awesome. Yeah, we'll have to link that. Yeah, and that's an approach I want to take with controversial things in the future as well for the same reason because it seems to settle the scent. Sorry, go ahead, Danny. No, no, no, no, I'm going to say like that. I'm impressed that you remembered the URL off the top of your head. Thank you. This is Jordan Harband. We're talking about here. He's like half human, half machine, 100 percent of us are human. Well, Jordan, this has been an absolute delight. We are really, we're just about out of time now. If folks wanted to get in touch, if they have questions about TC 39, if they wanted, if they wanted to get in touch with you on Twitter, what is the best way for folks to get in touch? Yeah, I mean, my Twitter handle is LJHARB and it's the same on GitHub and virtually everywhere else. You can email me, pick a site. You can find me on IRC there's a bunch of channels on FreeNode. I'm in the Node Slack in the Babel Slack. You know, just kind of look for my handle anywhere and feel free to reach out. My DMs are open. So yeah, that's anything. Sorry, we couldn't we couldn't talk for hours because we are live from OpenJS today and we are under some time constraints, nudge, nudge. So we we're really, really grateful for your time, Jordan. You know, this is this was really last so. Yeah, thanks. It's fun talking to you. And we'll just have to have you back. Happy to be back. Let me know. All right. Well, thanks everybody for listening in. And this has been the Web Platform podcast.