So, if not, you are not in a state to just use it and test it, you will get an idea about what the future will be like and what are all the, you know, probably in syntax or the changes that this proposal is bringing. So, that's one of the ways that you could handle.The other way is you go and read the spec and try to analyze. You might not really, you know, get the hang of it if you're not into reading spec, and me and one of my friends are running the show called Read the Spec with Us where we are reading bits of the specification and trying to translate it to <a href="/tags/code">code</a>.As Vik mentioned, there's this test, 262, which would have the test implementations of these proposals, which is part of the process where you should have this test. So, you can go and go to the test and see the different variations so that it covers the entire spectrum and you can understand how it works. So, there are many different ways, but I also see there is a bit of a drawback here at times when there is a qualifier already that's there and people start using it and the spec changes a bit but the plugin is not catching up with the specification. For example, decorators is one such example where <a href="/tags/typescript-libraries">TypeScript</a> has implemented a particular version of decorators, but the spec has changed from there a lot and there's some catch up that needs to happen. and Babel made it pretty clear that these are staged proposals so you should be pretty careful about how you are using it and not really like production-ready and things might change and break. So there is always the two-sided you know as the associated face of a coin like you have the pros and cons but definitely you could explore in many ways and following the proposal repo looking into issues will give you more insights.With that I will hand it back to Rick with my question on I think Rick covered most of it but I had this question in the pipeline that how do I contribute to <a href="/tags/tc39">TC39</a>? Like when I speak in a public forum this is the common question that I get asked to say that I have an idea or an idea for proposals and I want to take it to the committee or where is the entry point or how do I get started? Yeah so this is a this is also an interesting question. It depends on whether you're well it depends on a lot of things we kind of touched on a lot of these things throughout the panel. One of the most immediate ways and direct ways is if your company is already a member of <a href="/tags/tc39">TC39</a> then reach out to the people internally who are those delegates. We you know figure that out and then contribute that way. That's the most direct option or like it was mentioned previously convince your company to join ECMA which is very beneficial for both you know ECMA, <a href="/tags/tc39">TC39</a> to get more input from more constituencies and beneficial to the company because you get to help the language grow then you can contribute that way. There's also every proposal has its own GitHub repo that you can post to you can open issues you can read the <a href="/tags/documentation">documentation</a> there's for each proposal or at least the kind of standard format. This is not technically required but most proposals along side the specification diff that like actually changes the spec there's a big explainer. I know that but one of the proposals I work on Record and Tuple has a massive explainer that goes through in detail a lot of the <a href="/tags/creativity">design</a> decisions and if you're interested in contributing the first step is to read that explainer in full and then come up with your own ideas for like how it should work and then you can open issues. Lots of people open issues on those repositories to ask questions or to get clarification on certain parts of the <a href="/tags/creativity">design</a> or to suggest alternatives. There's a massive amount of issues on most proposals and I highly encourage everyone to engage in that because people will answer them. There are a lot of really smart people working on these proposals that talk to people all day for a job so it's certainly a way to engage with the <a href="/tags/community">community</a>. Outside of GitHub itself and outside of the proposals, in the more experimental land, there's our discourse which is our forum in a way. I'll put a link in the Discord as well for this. It's not Discord. It's discourse. It's es.discourse.group. It's a forum where there's a variety of topics that you can put <a href="/tags/tips">suggestions</a> for new features and talk about proposals and ask questions in a more detailed like you know forum style environment. That's kind of the majority of the ways. We are always looking for more constituencies to contribute because the web like <a href="/tags/javascript">JavaScript</a> specifically in the web which you know has <a href="/tags/javascript">JavaScript</a> and you know back end node all that stuff do you know is like a big platform. So to exclude anyone is incorrect.

