>> Am I on?
Nice.
Hi, everyone.
I hope you're having a wonderful JSConf.
I would like to introduce the lovely members
of the TC39 who are joining us today to answer
questions.
It would be great if you could each introduce
yourselves and mention who you're representing
on the TC TC.
>> I work on V8 at Google.
>> I'm Aki, and I work at PayPal.
I work for Google and one of the core contributors
to Babel.
>> I'm Keith, and I work for GitHub.
>> I work at Google.
>> I'm Lynn Clark, I work at Mozilla.
>> ... work at blood glucose berg.
>> Also at Mozilla.
>> I'm Leo, I work at Buku and ... .
>> Now, we've got a lot of really task people
representing a diverse number of companies
and groups, but, in fact, there are more people
here.
They're among you.
We have a number of TC39 members who are not
on stage.
If they could stand up and wave hello?
Yes.
So be if we don't manage to get to your question,
please come and see us after this panel, and
we would love to talk to you.
We will be hanging around the community lounge
just behind the Google booth.
Everyone knows where it is.
Come and say hi.
I'm going to start with a question that the
JSConf EU team had for us which is date.parse.
They had an issue with the website in that
iOS wouldn't volume down to the right spot,
and the question is: date.parse, who did it
wrong?
V8 or Chrome?
>> I can take that one.
So I encourage everyone in the room to go
to their DevTools console after this talk
and try out date.parse 1 octopus 2018.
It works in Chrome, it works in JSC and Safari
and nowhere else.
It turns out based on the spec, everyone is
right.
There are certain date formats guaranteed
to work according to all browsers according
to the spec at least, but when the format
is not matched, it's up to the implementation.
Others still try to parse the date.
>> Let's talk about what we are doing.
Mathias gave us a great explanation about
what the spec is.
It's not an implementation but it tells us
how to implement a JavaScript engine.
Let's just talk about what the TC39 is, and
what the process is and how it works?
>> No!
[Laughter].
>> I will start with a TC39 works and let
someone else explain the stages of the process.
We are a committee of delegates who are representing
members in ... international.
We get together every two months, and we usually
meet for three days.
We discuss what proposals are up, we talk
about the impact of the language, we discuss
what changes need to be made, and we operate
on consensus, which means that we all have
to agree for something to move forward, which
is pretty unique in programming language standards.
So, that's kind of like the basic gist of
what TC39 is and does.
Does anybody else want to go through the proposal
process?
>> Sure, there are four stages.
Stage 0 is like a pseudo stage that is a proposal
exists.
Stage 1 is that the committee has considered
that this is a problem space that we want
to continue to explore, and find a solution
for.
Stage 2 is that there is a draft specification,
so there is some spec text that identifies
what the behaviour should be.
Stage 3 says that there is — there should
be significant in the field implementations,
in other words, some browsers or other engines
should have implemented this feature, and
stage 4 means it's ready to land in the spec.
Every year, we make a cut of the stage 4 features
that are — I think it's somewhere around
March, and, by around June time, that's [sound
feed distorted] .
>> I think it's important to mention that
the meetings happen every two maps, it happens
where we discuss, like, — every to months,
consensus taking stuff, but actual conversation
about how it should be written happens all
the time.
This is not like every two months, we pick
up, "Two months ago, where did we leave off?"
It's not.
It's usually, the meetings that we have are
more like this is what has been happening
on GitHub on the TC39 organisation for two
months.
Let's decide on how to move forward.
>> Great.
We had a couple of community questions about
how the speccing process works.
One person asked: is JavaScript evolving at
the right speed?
Are you in features being sufficiently integrated
with other new and existing features?
>> Yes.
[Laughter].
>> I think one proposal that might be a great
one to illustrate is is the clasp proposal.
One person asked: what is going on with the
private method?
We've got the hash sign which is used to express
private.
Most use the private key word.
How did we come up to the paint that we're
using the hash sign?
>> There is private access which allows you
to get the private property off an object.
There is the private declaration.
The reason we came upon this decision is because
every other language that has private is also
statically typed.
You can figure out exactly what the property
is based on the object it is being called
on.
For JavaScript, we don't have that.
There's no way of knowing what the object
is.
Whether it's supposed to be a private or public
property, based on the base reference, that
this dot object dot whatever.
So we have to have a different sidual to distinguish
between private and property access.
That's how we came on the dot hash, whatever
the name is, to access the properties.
To mirror access, we decided that the declaration
should also include the hash symbol.
It makes it clear up front that this is the
part of the name that the way that you access
it is that you pretend that the hash is part
of the name.
So, if it is hash pro.
You access it by this hash prop.
You think of it that the hash is the name,
not the signatures, the private modifier key,
or anything else.
>> Nice.
The private class field was being proposed
as a single proposal.
However, there were several other class-related
proposals that were being proposed at the
same time such as public fields.
How was the communication across those proposals?
>> We do a lot of work to make sure these
two features are synchronised.
We actually split them and then merged them,
and split them again between public and private,
and instant, and static properties.
Just trying to figure out all of the different
issues that could have happened with either
of them.
Then once we settled upon the semantics that
we were happy with, we merged them all again.
>> Awesome.
I think a natural question that would follow
this, is we've got this hash symbol now, this
could be confusing to newcomers, and another
person has asked us over Twitter: with these
new operators and features being added to
JavaScript, are we at risk of becoming too
cryptic syntax-wise for new developers.
I'm very much in favour of them but web development
it being approachable is a big boon.
>> I guess you could say, it's something that
comes up in the meetings.
It's referred to as the syntax budget, is
a there is only so much syntax you can add
to a language before it becomes ASCII gibberish.
So it is very much a concern, and everybody
pays a lot of attention to it, and we try
to make all of these proposals fit together
as a whole.
>> This is why syntax proposals are different
from new API methods, like array proto-phenotype
or something like — prototype, or you caning
loo up to how to call a method on an array.
When there is a new somebody tax, that produces
a burden on the developers to recognise the
new syntax and its meanings.
Syntax is more complicated to learn as a newcomer
than it is to call another method.
>> Maybe this is also a good point for another
note on the process.
One thing we are trying as a middle ground
between design by committee, either achieving
nothing, because in constant deadlock, or
I get my feature in, and you get yours, we
get this explosion of features that nobody
really needs, we have the so-called champions'
model.
Our proposals have one or more champions who
work on really developing the feature, and
present it to the committee, and by and large,
the committee overall does not do the design.
It needs to achieve consensus, but it is not
like all everybody gets to chime in and say,
"I want this tweak in, and this syntax should
be slightly different," and then I'm happy.
In practice, that works out fairly well to
achieve a manageable complexity budget.
>> Another question that is going around like
the general development of how JavaScript
is designed is a question around what is JavaScript's
identity?
Are we moving towards other non-strongly typed
project language, like object-orientated concepts
like ES6 classes, or more functional?
This is tied to where are we going as a goal
in JavaScript?
What are we aiming for?
>> I think — I believe JavaScript has a
very strong notation on all the behaviours
it does around the types that are well defined
in JavaScript, but I think being a dynamic-type
language, it is one of the highlights of JavaScript
itself.
I don't see this thing happening for now;
I don't expect this to happen in TC39.
I think it's a highlight, and we should consider
all the advantages from using a dynamic language,
and a type language.
Both are fine, but we're on the right place
here.
>> I also think that this is just to some
extent a false distinction.
More modern languages like Swift or Rust are
heavily influenced by both object orientation
and functional design patterns, and you really
take the best of these worlds and make a well-designed
overall languages.
It allows people to express their logic in
ways where it makes sense instead of having
to cram it into some notion of purity.
>> So one of the — one topic that came up
a bit on Twitter was of course about types,
but it was also about typescript, peer script,
and Babel.
These are things that transpiled to JavaScript.
So JavaScript isn't necessarily pure, but
do these other languages that adopt different
paradigms than what JavaScript have, how much
does this influence our work on the language
in general?
>> I think it's great to have all of these
languages.
Even if they are like targeting JavaScript,
I believe they allow the community to bring
feed back as these languages allow, like sandboxing,
we can't do directly on JavaScript.
We can play with these languages.
We feature that we want, and we can make like
proof that they really are necessary if we
want to bring this to JavaScript.
From experience, there's a lot of nice interesting
features that we already have today in JavaScript,
and I really appreciate that.
>> Maybe, on one of the fields where there
is a lot of experimentation in compile to
JS languages, that is types, there is obviously
typescript and Flow and other languages that
add types to JavaScript or JavaScript-like
languages, and so the question comes up, "Why
aren't we adding types to the language itself?"
The reason is quite simply we don't believe
that anybody has come up with a design that
works well enough for JavaScript and is really
universal enough that we are comfortable taking
up the human being design space.
This is a huge decision, and so it is fantastic
that we have this ecosystem of compile to
JS languages that can do the experimentation
they want and scheme can decide to — and
hopefully, eventually, we will converge on
a design where we feel like yes, this really
fits the language.
This is what we should add to the standard
itself.
>> And we have — we also have some people
who are working within the Wasm community
group.
It would be great to hear about what is the
relationship about JavaScript and WASM as
compile targets?
>> We were talking about the explosion of
features in JavaScript earlier.
One of the nice things about having web assembly,
things that don't make sense, you can use
web assembly for the home for that feature
where it might make more sense.
I did — I think that web assembly and JavaScript
are complementary as compile targets and not,
as some people think, competitors.
>> This also affects types again directly,
because for good interaction with web assembly,
that isn't extremely low level on the on the
exchange level.
You want to have the ability to talk about
a type system from both sides.
And there are efforts making that possible,
they don't actually need syntax for those
types, which might be a bit surprising at
first.
This is something where over the next few
months or so, certainly within this year,
we will have more things to show.
>> One thing we got requested from the audience
via Twitter is that we talk more closely into
the mics.
Okay.
So, people have also been asking some things
that are just ideas about what the future
of JavaScript could be like, and one person's
asked: can we have something like a module
key word that makes bundling a first-class
citizen of JavaScript, and allows a single
JS file to ex pose multiple modules as an
interface?
>> Yes, come and see me, because I have a
proposal in the works for that, so, yes, we
can have that.
[Applause].
>> So, moving on to another topic: so, over
the last year, we sort of had a bit of a situation,
and someone asked: can you share your perspectives
on flattened versus smoosh debate.
>> I can give some history here.
What happens is that there was a proposal
to add flatten, and flat maps with the array
prototype, and when it got to stage 3 and
Mozilla implemented it, and started to ship
it in Firefox Nightly, they realised that
it was breaking certain web pages.
They relied on this particular implementation
not being there.
So, of course, this is kind of the worst thing
that can happen to a proposal, like, when
we ship it, we don't want to break the web.
This is not acceptable.
Mozilla unshipped it, but then we have to
go back to the drawing board, and we knew
we had to change the proposal in some way.
Because the name itself was the problem, specifically
for flatten, we had to rename it somehow.
Then the proposal author decided to send a
joke pull request to its proposal calling
it smoosh and smoosh map and you know what
happened next.
It wasn't clear that it was a joke.
People got upset.
I think we learned a lot from it.
I think other people can speak better as to
what happened next.
>> We had a TC39 three-day meeting right after
that event, and I think all of the consensus
was yes, we learned a lot from this interaction,
certain things that we can present, you know,
certain ways that we can communicate with
the community, and it's unfortunate that happened,
but we learned, and hopefully, we will never
do the same thing.
>> One thing that I personally learned from
this is that, for a lot of people, it is not
clear that TC39 is actually representing the
developer community as well.
In fact, some people are entirely just attending
these meetings only specifically to do that.
And, during smoosh-gate, people felt it was
an us versus them kind of thing, which it's
not at all.
We should work on clarifying that.
There is a lot of work we could do there.
>> That's a huge thing we took away from that
realising that we need to be more obvious
about the fact that we as individuals are
involved in TC39, because we are humans, we
are people.
We are people who work on libraries, people
who work on, sites, we are people who work
on browsers, and like, we are human beings
who might make a joke sometimes, but because
it's not super obvious to the community that
we are doing what we are doing, and who is
doing what we are doing, it is pretty easy
to forget that.
It is like some nefarious council somewhere
making the rules!
>> That no-one can attend.
So, there are a couple of people wondering
how do they get involved?
How does someone who is new actually start
talking to the TC39?
>> So we have all of our proposals on the
GitHub.
TC39 repo, organisation.
You can get involved in any one of the proposals
by opening issues, by commenting, by trying
to network to make sure your use case is served,
or you can contribute to Babel to get these
things implemented so you can use them in
your code.
>> And, related question to this is someone
asking about when writing up new features,
like, for example, someone wants to propose
something, where do you look the most for
inspiration?
Are there other languages, and which ones,
or is it mostly driven by requests from the
community?
>> I think it's a little bit of a combination
of both.
But when — what I personally find more expensive
is to start with a problem statement, a problem
that you want to solve, and then you motivate
that problem itself.
Then the solution can take various shapes.
At stage zero, you don't want to say I have
this amazing solution to this problem.
No, you want to say look, there is this problem.
Do we agree that this is a problem in JavaScript?
If so, maybe we can go to stage 1 and discuss
solutions and you've already thought of solutions
but it is important to focus on the problem
rather than the one specific solution to the
problem.
>> I would like to add to that saying that,
so, again, like there is a staging process,
and there is a chub, so usually, it is not
like we meet, and then say what is the problem
in JavaScript community?
What is hard?
No, somebody already came up, like I don't
like this syntax, or this is the source of
my bug.
A new proposal in sometimes about the array
and getting the last item from array, I constantly
stumbled upon the bug because of this.
I want to have new features, so I'm like proposing
is this a valid idea?
Should we discuss this?
That is how things get into the staging process.
So, like, you mentioned, I'm like, a person
who is just going to TC39 meeting, I was like
presenting like web developer point of view,
and I don't go to TC39 meeting because I have
something to proposal, like I'm more like
I want to listen to this conversation and
make sure that our views are respected, so
I feel really inspired.
I'm in such a JavaScript syndrome that I think
it is fine, nothing should be changed, every
time one of these fine people say, "I don't
like this, or this is really annoying" I'm
like, "It IS annoying!"
>> I was going to say to the original question,
once we have that problem statement, and once
we figured out that we want to solve it, from
there, there is a combination of taking inspiration
from other languages, figuring out if there
is a more JavaScript way to solve the problem.
It is it's a huge combination of all the different
ways we could approach it.
We don't restrict ourselves to any one route.
>> Awesome.
Thank you.
So, the next question is related to information
dissemination, and, like, how do people keep
up with proposals specifically?
Where do you keep up with updates?
Do you have a website.
Another question: how do you visually track
all of the new proposals through to the maturity
stages, maybe with a polyfill or Babel plugin?
Up to this point, we have had a GitHub repository,
but we noticed during smoosh-gate that we
had a communication problem with the developer
community.
It is hard to find information about proposals
and what is going on.
What we've been doing for the last little
while is working on — I hope this works.
It doesn't work, okay.
We've been working on as a result is this
project which also doesn't work when I use
my mouse.
Fascinating.
One second.
There we go.
That should work now.
Oh, it doesn't.
Fantastic.
Let's try this one.
Next slide.
Oh.
There we go.
Sorry, everyone.
So, we have built a website for the community,
and this is what it looks like.
It is in beta.
It is something that we are working on.
It is not complete, but what we would really
love is to get feedback from the community
if this is answering your questions, and,
if this is doing what it needs to do, and
if it is not, it would be great to have your
feedback and your comments, and this could
be a great first step for people who are interested
in getting started working with TC39, and
contributing.
Hopefully this now works?
It doesn't work.
Whoops.
Technical issues.
No worries.
So, I would like to say thank you to the contributors
who made this possible within three months.
You can find the URL there at the top if you
want to visit it, and there is also a QR code
there if you want to scan it.
We're trying to improve the information issue,
and namely, we are looking for feedback for
this beta version of a potential community
site.
So, moving on from the website issue, and
straight into the next section of this, which
is just for fun, we got a lot of questions
that were proposal-specific that we can answer
rather quickly, so we're going to do a rapid-fire.
Let's do that with TC39 logo.
Yes, there we go.
Nice.
So, we're going to have three minutes, and
we're going to answer these questions as quickly
as we can.
If we missed your question, please come and
say hi, to us in the community lounge when
we wrap up.
Let's go.
What are some of the most exciting features
coming next?
>> Optional chaining.
[Applause].
>> All right, a couple of people can answer
that one.
>> Personally I love the matching pattern.
>> Pattern-matching is awesome.
[Applause].
>> [Inaudible].
>> Yes.
>> Excited about BigInt.
Finally, integers that make sense.
You can do arithmetic on them and won't get
the wrong result.
That's kind of amazing.
[Applause].
>> Okay, moving on: What is your favourite
JavaScript function?
>> [Inaudible].
>> It's definitely flat, right?
>> Everyone's favourite one is flat.
>> Map and reduce.
[Applause].
>> Is okay, so this question is interesting:
local storage between subdomains would be
awesome.
>> Not something TC39 is involved in.
That's a DOM API and TC39 is really only involved
in the standardisation of the language.
Sometimes, it's hard to say exactly what is
language and isn't, but in this case, it's
about input/output, and that is not in the
language at all.
>> If you had that question, go chat with
the DOM API people, and maybe they can help
you out.
How about a native method for deep-object
cloning?
>> Good idea.
>> Very complex.
>> Yes.
>> Hey!
>> Come and talk to us.
>> The next one is similar: we would love
to have a non-expensive non-library deep object
comparison.
Any hope on that?
>> Again, come and talk to us.
We can go through it.
>> You want to write that proposal?
Go for it!
>> What is the medium turnaround for a proposal
becoming reality time-wise?
Do they follow the same procedure?
Yes, they follow the same procedure.
How long do they take?
>> Some of them take years.
>> I think minimum I saw was like 18 months,
maybe.
>> If you're feeling really ambitious maybe
a year.
>> The absolute minimum would be one stage
per meeting, so maybe you can do it four or
five meetings, eight to ten months, but that's
it.
There's no complex, everybody's on board,
and it just moves right along.
>> Another thing is that, in order to advance
through stage 4, you need two shipping implementations
in browsers which is not always in the control
of the champion or the author, like, unless
you want to go and implement this in two different
JavaScript engines yourself which is a lot
of work on top of the work you're doing writing
a proposal, then you'll just have to wait
until it happens, basically.
You can help that with contributing tests
so that these implementations can just check
if they're correct or not easily.
But still someone needs to do the work and
implement it.
>> We've got a couple of seconds left.
Can we use emojis in function declarations?
>> Please!
>> Right now we can because they're not valid
identified fires.
— you can't.
If you Google valid identifiers, you will
find a tool I built exactly for this purpose.
>> And we've got no time left for one more
question.
Please come and say high-to us.
We would love to meet you.
Thank you.
[Cheering and Applause].
