Technical Committee 39 Process

[00:00:00]
>> Maximiliano Firtman: Talking about the process before actually seeing some code. The TC, the Technical Committee process to create a new version of JavaScript or ECMAScript, works like this. Anyone, even us, we can go and propose something new for the language. Let's say we want something new, okay? We want the new conditional.

[00:00:23]
I don't like the if, I wanna change it, okay? So you say conditional. Instead of if, it should say conditional and then the expression and then whatever. I don't like curly braces, okay? I wanna change curly braces with something else, angle brackets, okay? You can propose the change.

[00:00:44]
Okay, but every proposal goes through a process. Your proposal, our proposal, will go to Stage-0, known as Strawperson. That is, yeah, it's a proposal that someone has just published. That doesn't mean that someone will take it seriously, okay? But it's there, it's a proposal, we can go, we fill a form.

[00:01:07]
Typically we publish a document on GitHub or somewhere explaining what we want to do. What is our proposal, what's the reason for the proposal, so why this is important for the language. And then someone will analyze that. If it goes to a Stage-1, it means that someone said, okay, let's put it into consideration in the technical committee to see if it makes sense or not.

[00:01:37]
Then there is a Stage-2 where it says, okay, it may work, let's create a draft. In this case, they create a draft of the spec, how this is gonna work. So then for example, browsers can give feedback such as, no, we cannot do that. We cannot implement that because of x and y.

[00:02:03]
This year, actually 2024, they created a new stage, but it seems weird, at least the number they have used is 2.7, that's new. There is a long discussion in a thread explaining why 7, okay? But it's because it's closer to 3 than 0.5, okay? It says approved, which means that here is no browser or no one that says, no, you know what?

[00:02:36]
We are not going to do that. Everyone said, okay, we can do this, okay? In this case it's approved. And then we have a Stage-3 where it becomes a candidate. That means that everyone agreed that we are going to do that at some point in the future, we can do that.

[00:02:53]
Every browser said, okay, we have green light. So, they create a candidate, they start making some tests. So they create a test suite, so we can run tests and see if the feature is working properly on every browser and so on. And finally, we have a Stage-4 that is complete and ready for the next version of ECMAScript, okay?

[00:03:18]
And actually, typically it's around June of every year. They collect all the Stage-4 proposals and they say, okay, this is ES2024, this is ES2025. So ES2025 is gonna be all the proposals that are still on Stage-4 at that moment. If we have one proposal in Stage-3, it will have to wait for the next year or maybe more years.

[00:03:50]
Does that make sense? So that's how it works. Something really important here is that back wire compatibility is always forced. That's something that is not happening in other languages, okay? So in other languages, maybe PHP 8 is actually making some PHP 7 incompatible. So you actually need to go and change your code.

[00:04:16]
In ECMAScript, every code that you're running that was written 20 years ago should still work, okay? So that's why sometimes we are not changing old stuff, the old stuff is still there. We have new ways with new keywords, maybe. For example, the most famous one is var versus let to create variables.

[00:04:41]
Let is not replacing var, it's just another way to create variables. We'll get into that in a second with a recap, but that's a good example of backward compatibility. There were a lot of people saying, hey, why didn't they change how var works? Why did they create a new keyword to create variables?

[00:05:01]
Because var was actually pretty good, right? Var, variable, okay, simple. So, well, they did that because if there is a new behavior, they need to use a new keyword for backward compatibility, okay? Makes sense? And that means that most changes are just sugar syntax from the previous version, what is that?

[00:05:24]
A different syntax that can be emulated somehow into previous versions as well.