►
From YouTube: The Web Platform Podcast, Evolution of Modern JavaScript w/ Jordan Harband LIVE @ OpenJS World 2020
Description
Evolution of Modern JavaScript with Jordan Harband LIVE @ OpenJS World 2020
To say the way we use and write JavaScript has evolved since the launch of ES2015 is an understatement. Atomics, TypedArrays, globalThis, and function generators are just a few ways JavaScript has grown up to meet the needs of a growing web platform. But it's not just language that has evolved, it's our entire toolchain as we have come to rely on compiled JavaScript as the "new normal". Join for a very special episode of The Web Platform podcast as we discuss all this and more with our invited expert on all things ECMA - Jordan Harband at OpenJS World 2020.
A
B
A
We
are
part
of
the
web
platform
podcast
and
we're
super
excited
today
to
be
talking
to
y'all
about
all
things
JavaScript
with
mr.
JavaScript
himself,
Jordan
Harve
and
it
will
get
to
Jordan
in
a
bit.
But
what
we're
gonna
be
talking
about
today
is
really
how
the
language
has
changed
in
the
past
five
years,
javascript
has
all
grown
up.
A
You
know
gone
are
the
days
of
just
you
know,
inlining
your
JavaScript
and
a
script
tag,
and
so
we're
gonna
be
exploring
all
the
ways
that
the
language
has
evolved
and
I'm,
just
really
how
that's
shifted
our
just
the
culture
around
how
we
build
modern
web
applications.
So
we
have
a
lot
to
talk
about
in
40
minutes,
so
it's
a
tall
order,
Jordan,
no
pressure,
but
with
that
said,
let's,
let's,
let's
get
started
so
welcome.
Jordan
hello,
tell
us
a
little
bit
about
yourself.
Hi.
C
Thank
you,
yeah.
Let's
see,
I've
been
on
tc39
the
committee
that
writes
the
specification
for
JavaScript
since
2014,
it's
been
a
while
I've
been
an
editor
for
two
and
a
half
years
or
so.
I
maintain
a
lot
of
open
source
libraries
yeah.
Probably
too
many
and
yeah
I've
been
doing
JavaScript
a
very
long
time.
Yeah.
C
A
And
so
for
those
of
you
who
aren't
familiar
tc39.
Is
the
committee
that's
in
charge
of
its
nearing
the
technical
direction
for
the
ACMA
script?
Language
specification,
which
is
you
know,
basically
the
JavaScript
standard
and
Jordan,
has
been
one
of
the
editors
of
the
standard
since
2018.
So
you
know
we're
really
excited
to
have
him
here
today
and
so
I'm
gonna
start
with
my
first
question.
Jordan,
which
is
you
know,
a
lot
of
the
new
language
features
since
2015
I
feel
like?
Are
they
fit
into
a
gamut
of
things?
A
We
have
syntactic
sugar,
you
know
for
things
like
classes,
we
have
you
know
language
extensions,
you
know
arrays
and
strings,
and
all
these
other
cool
things-
and
we
have
a
bunch
of
things
that
look
like
it's.
You
know
for
JavaScript
on
the
server
and
so
can
you
just
talk
a
little
bit
about
like
how
you
know
how
that
kind
of
has
come
to
be.
You
know:
do
you
think
that
node
has
really
pushed
the
envelope
with
JavaScript
the
language
and.
C
Yeah
well
so
things
changed
a
lot
after
es2015
es6
right.
The
process
for
getting
changes
into
the
language
before
that
was
essentially
a
bunch
of
smart
people
in
the
room
who
had
overlapping
and
also
conflicting
priorities
would
just
kind
of
talk
about
their
ideas
and
and
there's
a
lot
of
debate,
and
you
know
arguing
and
bike
shedding,
and
it
took
many
many
years
to
get
a
standard
together.
The
previous
version
before
yes,
2015,
was
from
2011,
which
was
es
5.1.
C
So
that's
four
years
between
you
know
producing
any
specification,
but
the
process
that
that
group
came
up
with
before
I
joined,
which
would
take
effect
after
es.
2015
has
a
bunch
of
concrete
stages
which
include
specific
entrance
criteria
and
explanations
of
what's
expected
during
the
eight
stage,
and
part
of
that
is
that
there
has
to
be
shipping
implementations
before
it
lands
in
the
standard
which
was
not
the
case
before
hand.
C
So
the
there
are
things
that,
from
es
2015,
that
virtually
no
browser
has
ships,
for
example,
and
that
is
partially
because
in
the
old
stage
process
that
wasn't
a
requirement.
So
I
think
that
what
that
means
is
that
in
the
current
process,
the
things
that
land
in
the
language
have
been
vetted
to
a
much
larger
degree
and
with
a
lot
more
people
and
a
lot
more
constituencies-
and
that
includes
node
node-
has
always
been
considered
in
the
committee.
C
B
So
Amol
mentioned
okay,
one
I
did
not
realize
so
I've
known
about
the
stages,
and
things
like
that.
I
did
not
realize
that
those
were
that
new
we're
getting
things
into
the
language.
That's
because
we've
talked
about
like
specs
and
that
kind
of
stuff
on
this
show
quite
a
bit
and
I
guess:
I
guess,
just
at
the
point
I
started
paying
attention
to
that
sort
of
thing.
They
were
always
there,
so
that
I
actually
find
that
very,
very
interesting.
B
One
question
I
have
about
I
guess
like
the
specs,
and
you
know
like
needing
implementations
and
stuff,
like
that.
It
Amol
mentioned
that
there
are
two
different
sorts
of
of
things
right
there,
some
things
it
seems
to
be
largely
largely
syntactic
sugar
and
then
that
might
not
be
100%
accurate,
but
things
like,
but
with
things
like
classes
and
then
there
are
other
completely
new
things
that
aren't
you
like
really
weren't
possible.
Before
is
the
proposal
process
different
for
those
sorts
of
things
like
it's?
B
C
So
there
there
are
definitely
some
things
that
slide
through
more
easily
right,
the
one
that
was
a
real
quick
one
was
optional
catch
bindings
because
all
of
us
in
the
room
had
had
that
problem
where
we
had
this
exception,
variable
that
we
didn't
need,
and
it
was
gross
and
ugly-
and
you
know
we
just
kind
of
ignored
it
and
removing
a
binding
is
like
like
it
was
just.
It
was
kind
of
a
no
brainer
like
it
didn't.
It
wasn't
controversial
that
went
through
really
quickly.
C
There
were
some
API
methods
like
object,
dot
values
and
object,
ID
entries
that
were
able
to
get
in
pretty
quickly
because
object
that
Keys
was
already
there
there
are
complements.
There
was
already
a
precedent
of
that
triplet
of
methods
from
other
things.
It
just
kind
of
moved
through
pretty
quickly
so,
but
the
the
difficulty
for
adding
new
language
capabilities
is
making
sure
it's
impossible
to
implement
it
in
a
performant
way
right
and
the
browser's
all
in
representatives
in
the
room,
as
does
node,
and
so
we
have
to
make
sure
that
that's
the
case.
C
There's
also
a
kind
of
security
and
encapsulation
level
concerns
no
kind
of
Oh
cap
stuff
and
other
things
that
you
know
where
folks
are
trying
to
run
untrusted
JavaScript
code,
and
they
want
to
be
able
to
maintain.
The
security
of
that
like
Salesforce,
has
a
whole
platform
where
anyone
can
put
JavaScript
into
it
and
run
it
on
people's
web
pages
so
but
like,
but
with
syntactic
sugar
people
are
still
bike
shedding
about
what
it
looks
like.
C
A
That
makes
a
lot
of
sense,
Jordan,
so
I
think
promise.
All
settled
is
another
one
that
I
can
think
of
as
I.
Remember
just
learning
about
that
a
year
ago,
as
a
proposal
and
it's
already
in
the
language
now,
it's
just
I
think
that
that
went
super
fast
and
I.
Think
it's
true.
It
feels
like
you're
right,
like
some.
Some
language
features
are
just
like
a
common
sense.
A
Kid,
like
the
committee
is
made
up
of
implementers
right
so
implementers
being
folks
that
are
writing
the
compilers.
That
JavaScript
runs
on
so
folks
from
the
v8
team,
SpiderMonkey,
chakracore,
javascriptcore,
so
there's
implementers
and
then
there's
you
know
just
like
language
nerds.
You
know
sorry
to
find
a
better
better
word.
You
know
the
representatives
from
other,
you
know
lots
of
companies
and
then
then
you
have
kind
of
practitioners
right.
So
you
have
like
a
web
developers.
A
C
Actually,
I
think
that
the
tensions
you're
describing
is
it's
sort
of
a
game
theory
right.
The
browsers
for
the
like
the
browsers,
don't
have
to
follow
the
standard
right
I
mean
there's
no
like
like
use
of
force
to
make
them
do
it.
They
are
choosing
to
do
it
they're
choosing
to
do
it
because
they
think
that
it
makes
the
web
better
for
everyone
and
they
think
that
it
mean
will
make
their
users
happier
and
it
also
I
think
frees
them
up
to
compete
on.
C
You
know
other
things,
then
what's
javascript
right,
they
can
compete
on
performance,
they
can
compete
on
synchronization
features
and
things
like
that,
but
there's
because
they
are
choosing
to
comply
with
the
specification.
That
also
means
that
folks,
that
aren't
browsers
can't
sail
into
the
committee
and
be
like
screw
you
browsers.
This
is
what
we
want
in
the
language.
So
it's
a
it's
kind
of
a
delicate
dance
where
the
browser's
don't
want
to.
C
For
many
reasons
they
don't
want
to
say
to
kind
of
ignore
opinions
that
aren't
their
own,
but
neither
can
anyone
ignore
browser
opinions,
and
so
everyone
has
to
sort
of
convince
everyone
in
the
room,
browsers
and
community
folks
alike,
and
there's
often
overlap
between
those
between
that
the
feature
being
proposed
is
good
for
JavaScript,
but
also
good
for
the
web,
because
javascript
is
larger
than
the
web,
but
the
web
is
very,
very
large.
So
it's
it's.
B
Very
cool
yeah
that
is
Internet
I'll,
like
I'm,
realizing
a
lot
of
things
in
this
discussion
already
that
I
didn't
really
think
about,
like
the
fact
that
you
just
said
he's
like
the
browser's,
don't
have
to
do
what
we
say
to
do,
and
that
makes
sense,
but
I
never
thought
about
that
before.
But
it's,
but
it's
absolutely
true.
That's
that's
very,
very
interesting.
Pretty.
A
A
A
A
Actually,
another
really
interesting
thing
about
Safari
and
please
correct
me
if
I'm
wrong
on
this
Jordan
I
think
folks
from
the
JavaScript
core
team.
If
I
remember
correctly,
when,
when
they're
implementing
new
features,
they
have
really
strict
performance
standards,
and
so
you
know
they
can't
implement
something
and
have
the
engine
be
affected
negatively
at
all,
and
so
they're
really
performance
fanatics
and
that's
really
not
the
case
and
in
v8
I.
Think
it's
a
little
bit
more
at
the
Wild
West
there,
but
is
that
true.
C
A
C
Mean
the
the
sense
I've
gotten
from
speaking
to
the
implementers
of
JSC
and
v8,
and
so
on
is
that
they
all
have
different
tolerances
for
impacting
performance.
But
there
are
a
lot
of
kind
of
scenarios
or
code
paths
where
none
of
them
will
will
work.
Any
slowdown
of
any
kind
I
mean
one
of
the
big
reasons
that
decorators
didn't
advance
in
its
latest
form
was
because
a
number
of
browser
engines
were
concerned
that
they
wouldn't
be
able
to
implement
it
in
a
way
that
would
avoid
slowing
down
non
decorated
classes.
C
Right
like
they
might
have
been
willing
to
accept
decorated
classes
being
slow,
but
not
regular
classes
like
getting
slower,
so
I
think
that
the
they're
all
pretty
performance,
sensitive
I
mean
this
is
like
I
was
saying
before
it's
a
bit
of
a
game.
Theory
right:
the
browsers
are
all
sort
of
competing
with
each
other.
They
all
want
people
to
use
them,
and
that
means
that
they
have
to
work
the
best
on
what
on
all
the
web
pages
somebody
likes
and
the
best
is
never
going
to
be
in
slower.
B
So
talking
more
about
the
the
language
itself,
so
the
language
seems
to
be
used,
maybe
differently
by
save
library,
authors
and
by
end-users,
and
there
are
certain
features
that
seem
like
they
are
might
not
be
used
very
often
by
me,
for
example,
it
just
a
just
a
just
a
lowly,
well
web
developer,
trying
to
build
a
website
not
used
often
by
me,
but
might
be
used
by
some
of
the
big
framework.
You
know
like
some
of
the
big
frameworks
or
something
like
that.
B
C
Everyone
loves
to
use
it
directly,
but
it
was
not
never
intended
for
that,
and
so
like
like
there's
a
lot
of
features
like
like
symbols,
for
example
they're
their
primary
value
is
in
avoiding
name
collisions
and
the
is
particularly
important
for
protocols
like
promises
have
dot,
then,
which
means,
if
you
name
a
thing
with
a
dot,
ven
method.
You've
just
accidentally
made
a
thing.
That's
like
a
promise
right,
but
if
you
use
it,
if
you
have
a
symbol
for
things
like
symbol,
dot
iterator
for
the
iterable
protocol,
you
can't
accidentally
make
an
iterable
right.
C
We
all
want
to
make
them
both
better,
but
it's
important
to
try
to
find
a
balance
where
you're,
not
sacrificing
the
utility
for
one
group
in
order
to
serve
the
other
group
and
there's
something
the
web
has
called
the
priority
of
constituency.
Is
this
I
think
is
really
important.
That
is
brought
up
a
lot
in
tc39,
but
isn't
one
of
our
like
official
principles
or
anything
and
I?
C
Don't
have
it
pulled
up
in
front
of
me,
but
it's
something
like
users
above
authors
above
implementers
above
spec
writers,
and
it's
it's
basically
saying
like
never
make
the
spec
easier
to
write
at
the
cost
of
like
making
it
harder
to
implement,
never
make
the
implementation
better
at
the
cost
of
making
it
worse.
For
people
who
write
the
code
never
make
writing
the
code
easier
at
the
cost
of
making
it
worse
for
people
who
use
the
web
right,
like
it's
I,
think
that's
my
understanding
of
it
anyway
and
I.
C
Think
thinking
about
problem
about
trade-offs
in
that
context
is
really
useful
because
it
makes
it
clear
when
you
are
optimizing
for
the
wrong
thing.
The
thing
I
say
often
is
like
don't
optimize
for
writing
code
optimize
for
reading
and
understanding
it
because
you
write
it
once
and
you
read
it
and
maintain
it
a
million
times
right,
and
but
it's
really
easy
to
make
writing
your
code
quicker
and
it
makes
it
harder
to
understand
later.
You
know.
So
it's
the
same
challenged
with
language
features.
A
C
A
Yeah,
that's
powerful,
but
but
but
kind
of
getting
to
the
you
know.
Danny's
earlier
point
around
my
language:
I
mean
things
like
symbols.
For
me
you
know
they
they're
they're,
it's
just
a
lot
of
things:
I
think
that
are
either
misunderstood
or
underutilized,
and
perhaps
that's
okay,
because
maybe
that
was
the
intention,
but
you
know
for
mass
consumption.
But
but
if
you
feels
like
there
are
elements
of
the
language
which
are
certainly
they
feel
very
much
oriented
towards
people
that
are
creating
libraries
right.
A
So
a
pro
proxies,
it's
another
good
example
of
that,
and
so
you
know
any
like
not
that
I
think
there's
analytics
on
this
per
se,
but
you
know
I
mean.
Does
it
make
sense
that
there's
you
know
80%
of
the
people
or
most
people
are
using
like
20%
of
the
language
or
what
a
perverse
is.
You
know
I'm
just
just
curious
like
if
there,
if
you
have
thoughts,
I
mean.
C
Unless
you
understand
all
those
concepts
which
are
beyond
me
so,
like
I,
think
it's
fine,
because
it's
adding
a
new
capability
right
like
shared
array
buffers,
that's
you
know,
that's
not
a
thing
that
most
people
are
gonna
run
into,
but
if
it
wasn't
there
or
if
it's
then
there's
a
lot
of
cross
kind
of
cross,
threading
speed
ups,
that
libraries
won't
be
able
to
do
in
the
future
right
like
a
shared
array.
Buffers
are
around
for
long
enough,
then
things
like
react
or
whatever
will
be
able
to
speed
up.
C
You
know
rendering
and
stuff
like
that.
I
don't
know
so
I
think
it's
okay
to
do
that
because,
like
the
other
thing
on
the
web,
is
we're
working
on
a
long
time.
Scale
right
like
features
that
ship
now
websites,
unless
they're,
fully
trained
spy
level
websites
can't
really
ship
them
for
many
years.
There's
still
plenty
of
websites
that
have
users
on
ie9
yeah.
A
Yeah,
no,
no,
that's
that's
a
really
good
point.
I
mean
I
think
we
could
talk
for
hours
about
like
the
bubble
with
modern
web
dev
and,
like
yeah
I,
think
it's
I
think
someone
has
put
up
a
photo
recently
where
it's
like
you
know:
here's
the
reality
of
the
web,
most
of
its
still
on
jQuery,
here's
the
reality
of
the
jobs.
Most
of
them
want
react
developers.
You
know.
B
A
Into
what
Danny
I
wanted
to
talk
about,
which
is
tooling
right,
so
we
have
all
this
like.
We
have
kind
of
made
JavaScript
impossible
for
newbies,
it's
modern
drama
script.
What
or
the
thing
that
we
call
modern
JavaScript
right,
so
we
it's
like
tooling,
it's
not
not
even
optional,
tooling
required
for
the
most
part
and
there's
certainly
a
movement
and
one
that
I
wholeheartedly
support
and
I'm
excited
about.
If
people
trying
to
kind
of
you
know
say
you
know,
I
don't
need
it.
A
I
want
to
try
to
build
things
without
bundlers
without
transpilers
like
that's
great
right,
but
but
ultimately
that's
just
not
the
reality
that
you
see
as
mainstream
adoption.
So
like
what
are
your
thoughts
on
that
I
mean
it's
it's
kind
of
scary
and
also
awesome
at
the
same
time,
but
also
I
can't
Arab
terribly
terrifying.
For
me,
I
mean.
C
That's
that's
not
I'm!
Sorry,
that's
that's!
Not
even
the
right
turn.
That
is
a
that
is
just
an
an
inordinate
amount
of
work
in
order
to
make
sure
that
a
webpage
does
not
exclude
users
and
I
really
think
accessibility
is
the
thing
that
people
should
focus
on
here
and
not
to
link
complexity
when
you're
making
a
website
who
are
you
excluding,
because
it's
always
gonna
be
somebody
right.
It's
fine.
C
If
the
answer
is
people
without
computers
right
like
maybe
you
can't
do
anything
about
that,
but,
like
you
know
that
you're
never
excluding
nobody,
so
you
have
to
decide
who
you're
comfortable,
excluding
and
there's
a
lot
of
people
who
have
slow
internet,
older
machines,
cheap
phones,
you
know
that
just
can't
afford
or
don't
know
how
to
upgrade
things,
their
browser
or
their
machine
and
the.
If
you
are
handwriting
all
of
your
code
and
not
using
any
tooling,
you
are
excluding
a
very
large
number
of
human
beings
off
the
internet.
C
They
all
matter
so,
like
the
thing
that
I
think
we
really
get
about
tooling
and
that's
often
often
missed
in
these
discussions
of
people
trying
to
produce
the
complexity
is
build.
Tooling
allows
you
to
not
have
to
think
about
it
and
yet
still
support
browsers
that
you
aren't
even
capable
of
testing
right.
It's
fine.
If
you
don't
want
to
support
ie8,
let's
say
but,
like
the
reason
your
site
doesn't
work
in
IE
8
shouldn't
be
a
trailing
comma.
C
That
is
a
completely
ridiculous
reason
for
your
site
to
break
there's
lots
of
great
reasons
for
your
site
to
break.
Let
it
be
one
of
those
right
and
a
build
tool
and
nothing.
You
know
nobody's
really
worried
about
i8
anymore,
but
like
a
build
tool
that
strips
trailing
commas
was
a
pretty
easy
low-hanging
fruit
back
at
that
time,
and
similarly,
now
like,
if
you're
just
typing
in
arrow
functions
and
you're
shipping,
that
to
browsers
I
mean
unless
you
need
the
very
few
parts
of
arrow
functions
that
aren't
syntactic
sugar.
C
A
A
If
the
JavaScript
you
write
and
the
drama
scripts
to
production,
matched
in
the
sense
that
you
you
know
you
had
to
wait
until
browsers,
implemented
things
you
know
or
you
or
you
write
your
code
in
a
way
that's
protective
or
whatever
like,
but
but
you
know
like
do
we
need
to
use
the
latest
and
greatest
and
greatest
JavaScript
like
in
web
applications
that,
to
be
quite
frank
like
it's
just
you
know,
you're
making
rest
calls.
You
know
you're
you're,
fetching
data
you're
entering
stuff.
Like
you
know,
most
people
are
not
doing
anything
super
fancy
yeah.
C
A
C
Of
the
time
it
takes
no
extra
effort
for
me
to
do
that
when
it
does
I
may
decide
not
to
do
it,
but
like
it's
just
easy
and
yes,
I,
don't
get
to
use
arrow
functions
and
nice
new
syntax,
but
I
don't
have
to
deal
with
any
tooling
complexity
either.
Now
that
said,
that's
not
a
trade-off
that
most
people
seem
willing
to
make.
Everyone
really
likes
the
new
shiny
and
they
do
not
want
to
be
forced
to
write
what
they
see
as
outdated,
obsolete
legacy
code.
C
A
C
A
A
I'm
gonna,
no,
no,
that
that
makes
sense
or
I
just
a
last
joke
that
I
want
to
say
again:
I
I'm,
like
I,
always
have
to
make
really
corny
jokes
on
this
show,
because
you
know
you
know,
because
anyways,
but
my
corny
joke
is
that
you
know.
Web
developers
are
a
really
self
select
group
of
people
and
they
typically
lean
towards
new
bleeding
edge.
You
know
so
I
think
it's
a
lot
to
ask
web
developers.
You
know
people
who
live
their
life
on
the
freaking
edge
of
the
world
to
wait.
A
B
What
this
leads
in
really
well
to
the
next
thing
that
that
I
wanted
to
talk
about,
which
is
about
specific
tools,
so
specifically,
I
want
to
talk
about
babble,
so
transpilers
have
been
around
for
a
while
I
just
had
it
on
to
my
tongue.
Tracer
tracer
was
around
before
babble
as
like
I.
Don't
know
like
that.
You
know
not
a
ton
of
people
use,
but
how
kind
of
marring
stuff
we
talk
at
the
beginning,
respects
and
ease
of
use
for
developers
that
want
to
use
shiny,
new
things
without
impacting
end-users.
B
How
has
Babel
affected
these
standards
process
or
has
it
affected
it
at
all,
I'm
asked
her
to
say
like
before
there
were.
You
know
like
there
were
no
stages
before
now.
We
now
you
can
just
go
into
babel
presets
and
be
like.
I
want
to
use
things
that
are
at
a
stage
zero
or
something
like
that.
If
I
want
so,
can
you
just
speak
to
that
a
little
bit
yeah.
C
C
I
actually
was
vehemently
opposed
to
transpilers.
That
was
my
position
for
a
long
time.
I
I
did
not
like
it
I
didn't
like
looking
at
the
output
and
seeing
that
it
was
gross.
Even
when
source
maps
came
like
it,
you
know
it
isn't.
It
doesn't
totally
fix
it,
but
I
think
that
the
the
ability
for
syntactic
features
to
get
feedback
before
they
actually
land
in
the
browser
and
are
never
able
to
be
removed
right
because
we
can
never
break
the
web
right.
C
Then
I,
the
Space
Jam
website
from
95
has
to
work
forever
like
that
is
the
mantra
of
the
web.
Right
do
not
break
the
web,
so
it's
being
able
to
get
the
sort
of
feedback
on
syntax
before
its
final.
It's
really
critical.
It's
not
as
big
a
deal
for
I
mean
Babel,
doesn't
have
only
really
transpiled
syntax
right.
The
rest
is,
you
know
shims
and
polyfills,
and
you
don't
need
Babel
for
that.
C
It
also
helped
persuade
detractors
because
a
lot
of
people
have
intuitions
about
how
confusing
syntax
is
gonna
be
or
how
easy
it's
gonna
be,
and
often
those
intuitions
can
be
wrong
in
both
directions
so
for
class
fields
we
had
five
years
of
you
know
tens
of
thousands
of
developers
using
it,
putting
it
in
documentation
for
public
fields
anyway,
right
and
and
understanding
how
it
worked.
And
so,
when
folks
said
well,
that's
gonna
be
unintuitive,
because
it
violates
this
expectation.
We
had
a
whole
bunch
of
like
use,
actual
usage
to
show.
No,
it's
not
actually
confusing.
C
Maybe
it
confuses
you,
but
it
doesn't
confuse
most
people
right
and
that
ways
into
the
discussion,
and
you
know
without
that,
that
research
right
it's
it's
hard
to
know
and
like
I
mean
we
never
really
know
right.
All
these
are
guesses,
we're
all
trying
to
make
the
best
guess
as
possible
for
what's
good
for
the
language
and
the
more
feedback
and
information
we
have
the
better
decisions
we
can
make
and
I
think
Babel
helps
with
that.
B
I
want
to
clarify
one
thing
that
you
said
before
we
move
on
because
I
know
we're
I
said
we're.
Also
you're
like
her.
It
feels
like
time
is
slipping
away
very
quickly,
so
so
you
said
that
polyfills
can
actually
count
as
implementation
in
order
to
get
to
stage
and
work
to
get
to
switch
four
okay
yeah.
So
so
because
when
I
thought
he
said,
implementation
and
I
had
assumed
that
meant.
Oh,
you
need
like
a
like
a
browser
implement
earth
at
a
JavaScript
engine
implementation
to
do
it,
but
you're
saying
that
is
not
the
case.
B
C
C
Essentially,
I
think
the
exact
wording
is
to
shipping
implementations
such
as
a
browser
behind
that
it's
not
behind
a
flag
right,
but
it
really
depends
on
what
the
proposal
is
and
I've
tried,
suggesting
things
like
defining
risk
areas
and
saying,
like
these
risk
areas,
need
these
kinds
of
implementations
and
so
on.
But
it's
really
tough
to
get
process
changes
in
some
times,
but
essentially
the
lake
for
object
that
values
an
object
that
entries
nobody
was
concerned
about.
C
Implementing
those
there
wasn't
like
it
was
just
kind
of
it's
gonna
be
easy
and
fast
to
implement,
so
the
polyfills
for
it
that
I
published
were
able
to
count
as
one
of
the
implementations
like
one
browser
and
the
polyfill
covered
it,
but
for
like
async/await
Babel's
implementation
doesn't
count
right
like
in
that
in
that
regard
right
it
helps
you
in
form
the
design,
but
it's
not
sufficient
to
say
yes,
this
can
be
implemented.
Performant
ly
so
I
would
say
generally
for
syntactic
features.
A
So
we've
only
got
five
minutes
left,
there's
so
much
to
talk
about
we'll
just
have
to
have
you
back
again
and
to
talk
about
other
pages,
but
I'd
love
to
dig
into
it's
just
one
specific
feature
that
I
think
is
20.
Yes,
20
20
global.
This
so
I
think
this
it's
kind
of
a
fascinating
I
just
was
wondering
if
you
could
kind
of
give
us
an
overview
of
what
the
context
is
and
I.
Think
for
me,
what's
interesting
is
how
I
think
the
growth
of
JavaScript.
You
know
in
the
browser
we're
using
more
JavaScript.
A
So
now
we
need
to
take
things
too
off
the
main
thread
so
now
we're
using
web
workers
and
service
workers,
and
you
know
we're
caching
things
and
in
a
strategic
way.
You
know
that
has
kind
of
led
to
this
need
to
kind
of
have
like
realms,
and
you
know
I
think
these
are
things
that
I
think
the
average
web
developer
doesn't
think
about,
and
you
know,
I
would
really
love
to
yeah.
Just
if
you
can
kind
of
talk,
walk
us
through
global
this
and
sure.
C
A
C
I
mean
this
one
is
a
bit
of
a
saga,
so
there
there
has
not
before
this.
There
wasn't
any
wick
thing
in
the
language
that
referenced
the
global
right
like
which
in
browsers,
you
could
get
it
with.
You
could
get
at
it
with
window
and
in
node
you
could
get
it
with
with
global
and
in
like
web
workers
and
frames
and
stuff.
C
You
could
get
it
with
self,
but
there
was
never
one
consistent
way,
so
you
always
had
to
do
a
bunch
of
feature
checking
to
figure
out
which
environment
you're
in
in
order
to
get
the
global.
So
it
seemed
like
a
pretty
simple
idea
that
everyone
was
on
board
with
let's
just
put
a
thing
in
the
standard
that
can
do
this,
and
there
was
a
bit
of
a
churn
trying
to
figure
out
some
of
those
security
concerns.
I
had
mentioned
much
earlier
in
the
the
podcast,
but
the
once
those
had
been
kind
of
overcome.
C
The
the
main
concern
was
the
name
of
it
and
unfortunately,
the
name
global,
which
is
the
one
everyone
wanted
and
was
the
best
was
not
web
compatible.
It
broke
like
Flickr
or
something
because
some
old
version
of
I
don't
know
a
moment.
Je
s
like
it
was
just.
There
was
some
some
craziness
that
just
broke
major
websites,
so
they
couldn't
ship
it
and
so
Russia.
Yes,
I
mean
it
was.
A
C
Think
they
should
did
just
I
think
it
was
just
in
like
their
developer
channel
or
something,
but
they
very
quickly
got
a
report
that
it
was
broken.
Okay
and
so
now,
I'd
like
at
that
point,
I
had
to
figure
out
how
do
I
name
this?
What
do
I
name
it
and
so
I
came
up
with
I
meet,
but
I
wanted
to
get
before.
I
tried
to
ship
it
again,
I
wanted
to
get
data
as
to
figure
out
what
was
actually
compatible.
C
So
I
came
up
with
a
list
of
names
by
talking
privately
amongst
the
tc39
delegates
and
some
folks
on
the
public.
Github
repo
had
thrown
some
names
into
that
as
well,
but
the
browser's
didn't
want
to
take
my
list
of
20
names.
They
wanted
like
four
or
something
so
I
had
to
just
arbitrarily
choose
which
ones
to
gather
data
on
and
I
got
that
data
and
then
I
presented
it
and
we
picked
one
of
names
and
global.
This
was
the
name
that
we
went
with
like
a
few
months
after
we
decided
on
that.
C
C
B
B
C
Yeah
I
mean
my
twitter,
handle
is
ljh
ARB
and
it's
the
same
on
github
and
virtually
everywhere
else.
You
can
email
me
pick
a
site.
You
can
find
me
on
I
or
C
in
the
like,
there's
a
bunch
of
channels
on
freenode
I'm
in
the
node
slack
in
the
babble
slack.
You
know
just
kind
of
look
for
my
handle
anywhere
and
feel
free
to
reach
out
my.