 Thanks, everyone, for joining this panel. We're going to talk about how web developers affected web standards over the years, which I think is a really interesting conversation. We've been chatting about it. We've all seen the folks who are involved have seen this sort of evolution over the years of web developers getting more involved in standards and helping to make change that really helps the ecosystem and developers and the work that they're doing. So this kind of started a while ago. I know back in 2013, 2014, we really started to see folks get more involved in standards and affecting how things were evolving. What were you seeing at that time, Joy? So 2012, 2013 is a special time for me because that's actually when I feel like I kind of took, I woke up like seeing the matrix and like, oh, shit. This is how everything works. I had been working at a web development consultancy called Boku. And we were a little boutique shop in Boston. And we worked on jQuery. And we worked on Backbone. And we worked on Grunt. And we worked on Johnny 5. And we worked on all these open source projects. And we were in our 20s. And we had no idea what we were doing. But we were having a good time doing it. And we were hosting these meetings of the TC39 and the W3C's TAG and some of the other working groups. And I was young and didn't know what was going on. And one day we were having a meeting. And they were having a meeting. And I was like, oh, what's Rick? What's going on in there? And he was like, oh, we're having a TC39 meeting. And we're going to argue over something. And I was like, wait. So you're in there deciding how we're all going to do something? And he's like, yeah. It's like, that's how this works? You all just get in a room and argue with each other? And then that's what I have to do? What the hell? So at that point, I felt like I needed to really get involved and start understanding and then start helping other people, because there were some other things that were also going on for web developers at the time, responsive. Design was really influencing the libraries and influencing how we were building software. There were a lot of really interesting things happening. And I think that's when you showed up on the scene too. Yeah, I mean, I had been maintaining very early in my open source career some, the ES5 shim and ES6 shim, which are polyfills so that you can pretend like the old browsers you have to support are the new ones that you wish you had to support. And Rick Waldron, who was a jQuery maintainer and worked with you at Boku, reached out to me on Twitter and was like, hey, he had noticed me participating in the old TC39 mailing list, because I was asking questions, trying to figure out how to not screw up the polyfills. And he was like, hey, do you want to come to this TC39 meeting? And the next one that they had that was local to me, I was like, hell, yeah, of course I do. Let's see what this is about. It felt like I was getting a secret invitation. And I went into this room and there were like 10, 11 people. It was very small. I was there were only two or three of us were felt. It felt like only two or three of us were younger than 50. Right? And that's, you know, and I felt like I was the youngest. And in that first meeting, I was able to provide like a meaningful change to what became ES6. It was the way that object.assign was going to work. They had some sort of language in the spec that like as it was iterating through the properties, it would catch the first exception and swallow every other exception. And then what was done, it would re-throw that first exception. And it was just bizarre. And I also was able, like I had been talking to John David Dalton, the maintainer of underscore, who also wanted like underscores or load ashes, excuse me, load ashes extend to match object.assign. And so I was able to represent both his and my opinions in the room. And convinced the room and they changed it. So object.assign works differently because I happened to be there saying some stuff. And that's an incredible feeling. Like I was addicted at that moment. I went home and I like, I was working at Twitter at the time and I like convinced, I went straight to the CTO. And I was like, we got to join ECMA. We got to go to TC39. And I've just never looked back. You're like, crack cocaine moment. Very much. I'm not appropriate, I'm sorry. But I think what you just, there's a couple of things that you just said that I think are really important to call out. And one is immediately that you were able to come into that room as an open source developer and say, hey, spec engineers, the open source developers are doing it this way. And if you continue this pattern, like it's not going to break anything. It's going to kind of standardize what everybody is already doing. And I think that era of TC39 in particular kind of does represent a little bit of a shift from some of the gray hairs who led us through the first versions. I'm sorry, maybe shouldn't be. No offense to anyone. Who led us through the first versions of ES in the late early 90s and then to 1999 where we hit sort of a winter, if you will. Well, and I had sort of before getting plugged into TC39, I had that sort of perspective of like, what are all these ivory tower morons doing? They don't know what real developers are doing. Like this is bad and this is bad. And like, first of all, they were very welcoming. They listened to my feedback right away. I definitely felt intimidated, right? Like, I think I was the only, I don't have a degree and I think I was the only one in the room without multiple degrees. And like, they listened to me and that was a great feeling. But the other thing is, I think that the group wanted that input from the community and they weren't really sure how to get it. This was before Twitter was mainstream. This was before everyone had a smartphone in their pocket. It was before a lot of people were on GitHub. Exactly. And that pattern of standards are developed by, you know, people who work in research departments or work on some like obscure like product area and not necessarily involving their users, involving customers, involving like the people who may be building on top of them was really common. And I think in this era of ECMAScript, you started to see more of the participation come into play and folks on, this is back like again in jQuery days where, okay, because there was such a stalemate in the spec for so long, jQuery and other libraries like, you know, started to get really popular and started to push things forward because people weren't sure if frankly there would be another version of JavaScript, right? So at that point, I think sometime in late 2008 or early 2009, I don't know exactly when, they started to resume conversations. Can we pick, can we abandon ship on ES4? Can we pick up, you know, and start trying to build some consensus around what has become more standard within the community today? And then the jQuery project started sending to Huda and Rick. And I think that really helped to unlock momentum and allow folks to start to find consensus on things that we'd already more or less agreed to. And I mean, the progress has definitely increased. Like the progress of the progress has increased, right? Between ES3 was in 1999 and ES5.1 was in 2009 as they had, like as you said, when they just started to get back together. So that's nine years. And then six years later was ES6, ES2015. And now we're on a yearly cadence. And it feels really slow when you're watching a proposal that you're interested in advance and take years to make changes and to get blocked by things that seem silly. But like, and it's even worse if you're trying to drive that proposal and you're watching that slow down. But like JavaScript moves pretty fast. And like the speed at which we, I think we're able, we've become able to gather feedback and incorporate, you know, various opinions and come up with good outcomes, I think has improved a lot. It's been really nice to watch. And as I said, there were like a dozen people in the room when I first got there. I think if we could, you know, teleport everyone to the meeting who participates, I think there'd be 60 to 80 people at this point in the meetings that we have six times a year. There's a lot of people involved. Yeah, and I want to emphasize the point too that, you know, folks can get involved. You kind of mentioned like being invited in the early days, but that's probably just because people didn't know, but everything's online. I think TC39.es is the website. And all the repos are in GitHub. So I encourage folks to take a look and get involved if you're interested. I think, you know, there was a similar shift happening in a different organization around HTML and kind of a similar, some similar things happening. You want to talk about that for a minute? Yeah, so I think another thing that was going on in that era was, of course, devices. Suddenly we have, you know, the internet in our pocket and what's that all about? You know, Dylan knows all about that. And so, you know, we were, as the web developer community, we were trying to figure out how do we build for those devices? What are some of the challenges as we put more and more media on those things? And so, you know, we have pictures. We have things that we want to show people and we have to do that in a, you know, sane way. So some of you may remember this particular battle but over the picture element, right? So you've got a group of very passionate and experienced UX developers who felt very strongly that the best way to handle something and handle responsive images in particular was to do that with the picture element and the source set attribute, right? And so, that was actually a pretty big disagreement among some of the folks leading the HTML spec at the time and thanks to their hard work and their sort of stick-to-itiveness and just really gathering all of the folks who were like, we are working on this. Well, this is our problem. This is our need. This is our pain and we need you to evolve the specification in a way that we can use it, right? This is how we wanna, this is how we do things. Please do not standardize something that, you know, we're not gonna do. Yeah, and I think in that particular one, watching from the sidelines, it felt like folks, some of the folks building the browsers who I think historically have not often been web developers themselves. I'm assuming that I've seen some of that shift a bit but they were proposing something that seemed performant and easy to implement for them but it wasn't necessarily the thing that the developers wanted and the thing the developers wanted might have been really difficult to implement or slow and so there was this sort of tension between what we, the web developers wanted and what the browser folks would be able to actually build and I believe the compromise that was ended up with was a good one and that everyone was a little unhappy but like we got something that kind of worked and took the feedback and actually since then I think web specs have taken a lot. Like I've seen browser implementers conscientiously try to pay more attention to what web developers want and they still have that same pushback, right? There's still that same tension, performance and implementability is important to them and sometimes the things we all want and need, we just don't get to have it because the browsers can't build it, right? But the fact that they're willing to pay attention is nice and the more we can incentivize them to pay us attention and try to, and the better we can present our needs so that they can try and come up with a way to solve them in a way that works for us, like that's the process working is when we're all able to figure out how to better express ourselves and listen to each other and come to compromises. I think that example, I'm just remembering it was Matt Marquis, Wilto. That's right. Credit Wilto for his work on that. That was a very painful time for Wilto, but I think that what he maybe inadvertently did was start more of a trend of the spec authors sort of listening to some core constituencies and going out and seeking their input as part of the process and that responsive images community group has now evolved because it's not just images that needs to be responsive. It's lots of other things. So it's not the responsive issues community group. And again, it's a great space for those users to share feedback early on to the different representative spec groups within the W3C on issues that really affect and needs that they really have. And just it's like echoing what Joe was saying about anyone can just go to the TC39 repos and kindly add your informed opinions, please. But similarly for the W3, they have all these community groups and you have to go sign up on a website and find the group and click a button, but then you're on the mailing list and you can talk just like everyone else, right? And the same thing, like be nice, respectful, follow codes of conduct and try and read some stuff before you say things, but anyone can just hop in and you should if you feel like you have something to offer. You probably should even if you don't think you have something to offer because you probably do. So I'm thinking about like implementing things before their standards essentially. And I know this happens sometimes in the browsers, but also in like polyfills and such. I think you kind of mentioned that in the beginning there. Can you talk about how that works and why it's important? Yeah, I mean, so there is, it has been for decades now, a wide ranging best practice in the web development community do not modify objects you do not own. So this means like language built-ins or web platform built-ins, don't screw with them. However, polyfill authors, that's all we're doing. Like that is entirely what we're doing. So it has to be done very carefully. And the reason is because if you modify built-ins in a way that, or there's a lot of ways you can modify built-ins that will actually obstruct standardization in the future. There's, I could list off a bunch of examples, but there's a bunch of libraries from the late 2000s, early 2010s, Mutual's prototype scriptaculus and things like that. That at the time it was less, I said decades, but it was actually not as long as I wish it was. At the time it was actually considered kind of okay to just go mutate stuff. And so these libraries were doing that and they thought it was defensible at the time. History has shown otherwise, but they didn't know that. So I'm trying to be diplomatic here. But some of the modifications these libraries have made have actively blocked proposals in the last five years or six years or something. And they've had to rename things. Or like right now there's a stage three proposal for a grouping method to take an array of stuff and group it into an object with names and sub arrays, right? And we want it to be called group. And we probably can't, because some code on some website that's big enough like has installed that somewhere. And the same thing happened for like string contains versus includes and there's a whole long list of these. So it's very, for language built-ins, like my advice that I always give is until it's stage three, do not ship it. And for web platform built-ins I would, I'm not familiar enough with the progression to know exactly when the time is, but I would say when two browsers have shipped it, you're good. And if only one browser has shipped it, especially if it's Chrome, hold off a little bit. Because Chrome is a little eager sometimes to ship things but they're also willing to pull them back. So like Chrome has it is not enough of an evidence that it's permanent. But if two browsers have it, it's like pretty good. And so browsers are implementing things before they're officially a part of the standard? Yeah, well, and as the actual proposal process that TC39 adopted after ES6, ES2015 includes stages where stage four is the final one. That's when it's like merged into the specification. But stage three is like we think it's done and we don't think we can get any more feedback unless we actually try to build it. And the requirement to make it stage four is that it has to have been shipped. So like your, our process actually requires it to be shipped in some form, usually like unflagged and stable and available by default in order to get it into the spec. So individual browsers and engines have their own amount of enthusiasm or caution about how, when they ship which proposals, but like it is an actual requirement that it should be shipped before it's in the spec. Cause the intention is because we want the specification to document reality and not to be this, like forgetting the word I'm looking for, but like a aspirational document of like, this is what we hope it should work like, but if nobody's actually doing it, right? Like a standard of specification is just a piece of paper unless everyone's following it. And so we're trying to make the JavaScript spec be the thing that everyone's following and not just the thing we hope they would follow. Yeah, I think that's an important distinction, because you could standardize on something and then have it go terribly wrong for whatever reason that you didn't think about. So to have it out in the wild first really makes a lot of sense. And I was gonna just add that, like I think that shift that you're talking about coupled with other patterns that I think web developers really pushed for through like the test the web forward movement that happened early on. And that's where we got like more support and like buy-in and use for like web platform tests and the test 262 suite and that kind of thing really helped to, you know, speed up the process is almost a little bit like it enabled the continuous delivery if you will of ECMAScript in a way that frankly wouldn't be possible if we were still sort of sticking to sort of the other methodology. And I think that's just like, that's a very cool and very important shift that our industry saw. And I think, you know, like I think we, I think they kind of led on it that I'd love to see transfer to other industries. Yeah, and that's actually, I sort of forget the evolution over time, but like when ES6 came out, nobody had implemented any of it until after it came out. And also not one browser fully complied with ES5 until years after ES6 came out. And like, I know this painfully because all of my shims had to feature detect all of the many ways each random browser and browser version like deviated from the spec. But on top of that, there's this compatibility table, Kangax, like it's like, you can Google ES6 compatibility table or something. And it was just a bunch of like green and red check marks, probably like in Luke's talk earlier, like the MPM status board was when it first started out. And it just, eventually the browsers realized and the engines in general realized, users care about this. They want things to be the same. And so we either have to change the spec or we have to follow the spec and they went and did those things. And those tables are mostly green at this point. There's just really random edge cases that are off, you know, in some cases, but like they've done a lot of work to try and like consolidate on a single set of rules. And that's really helpful. Like the, I mean, yeah, the amount of like browser specific CSS and JavaScript hacks I have buried in my poor suffering brain from the last 20 years that like modern web developers just don't have to deal with. Like it's, yeah, it's, it's just, it's, it's glorious. How much better things are than they used to be. And the Kangax tables again, that he just was like responding to, okay, what a thing works where, you know? And then now that's something that we take for granted that we can just go to MDN web docs and look at the BCD data and see what's working. And, and, you know, and it's all nice and tidy and knit together for us because developers did the docs in an open source way. Developers did the tests in an open source way. Developers are deploying the spec continuously in an open source way. That's rad. It's really cool. And I'm reminded too of, of like coffee script, which seemed like a really creative way to kind of muck with things. And I think some of those things were brought into the language. Some of them not, but those were really interesting. I felt very creative, I guess. It was a very creative experiment. That is how I learned more about ASI. So there you go. Tell me about ASI. We're not going to talk about semi-colons today. I meant to mention this earlier, but like the, the both the ECMAScript and HTML kind of had a jump in their versioning. Like what, what was going on there, particularly with HTML? We went from what? HTML was, what was it before? Well, there was, there was HTML three and four. And, and then back, back in the year 2000, I had, you know, there was these validation badges you could go get. You could like run your website through and it tell you how compliant you were. And I would be really excited to put the little badges all over and like I'm compatible with all these things. The HTML five, the idea was they wouldn't have to ever make another one. Go ahead. Yeah. And then, and then there was also, I think the other thing that kind of happened was we were kind of thinking about HTML and CSS kind of together. CSS versioning is actually super confusing to me because they're, they're of the way they split the, the surface of that specification up. And so I think for some of those efforts, there's such a, you know, disparate disparity between like just what the needs are in some of these APIs. So it's the versioning of like one to two to three. This doesn't make as much sense to describe all of HTML as at a single version when, yeah. And for ECMAScript, it's also a little funny. Yeah. I mean, it's, it's sort of a living standard at this point, right? As soon as something is merged into the spec, it's in the spec. That's the spec, right? But the, like you were talking about HTML five, right? In the same vein of like web hacks that you don't have to do anymore, there used to be all these different doc type declarations at the top of your HTML file. And you could put things in standards mode or quirks mode and different browsers did different things. And with HTML five, I guess they got lucky and figured out that if you did doc tape HTML, it gave you the least weird behavior in all the browsers. And so they're like, that's it. It's just that forever. And then they like added new stuff on top of it. And it really smoothed out a lot of the incompatibilities we all had to deal with at the time. But I think it did maybe set the groundwork for us to think about specs in a way that is more adaptive. And yes, we do need to have at, at for varying reasons moments in time where we lock something in and we say this version is canonical. This is what we're shipping. And that may be less important to us as work a day developers, but it becomes more important to your companies that are shipping product on top of your work. And so for those reasons, we do need to be developing standards together and making periodic notes of like, this is final, this is approved, but it doesn't mean that we're done. It doesn't mean that maintenance ceases. And that's a big, big shift, I think. Yeah, I think there's another tension as well that like, like in a company, you're often told, you know, move fast and break things or like, perfect is the enemy of the good and just, you know, what is it, disagree and commit, things like that. And in a company that makes sense, but in software, like in open source software in general and standards and stuff, no is temporary, yes is permanent. And so it's actually really important that we gather as much information as possible before saying yes to stuff, before adding things and making changes and shipping things. And the more everyone kind of understands the, I don't wanna get too philosophical, but like the intrinsic humanity of every other person and like the more we actually empathize with everyone else and the things that they care about and the things that they suffer through and like, you know, like the more that browser like developers understand that like, what pisses off web developers and what makes their life easier and vice versa, right? Like the more web developers understand about like, why some things can't be implemented in a performance way or like kind of how browsers sort of work under the hood so that like, that's why this pattern is faster than this pattern, right? The more that there's that shared understanding and empathy, the more we're gonna be able to build stuff that is the right thing or is the least bad thing or that is like the most open to further extension and evolution and iteration. And you know, so it's, I think the biggest, like the biggest thing I'm optimistic for seeing the last decade or whatever of standard stuff is how much, like how much more open the processes have become to collaboration and participation. Even the venues that require membership dues and so on, which are most of them, right? There are still plenty of ways to collaborate and participate for free. And like, I encourage everyone to do that because we want everyone's voice and input. It feels like a good way to close our conversation. I'm not sure what time this ends. I have no idea. Okay. I'm inclined to ask about temporal, but I don't know if we wanna get into that. The temporal proposal? Yeah, okay, let's, cause that's, you know, time. Sure, so I'll give a little context. Anyone who's worked with JavaScript date knows that it's terrible, it sucks. It's like broken in all sorts of ways. It's hard to deal with time zones. It gives you mutable objects. It's blah, blah, blah, blah, blah. It's to the point where for years, the only rational thing to do was use Moment.js. Because like, that's the only non-terrible way to work with dates in JavaScript. And Moment has its own problems. It was originally designed at a time when mutable APIs were considered okay. And we're now in a time where they're largely out of fashion. And, you know, it's a very large library, but part of that is because it has to deal with time zones and locale information. And anything that claims to be smaller probably isn't accounting for all those data. But, and there's a few competing libraries to Moment as well that are trying to provide a more functional interface or be a little smaller and so on. So, the Moment maintainers a number of years ago started, came up with this language proposal. How can we fix dates and times in JavaScript so that they're not terrible? And that proposal is called Temporal. And it was like the original two people that drove the proposal. Maggie and Matt were both maintainers of Moment and are both like extreme experts in dates times, time zones and all things related. And they pulled in the right expertise from the right folks. There's, you know, as much as I don't want to take cues from Java, there's apparently a great language in Java called Jodetime that seems to do these things well. And so a lot of input came from the Jodetime maintainer and was incorporated in. This proposal has advanced over many years. It has been stage three for about two years. However, no one's shipping it because our TC39 meetings are every two months. Not one meeting has gone by since it hit stage three where it hasn't had what is called normative changes, like a change that a user of the API would observe. You could argue that that, you know, like breaking changes in most ways. So basically until that sort of settles down, no one's gonna ship it without a flag or anything. And similarly, like I have a bunch of polyfills. I haven't tried to build one for Temporal yet because I wanna wait till my, you know, I'm not trying to hit a moving target. But the very moment and pun intended that Temporal stabilizes and polyfills become available that are backwards compatible, you know, and in ways that there are a few polyfills out there, but they're aiming for moving targets and they're not incredibly backwards compatible. They're more trying to hit completeness instead of supporting all the browsers and engines you might care about. And the moment that that happens, everyone, every library, every application should just drop every date library and date itself and only use Temporal and you will all be much happier for it. It, you know, every TC39 meeting, the Temporal champions pop up and they're like, here's the latest changes. We hope these are the last ones. So the next TC39 meeting is next week. Hopefully those will be the last changes we see. And we will call that Temporal Day and we will declare it a federal holiday. There you go. So there's been a lot of hard work done on that proposal over a lot of years spanning a lot of champions and I'm very excited for when that day finally comes. Great. Any questions from the audience? You, sir? You, sir. Kind of stranger. I'm just kidding. Has there been any other languages that Echmer has or is, you know, taking inspiration from in terms of language development? All of them. I mean, like the room is filled with people who love and hate all of the languages in aggregate and some of the people in the room have designed some of those languages and every proposal part of the process, it's expected that prior art in user land, like in regular JavaScript code, but also in other languages is explored. The general sense is if every other language is doing something a certain way, we should be careful before deviating it from it, but we still might if we think it's better for the language. And if a bunch of languages haven't decided on a, like, haven't cohered on a single consistent way to do something, then we should look at the trade-offs of each of their approaches and try and figure out what choices make the most sense. Yeah. So yeah, basically every language contributes something. Any other questions? There we go. Other than temporal, what's the next most exciting thing that is coming down the pipe? So from TC39, I mean, there's such a long list of proposals that I'm interested in. So like, I'm champion of pattern matching, but that's only stage one. So like, don't get too excited yet, but we're doing, there's like six of us championing it and we're doing a lot of work trying to work with implementers to figure out a form that will be palatable and solve all the use cases. Things that are more advanced, right? There's array change by copy. So a lot of the methods on arrays that mutate stuff like sort and splice and whatever. Now there's two sorted and two spliced and there's a couple other methods in there. So there's a nice little helper convenience methods. Yeah, there's a type annotations or types as comments proposal. That's still stage one and that is, I think, it is unclear what that path forward looks like, but the future is long. So we shall see. Any other questions? No? Assuming it's 2030 before we actually have a date library and JavaScript that's compatible with the rest of the world, at what point does it make sense to say, hey, if by now you haven't figured this out, maybe we should just use Wassum? I mean, I don't think Wassum was ever designed as a replacement for JavaScript. I've seen a number of statements to that effect. No, but it brings in all the tools that you use. Oh, like use a Wassum date library. Right, in their own libraries, which still have sanity, and it will run faster in your browser. I think that that is certainly an option, right? You could do that now. I think that the challenge, it's more than just about an individual library. Like having it in the language makes it a coordination point for everybody. So right now, it is expected if you're trying to pass around dates, it's either a date instance, and then a number of libraries will expect a moment instance, but only those two. And if you, or a string perhaps, and so if you are and start working with a bunch of, from any random library, like instances of something, whether it's Wassum or JavaScript, you're gonna have to do a lot of conversions back and forth to cross all the API boundaries. And I suspect that you'll lose a lot of the convenience and performance benefits from doing that, whereas if something lands in the language, which I think will be hopefully much sooner than 2030, but if something lands in the language, then that's something everyone will cohere on. Every API will just expect a temporal instance, and it's really trivial to convert a date instance to a temporal instance, and I'm sure Moment will ship a like dot two temporal something, right? Like, so it'll just be really easy to, just like it was with promises, right? There were a bunch of promise libraries, but they've all kind of cohere it as like, this is the real promise, and that's what everyone expects now. You've also noticed that things like AI, blockchain, TensorFlow.js, they are basically moving all of the workload to a Wassum kernel and just exposing APIs to it. And frankly, you could say that after a couple of years, Wassum has more cross compatibility than JavaScript has tried to get to in 20. I think Wassum has more potential cross compatibility. I don't think the actual implementations are quite there yet, and there's a lot of, like I was overhearing earlier this week, like there's no way to composite two Wassum files together, and so like there's a lot of polish and tooling and functionality that would need to add for it to be as viable a replacement as you're implying, but like there's nothing wrong with doing that. If you can find a way to do something, like I would say Wassum versus JavaScript is more of a performance question or a question of what language you wanna write it in, since some languages can compile to Wassum much better than they can compile to JavaScript, but beyond that, I mean the API, the outer API is the outer API, and that is all JavaScript from the perspective of a JavaScript consumer. So I would just say, run your full application benchmarks, not micro benchmarks, like weigh the maintainability of who's gonna be maintaining the code and who you can hire for that and what the resources are and stuff and make the choice that's best for your application. I believe we're at time, so I'm happy to take my answer off there if necessary, but how often and how much do performance needs happen in spec conversations? Like I believe map might have had some specific performance parts of the spec, like methods needed to be something, and so like temporal, for example, are there, is that common for performance implication to be discussed as part of the spec? So kind of answering this a little bit in the abstract and then maybe we can just talk specifics because we don't have a ton of time. Any time we're evaluating proposals for a language feature, there's tons of trade-offs that have to be considered. Performance and security probably top most among them, and so for people who care about making things fast, the most important thing is that it's fast, and for people who care about making things secure, the most important thing is that it's secure and the solution might not satisfy both cases. So there are lots of other things that we look for too, like how could this potentially be used incorrectly and does that cause harm? Does that cause unintended consequences? So it's not an easy question to answer and it is why sometimes it takes so long for things to move through because that compromise on the right conditions of each thing is part of what ends up driving the final outcome and we can, yeah. So the specific thing I'll talk to is there's another proposal that I failed to mention earlier, set methods like intersection, union, difference, and I believe if intersection, there's a pathological performance case where if you have an empty set as one of the two sets, depending on how you write the algorithm, it could either be really, really fast or really, really slow, and the champion of the proposal deems it unacceptable to have it be really, really slow. So he's trying to figure out a way to write the algorithm to make it be, to make it work and that has delayed the proposal a bit but that's very important to him and to others as well and so that is coming up as a topic. So I know we're at well at time and we're standing between you and lunch but before we take off, I think I just wanted to plug some of the projects at the OpenJS Foundation because we're on the OpenJS World Track that I think are really important and influential in this space and also invite you all to come to an OpenJS standards working group meeting sometime if you're interested in learning more about how some of our projects like WebDriver or Globalize or Node are influencing and really leading change I think in key places this the spec world we would love to have you so thank you. You can find out more OpenJSF.org slash collaborate links to the calendars and such we have a standards meeting every other week so be happy to see some of you at the next meeting. Thanks everybody. Thank you.