Placeholder Image

Subtitles section Play video

  • >> Hello, everyone.

  • 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.

  • >> Actually, we have another slide here.

  • If you want to check that out, here's a QR code, and you can go to that directly.

  • I will leave that on for a second.

  • Thank you, Aki.

  • Moving on to the next question, and we have had this the last two years, which is on the

  • pattern-matching proposal.: I've not seen any movement on the pattern-matching proposal.

  • Is it in an idle state?

  • If it lands as a statement, what will be the heuristics to decide when using it or a chain

  • of if-else?

  • Do you think having pattern-matching as an expression would be more beneficial?

  • >> That's a big question.

  • I'm Cat and one of the co-champions and co-authors of the pattern-matching proposal.

  • The proposal has stalled right now.

  • These things take a lot of time right now.

  • Sometimes, what is hot right now - what is at right now, it's waiting to be proposed

  • for a stage 2.

  • As soon as I get lead to show up for a meeting and - get is ready for a stage 2.

  • As far as the statement versus expression thing, that's a much harder problem.

  • We have Dan, actually, proposed a really interesting solution to the statement and expression problem.

  • For those of you who don't know, like the pattern-matching proposal currently is only

  • a statement, so it doesn't allow you to directly assign from the pattern-matching theme because

  • it was it has ergonomics that are more spectacular to other things like if, and else, and that

  • stuff.

  • >> It's hard to evolve the grammar of JavaScript.

  • There's a lot of things in it already, and there are a lot of things that sort of happen

  • implicitly so, to sort of work through this, there are various different solutions, and

  • that's sort of why a lot of these proposals take time at TC39 because, for a big proposal

  • like pattern-matching, we need to consider a lot of different alternatives to work through

  • these kind of technical issues, and find something that's really going to be good again.

  • >> We have a second question about this from last year.

  • Leonard Koch asks what are your thoughts on reducing the capabilities of the pattern-matching

  • proposal expression to statement in favour of cohesion?

  • >> So, I guess I kind of answered this already, didn't I?

  • >> You might have.

  • Sorry.

  • >> I think I might have answered this already.

  • You know, the idea is I don't like the idea that it's a statement.

  • I want to get something out there because I would rather have a statement than no pattern-matching

  • at all, and my hope is that once we have it as a statement, we can use that as justification

  • to bring more conditionals into expressions, so that maybe we can start discussing, say,

  • bringing if-else into bringing an expression, and then the trouble it's like the semantics

  • in the language don't make it particularly easy to say what the result of a statement-like

  • thing will be if used in an expression position.

  • And kind of like there's one proposal that is out there answering those questions, and

  • I kind of wanted that proposal at least to start exploring that before giving us a solid

  • answer.

  • That's an expressions proposal, whether or not it's required to wrap it with "do" is

  • up to the future, but we need to answer the same problem regardless of these.

  • >> Next yes, moving right along into questions regarding language design.

  • We had a question from Marvin.

  • This is also from last year: are there any long-term goals?

  • What is the bigger picture for JavaScript in the next five years?

  • >> Hi, I'm Shu, I work at Bloomberg.

  • So, JavaScript is many things to many people, including all of you in the community here.

  • That is the same for us in committee.

  • It's many things to many of us in committee.

  • We have different personal visions and aesthetics to what we want the language to be, and perhaps

  • we are also constrained by what our companies would like the language to be for its use

  • case.

  • It is a committee language, so it's not a one-author language where it's much easier

  • to kind of exercise your singular vision for better or for worse.

  • So, the answer is it's really hard to say what the five-year picture, or what the big

  • picture of what JavaScript is right now.

  • It's we are trying to work out a consensus between the many different visions that people

  • bring to committee, and I want to - the usual response to this when you hear this is it's

  • going to be a mess, and it's going to be full of compromises, going to be full of things

  • that people don't like.

  • But I think in practice, JavaScript is eminently useful, it keeps getting more and more popular,

  • used basically everywhere on the front-end and the back-end.

  • We've done a decent job, and I would hope that we can do a better job the a bringing

  • more cohesion, but there's going to be no singular vision going forward.

  • It's going to be difficult to get that but I hope to have consensus on practicality,

  • and what is most important thing at the time.

  • >> Thank you.

  • The next question we have is about how transpiling impacts JavaScript, and specific questions

  • are foals: JavaScript has become the target of many compilers.

  • How does this fact influence your work on the language in general?

  • >> I work on Babel.

  • I think it is what it is being able to use features

  • before they're implemented, an opportunity for all in the community to work out involved,

  • testing them out in the early stages, although we warn against doing that in production,

  • and just being able to be a part of - you don't have to be on the committee, but being

  • able to be involved - yeah.

  • >> Thank you.

  • And moving on to the next one from Soran: when writing new features, where do you look

  • most for inspiration?

  • Other languages?

  • Which ones, in that case?

  • Or is it mostly driven by requests from the community?

  • >> Very quickly, again was the answer is many things to many people, but for me personally,

  • I've always very much wanted to bring new capabilities to the language on the web that

  • it could not do before, like what we have done with shared array buffers to bring shared

  • memory programming to the web, and as we hope to do soon, ...

  • >> I want to second what Shu said, but from my perspective, as somebody who represents

  • the Chrome team, we're interested in what makes programming on the web easier, and so

  • when we think about new features, we're like, what are people commonly doing?

  • What shows up popular - what is a popular pattern for writing websites that is hard

  • because of JavaScript today?

  • An example proposal which I kind of started but never really followed through on is something

  • called blocks where it's we want it to be easier for people to write web workers inline

  • in JavaScript because we think concurrency is important on the web.

  • Things like that is one motivating factor that at least one member of the committee

  • tries to use to govern this process.

  • >> Thank you for that answer, Dominic.

  • The next question is from Mark, with the new operations and features being added to JavaScript,

  • is there a risk that the language will have too cryptic a syntax for new developers.

  • Web development being approachable is a big boon.

  • >> I will try to answer this as quickly as possible.

  • We do this strongly with each proposal.

  • We have a notion of a syntax budget which simplifies the idea that there is only so

  • much syntax you can take before being overwhelmed in using a language, so we want that to be

  • comfortable.

  • We don't want to overshoot that, but we do want to make use of new syntax where it really

  • is worthwhile.

  • >> We will have a couple of quick back-and-forths.

  • >> Sometimes, adding just a little bit of new syntax can make programming easier.

  • Like a lot of programmers are exciting about the optional chaining proposal where you use

  • question mark dot.

  • Even if it is undefined, it still works.

  • Adding new syntax can make things easier to programme.

  • We consider this as a trade-off, not an absolute.

  • >> Thank you.

  • So thank you very much to everyone who is on the panel, and thank you all for being

  • such a wonderful audience.

  • As always, we are looking for different ways to help people participate in the process

  • and also help us get the best data.

  • One thing that we are doing right now is an experiment that's currently running.

  • I forgot that side was there.

  • We currently have an experiment running.

  • If you want to participate in it, here, this is very finicky, here is -- please feel free

  • to go to the URL and take the survey.

  • It will help us whether or not experimental data works for the committee process.

  • That's all for our panel.

  • Thank you so much, everyone.

  • [Applause].

  • Oh, one last thing: anyone who has further questions and didn't manage to get their questions

  • in, we will be in the corner over there taking more questions if you want to talk to us directly.

>> Hello, everyone.

Subtitles and vocabulary

Click the word to look it up Click the word to find further inforamtion about it