So it's really important that we hear from as many people as possible. So it's really important that that effort is low friction.So that's about it. Yeah so we have run out of canned questions. So what I'm going to do is now improvise. Do we have in the Discord. Yes I was just going to answer one. Let's see the very first one I thought was a good question of implementation burden which I don't anybody can answer this. I'll just mention it out loud. Metin in the Discord asks could we have a main JS2 so we can have two JS versions? Is that a solution to our woes? Does anyone want to take that? Sure. That is definitely not a solution. This has been somewhat attempted in the past. Firefox used to ship like an actual, they used to ship two different kinds of <a href="/tags/javascript">JavaScript</a>. They used to ship the standard one we know of on the web and then a Mozilla-specific one. They had some extensions. So there's like syntax like for each and some stuff. And they had led and const many years before ES2015 did. It behaved a little differently. But the my understanding is that this made it really difficult for webpages because if let's say there's two versions of <a href="/tags/javascript">JavaScript</a>, the browser still have to ship both versions forever. And it can make it really difficult to share <a href="/tags/code">code</a> between those environments. Like, let's say I was jQuery. Could you use jQuery in both versions of <a href="/tags/javascript">JavaScript</a>? The only way for that to be the case is if jQuery either made two copies of itself, one for each, or if there was a backward compatible interoperable way to write jQuery. And so it kind of ends up that most things end up being whatever the interoperable form is. And it, you know, which means that you end up having just the same basic language that we do now, and you're still stuck and constrained by previous decisions.So the, there's a similar kind of, so the general response that I've heard is nobody wants to do versioning anymore. And similarly, when ES5 added strict mode, like a pragma, to kind of try and fix some things about the language. The fixes are good, everyone likes the improvements, but the general reaction inside <a href="/tags/tc39">TC39</a> is no more modes, no more pragmas that like doing it this way was, you know, not necessarily a mistake, but not also not something anybody wants to repeat. It sort of magnifies the number of permutations everyone has to deal with. And it makes the language more confusing and harder, you know, harder to build with in the long run. I don't know if anyone else has thoughts.

Go ahead. Just a comment on breaks, you know, you were talking about we don't like pragmas, UStrick was helpful, but it sort of like broke things in a way, it broke back and pat in a way. I think it was really interesting for me with <a href="/tags/tc39">TC39</a>, it like took me a while after I first started attending to get my head around something that Rick said, which is that it's everyone's programming language. Nobody's going to break a website from 1995. You may think it doesn't matter, but it may matter deeply to the small business owner who can't afford to have it remade. We're going to try to give continuity in a way that is unexpected. If you're used to being a software developer in an organization that would think, oh, well, all codes replaced on a five year arc anyways. You've heard people say that about software. But that's just not not the mental place. I've picked up a Super Nintendo and tried to replay old games every now and then. What if you wanted to look up a walkthrough to get through a hard part and that walkthrough was on a website that hasn't been updated in 25 years? It'd be really disappointing if that didn't work because somebody wanted some new browser feature. There's lots of ways, I think, to do what everyone's talking about and you have to figure out a reason for yourself why that helps you understand why it is in fact everyone's programming language and why you really don't want a bunch of, you know, a relatively tiny number of people in a room to make a decision that excludes something because what's to stop you from being excluded? I was just gonna say that, like, to not to follow up on this, to follow up, something else to think about, we mentioned a couple of times, is that <a href="/tags/javascript">JavaScript</a> is a live living standard. If somebody releases a new version of a language, like a new runtime, like Python or something, that breaks a lot of things, you can just not upgrade. I mean eventually you'll run out of <a href="/tags/automated-security">security</a> updates, but like, it's not as big of an impact, but if we break the web and everyone's chrome updates and now the website isn't working, that's an immediate negative, it's not something that you can opt out of. Or the nature of <a href="/tags/automated-security">security</a> on the web and the nature of <a href="/tags/automated-security">security</a> in the year 2021 means that you should not disable updates on your browser, like that's a very bad idea. So it's also a balance of that, of like, the implementation concerns of browsers, and how we want to deal with the <a href="/tags/ecosystem">ecosystem</a> and <a href="/tags/automated-security">security</a>, for the long term.

