JSNation Live 202139 min
Panel Discussion: The Future of JavaScript
Video
Hi, everyone. We are all delegates of TC39. And if you aren't familiar, TC39 is the standards committee that effectively makes your favorite programming language JavaScript. Legally, we have to call it ECMAScript. Fun fact. I'm Maggie Johnson-Pint. I work for Microsoft. I am a PM on the Azure SDK team. I also have been an active participant in TC39 over the years. Most notably, I originally brought the temporal proposal. That's how I ended up involved. I was a maintainer on Moment.js. And we needed something different than that. So the Moment team decided to get involved in TC39. I'm going to have everyone do intros. And I'm going to have everyone say their favorite upcoming proposal. So 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. It's my favorite upcoming proposal. That does come from my history with DateTime. So many times we needed immutable constructs. So let's see. Who will I go with next? Rick, do you want to go next? Yeah, sure. So like she said, my name is Rick Button. I work for Bloomberg in software infrastructure, specifically working on our JavaScript stack. I've been with TC39 for about two years, I think. That sounds about right. I ended up involved in TC39 because of record and tuples. My coworker 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. So my favorite upcoming proposal is definitely probably pattern matching. I really am a fan of like the Lispy functional programming language style expressiveness. So one day it will happen. I'm very excited for it. I think next up is probably Hemant. Thank you, Rick. I'm Hemant. I work with PayPal as a member of technical staff and how did I get into TC39? Well, I've been following it for a pretty long time, 2008, 2009, and had been pestering Jordan 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 happened to move here a couple of years back and I got into the committee and I got awesome support and all of it from the committee members and super smart people. And today I'm working on a few proposals like string.needint or error caused and array equality and likes. And I wanted to say my favorite proposal was records in tuple and the second one was pattern matching, but now both of them are card and definitely temporal Maggie covered that. So I would probably go with this proposal called partial applications that probably not many of them would have heard, which would definitely make the functional programming syntax a bit more interesting in JavaScript. With that, I would like to tag Jordan. Sure. Hi, I'm Jordan. I work at Coinbase. I maintain hundreds of open source projects and I've been on TC39 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 so 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. So I'm looking forward to kind of the simplicity of being able to do that. Yeah. Oh, 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 is going to go to Jordan and it's a big one. And it's this why question. Why does standardizing JavaScript matter? What's the process like? You know, how does a proposal happen? How do I know when a proposal is coming? Like how does this whole 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 to speak the same language about whatever is being standardized. So JavaScript 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, you know, 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. 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 design 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? After ES2015 or ES6, we added a new stage process. So there's stage zero through four. The quick and dirty way I described them is stage zero is like I have a crazy idea. Stage one 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 two 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 two. And then stage three is time for everyone to start shipping it and implementing it. And at that point, usually you only expect changes when you couldn't have possibly anticipated something sooner than the time you ship it. And then stage four is sort of the mission accomplished banner is when you actually merge it into the specification and it becomes official. And as far as how you know when proposals are coming, there's lots of places you can look. You can certainly read the notes for each meeting, which are long and very archaic, or not archaic, obscure. But you can read those which are published about 10 days after every meeting. But we also have the proposals repository on GitHub, GC39 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 TC39 and other web standards? Sure. So there's a there's kind of an underlying question there, of course, which is, how does anyone get involved with TC39 and web standards. And it's worth noting that officially to participate in the TC39 process, you need to be with an ECMA member company. So ECMA is this standards or international standards organization, it standardizes a lot of things, not just JavaScript, there's a whole bunch of IoT standards, wearable standards, there's quite a lot of stuff in ECMA. And to technically to participate in TC39, you would be a delegate of a member organization. So Microsoft is a member organization to TC39. 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 TypeScript and stuff, we have a pretty vested business case for involvement in TC39. 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 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 performance space, whether it's APIs that you think that you're missing. I also think that there's a lot of there's an argument to be made for goodwill, for community involvement for saying we want to be good community 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 standards process. I guess the next question will 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 know, 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 is it's very difficult to design 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 design is constrained by every decision you've made in the past, right? We can't just like, make a new version of JavaScript, we have to keep the web that we already have. So that's a really big challenge. 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 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 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. So the specification that renders on GitHub and on the TC39.es website, that's the latest version of the standard. And the yearly snapshot is kind of not particularly useful anymore. It's necessary for the way ECMA operates and it's necessary, some tooling and books and stuff like to refer to a specific edition year. But browsers don't actually 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, like, when it finished the process. So I think one of the bigger challenges is when do we say no? There's a lot of folks in the room in the TC39 meeting and they all have slightly different priorities and philosophies about things. Some people are very enthusiastic about adding things to the language, improving the language. 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 JavaScript 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 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 going to 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
&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. So the spec, just like Jordan mentioned, is kind of a live like moving specification. It's just hosted on the internet. So 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 all the variable hoisting and all the nonsense that JavaScript has accumulated over the years, it's surprisingly readable. It has documentation for how the majority of it operates. And it's a really good, useful resource for what the end goal of standardization looks like. Because one of the first problems with standardization is, well, what do you actually do? Because at the end of the day, various browser vendors ship code that runs JavaScript. 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. So on top of that, there's a fantastic series of blog posts written by Marcia on the V8 team. I'll link this as well. Called Understanding ECMAScript. It's written in four parts. And it goes in detail into how the spec is written and what the intricacies of the spec actually mean. So I think that's a level up past reading the spec itself, is 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, code oriented and want to just visualize how, like, the specification of, like, array prototype methods work. But in code, you can look at something like Engine 262. Engine 262 is effectively an open source project written by a community member slash TC39 delegate, DevSnick, that is essentially an implementation of JavaScript in JavaScript. And it's pretty dang close to the specification. If you look at, for example, like, V8 or Firefox code, the code that implements all of the standards 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 just step through a piece of code and say, oh, this is how you would implement this if you wrote it in code. 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 JavaScript, 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 JavaScript, the first 20 years. And I'll link this as well. And it's a fantastic resource for the evolution of JavaScript. Because unlike a language you might design in, like, you know, a language class or, like, a PL degree or, you know, just like from first principles, JavaScript 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 design of JavaScript, 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 good language to use. I've got a couple more things. We've got if you're interested in how TC39 specifically operates, we have the how we work repo. So TC39 operates this repo that kind of tries to document all of our processes as much as possible from, like, how we run plenary and which is, like, the actual discussions we have, how we, you know, document proposals, what they do, what stages what, like, more detail about what the stages mean, stuff like that. So 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 TC39 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 TC39 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 discussion looks like. And there's an insane amount of discussion 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 design choices that if you just look at the standard itself, you might not capture. So it's really important to capture that discussion itself as well. So that's a lot of links. I'll post all of these in the Discord channel so that we can, like, 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. If I understand, I should pass it over to Himant to ask, because I have a question for you, which is, how do we test features before they release? Thank you, Ben. So how do we test features or rather use features before they're released? There are many ways. First thing is most of the proposals will probably come up with a 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, which may be where it's implemented in a browser or Node and likes. So I normally tend to use JSFluke, one of the modules that will help you to fetch all the runtime engines, maybe like V8 or Spiderman, Rhino and V8TBurg 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 write, 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 polyfilled the required things and they have good examples on how the code works, what is the feature all about with good code 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. So if not, you're not in a state to just use it and test it. You will get an idea of what the feature will be like and what are all the probably syntax or the changes that this proposal is bringing. So that's one of the ways that you can handle it. The other way is you go and read the spec and try to analyze. You might not really 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 code. As Vic mentioned, there's test 262, which would have the test implementations of these proposals, which is part of the process where you should have these tests. So you can go and go to the test and see the different variations so that it covers the entire spectrum. 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 quality 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 TypeScript has implemented a particular version of decorator, but the spec has changed from there a lot. And there is some catch up that needs to happen. And Babel made it pretty clear that, hey, these are staged proposals, so you should be pretty careful about how you're using it and not really production ready and things might change and break. So there is always the two-sided, as the associated face of the 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 on the pipeline that, how do I contribute to TG39? 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 a proposal 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 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 TG39, then reach out to the people internally who are those delegates. We 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 ECMA, TG39 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 documentation. For each proposal, at least the kind of standard format, this is not technically required, but most proposals alongside the specification diff that like actually changes the spec, there's a big explainer. I know that one of the proposals I work on, Record and Tuple, has a massive explainer that goes through in detail a lot of the design 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 design 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 community. 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 suggestions for new features and talk about proposals and ask questions in a more detailed 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 JavaScript specifically and the web, which has JavaScript and backend, Node, all that stuff, Deno, 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. 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 mention 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. Mitten 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, like, they used to ship two different kinds of JavaScript. They used to ship the standard one that we know of on the web and then, like, a Mozilla specific one that had some extensions. So there's, like, syntax, like, for each and some stuff. And they had, like, let and const many years before ES2015 did. It behaved a little differently. But my understanding is that this made it really difficult for web pages because if, say, there's two versions of JavaScript, the browser still has to ship both versions forever. And it can make it really difficult to share code between those environments. If I write, like, let's say I was jQuery, could you use jQuery in both versions of JavaScript? 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 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 TC39 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. Can I add a comment on... 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, use strict was helpful, but sort of like broke things in a way, broke back and pat in a way. I think it was really interesting for me with TC39. 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 gonna 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. Right? Like we're gonna 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. Right? You've heard people say that about software. But that's just not the mental place that anybody's in. Well, just imagine, like, even if you were like, I don't know, I've picked up, you know, 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. You know, it'd be really disappointing if that didn't work because somebody wanted some new browser feature. You know, there's lots of ways, I think, to do what everyone's talking about and kind of 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? Right? Rick, you're muted. I apologize. I was just going to say that, like, not to follow up on this, to follow up, something else to think about, we mentioned it a couple of times, is that JavaScript 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 security 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's not working, that's an immediate negative. It's not something that you can opt out of. Or like the nature of security on the web and the nature of security in the year 2021 means that you should not disable updates on your browser. 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 ecosystem and security for the long term. Hemant, 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. Oh, is it? Okay. 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 TC39? 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. It 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 on 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's a lot of thought process put into it and 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 what 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, you can talk about this. If you have any questions, I can be 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 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. Yes. 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 testing those facts with the Temporal. So we'll probably pick up the questions and answer it on the channel. You want to give any notes, Maggie or Rick? 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 JavaScript. That was I was like, really? 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. All right, we will see everyone in Discord and it was awesome to be able to chat.
&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. So the spec, just like Jordan mentioned, is kind of a live like moving specification. It's just hosted on the internet. So 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 all the variable hoisting and all the nonsense that JavaScript has accumulated over the years, it's surprisingly readable. It has documentation for how the majority of it operates. And it's a really good, useful resource for what the end goal of standardization looks like. Because one of the first problems with standardization is, well, what do you actually do? Because at the end of the day, various browser vendors ship code that runs JavaScript. 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. So on top of that, there's a fantastic series of blog posts written by Marcia on the V8 team. I'll link this as well. Called Understanding ECMAScript. It's written in four parts. And it goes in detail into how the spec is written and what the intricacies of the spec actually mean. So I think that's a level up past reading the spec itself, is 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, code oriented and want to just visualize how, like, the specification of, like, array prototype methods work. But in code, you can look at something like Engine 262. Engine 262 is effectively an open source project written by a community member slash TC39 delegate, DevSnick, that is essentially an implementation of JavaScript in JavaScript. And it's pretty dang close to the specification. If you look at, for example, like, V8 or Firefox code, the code that implements all of the standards 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 just step through a piece of code and say, oh, this is how you would implement this if you wrote it in code. 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 JavaScript, 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 JavaScript, the first 20 years. And I'll link this as well. And it's a fantastic resource for the evolution of JavaScript. Because unlike a language you might design in, like, you know, a language class or, like, a PL degree or, you know, just like from first principles, JavaScript 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 design of JavaScript, 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 good language to use. I've got a couple more things. We've got if you're interested in how TC39 specifically operates, we have the how we work repo. So TC39 operates this repo that kind of tries to document all of our processes as much as possible from, like, how we run plenary and which is, like, the actual discussions we have, how we, you know, document proposals, what they do, what stages what, like, more detail about what the stages mean, stuff like that. So 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 TC39 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 TC39 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 discussion looks like. And there's an insane amount of discussion 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 design choices that if you just look at the standard itself, you might not capture. So it's really important to capture that discussion itself as well. So that's a lot of links. I'll post all of these in the Discord channel so that we can, like, 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. If I understand, I should pass it over to Himant to ask, because I have a question for you, which is, how do we test features before they release? Thank you, Ben. So how do we test features or rather use features before they're released? There are many ways. First thing is most of the proposals will probably come up with a 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, which may be where it's implemented in a browser or Node and likes. So I normally tend to use JSFluke, one of the modules that will help you to fetch all the runtime engines, maybe like V8 or Spiderman, Rhino and V8TBurg 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 write, 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 polyfilled the required things and they have good examples on how the code works, what is the feature all about with good code 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. So if not, you're not in a state to just use it and test it. You will get an idea of what the feature will be like and what are all the probably syntax or the changes that this proposal is bringing. So that's one of the ways that you can handle it. The other way is you go and read the spec and try to analyze. You might not really 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 code. As Vic mentioned, there's test 262, which would have the test implementations of these proposals, which is part of the process where you should have these tests. So you can go and go to the test and see the different variations so that it covers the entire spectrum. 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 quality 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 TypeScript has implemented a particular version of decorator, but the spec has changed from there a lot. And there is some catch up that needs to happen. And Babel made it pretty clear that, hey, these are staged proposals, so you should be pretty careful about how you're using it and not really production ready and things might change and break. So there is always the two-sided, as the associated face of the 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 on the pipeline that, how do I contribute to TG39? 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 a proposal 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 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 TG39, then reach out to the people internally who are those delegates. We 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 ECMA, TG39 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 documentation. For each proposal, at least the kind of standard format, this is not technically required, but most proposals alongside the specification diff that like actually changes the spec, there's a big explainer. I know that one of the proposals I work on, Record and Tuple, has a massive explainer that goes through in detail a lot of the design 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 design 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 community. 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 suggestions for new features and talk about proposals and ask questions in a more detailed 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 JavaScript specifically and the web, which has JavaScript and backend, Node, all that stuff, Deno, 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. 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 mention 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. Mitten 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, like, they used to ship two different kinds of JavaScript. They used to ship the standard one that we know of on the web and then, like, a Mozilla specific one that had some extensions. So there's, like, syntax, like, for each and some stuff. And they had, like, let and const many years before ES2015 did. It behaved a little differently. But my understanding is that this made it really difficult for web pages because if, say, there's two versions of JavaScript, the browser still has to ship both versions forever. And it can make it really difficult to share code between those environments. If I write, like, let's say I was jQuery, could you use jQuery in both versions of JavaScript? 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 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 TC39 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. Can I add a comment on... 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, use strict was helpful, but sort of like broke things in a way, broke back and pat in a way. I think it was really interesting for me with TC39. 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 gonna 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. Right? Like we're gonna 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. Right? You've heard people say that about software. But that's just not the mental place that anybody's in. Well, just imagine, like, even if you were like, I don't know, I've picked up, you know, 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. You know, it'd be really disappointing if that didn't work because somebody wanted some new browser feature. You know, there's lots of ways, I think, to do what everyone's talking about and kind of 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? Right? Rick, you're muted. I apologize. I was just going to say that, like, not to follow up on this, to follow up, something else to think about, we mentioned it a couple of times, is that JavaScript 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 security 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's not working, that's an immediate negative. It's not something that you can opt out of. Or like the nature of security on the web and the nature of security in the year 2021 means that you should not disable updates on your browser. 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 ecosystem and security for the long term. Hemant, 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. Oh, is it? Okay. 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 TC39? 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. It 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 on 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's a lot of thought process put into it and 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 what 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, you can talk about this. If you have any questions, I can be 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 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. Yes. 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 testing those facts with the Temporal. So we'll probably pick up the questions and answer it on the channel. You want to give any notes, Maggie or Rick? 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 JavaScript. That was I was like, really? 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. All right, we will see everyone in Discord and it was awesome to be able to chat.