Welcome to the third and final, for the time being, TC39 panel we are doing at JSConf.

It's always a pleasure to come back.

We will introduce ourselves as we speak.

We collected your questions in the last couple of weeks.

A little bit differently, we are going to ask questions from the past years, so, that's

how the panel's going to work.

Let's give a round of applause for the panel members.

[Applause].

As we get started, not everyone knows how the committee works or what the committee

is.

There was a question that was asked in person at one of our prep events that seemed quite

obvious, but it is a great question to start with: what is the organisation behind TC39

in ? >> Hi, I'm Aki, part of the chair group for

TC39.

I work for PayPal in Braintree.

TC39 is the 39th technical committee by the name of a committee called Ecma International,

a standards body, like ISO, or that sort of thing, and they publish the standard that

we work on as a committee.

That's the organisation behind TC39.

The committee itself is made up of people who are sent by member organisations that

are companies and non-profits who are part of Ecma.

We are considered delegates.

We either work for or are associated with these companies that are part of Ecma International.

We work together and collaborate on what goes into the spec, and how we are going to be

able to make improvements and changes, and support all these different ways that JavaScript

is used.

>> Thank you, Aki.

And the next question that we are going to do to set up the stage what TC 39 is and does

is how does a proposal move through the committee.

We have Jase here on stage who did a wonderful talk about his Rust engine in JavaScript,

and he's been doing more work with the TC39, specifically, he's been getting a proposal

through called All Settled.

Can you tell us about getting a proposal through such a committee?

>> Yeah, I was quite lucky to meet a lot of people on the committee last year in London.

I felt a lot started off with a conversation, and talking to various members of the committee,

if there was an appetite for such a proposal.

It turns out there was.

That was a good thing.

Daniel, he has been helpful in putting me in contact with the right people.

Not only that, but people who come from different backgrounds as well.

That really helped.

It started off by a "straw person proposal" which is a state zero which is a GIT repo

with identifying the problem space.

Then we managed to get a champion here, Matthias, V8 - and stage one is identifying what is

the problem here?

What is the limitation and you and how we can fix it.

It's not too important to have a solution at this point.

We managed to craft something up that worked.

We had a small proposal that went through - Matthias championed it.

For stage 2, myself and Rob from Bloomberg both worked together on some of the specification,

and also getting more ideas from people as well.

Also, another good thing is after stage 1, we had implementation from Babel which is

really good which helps as well when you get feedback.

Stage 3 is getting even more feedback and thinking about a candidate release, and luckily,

I don't think there were too many sort of rejections or limitations, and most people

seemed happy with it, and very recently, we made stage 3 as well, and so now, I think

it's just getting some implementations in browsers, and people can try it in Chrome

and Canary, and nightly.

Yes, hopefully stage 4.

>> You made this proposal not as a member of the committee but as an independent contributor,

right?

>> Yes, absolutely.

I was become at the BBC at the time.

It was a limitation for me as a JavaScript developer, and I thought if it's a limitation

for me, how many other people have this limitation?

One of those ways of working that out was going to npm seeing how many people download

these packages, others languages have this natively.

Can we do it in JavaScript?

Everyone here was friendly.

I had a conversation with members of the panel, and they were very happy to champion it, and

we went from there.

>> And I'm going to ask you to introduce yourself?

>> Yes, Jason Williams, software engineer at Bloomberg.

>> So, another question that we get sometimes is we've got this whole proposal structure,

but how do we know it's implemented correctly in browsers?

What is going on there?

I'm going to hand this over to Valerie, and, if you could introduce yourself, and how we

do that?

>> I'm an open-web engineer.

I'm also the editor - the extension to JavaScript called Ecma 402, the object that does pluralisation

and daytime formatting.

I help to maintain the test 262 test suite which is ECMAScript implementations.

The test suite is about 35,000 tests which test the individual tests, which test JavaScript.

Each test is a test file which has some metadata about what line it tests in ECMAScript itself.

Each test is run twice.

There are really 70,000 tests, once in strict and this is non-strict mode.

This report is showing how well the tests are doing on all of the four four JavaScript

engines, and the tests are each in individual tests files, so this is a directory structure

which shows the test structure that you can find, and, if you want to look at the source,

you can drill down and look at individual tests and whether or not they're passing,

and see the source code on the page of this website.

Or you can go to our GitHub, TC39/test 2662, and to get a standard in ECMAScript or a new

proposal in Ecma script, the last test is to add to test 662 as well as the browser

implementation.

There are tests beak contributed, and all the browsers can make sure they're in compliance

and passing the same tests.

It's a fun project.

[Applause].

>> Thank you, Valerie.

>> If I could add to that.

This is actually really an awesome resource.

Jason talked about implementing a JavaScript engine, but for our major JavaScript engines

having something like this to be able to say very easily when are we not being spec-conformant

is such an immense resource.

>> And can you introduce yourself?