Hey Mith, I think you were going to say something. Yeah, I was trying to pick up another question on discord but it looks like we are right on time. You actually have five minutes left. So there are a few many questions on the group, so I will probably pick up a random one which we can quickly answer. What's it like to be a public associate with <a href="/tags/tc39">TC39</a>? Do you get pressured online to add someone's favorite feature or do you see people complaining about the language to you? Yeah. So it's a fun question. I would say it's not that we are being pressurized by people but a lot of people would probably ask us on, how do we get? So this so happens, right? Someone has a brilliant idea or all of us have folks who come to us, have ideas that, hey, I have an idea for a proposal and how do I get it in? That would be the basic question and there's no pressure as we said, it all works in consensus. It's not like we've been pressured by some company and we're doing it. So all of these committees are agreeing upon a feature and there is a lot of thought process put into it on why it matters and what it's trying to solve and is it really solving a real world problem or is it already being solved? Or a similar proposal was brought up many years ago and was dropped on for these reasons and it's not going to happen. So these kinds of things is one basically goes in and people do complain about the language and not only outside the committee, within the committee also. And that's an healthy argument to have, right? We don't just end it with complaints, but rather look into how we could make it better and try to find solutions to make it better. And that's what I feel and Jordan or Maggie or Rick if you have opinions, we can talk about this or there are many questions actually on the channel. I will say occasionally someone gets really passionately upset on a proposal. I've seen that a few times. I'm thinking of a particular commenter on Temporal who was very opposed at the beginning. Jordan remembers this incident I think. So sometimes people really do like apply a lot of pressure. For the most part people are very nice. It's usually an exception and it's usually on our online forums when we get someone who's not. One minute. There was a quick one probably I could end or have this talk here. They said do you have a juicy war story? What is the most mind-blowing or unexpected reason to refuse a proposal? I think Maggie was touching those parts with the Temporal so we will probably pick up the questions and answer it on the channel. Do you want to give ending notes Maggie or? I mean the most mind-blowing reason to refuse a proposal. So this wasn't someone on the committee to be fair. This was a random commenter on the internet but I did have someone tell me that Temporal was emotionally motivated and there was no real need for improvement for date in <a href="/tags/javascript">JavaScript</a>. That was I was like really? So but for the most part people are positive I want to emphasize that. I think we're signing off but we'll have in the discord.

So, on top of that, there's a fantastic series of blog posts written by Marja on the V8 team. I'll link this as well. Called understanding ECMAScript. It's written in four parts and goes in detail into how the spec is written and what the intricacies of the spec actually mean. So, I think that that's, like, a level up past reading the spec itself. Reading the spec itself from the perspective of someone who's definitely an expert in the specification and works on V8. That's a really good resource.Another thing, if you're a little bit more, like, <a href="/tags/code">code</a> oriented and want to just visualize how, like, the specification of, like, array prototype methods work. But in <a href="/tags/code">code</a> you can look at something like engine 262. Engine 262 is effectively it's an open source project written by a <a href="/tags/community">community</a> member that is essentially an implementation of <a href="/tags/javascript">JavaScript</a> in <a href="/tags/javascript">JavaScript</a> and it's pretty dang close to the specification. If you look at, for example, like V8 or Firefox <a href="/tags/code">code</a>, the <a href="/tags/code">code</a> that implements all the <a href="/tags/standards">standards</a> is not necessarily always it doesn't look the same as the spec. The spec is, like, the lawyer part. The implementation is, like, the way we actually, you know, the shovels, the way we get things done. Engine 262 likes to look like the lawyer part. So it's a really good way to step through a piece of <a href="/tags/code">code</a> and say, oh, this is how you would implement this if you wrote it in <a href="/tags/code">code</a>. So those are, like, some of the intro things of, like, what the deliverable itself looks like.But there's a lot of history in <a href="/tags/javascript">JavaScript</a>. And there's a lot of, like, it's live. It's always moving. And it's the most popular language on the planet. So one of the things that recently came out that I love sharing with people is actually this paper written by Alan Wersbrock and Brendan Eich called the history of <a href="/tags/javascript">JavaScript</a> for the first 20 years. And I'll link this as well. And it's a fantastic resource for the evolution of <a href="/tags/javascript">JavaScript</a>. Because unlike a language you might <a href="/tags/creativity">design</a> in, like, a language class or like a PL degree or, you know, just like from first principles, <a href="/tags/javascript">JavaScript</a> has a lot of legacy. And like Jordan mentioned, the web doesn't break. At least that's our goal. So in order to understand a lot of the decisions around the <a href="/tags/creativity">design</a> of <a href="/tags/javascript">JavaScript</a>, you have to understand kind of the entire history and, like, understand A to B to Z, what exactly happened and, like, why decisions were made. And it clarifies a lot of, like, how we think about standardization over time and, like, how we try to, like, put an umbrella over history in order to provide people a good language to use. I've got a couple more things. We've got if you're interested in how specifically operates, we have the how we work repo.

