All right, all right, people were going to get started with
usual, usual is a dear friend of mine and a T.C. 39 coacher, so please give
them a round of applause to get them started.
Okay, hi, welcome everyone to this talk, it's pretty early for me, but I hope
you're excited and energized for this talk.
Luca told me stole my team, but whatever, like yellow slides, that's kind of my
technique.
No, but yeah, thank you for being here, before we get into the actual subject matter,
I want to go over what's probably the most important thing here, a little bit about
me, here's me with the first G.S. spec, I don't know, something like that, I'm
usual, on the internet, you might find me at Ryzo Kuchen, whichever is easier to
pronounce, you might go with that in person, I am from India, from New Delhi, and I live in
Akorunia in Spain, it's one of the fun places, so check it out.
I love open source software, the open web, it has taught me everything that I know, and also
a badly designed video games that hurt my mental health permanently, but I work at EGALIA,
quick show of hands, how many of you know about EGALIA, wow, it's the best conference,
but for the rest of you, I'll go over what EGALIA is just a little bit, so we are an open
source consulting, that means that we work on open source software, exclusively as long
as we can at least, we are also a worker on cooperative, and we work across different projects
and various different ecosystems, these are anywhere from really low-level, Linux kernel stuff,
stuff in the Linux user space, G.S. streamer, multimedia, all the way to browsers, as you might
know, most important browser engines are entirely open source, so we work on Chromium and VETKit
primarily, and also on Compilers, so that includes JavaScript engines, LVM, and that brings me
to my area of work, which is programming language design that includes the assembly and JavaScript,
but I hope that's what we're interested in. So JavaScript, right? It's a weird language,
but hopefully the one that we love, even though it's not that easy to love, but
we have a lot of great talks today about different subjects about JavaScript, how to do x, y, and z
about JavaScript, but that sort of irks me a little bit because, you know, nobody asks how is
JavaScript, but okay, y, I mean, if we tried to dig a bit deeper into how is JavaScript,
maybe we wouldn't be where we are now, and it'd be a language that serves its core users
rather than hurt them mentally, but to get into like, why it is like that, I think we should
focus on like, what makes it evolve, right? Did you know that JavaScript is a standardized programming
language like C or C++, and unlike Rust? It's a good programming language that is standard,
that means that various different stakeholders come together to evolve it, but how does this happen,
even? So first of all, what is even a standard spotty? Have any of you ever participated in any
standard spotty? What's whoever? No, okay, a few people, but you know, do you remember this whole
fiasco about emojis? So why does like the Google emoji have cheese on the bottom? Like,
it's just cheese on the bun, but that sort of is the issue with standardization, right? Unicode
can standardize that you have to make a burger, but they can't make you make good burgers. So it might
be a very useless burger, but it is a burger, I guess I mean it's obvious that all of these are
burgers, but sometimes the lines can be a bit blurry, but this is how standardization works.
So we have all of these various standards organizations. You might know about what
we're doing about W3C, that standardized a lot of the web as we know it. Iso, which does things
like how tall your ceiling should be, and everything else, I mean it's very important, and that brings
us to Ekma. Ekma sounds difficult, I think it was like brand-night who said that it sounds like
a skin disease, but I promise you that it's less painful than that because Ekma is important actually.
But Unicode, we already talked about that, that's a standard organization that does useful work as
well, and so many other things, IFF might be popular among foster attendees, for instance. But
all of them strive to do basically the same thing, which is bring different people, different parties,
stakeholders, together to unify on a certain vision, and make things easier for everyone,
hopefully better as well. TC39 also is one of the more descriptive names that we have.
TC39 is the technical committee that defines the JavaScript language.
Quick question, does anyone know why it's TC39, like why 39? Why?
Yeah, the first 31 failed, this is a 38 failed, no. But it's the 39th, so that's why
there's TC39. But who is TC39? Like what makes up this abstract sounding entity,
you might realize that there's a few people that you like in there, there's regular delegates in
TC39, so these are different stakeholders, for example, implementers, these are people who build
different implementations that one JavaScript, so it could be your Apple, Google,
Mozilla, Microsoft, delegates, then there's different companies that build big JavaScript code bases,
it could be big web applications, it could be something more interesting than that, that includes
players like Sony and Bloomberg, then there's student bodies and non-profits, so various universities,
I don't know if ULB actually is a part of TC39, but definitely, yeah, no. So there's a few
different universities that we work with, students who are excited about JavaScript or professors
who have to tease the slangwage and want to make it better or bodies like the OpenJS Foundation
that represents different open source projects in the JavaScript space. Then there's invited experts,
now these are individual people who are invited to the committee for their expertise or, you know,
some area that they could help us standardize things in a way that fits the needs of users,
so usually it includes subject matter experts, let's say for example, that we're building a library
that does time zone handling, none of us know how to do time zone, so might as well include somebody
who has some idea of how time zones work. It's hard to find that person, but if we can, time zones,
but there could be community representatives, there's people who either are very influential
in certain parts of the community or are, you know, very aware of the needs of certain communities,
and it's very important to invite them so that we can get their perspective, and there's the
cast of everybody else, there's contributors who help us basically do everything editors who
look after the editorial health of these different specs that we publish, there's people who
review different things, and the community at large, I would like to believe that they're
apart of TC39, that said as we will go through the rest of my presentation, you'll realize that
it's basically my bit to get you all excited about TC39, so hopefully the community will play
better or bigger role in things moving forward, but let's see how that happens.
First of all, how does TC39 work? It might be boring if you already know, but this is very important
because unless you know at least vaguely how things progress, it's very hard to just go in
and try to contribute, because somebody else might have completely different context than you,
they might say, hey, thank you for your review, but this is very badly time, so how can you
optimize for you know, best engagement whenever you want to contribute with TC39?
First of all, if you take away one thing from this old talk, this would be it.
No decision in TC39 is ever voted on, we also don't force people to do certain things certain
way or go on sort of some technical criteria for doing certain things, rather we build consensus.
So everything that happens in the JS language needs to have consensus from the various stakeholders
that are there. So this is very important and this only works if you have these two things.
First of all, we need to have a diverse set of people in the committee. If the committee is just
you know people with essentially the same interest, there's no point of consensus, I mean they're
virtually aligned on everything. So it's very important to take these different sides of every argument,
the perspective of somebody who is an implementer, who is very focused on the technical details in
some aspects, then there's practitioners, people who actually write JavaScript and get a lot about
the ergonomics, there's people who are academics, for example, who are more interested in how
do I even teach my students, how do I do any of this? Secondly, it's important that any
objections that are made to anything is done in a way that is respectful to other people's work.
You can't just come in and say, I hate your work. Please stop doing this. Instead, you must
elaborate your concerns. You might have to say what would make you change your mind, for example.
And this is important because at the end of the day, no stakeholders should have more power than others.
Right? If your, you know, not in control of say an implementation, that doesn't mean that
your opinion on certain things matters less, it could mean that it, you know, is more important than,
you know, people who are so immersed in a certain area of work that they don't have the perspective
that you do. Most importantly, though, all the concerns must be rationed. You cannot just say,
I hate this feature because it looks weird. Like, you know, you might have, you might have to explain
your reasoning for why you object to certain things. So, yeah, that's how we build consensus.
This consensus is built in stages. So, we have a stage process. We'll go into this later,
but there's basically four different stages of maturity for everything that we do, which means that
at a certain stage, a certain kind of decision making might be more important than the other.
So, yeah, we'll go into that a bit more. But these are basically different steps in the evolution
of any proposal. So, we go from something very theoretical to something that exists out there on the web.
And, you know, I'll explain how that sort of materializes. We have different task groups that do
certain tasks. Now, obviously, T.C. 39 as a whole is responsible for certain things,
but a lot of like the technical dirty even responsibilities lie in individual task groups,
which tend to meet more often, more, you know, and discuss basically more technical matters.
These are T.C. 1, which is the sort of core, etymotry of specification that's virtually everyone
in T.C. 39, although maybe not, because certain people are only interested in a single task group
and not JavaScript writ large. So, you know, T.C. 32 is about internationalization. This is where
I've spent most of the last couple of years working T.C. 3 is all about security, security,
in certain special context where maybe you need something special compared to like regular browser.
Security model is, if you know, a lot of the security model of the browsers is very specific
towards browsers, then there's source maps, which is relatively new. We have an editor of the source
map spec, but there's already a source map spec right now. So, yeah, I hope you're excited about
that. And then finally, we have another new task group, which is for research on language
standardization. This is quite a bit more academic and if any of you are into that, then I
would implore you to check it out. There does all of this activity happen, you may ask,
primarily on GitHub, right? So, we have a GitHub T.C. 39 organization where there's a bunch of
these repositories, and as you might notice, one of our repositories is ECMA-262, which is
the JavaScript spec. So, everything that is the JavaScript language standardized and specified
is entirely in this repository. You can go and check out the different issues, you can maybe
fix a bug or just like, you know, open an issue and let people know what you think about certain
things, but be respectful. Then there is different like meta repositories, as you might see,
there's things for tracking different proposals, there's things for notes, but basically,
every single TC39 proposal that is ongoing at the moment is the repository here. So,
anything that you might want to express yourself about or get involved into is going to be on this
single organization. So, I hope that this is like, you know, the funnel that brings you into anything
you're interested in. Then we also have literally the ECMA-Script spec. It's on a website.
Here's the website, but, you know, if you search around, you'll find it. You can read through it,
if you'd like, and if you don't care about your sanity, but most importantly, there's different
parts of the spec where, you know, you can see exactly how the language has these different
semantics that actually play out when you write your code. So, that's the spec. When do we meet?
We have these big plenary meetings where everybody comes together and all the big movement happens.
So, this is the only place, for example, where a proposal may advance a stage that we talked about,
these stages, and these six meetings per year are either online or in person. Right now,
we have reached a fun cadence of three and three. So, three meetings are entirely online and three
meetings are in person with online participation, with each of them being in one of the continents,
either in the Americas, in Europe or in Asia. Then we have these more focused calls or different
groups that can meet more often. They talk about some specific areas that they're interested in,
and then there's more like administrative calls like the TG2 call like that does everything about
in nationalization. There is the editors group that meets every week or so to talk about their work.
There's outreach calls, every proposal might have their own poll. There's a call for educators,
for two makers. Basically, anyone who might have some important feedback to bring to us or,
some bone to pick can be found in one of these calls. And some of these are open to public
participation. So, if you're interested, then here's a way to get involved quite easily.
Now, let's talk about the next stage by stage process. So, first stage is stage 0. We start with
0 because we have to, we're programmers. The first stage is Stroperson, and I represent it with the
light bulb because it's just an idea. It could be something that you've struggled on a piece of paper.
It might be something that purely exists in your head. Most likely, it's an explainer document.
And an explainer document is basically a document preferably marked down that
explains kind of your idea, the motivation, something that exists sort of prior art, and
you know, how you're going to achieve something. But most importantly, it's an idea under
discussion and consideration, but it is not yet a proposal. It's at best heavily oversimplified proposal,
but it's not something that has actually been accepted at any level by the committee as, you know,
something legitimate. It might be just too early for that, or it might be a very unpopular idea,
or none of those, but like, that's what stage 0 is essentially. There's a lot of stage 0 proposals.
As you might see, some of them are just abandoned. Some of them are fun. I don't know.
If you're interested in any of these, I don't know. Maybe not the most productive set of proposals,
but we have do feel free to sort of put your effort behind these. Then we have stage 1,
which is a proposal. You might say they're all proposals. Yes, but this is where the proposal gets
real, right? Like, essentially what happened is you had a stage 0 proposal, you brought it to committee,
and the committee, by consensus, agreed that this is a problem, right? And this is the important
part here. By this stage, we are not talking about solutions yet, because it's probably unproductive
to talk about solutions at this point. The more important thing at this stage is the problem,
you know, the first thing that we have to agree upon is a problem statement that there is indeed an issue
in the language, and it needs to be changed somehow. And the solution is very much up to, you know,
where things sort of go after this. But finally things are starting to get serious. So,
this is where we start to devote actual time, either in committee or outside, but probably both,
and you also get a champion. Now, what is the champion? Is it somebody who takes a great
sword and fights people, kinder, online? But mostly it's like, you know, somebody who is on the
committee and is basically responsible for managing the lifetime of a proposal, right? It's somebody
who brings the proposal to the committee and says, hey, like, we need to get some work done here.
This is also where we start dealing with some demos, some polyfills, and where all the major
changes happen in any proposal. An example of this is signals, and if you use signals in your
applications or excited about signals, no, okay, a few of you. Like, signals is one of the ideal
stage one proposals, in my opinion, it's something that is vitally popular from what I understand
in the front end ecosystem at the very least, and it's something that we are starting to investigate
more recently in the committee. So, this is kind of how it looks not very important yet,
because as I told you, stage one means everything could change. So, don't get too attached,
is what I mean. Then there's another stage one proposal that's decimal. I don't have to explain
a lot about this proposal, and yeah, I mean, stage one proposals for the PLDR, there's a few of
these that we're working on type annotations might be popular, but basically are all of these things
that we're working on that we're actively exploring the problem space in trying to figure out
what works best. Then we come to stage two. I have a construction emerging for this, but we call it a
draft. This is where certain precise like syntactic and semantic details are starting to like,
you know, basically come into place. It's like a puzzle that is starting to come together.
This is the part where we lay down the actual spectacles. So, we start specifying things,
and as you might have realized this is where, you know, we have to define certain semantics
and API. These are not completed at this stage, but it is certainly something that starts
getting fleshed out. An important thing here is that TC39 expects at this stage that certain things
would be developed in the future. Now, there might be cases where things still fall apart,
after stage two, but it's not by design. Also, things at this stage are highly experimental.
It's not stage one, but still, a lot of the problem space is still getting explored. People are
on their computers typing seriously and trying to figure out what's the best solution for anything.
But most importantly, from what I said, this is the area where we're actually in solution territory.
Now, the only issue is that we still haven't unified on a single solution, and we're probably
exploring a bunch of different ideas to see what works best. An example of stage two proposal is
a syncontext. I have some examples for how a syncontext works, but that's not very important,
and I'm running behind on time. So, let's be quick, but a syncontext. And there's a stage
two proposal for extractors. So, you know, something you might be familiar from Rust, I believe.
N, after stage two comes, drum roll, stage 2.7. So, we have a stage 2.7. Why 2.7? I don't know,
because we're nerds, but why introduce a new stage? Because we realize that there's something
wrong with the life cycle of a proposal, which is that you are constantly working on these different
details in stage two, and then on stage three, as you will hear from me in a bit, you're supposed
to start implementing things, which means that there's a small window of time between those two
things happening, where the feature might be done, like whatever we were working on, but there's no
test. So, you can't actually start implementing it, and we started to be more mindful about these
things. So, we decided to put in a separate stage that hopefully doesn't take a lot of time,
but this is the stage where you literally stop making changes and start writing tests.
So, we call it the candidate stage, but essentially idea is that the details that we have done so far
are proved in principle, but still needs feedback from testers. So, we start writing extensive tests,
and yeah, make way for implementations. There's these different areas where you might feel like
getting involved. There's the test two six two repository. It's literally the conformance test
suite for this standard, the pre-white, and it's one of the more fun JavaScript projects in my opinion,
and yeah, do contribute, and you might feel like you know a little bit more about the weird
porcupine details of our language. And there's also this dashboard by our friend Canada Hong
about, you know, test two six two coverage in different engines and so on.
An example of stage 2.7 is a different evaluation. So, you can differ evaluating the proposal
until it's actually used. Another one is shadow realms. This has nothing to do with ugeo,
I think, but you know, I told you were nerds, but things are getting out of hand, but
there with me. So, yeah, shadow realms is real like it's a real object that's called shadow realms,
and I think that's the most interesting detail about it. Then there's math dot some precise.
We might not be able to get decimals, or at least quickly, but we can actually at least
precise the add numbers. So, that's the first. But yeah, so basically it allows you to do
better addition without losing some precision. Then there's stage 3. This is where things are
actually recommended. It recommended sorry for implementation, and we start getting feedback from
implementers and from actual developers. The most important thing though is that this is the point
where we stop, we take off our opinion hats, and try to listen to more feedback from people.
And yeah, things are tested. You can implement them in your engine, and things might be shipping
at this point, with or without a flag. I hope that this is a popular proposal. It's something that
I personally worked on, but one of our better stage 3 proposals is temporal. From what I hear,
it's now in Firefox nightly, so do check it out. And we have a talk later today about it.
I don't have to say much about temporal. I think this statistics says it all. It's
by far the most popular proposal in JavaScript. And yeah, I hope it really helps developers as much
as we want it to. But yeah, quick, example about temporal, you can do fun, sort of daytime
math things with it that were not really, I wouldn't say possible, but easy to do so far in
JavaScript, and all of these different operations, time zones, somehow work. Wow. And then there's
decorators. This way, we also something that you use in your code base already without even noticing
that this isn't yet, well, it is now, but it hasn't been for last 20 years or so, something that
was implemented in the language itself. But yeah, you can have, it's not exactly what people use
in their applications, but it's a bit more restrictive version of decorators. And then finally,
we have the final stage, which is stage 4. Everything is done. We have process all the feedback
that we got and we need to call the project finished. It might not be shipping everywhere yet,
but this is kind of the moment where we keep down our pens, add the version to the next addition
version of the spec and call it a day. An example of this is a rainbow for transfer, which allows
you to write code that could be optimized by the engine. Set methods, I have no idea why these
never existed so far, but now you can do actual stuff with sets. Wow, they're useful. Now,
and a bunch of different proposals that are, you know, by this time you might have noticed that
the proposals are getting continuously filtered down to the point where everything that ends up here
is more or less, you know, something that we all find useful in one way or another.
And then we have, you know, all these different tools, like Babylon's WC or TypeScript,
that implement even newer features in like every year, we introduce a new version to the spec.
So, yeah, the next addition will come out in June. Finally, I would like to help you get involved here.
I hope you were excited by what I talked about, but there's a few different ways that you can
contribute, even if you have no experience in standardization. Really, anyone who is somewhat
vaguely excited about JavaScript should be able to do any or all of these tasks. So, please
help out in any way you can and do reach out. Thanks.