>> Oh, yes, I'm Ross Kersling and I work at PlayStation on our WebKit team.

>> Thank you.

So, this sort of rounds off our introduction to how TC39 works, and we're going to be moving

on with community questions that you folks asked, and we will start with one from last

year, asked by Sam Basson.

He asked, "I notice the committee's very heavily dominated by Americans and American companies,

particularly Google.

Do you have any plans to become more representative of the world, and only give certain companies

so much power?"

>> We're looking at how individual companies and specifically individual spaces where we

get together in person are impacting those contributions, and Ecma International, which

is the organisation we're part of, in fact, is currently put an effort into helping us

find a way to be more inclusive internationally in future years.

The 2019 meetings are already scheduled, but 2020 is being scheduled right now, and we

are going to work on finding a way of being more inclusive.

>> Thank you.

That was a nice answer.

>> Hi, I'm Daniel Aaronberg, I work in our compiler's team.

I think there is a real issue of this particular kind of bias, that was identified, but I just

also want to point out there is heavy European involvement in the development of the JavaScript

specification, both from people in Munich V8 office, V8 from Bloomberg, and my company

based in Spain, and several others also.

We can build on that success, of course.

Julia based in Germany.

>> I'm based in Germany and Berlin, so, if you have any complaints, you know where to

find me!

Thanks for that answer.

Moving along into more specific questions about the standard, we have had several questions

about how long it takes to standardise things and when do things come out?

Like how long does it take for a proposal to go from stage zero to stage four?

>> I will take that one.

It can take a very long time.

The simple answer is years.

If you were to essentially - essentially, you wouldn't really expecting to through our

staging process more than one per meeting, and we do meet every other month, but, you

know, there's a lot to do in that time frame.

Implementing in Babel may take time, for instance.

The problem space you're addressing might be quite clear but the solution may not be.

Maybe you need to revise that ultimate times.

Decorators might be a great example.

Finally, at the end of it all, before we can say that we are all said and done, we need

this to be implemented - and shipping - in at least two of the major engines, and you,

unless you want to implement that yourself, might not have control over that time frame.

It can take a very lock time, and discussions can get very heated, and so unless you have

a very simple, very uncontroversial proposal, it will probably take on the order of years.

>> The next question we have is about when are we going to get a standard library for

JavaScript?

>> So, from the way I see it, we already have a standard library in JavaScript.

We have a bunch of functions, map, JSON, array, a map set.

JavaScript has a pretty - well, I was going to say a pretty big standard library but that's

not true.

That's what this question is really getting at, is can we have a bigger and more standard

things in the library for JavaScript?

Should we put the standard library in modules instead of where we are currently putting

it which is in globals?

And these are pretty interesting questions, and I'm definitely supportive of exploring

them.

I've been working on them myself partially from the website.

I am Dominic from the Chrome Team at Google.

Thank you.

And I want to mention our colleagues at Apple have focused, adding these new standard library

features as built-in modules rather than built-in globals.

>> We're looking into several concrete proposals in TC39 about features to add to the standard

library.

You heard in Tara's talk earlier today about recent additions like object from entries,

and there are other things that we are considering putting in maybe built-in modules, or maybe

in the traditional way as properties of objects that are connected to the global.

We're looking into Temporal which is a date-time library which could make it so that you don't

need to use moment, looking into possibly new ID standard library, or a library for

iterator helper methods, as well as methods on set and math.

I think we are missing a bunch of things that would be useful to have in the standard library,

so it would be great to have more help from contributors about this.

>> Yes, I want to mention that some of these library-type features have been some of the

most successful proposals in getting through the process more quickly, so I mentioned that

features can take years, but we've also had years that take six months or eight months,

because they're kind of just, oh, yes, everybody agrees we should have a finally method on

promise, that kind of thing.

When we talk about the JavaScript standard library, it's important to look at things

that are available across the ecosystem and that ship with JavaScript run times everywhere,

and that include things like URL and text browser which are in Node and other run times

if they wish to implement them.

There are a bunch of examples like that.

>> You will hear more about the integration of URL and texting coder and browser web API

s in a talk later today.

We are trying to break down the barriers of different standards groups and make sure we

can all work together to build a good JavaScript-centred library.

[Applause].

>> Thank you, Dominic and Dan.

Moving on to our next question.

we have a question that's been given to us anonymously, asking: often we are having discussion

that are related to proposals and larger questions than TC39.

Yet Discuss is not being used.

Is there any plan to improve this?

>> Funny you should mention!

We are currently working on having a new discourse instance.

It gives us an opportunity to be able to figure out what people really are talking about so

that delegates who have limited time - and we also have day jobs, we do this in addition

- can really engage with what the community wants to talk about, and it will give us the

ability to have those conversations in public, and hopefully be less of a black box to people,

because we really do want to engage with people.

It's just hard to find each other when what we talk about can be so esoteric.