It operates this repo that kind of tries to document all of our processes as much as possible from, like, how we run plenary, which is, like, the actual discussions we have, how we, you know, document proposals, what they do, what stages, more detail about what the stages mean, stuff like that. That's a really good resource if you're just interested in the, like, more into the lawyer-y stuff.And then we mentioned this before is that the meeting notes are very important. When I first got started and I- like the day after I went to my very first <a href="/tags/tc39">TC39</a> meeting, the first thing I did was look up all the proposals I loved and then figure out on the agenda, which we also post, which I'll also post a link to, when it was talked about. And then I went through the notes and read the discussions. And I didn't read everything verbatim. There's a lot of notes. Some of the notes for <a href="/tags/tc39">TC39</a> discussions are like 40 pages long. But if you just isolate it to a single proposal, you can get a really good idea of what that <a href="/tags/panel-discussions">discussion</a> looks like. And there's an insane amount of <a href="/tags/panel-discussions">discussion</a> that happens across the entire spectrum of the language in terms of how features will interact with other features and how the implementation complexity of a feature might affect the <a href="/tags/creativity">design</a> choices that if you just look at the standard itself, you might not capture. So it's really important to capture that <a href="/tags/panel-discussions">discussion</a> itself as well. So that's a lot of links. I'll post all of these into just the Discord channel so that we can have links to them. But that's kind of like if you want to learn about standardization, the internet is the solution. And I will give you as many links as possible. So that's kind of that. I should pass it over to Himanth because I have a question for you, which is how do we test features before they release? Thank you, Bing.So how do we test features or rather use features before they're released? Well, there are many ways. First thing is most of the proposals will probably come up with Babel plugin or a polyfill. So do check out their repo if they have a polyfill or a Babel plugin. Well, it's not really part of the process, but most of the proposals which are polyfillable tend to have polyfills. And then when it hits stage three and when it's seeking for feedback from developers, it will normally be under a flag. It may be where it's implemented in a browser or node and likes. So I normally tend to use JSFlue, one of the node <a href="/tags/modules">modules</a> that will help you to fetch all the runtime engines, maybe like V8 or Spiderman team, Rhino, and V8 <a href="/tags/debug">debug</a> and likes. So I would fetch all of them and grab for harmony flags. That's where normally the features which are seeking for feedback will be implemented under the flag. I would run those engines with the harmony flag and try to experiment with it. And some of the proposals also have playgrounds like temporal or records and tutorials have good playgrounds where they've already polyfill the required things and they have good examples on how the <a href="/tags/code">code</a> works, what is the feature all about with good <a href="/tags/code">code</a> samples and you can go and try that and get an understanding. If you want to go a bit more deeper, you could probably open up the spec and see the pull request that went into for the specification changes and see what is the existing spec like and how this proposal is changing the existing spec. So, you will get some details on what are the changes that went into the feature.

Hi, everyone. We are all delegates of <a href="/tags/tc39">TC39</a>. And if you aren't familiar, <a href="/tags/tc39">TC39</a> is the <a href="/tags/standards">Standards</a> Committee that effectively makes your favorite programming language <a href="/tags/javascript">JavaScript</a>. Legally, we have to call it ECMAScript.I'm Meghan Johnson-Pint. I work for Microsoft. I am a PM on the <a href="/tags/azure">Azure</a> SDK team. I also have been an active participant in <a href="/tags/tc39">TC39</a> over the years. Most notably, I originally brought the temporal proposal. That's how I ended up involved. I was a maintainer on MomentJS, and we needed something different than that. The Moment team decided to get involved in <a href="/tags/tc39">TC39</a>.I'm going to have everyone do intros, and I'm going to have everyone say their favorite upcoming proposals. I already did my intro. I will note, because you can't push your own proposal, that I'm going to go with Records and Tuples. That's my favorite upcoming proposal. That does come from my history with DateTime. So many times, we needed immutable constructs. Let's see. Who will I go with next? Rick, do you want to go next? Yeah, sure.Like she said, my name is Rick Button. I work for Bloomberg in software infrastructure, specifically working on our <a href="/tags/javascript">JavaScript</a> stack. I've been with <a href="/tags/tc39">TC39</a> for about two years, I think. That sounds about right. I ended up involved in <a href="/tags/tc39">TC39</a> because of Rekord &amp; Tuples. My co-worker and co-champion, Robin Ricard, kind of came up with this Crackpot thing and worked internally on it for a little while, and then we joined forces to work on it. Yeah, and like she said, mentioning your own proposals is a bit of like wearing your favorite band's t-shirt at their concert. My favorite upcoming proposal is definitely probably pattern matching. I really am a fan of like the Lisp-y <a href="/tags/functional-programming">functional programming</a> language style expressiveness. So one day, it'll happen.

