Panel Discussion: The Future of JavaScript

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.

I'm Meghan 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 MomentJS, and we needed something different than that. 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 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 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 Rekord & 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 functional programming language style expressiveness. So one day, it'll happen.

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. But legally, we have to call it ECMAScript. Fun fact. I'm Maggie Johnson-Pinn. 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. 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, you know, like push your own proposal, that I'm going to go with records and tuples as 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. 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 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, a bit of like wearing your favorite band's T-shirt at their concert.

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 TC39? 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 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... 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...

So, my favorite upcoming proposal is definitely, probably pattern matching. It's, 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 at PayPal as a member of technical staff and how did I get into TC39? Well, I have been following it for a pretty long time, 2008, 2009 and had been pestering Yarden 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 with 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.bdint or error caused and array equality and lakes. And I wanted to say my favorite proposal was records in QPL and the second one was pattern matching, but now both of them are covered and definitely temporal MAGI covered that too. 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 function programming syntax a bit more interesting in JavaScript. With that, I would like to tag Jordan.

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 JavaScript 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, 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 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 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, 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 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 DC 39 and web standards, 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 standards or international standards organization. It centers 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 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 TypeScript 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 performance 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 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 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 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 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 tooling 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 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 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&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 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 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 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 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, 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 it's an open source project written by a community member 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 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 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 for 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, 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 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 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 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 modules that will help you to fetch all the runtime engines, maybe like V8 or Spiderman team, Rhino, and V8 debug 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 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 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 code.

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 TypeScript 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 TC39? 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 TC39 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, TC39 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 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 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 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 JavaScript specifically in the web which you know has JavaScript 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 JavaScript. 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 JavaScript, the browser still have to ship both versions forever. And it can make it really difficult to share code between those environments. 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 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 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. 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 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 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 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 isn't working, that's an immediate negative, it's not something that you can opt out of. Or 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, 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 ecosystem and security, 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 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 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 JavaScript. 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.

Hi, I'm Jordan. I work at Coinbase. I maintained 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. I won't mention the ones that have already been mentioned and I won't mention my own. 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. I'm looking forward to the simplicity of being able to do that.

We're going to be a little 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? How does a proposal happen? How do I know when a proposal's coming? Like 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, 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 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 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 hate a bunch of things. And it turns out that, like, when I understand the reasons why things are the way they are, that 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 describe them as 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 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. It's 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 could 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 throughout the meeting. And so you can browse the list of proposals at each stage. And each one will link to its own repository where you can ask questions or read about the proposal.

OK, 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 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 ACMA member company. So ACMA is this standards or international standards organization. ACMA 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 ACMA. And 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 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. 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, one of the major drivers of them coming to the table. Not that I want to speak, Rick, for your company. But I think it's finding that place where your business sees a gap and really 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, this is critical paths to the product that we make, and we can be better through the standards process.

Awesome. 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 longterm, especially, you know, you were 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'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.

We can't just 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 it is the most sensible evolution from the current state of the language to the next place we wanna 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've 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, like 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 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 the CS39 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, 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. 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 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 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 gonna 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 this, 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, movie 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. You know, 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.

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 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 2.6.2. Engine 2.6.2 is effectively, it's an open-source project written by a community member slash TC39 Delegate, dev-snick, 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 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, 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 in the planet.

So one of the things that recently came out that I love sharing with people is actually this paper written by Alain Westbrock 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 a language class or like a PL degree or 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.

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 document proposals, what they do, like more detail about what the stages mean, stuff like that. So that's a really good resource if you're just interested in like more into the lawyery 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 also post 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.

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. If I understand, I should pass it over to Hemanth 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 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 JS Fu, one of the node modules that will help you to fetch all the runtime engines maybe like V8 or SpiderMonkey, Rhino and V8-T-Bug and likes. So I would fetch all of them and get up for a HarmonyFlags.

So I would fetch all of them and get up for a HarmonyFlags. That's where normally the features which are seeking for feedback will be implemented under the flag. I would run those engines with the HarmonyFlags and try to experiment with it. And some of the proposals also have playgrounds like Temporal or Rekords Incubatables 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 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 would be like and what are all the, 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 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 are trying to translate it to code. As Rick mentioned, there's a test, a 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 to the testing, 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 qualifier already that's there people start using it and the spec changes a bit but the plugin is not catching up with the specification. Or for example, decorators is one such example where TypeScript has implemented a particular version of decorators 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 are using it and not really production ready and things may change and break. So there is always the two-sided, as two-sided face of a coin. Like, you have the pros and cons but definitely 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 with TD39? 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 I have an idea for a proposal and I want to take it to the committee or where is the entry point? How do I get started? Yeah. So this is also an interesting question. If 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 TC39 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 ECMA, TC39 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, Rekord 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. You know, like 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 back-end 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.

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, do we have? 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. 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 an actual, 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 a Mozilla-specific one that had some extensions. So there's syntax for each and some stuff and they had like let and const many years before ES 2015 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 JavaScript, the browser still have 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, can you use jQuery? Could you use jQuery in both versions of JavaScript? The only way for it 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 ends 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 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 to build with in the long run. Can I add a comment on- I don't have any more thoughts, go ahead. Just to comment on breaks, you know, you were talking about, we don't like pragmas, use strict 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 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 are replaced on a five-year arc anyways, right? You've heard people say that about software, but that's just not, not the mental place. Just imagine, like, even if you were like, I don't know, I've picked up a, 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 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. Rick, you're muted. I apologize. I was just gonna 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. 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 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 that 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 an brilliant idea or all of us have folks who come to us have ideas and they say, 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 are 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 or was dropped on for these reasons and it's not gonna happen. So these kind 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. But 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 Dawden or Maggie you can read if you have opinions, people 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 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 world story? What is the most mind-blowing or unexpected reason to refuse a proposal? I think Maggie was testing those parts with the temporal. So we will probably pick up the questions and answer it on the channel. Do 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 commentator 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? So, but I, 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. You've got a great day. Take care. We'll see you next time. Bye.