hi I'm miles borns I work for Google as
a developer advocate
c39 for just over three years my name is
Michael say buff I work at Apple on the
JavaScript core engine been attending
tc39 since 2015 my name is Mark Miller I
started on tc39 in 2007 while I was at
Google about two years ago I left to
form a gorrik which is a blockchain
start-up where we're going to be running
JavaScript on blockchain and I've been
doing a lot of work to make the language
better able to support more disciplined
and more secure programming I'm Aki
Braun I work at PayPal I work at
Braintree at PayPal I've been on the
committee since 2017 and I have been
co-chair this will be my second year hi
I'm Rob Palmer I work for Bloomberg
where I lead the JavaScript
infrastructure and tooling team I've
been on the committee since 2018 and
just this week I became one of four
co-chairs like a key here hi my name is
Shankar I've been on tc39 since 2018 I'm
I'm work at Google on the
internationalization engineering team
and I lead the lead the
internationalization subcommittee for
tc39 focusing on making JavaScript's a
language that's very friendly for for
international first applications and hi
I'm Justin Ridge well I also work for
Google I work on the amp project and I'm
one of the core maintainer Jean Babel
wow so many impressive people in the
room so the first question that pretty
much a lot of people have asked is what
is the organization behind tc39 and what
actually is tc39 any one of you can
answer that I'm sure very well
okay so tc39 is the thirty-ninth
Technical Committee of ACMA
international Accra International is a
standards body they are who publishes
the Xmas script standard once a year
which you may think about you know
es2015 changed on things sure but every
year now it gets published 2016 2017
yes 2020 what we published in June yeah
yeah
so we ACMA is an organization made up of
member organizations
it's a standards body that large
corporations small companies and
nonprofits and universities can all join
and once organization has joined ACMA
they can send delegates that's what we
all are
delegates to two technical committees I
don't know if that actually explains
what's behind a tc39 or not that answers
that answers the question pretty well so
I'm sure you get a lot of features
requests and features that are proposed
and everything how does a feature move
through the committee through the
proposal process crack at that now we
have a stage process in the
documentation of stage one through stage
four there is a stage 0 computer
scientists we don't know how to count we
start counting at zero instead of one
but stage zero stage one is this is an
idea that that someone thinks would be
good to add to the language and stage
one proposal basically says the
committee thinks this is worthwhile to
consider adding to language Stage two is
now in the step where you're going to
look at SPECT X so how you specify it
you define semantics and things like
that Stage three is where it's
implemented by at least two
implementations and an implementation
doesn't necessarily have to be for
example the engine a JavaScript engine
side of a browser it could be for
example a Babel implementation it could
also be there's a embedded engine called
XS
it could be in that engine as well and
stage 4 it's in the language stage 4
synonymous with it's in the standard and
we say something stage 4 until it's
produced in that standard so there's
stage 4 proposals that are gonna be part
of the 2020s 2020 and after 2020 is out
we won't call them stage 4 they're just
in the language so that's basically the
process you go through it's typically
done by a champion that's going to take
it or champions there could be more than
one person more than one delegate that's
going to take it through that whole
process there's some debating on on you
know is this a at each stage is this
something that we think is worthwhile
are people going to use it what are the
use cases also the semantics of the
semantics mesh well with the rest of the
language so on and so forth so that's
basically the process that we go through
to put something in the language so for
a were you going to say something it's
worth noting that our standard for
whether or not we're going to tackle
something in the first place isn't is
this new syntax or API something that we
want to add it's is there a problem that
we're going to solve which i think is a
maybe a different approach than a lot of
people assume that we make to make you
change the language it's it's Wiis we
identify problems that need solving
and from there we decide how we're going
to do that so I first heard about
optional chaining which i think is stage
4 now now I first heard about that I
think when it was stage 0 which was like
three years ago or something 2016 and so
is that typical for something to take
that long to go through stage zero to
stage four how long does something
typically take years so I was actually
one of the co champions on optional
chaining thank you the I actually saw
there are Google internal documents
suggesting optional chaining back in
like 2012 the fact that we add only
finally produced the spec text for it
and tried to go through the staging
process starting in like 2016 or so the
I think there was a little bit of
infighting about what the scope of what
we wanted to do with optional chaining
and how far like the optional miss the
chain is
where it ends whether or not should be
undefined or null so that took a little
bit of time extra time in order to work
through but then once we actually add
like a concrete idea we knew all the
solution to it
it only took maybe three meetings to go
from the stage to stage three and then
to stage four so once we actually have
agreement about overdoing it's pretty
quick but it's getting that initial idea
hammered out that took forever yeah and
I just add to that really quickly so as
Justin mentioned we need multiple times
a year so we have six meetings a year
every other month generally a future if
it goes for a stage advanced advancement
only goes one stage per meeting and so
in theory and this is not generally in
practice but kind of the fastest you
could go through the whole process would
be like eight months has anything ever
gone in eight months I I don't know if
it's gone that fast but I have seen
proposals for example that are for very
very clearly defined features that come
in as stage two because they've come
with a really really clear use case the
spec text is already written it is not
controversial that this is something
that we need I'm spacing on the exact
one I know that a delegate Mike Samuel
had a couple catch went through very
quickly optional catch I'm a bit puzzled
by the process implication there I don't
remember anything so to speak coming in
at stage two just that it rapidly
advanced the stage two there's a few
examples from the internationalization
point of view where we bring things
directly and at stage two which sort of
segues for how do proposals work on
internationalization so we have a
subcommittee where we were we review
internationalization specific features
this is things in the insult object so
in tool number format until date format
into a col later those kinds of things
and we review you know the those
proposals and check the use cases and
check the implement ability of them
before we bring them to
full committee so we frequently have
proposals that come directly and at
stage two because we've already done a
lot of this vetting before we bring them
to the larger committee and you know it
means that sometimes we can have
proposals that go through the process
faster because of that for prefer Intel
I find that the biggest bottleneck for
us is getting the implementations
because in the internationalization API
is tends to be to tend to have a lot of
dependencies and are more difficult to
implement sometimes because you know
they vary you know greatly from you know
language to language and region to
region so so we tend to have a lot of
proposals that get stuck at stage three
and can say it's age three for a year or
more before the browsers have all have
have implemented them whereas whereas I
know a lot of other proposals that get
stuck at stage 1 or stage 2 and one
thing I was just gonna add really
quickly is there is somewhat of an
ambiguity in the stages and so the
conversation that Mark and I were having
right now is actually a very healthy
debate that can often happen around like
there's the reality of how things go
through but then our understanding of
how that applies to the stages can vary
and so it is not uncommon we're a group
of people who like being pedantic it is
not uncommon that during a meeting we
may actually stop and discuss the
process and ensure that we're being fair
to the process that were yeah following
all the criteria and I at least like to
think that it is to an extent a living
thing and we want to be flexible and we
want to have a process that that creates
a great language so you know even just
this past week I think probably almost a
third of the committee time in the three
meetings that we had were discussing a
variety of different process changes
that were exploring for a number of
different reasons including potentially
introducing more remote work that we
could do or more ways of meeting in
between meetings because one of the
things that can't happen for good or for
bad if you bring something for stage
advancement and someone
points out something that you hadn't
thought of between the two meetings
something and get delayed for two months
which is why things can take three or
four years so we're actively trying to
think of different working modes that we
can use to minimize the possibility of
that happening
so speaking of all of this process and
you mentioned the actual implementation
part how does the implementation process
work and how do you actually know that
things are being implemented correctly
you can use my mic if it doesn't work
and so one of the the key criteria or
actually landing in the spec and -
getting it into stage four is that we
have conformance tests so the the main
project for that is let's test 262 and
and that has a number of maintainer x'
folk who've done a lot of work on that
and oh yeah a ton ton of work there with
Leo voltar in particular contributing
and so having that all implementations
to go through should be a hundred cent
compliant with that ideally I think you
can see a lot of the stats that there's
still still a way to go there oh yeah
there was a project oh you can you can
see them for yourself at test 262 dot
report it's a website that shows each of
the engines and how many tests are what
their compliance looks like and all of
you in the room can help with this as
well because whenever a feature is
released it normally comes out in
browsers in early versions like Canary
versions and maybe it's behind a flag so
if you enable these in your browsers and
then and try them out there if you find
any issues if you find any bugs or maybe
you've just got feedback maybe you like
it maybe you don't and please do please
do provide that feedback all the
proposals have a repo on github
so you can raise an issue there and
that's always massively appreciated and
we do see a
a lot of people reporting real-life
things there or you can file an issue on
the actual browser bug trackers as well
so so please please do try and
experiment and have fun
our organization is tc39 on github and
you can see every proposal we're talking
about and the agendas for every meeting
we're doing and a few other things so
it's the easiest way to actually
participate in the process that back to
the implementations during stage 3
that's where these implementations are
being done and quite often we quite
often it's often the case that we find
that we're under specified about certain
semantics and so implementation a will
do something one way and implementation
B will do something slightly different
and it's during that that process either
using test 262 or the tests that those
implementations write to validate their
own implementation that we find those
are some discrepancies and we work
through those discrepancies and and
unify things and we're going through a
proposal now where there's a little bit
unification around that but that
occasionally happens and that's why we
have that implementation stage or stages
hi Mary focus on implementation that we
make sure that we're compliant with each
other we're compatible with each other
as well as complying with what the spec
says I always like to talk about
weaknesses as well as strengths my tests
262 is an amazing piece of work but it's
important to understand that it consists
of very very detailed unit tests they go
through the spec kind of in order and
try to make sure to touch everything in
the spec individually as a unit test
what it is not is an integration test
languages have lots and lots of
non-local and non orthogonal interaction
between features and we have repeatedly
seen non conformance that was not
detected by test 262 at the non
orthogonal interaction of different
language features so going forward one
of the things that that I would very
much like to see is some creative
thinking on how to bring more
integration testing you're testing the
language
and how to do that without a
combinatorial explosion I think it's an
interesting problem
so are these repos that you've all
mentioned is that the best way to
interact with the committee are there
other ways that individual developers
can get involved outside of being a
delegate from their company we have a
discourse instance at yes dot discourse
dot group where you can ask questions
you can see discussions of sort of
potential ideas or or you know kick
around some thoughts you might have a
language there's also of course github
each proposal is at t39 slash proposal -
the proposal name and you can see all of
them at tc39
slash proposals you can contribute
yourself as long as you have filled out
our royalty-free intellectual property
rights agreement which sounds like a
mouthful but let me tell you my
organization has rather cautious
attorneys and they're like not school so
you know it's cool we also are on IRC
we're on freenode at tc39 good I'm on
Twitter all the time we got our we got
our Twitter handle back but I don't
actually know who uses it so so contact
you on Twitter specifically actually a
lot of us do follow looking 40 through
nine hashtag to see what people are
saying and thinking about this stuff
we're working on so it actually is a
pretty decent way to get our attention
we also have a process as the committee
known as invited experts so if you're
working on like open source libraries
are working on things that directly
impact the standards that we're working
on there is a process in which you can
be invited to come and attend a meeting
we I'm working on one proposal right now
for module attributes where I believe
that I could be mistaken but I believe
one of the people
working on it is not a delegate one of
the champions is someone from the
ecosystem who helps maintain Babel who's
building out examples of the
implementation and I won't lie like it
is a little bit of a black box to figure
out how to get involved but when you
find those contacts and all these people
who you see on the stage now can be in a
place where you can start there
but if you have ideas and you can get a
champion excited about it there's
definitely a lot of ways that you can
help directly in creating proposals and
potentially even come to the meeting the
open jazz foundation in particular is a
member as a non-profit and we have
within the open Jas foundation $40,000 a
year travel budget to cover travel for
people within the foundation we've
actually paid for individuals who are
not members of large companies have been
invited as experts to go and attend the
meetings because the travel can be cost
prohibitive but there are ways to do it
and I think as a group one of the things
we do want to do hopefully in the near
future
is try to make some of this better
documented so folks can figure out how
to get involved cool and another
interaction point is that there's a set
of calls they're set up so running
regularly for things like tooling where
we get the tools vendors or altar all
together like typescript Apple if you
have an interest in maintaining our
tools there you could join yourself
there's also a frameworks call where for
example react view and all these
contributors come on to talk about hem
how the new Pro new proposals that are
coming up hey they may be shaped or
where they might impact leave these
groups and there's also the educators
call this is all about people who are
teaching the language so if you're if
you have a responsibility for teaching
people at your company and/or an
interest in that please do join and then
you'll hear about all the new proposals
coming up and if you have concerns maybe
a feature is going to be hard to teach
the people
is going to confuse them then that's an
excellent way to provide feedback and
talk to other humans speaking of that is
there with all of the new things being
added is there a risk of the language
being too cryptic for new developers ooh
you have a thought yes okay yes it's
it's a continual battle but this
committee I think has been engaging in
the battle well but there's an inherent
problem in the dynamics of any standards
committee which is there's two things
being battled there's two things in
tension one is for any new feature the
benefit of the feature individually and
then there's the overall cost on the
complexity of the language as a whole
and when you're the promoter of a
particular feature and and even if
you're not the promoter when in the room
we're discussing the feature we're very
naturally are focused on thinking about
the feature in which case we're
generally thinking about the the value
of the feature it's very hard to
maintain vigilance to guard the overall
complexity budget of the language and as
the language gets bigger the danger
increases because each additional thing
added is a smaller fraction addition so
it's easier not to see the danger
there's also sort of the first I think
two years we've had a presentation about
syntax complexity there's all these very
funny slides about how cryptic can you
make your code layout presents this
every time last year it was just filled
with so many question marks I like to do
like triple nested turn Ares and classes
just to be like did you know you could
do that and then people's brains hurt
I think one of the other protections we
have in the committee from the language
becoming too complex is that in more
recent years though previously and the
committee was populated with mostly
implementers and a few other people in
recent years the the membership has
grown quite a lot and so there are now a
lot more users of JavaScript involved
and so there's a lot more regular web
web developers and they're there to
actively speak up if they believe that
that things are getting an out of hand
so for new features to come in how often
does it come from these just web
developers out in the wild how many how
often do they come from community
requests and how often do they come from
internally in the committee or elsewhere
I think for Intel we we have a github
repository which is github comm / tc39
slash equi four zero two four zero two
is the number of the insula
specification and we get feature
requests from from from users and the
more users that request a feature the
more interesting that feature becomes
for us to prioritize and implementing
ultimately you know these proposals are
driven by the members of ACMA
international so for the ins for the
Intel objects these features generally
have to be features that's in my case
Google clients need but those are quite
often aligned closely with the features
that that regular web developers need so
it's really good to get signals on what
features users are requesting and at
least for install the way that we do
that is by engaging with users on github
which also segues back to the earlier
question about how can you get involved
if you go to our github page we have a
calendar with our monthly meetings we
have a monthly to our phone meeting
which you can you can subscribe to that
calendar if you're interested and silent
to those meetings so I think my my claim
subjectively is that at least 80% maybe
90% of new features in the last three or
four years have been done by developers
and not implementers I think that's been
the case recently I believe before that
there is implementers were more wanting
to add certain features as engine
developers and language niobium
developers I think it's it's it's
switched in like the last five years I
guess one thing I can add as well
especially when we talked about stage
one we talked about the difference
between coming with solutions versus
coming with problems and so I think that
while the solutions may not be exactly
what developers from the ecosystem had
in mind or even necessarily what we had
in mind as we just like as we're still
discovering the problem space the
problems that were coming to solve are
very much problems that developers are
running into and I think some of the
work that we've done around modules is a
really great example of that like being
able to write modular code very much a
developer problem what kind of weird
solutions we need to come up with
because of history you know that may not
be something anyone would have ever come
up with in a vacuum so it's a bit of a
balance there so with all of these
things coming into play what are what
are the goals for the committee
especially in like the next five years
what is JavaScript's identity in the
next five or so years or more if there
are so many different answers I'm
genuinely curious honestly so I think
one of the most important things about
the nature of the committee is that
people on the committee represent
different constituencies and have
different perspectives and different
long-term visions back I think three
years ago now
the there was a set of presentations
specifically soliciting from committee
members who wanted to present on this
what their long-term vision for
javascript was I did one of those it's
up on YouTube I recommend it
but the important thing about the
diversity of goals on the committee
combined with the consensus process is
something really magical happens as we
all negotiate with each other is
something will seem very good for some
goals and will conflict with other goals
and when that conflict is unresolved
that can prevent it from going forward
but the thing that's being proposed is
it's it's not that there's a particular
technical solution that somebody's
trying to move forward they're trying to
solve a problem and when you run into
those conflicts it forces the people who
want the feature to figure out how to
redesign the feature so that it doesn't
step on any of the other goals and often
these are goals that those people would
not have had in mind if it was not for
the the the discussions in the room and
the need to achieve consensus well I
think we have a very very good process
and it and the language as it moves
forward really does succeed at advancing
many different visions of the language I
think one of the it's also going going
on now is that say like three years ago
node wasn't really involved in the
conversation at tc39 and node now very
much is we also have embedded devices
that are using javascript there's a new
TC TC 53 and you know you're talking
about JavaScript for very very small
constrained devices not necessarily
wearables but certainly that's one of
the targets and that's kind of a
different ecosystem marks involved in
javascript on blockchain so you know
five years ago javascript was about the
browser and pretty much that's about it
and we saw this monitor mantra don't
break the web and you can't have a
breaking change but the conversation is
now involving other ways javascript is
being used and I think that that
like I said coming before the last three
years and I think that's can continue to
be the case moving forward let us not
forget my favorite places that
javascript is running satellites in
space and whirlpool washing machines so
I think for myself and Michael kind of
touched on it selfishly my my hope for
the language over the next many years is
that we have a lot of different places
where we're gonna want run JavaScript
and I would very much like to have a
language that we can run everywhere one
of the biggest risks that we have in the
way that we standardize things is we
don't standardize absolutely everything
there are things that are left up for
the hosts and the implementers to make
decisions on really obvious one is the
specifier when you import a module how
do you turn that specifier into a path
on the file system and then resolve that
to actually get the resources the
language doesn't actually know anything
about a file system so this is left up
to the host in the embedder to figure
out which becomes a place where we can
have contention between a thing like
node and the browser and that's
something I've been doing a lot of work
on within node but I'd very much like to
see us move towards having developers
the people in this room be able to like
kind of write code once and run it in
all these different environments and not
need to know all of the different
intricacies and that's not to say there
won't be unique api's across these
environments but the the core language
should not be getting in the way of that
I'll take a stab so from the from the
internationalization engineering
perspective our our team at Google is is
is is looking forward to building an IE
10 frame work not just for JavaScript
but also for other client-side
applications including Android and iOS
and watch OS and where OS and flutter
and fuchsia and we're sort of starting
with JavaScript as one of the most
popular client-side
forms the the web platform in general
and then sort of taking some of some of
the lessons that we learn here and then
applying those to the other platforms so
we're sorta so I sort of see JavaScript
as sort of the leader in how you can
build a great ITN friendly platform so I
think you can probably tell from some of
the answers here that the wide range of
answers that there is no singular vision
there is no dictator that decides
exactly exactly what it's going to be a
key keeps us on time she's very very
good and but that's also also another
thing is that javascript is not owned by
any one person or company I think that's
a really big thing about the reason that
it's special reason that lots of people
come together to invest in the language
people invest their careers into it
their spare time but equally companies
these features that are coming out they
don't come for free companies are
choosing to to direct investment because
they think that javascript is a safe
investment for the future and will
continue to grow and evolve and in
building on their perhaps the real
javascript is the friends we made along
the way so having talked about why this
this composition of lots of different
goals has been so beneficial for
JavaScript I'll now also tell you just a
bit about division I've been pursuing
when I joined the committee the standard
JavaScript was Eknath script 3 and the
committee was most of the committee was
trying to standardize on ACMA script for
when I joined the committee I joined the
rebellion against ACMA script for one of
my proudest accomplishments on the
committee is helping to kill ACMA script
and and the thing that we were designing
instead the the the underdog was a time
ACMA script 3.1 became equi script 5 a
neck mascara 5 is a rare accomplishment
a rare kind of accomplishment on a
standards committee which is its
subtractive it gives the users a better
language by making it smaller and
specifically the introduction of
strictmode you can't break the old
sloppy code but the strict mode was an
opt-in to create a simpler language that
was better bite because it left out so
many missed features so the shirt that
I'm wearing today really does express my
vision which is starting from big messy
JavaScript find different subsets of it
that can be enforced subsets that by
staying within those subsets you can
have an improved developer experience
you can program in a more disciplined
manner you can program in a more secure
manner and you can compose programs that
are written separately with with less
danger that the that they'll have
inadvertent interference with each other
so in particular I've been working
towards a vision we call SES secure echo
script which is one of the circles on
this t-shirt on this t-shirt that's a
great shirt I would like to see do you
have that graphic on Twitter or
somewhere where we could look for it ok
I don't know that we have it on Twitter
but we have it yet yeah yes it'll it'll
get or something sure yeah it's Andy
Jesse you repository the Jesse is the is
one of these smaller languages here that
we use it or gorrik it's not something
we're proposing as a standard but that's
worth it's graphic is found eight so a
few of you mentioned having JavaScript
run everywhere across different
platforms and space of washing machines
everywhere so because it's being
targeted by so many different devices so
many different compiled
there's so many different things how
does that affect the design at all of
how you have to move forward because
it's starting to be everywhere and be
targeted by so many things one of the
the reasons we have implementers start
implementing these features at stage
three is because we actually want their
feedback about whether this is something
that's possible in their engines because
if we add a feature not every language
or not every engine can actually do the
feature then that's not really a feature
you can't depend on it anymore so that's
the reason one of the reasons we require
two implementations before going to
stage four is just to make sure that
everyone has had time to actually look
at it try to implement it and it's
actually possible cool that was a
concise enough answer nobody has words
okay if no one else has anything to add
on to that I'm so for the insole space
there's sort of two places that you can
do internationalization in your
client-side code you can either do it in
you can either ship the JavaScript
directly to do the date formatting for
example or you can use the browser
engine so by putting this into the job
into the JavaScript engine and we are
actually able to make the app the
JavaScript code that you have to ship a
lot smaller and then that's one of the
motivating factors for having insel in
the standard library of the language and
it's it's implemented in a separate
specification so you can have a
conforming JavaScript implementation
without the Intel object but at least
four browser applications this is a very
important feature and so this is one way
that we're able to provide this feature
for for browser users and not
necessarily require it for all
implementations of ECMO to six-two which
is the main language how often I know we
already talked about like how features
come in from from different places how
often do features come in based on other
languages and other things like I don't
know see c-sharp
Perl anything there there appears to be
a lot of that recently
you know c-sharp Ruby things like that
that we're adding those and in a lot of
cases that's syntactic sugar and we
already have the capability you know
think about like arrow functions we can
do functions we do function for a long
time but now we have arrow functions
because that's one ways of people like
brain functions we have another language
and there's I think there's a little bit
of a danger here that we have to be
careful because if we take every
construct in every other language that
we already have some way of doing that
in JavaScript we add it and so now you
have multiple ways of doing the same
thing it may become confusing so Ruby
what's that it may become Ruby yeah so
there there is a lot of genesis of ideas
for JavaScript proposals for JavaScript
that we see that do come from other
languages and go back to the discussion
earlier where there's you know people on
the committee says okay this is what the
syntax will look like possibly if we do
this for all languages and so there's
this weighing the balance of how much
because mostly these are syntax kind of
proposals what is the syntax budget we
have you're running out of special
characters and having three characters
in a row for a keyword starting to get
to be a little bit too much is the is
this feature worth it and so that's the
the discussion you have and again as
much as Mark said it's not just that
feature but that in collective with all
the other features and one thing to add
on top also the motivation may not come
from other languages but I think it's
definitely an important thing for us to
as part of research as if we've
identified a problem we look at the
solutions that other languages have come
up with maybe they come up with a great
solution that we can copy but they may
have also come up with a solution that
absolutely didn't work which we can
learn from and not make the same
mistakes so I think that any champion
who is really doing their due diligence
is looking at other languages for at the
very least inspiration when designing
things within JavaScript the phrase
prior art comes up a lot in proposals
like a lot it's good
well we did have a question from Twitter
and the question was what is the
difference between tc39 and groups like
w3c there there are a number of
different standards organizations that
standardize different things so tc39
exists with an ECMO and focuses on the
core language in just the language and a
really great example that can show a
difference here is the console object
most people myself included debug by
console logging it's really easy and it
works and you put emoji in there and
then that works you're like oh but the
JavaScript language doesn't have any
sort of idea of system calls it doesn't
have this idea of printing so it doesn't
have any output you can execute and run
things and put it out console has no
place within the language if we wanted
to implement console in the language
we'd have to also implement like our own
kernel for interacting with the the
system which I don't think mark would be
happy about I'll give it to you
afterwards to add on that process but
the console is standardized at the what
working group of what working group
standard is is a number of different
things including the URL object and
these are things that traditionally were
implemented in the browser fetch is
another standard that was made at what
working group but you're seeing other
runtimes such as node and demo and
CloudFlare edge workers adopting these
web standards that are not from tc39 to
make part of their runtime we talked
about implementers and engines that's
like v8 or Jas core or SpiderMonkey
these are the JavaScript engines inside
of the browser's but a pro a product
like Chrome is made up of a lot of
different parts of which the JavaScript
engine is just one there's the whole
rendering layer there's everything that
has to do with accessing all the system
bits so w3c for example is where HTML is
specified between w3c and what working
group CSS is specified at w3c web
assembly is specified at w3c and these
organizations have a different
fast-track to international
standardization they have completely
different governance models my
standing at w3c where I've not done a
ton of work is that each working group
charters their own charter and operates
completely differently so the CSS
working group and what working group the
CSS working group and webassembly
working group operate completely
differently I do think that especially
with division that I proposed earlier
there is a need now more more than ever
for these various organizations to be
working together and thinking about a
shared division and I think an
interesting problem for the next couple
of years will be starting to think about
like hey where are neutral spaces where
we can all collaborate Michael's working
on a proposal for built-in modules for
example and a big question is well who
owns the built-ins where do those
built-ins come from how do we categorize
those built-ins and you need a lot of
trust between different groups if we're
going to expect other people to kind of
respect it and the flip side is there is
a risk that if tc39 tries to specify an
overstep that people won't want to
implement the spec that is thankfully
something that's never happened but it
is a very real risk I think that every
member on our committee takes the the we
have a really large responsibility
everything works right now because
people are happy and working together
but that is fragile and could fall apart
if we don't take that responsibility
seriously want to explain a interesting
historical accident that I love story
tile that that really set us up for
success and we really just got lucky
here the first few decades of
JavaScript's existence there was only
one host which was the browser and you
think about a language that's only being
used for one purpose and the thing that
is looking back on that kind of
miraculous is that the language does not
have many browser concepts in it and
doesn't have any browser io in it even
when the language was evolving only
under pressure to serve one host it did
not the ballot the cut
boundary between the language as
computational and the host as providing
IO was maintained there's I think the
only explanation for this historically
because people didn't appreciate that
that property until there were multiple
hosts historically the only explanation
that I can see is what's called Conway's
law Conway's law is that an organization
can only create technical artifacts
whose communications structure reflects
the communications structure of the
organization the language was under
Aetna the browser was under w3c that
organizational split I think more than
anything is responsible for the language
and the browser not getting too
entangled even when nobody was viewing
the lack of entanglement as a virtue
that needed to be maintained that's a
really cool story because I didn't I
didn't know about the separation as much
until you started talking about it and
that was great well we are slowly
running out of time one last thing
do any of you have a favorite JavaScript
joke one at one of my favorites for
example not that I had any other ready
or anything was there was a developer
that said hey what is this and the other
developer said oh I tried to call about
it earlier but I was in a bind what is
this bind call okay anyway do you y'all
have any others yes dude do you want to
hear an asynchronous joke yes
[Music]
kid you promised okay one and how do you
fix a jog javascript bug you can soul it
[Laughter]
well I think with that we're done thank
you all so much
this is awesome
[Applause]