I'm very excited for it. I think next up is probably Hemant. Thank you, Rick. I'm Hemant. I work at Paypal as a member of the technical staff. And how did I get into <a href="/tags/tc39">TC39</a>? Well, I've been following it for a pretty long time, 2008, 2009, and had been pestering Jarden a lot. And at that point of time, when I joined Paypal, I was not able to make it to the committee because it was in-person and I was in a different time zone and all of that.And then I happen to move here a couple of years back and I got into the committee and I got awesome support, all of it from the committee members and super smart people. And today I'm working on a few proposals, like string.bidden.errorCaused, and arrayEquality, and likes. And I wanted to say, my favorite proposal was records and tuple. And the second one was pattern matching. But now both of them are card. And definitely temporal Maggie covered that too. So, I would probably go with this proposal, called partial applications, that probably not many of them would have heard, which will definitely make the <a href="/tags/functional-programming">functional programming</a> syntax a bit more interesting in <a href="/tags/javascript">JavaScript</a>. With that, I would like to tag Jordan.Sure. Hi, I'm Jordan. I work at Coinbase. I maintain hundreds of <a href="/tags/open-source">open-source</a> projects. And I've been on <a href="/tags/tc39">TC39</a> since 2014. It's been a long time. And I was an editor of the specification for about three years. So, let's see. My favorite proposal since... I won't mention the ones that have already been mentioned. And I won't mention my own. So, I think I really like do-expressions and async do-expressions. Those are two separate proposals. But I'm kind of lumping them together. I just...

There's a lot of places where it's convenient to use a few statements in expression position. And I'm looking forward to kind of the simplicity of being able to do that.Cool. So, we're going to be a little, like, unmoderated today. We're going to ask each other questions just for the fun of it. So, I will kick the first question off. The first question's going to go to Jordan. And it's a big one. And it's this why question. Why does standardizing <a href="/tags/javascript">JavaScript</a> matter? What's the process like? You know, how does a proposal happen? How do I know when a proposal's coming? How does this whole machine work, Jordan?Yeah. All right. Well, why does it matter? Well, standardizing anything matters, in the sense that it makes sure we're all doing stuff in the same way and we can all speak the same, you know, no pun intended, speak the same language about whatever is being standardized. So, <a href="/tags/javascript">JavaScript</a> has this additional wrinkle that it runs in the web browsers that we all use, like, all the time, you know, to do everything. So, it becomes really important that you can write a website in a way that everyone will be able to use the same. So, everything that gets standardized is one less thing you have to kind of worry about as you're deploying to an infinite number of devices that you don't control throughout the world.So, as far as what's the process like, that can vary widely. It can be fun. It can be torturous. It can be very pedantic. You know, I think it takes – there are times when it takes a special kind of personality to not run screaming from the room. And – but that said, I really enjoy myself. I think that the – trying – it has been very enlightening to consider lots of different perspectives and use cases beyond the ones I would normally have considered when trying to <a href="/tags/creativity">design</a> features for languages, and it has modified and kind of tempered my opinions about things a lot over the years. When I first showed up, I was kind of expecting to, like, come in and, like, hate a bunch of things, and it turns out that, like, when I understand the reasons why things are the way they are, that, you know, it's a lot. I can sort of move past it instead of just grumbling about something I don't like. As far as, so how does a proposal get finished, right, with the after ES2015 or ES6, we added a new stage process. So there's stage 0 through 4. The quick and dirty way I described them is stage 0 is, like, I have a crazy idea, stage 1 is maybe the idea is not so crazy, right. That's when the committee has said, like, yes, we want to spend more time looking into the problem, how do we solve whatever problem we're looking at? Stage 2 is when you kind of, we're pretty sure that the solution looks like this. So that's when the committee is basically saying we are, you know, pretty certain this is going to go into the language. We're pretty sure this is what the shape of the solution is going to look like.

And then we kind of iron out all the details inside stage 2, and then stage 3 is time for everyone to start shipping it and implementing it, and, you know, at that point usually only expect changes when you couldn't have possibly anticipated something sooner than that. the time you ship it and then stage 4 is, you know, sort of the, you know, mission accomplished banner is when you actually merge it into the specification and becomes official.And as far as how you know when proposals are coming, there's lots of places you can look, you can, you know, you can certainly read the notes for each meeting, which are long and very archaic, but are not archaic, obscure, but you can, you can read those which are published about 10 days after every meeting. But we also have the proposals repository on github dc39 slash proposals, and that's typically updated, like throughout the meeting, and so you can kind of browse the list of proposals at each stage. And each one will link to its own repository where you can ask questions or, you know, read about the proposal.Okay, well, so the next question, I'm actually going to ask Maggie back. How can a person make a business case for their organization to get involved with DC 39 and other <a href="/tags/web-standards">web standards</a>. Sure. So, there's a there's kind of an underlying question there, of course, which is, how does anyone get involved with DC 39 and <a href="/tags/web-standards">web standards</a>, and it's worth noting that officially to participate in the DC 39 process, you need to be with an ACMA member company so ACMA is this <a href="/tags/standards">standards</a> or international <a href="/tags/standards">standards</a> organization. It centers a lot of things, not just <a href="/tags/javascript">JavaScript</a>. There's a whole bunch of <a href="/tags/iot">IoT</a> <a href="/tags/standards">standards</a>, wearable <a href="/tags/standards">standards</a>, there's quite a lot of stuff in ACMA and to technically to participate in TC 39, you would be a delegate of a member organization. So, Microsoft is a member organization to TC 39, and there is a membership fee. So, what it comes down to is, if you want to be an official delegate, you need to get your organization to decide this is worth it for them. I think it's interesting, obviously, at Microsoft where we have like a browser, and <a href="/tags/typescript-libraries">TypeScript</a> and stuff, we have a pretty vested business case for involvement in TC 39. But a lot of organizations have gotten involved, and I think it comes down to finding the thing that really matters. You know, when I first brought Temporal, I didn't realize how much help I would get from Bloomberg, who had just joined ECMA. And the reality was that Bloomberg was feeling a really strong business need when you think about the kind of business that Bloomberg runs to have a great date time API. And so that was, I think, you know, one of the major drivers of them coming to the table, not that I want to speak for your company. But I think it's finding that place where your business sees a gap and really, you know, sees a need to advance, whether that's in the <a href="/tags/performance">performance</a> space, where there's APIs, that you think that that you're missing. I also think that there's a lot of there's an argument to be made for goodwill, for <a href="/tags/community">community</a> involvement for saying we want to be good <a href="/tags/community">community</a> players and something that we use so much. But the biggest thing is finding that case where you're like, you know, this is critical path to the product that we make and we can be better through the <a href="/tags/standards">standards</a> process.I guess the next question we'll go with, this one's going back to Jordan, is what are some of the challenges of standardizing the language in the long term, especially you're talking about the yearly spec updates, especially given the yearly spec updates. Yeah, I mean, so one of the bigger precepts that the committee has is don't break the web. The canonical example we always use is the Space Jam movie website from 95. I think that it is, it's very difficult to <a href="/tags/creativity">design</a> a good programming language anyway. And there's a lot of programming languages to look at for both good things and mistakes. And it is extra difficult when that <a href="/tags/creativity">design</a> is constrained by every decision you've made in the past, right? We can't just like make a new version of <a href="/tags/javascript">JavaScript</a>, we have to keep the web that we already have. So that's a really big <a href="/tags/developer-challenges">challenge</a>, and there's a lot of things that we decide to do, not because we would have done it if we were designing it from scratch, but because like, it is the most sensible evolution for the most sensible evolution from the current state of the language to the next place we want to take it. I think that the yearly spec updates have actually been really beneficial. Some years there's many things and some years there's very little things.

It's that are in it. It's more what I found most helpful from it is that we kind of treat the specification as a living standard now. The specification that renders on GitHub and on the TC39.es website, that's the latest version of the standard. The yearly snapshot is kind of not particularly useful anymore. It's necessary for the way ECMA operates, and it's necessary. Some <a href="/tags/tooling">tooling</a> and books and stuff like to refer to a specific edition year, but browsers don't implement features in chunks a year at a time, so there might be some browsers or engines that have ES2019 features but are missing an ES2016 feature. So, the year doesn't really help you too much. It's just kind of a historical note of when it finished the process.So, I think that the I think one of the bigger challenges is when do we say no? There's a lot of folks in the room in this ES39 meeting and they all have slightly different priorities and philosophies about things. Some people, you know, are very enthusiastic about adding things to the language, improving the language, right, and that's an admirable goal, but I think there's other folks who are more concerned about preventing something that we would think is a mistake in a few years that we then have to support for the next 50. You know, a phrase that I've heard over time a lot is the future is longer than the past. Basically, any decision that we ship in <a href="/tags/javascript">JavaScript</a> is permanent. And so, for myself, at least, I think that it's very important that we're cautious and that while it's great that we can have a, that we can move the things through the proposal process quickly when they seem to be the appropriate choice, I think that we have to kind of do that in a measured and careful way to make sure that we're not, you know, making a mistake we can't unmake.Okay, well, I think that was, so for the next question, I'm gonna ask Rick, what are some of your favorite resources to share with others who want to learn more about standardization? Yeah, okay, so this is a bit of a complex question, and I'll give you hopefully less of a complex answer, because standardization is this weird beast where it's not really programming in a sense. It's more like being a lawyer, but you have to have a background in programming first. So, it's a bit weird, and I'm going to mention a bunch of links that I'll post in the Q&amp;A Discord channel after we're done here, or after I'm done with answering this question, so don't feel like you have to write all this down, but there's a lot of resources. The benefit of us kind of working on the language that runs the web is that we put a lot of this information out on the web. So, I guess the first part is just the spec itself. The spec, just like Jordan mentioned, is kind of a live moving specification. It's just hosted on the internet. You can go to tc39.es. You can read the spec. It's written in English. It's surprisingly readable for the most part. If you ignore the nonsense that <a href="/tags/javascript">JavaScript</a> has accumulated over the years, it's surprisingly readable. It has <a href="/tags/documentation">documentation</a> for how the majority of it operates. And it's a really good, useful resource for how like what the end goal of standardization looks like. Because one of the first problems with standardization is, well, what do you actually do? At the end of the day, the various browser vendors ship <a href="/tags/code">code</a> that runs <a href="/tags/javascript">JavaScript</a>. But there's a bunch of steps in between there. And to visualize what that means and what the deliverable output is, is kind of weird.

JSNation Live

JSNation Live 2021

Panel Discussion: The Future of JavaScript

Hemanth HM

Jordan Harband

Maggie Johnson-Pint

Rick Button

JS Nation

I’m attending JSNation – the main JavaScript conference of the year. You may join me there for free with 10k other JS engineers and 40+ great speakers. Just follow this badge. 

#javascript

JSNation 2024

Vue.js Live Conference

I'm attending Vue.js Live 2024 – get your free remote ticket and join me there with 5k other Vue.js engineers and 15+ great speakers.

Vue.js Live 2024

C3 Dev Festival

Join me at C3 Dev Fest, a contemporary software engineering festival!

Register to win an all-paid trip to Amsterdam. Elevate your career with industry experts and workshops & rock 3 dance stages at the after-party!

C3 Dev Festival 2024

React Summit

I am attending the biggest #Reactjs conference remotely. You may get a limited free ticket (50% of talks, no workshops) and join me by clicking this badge.

#react #reactjs

React Summit 2024

TechLead Conference

I'm attending TechLead Conference 2024 – get your free remote ticket and join me there

TechLead Conference 2024

React Advanced

React Advanced Conference 2024

Productivity Conference

Productivity Conference 2024

JSNation US

I’m attending JSNation US. Join me there for free with 10k other JS engineers and 50+ great speakers. Just follow this badge.

Panel Discussion: The Future of JavaScript

Check out more articles and videos