►
From YouTube: Next 10 years of Node.js - Aug 12 2020
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So
welcome
to
the
this
week's
session
on
the
next
10
years
of
node,
we'll
start
with
the
agenda
that
we
had
based
on
the
issues
tagged
in
the
issue.
A
From
our
last
discussion,
there
were
kind
of
two
two
key
things
I
think
we
should
dive
into
which
are
on
the
agenda,
and
I
guess
one
thing
I
should
mention
up
front
this
time.
We
had
agreed
to
rotate
the
meeting
times
this.
When
I
looked
at
the
schedule,
none
of
the
we're
going
to
rotate
them
using
the
tsc
meetings,
but
because
the
tsc
meetings
rotate
every
week.
This
meeting
is
every
two
weeks.
A
It
ends
up
colliding
with
the
slots.
We
would
have
rotated
to
collided
with
the
tse
meeting
and
there
was
already
another
meeting
scheduled
node
meeting
scheduled
the
other
time.
So
it
may
not
be
quite
as
easy
as
just
rotating
across
the
tsc
meetings,
but
we'll
try
and
figure
out
something,
and
hopefully
next
time,
we'll
move
to
the
next
slot
in
the
rotation.
A
A
Agenda,
if
not,
okay,
let's
move
on
to
the
first
one,
which
is
add
the
initial
constituencies
documents
so
mary
thanks
for
creating
that
pr.
I
think
when
we
discussed
last
time
we
wanted
to
get.
You
know
broader
input
from
the
node
community
on
this
before
we
landed
it.
So
I
don't
know
if
people
have
thoughts
on
that,
like,
I
guess
the
two
things
I
thought
we
should.
You
know
maybe
time
box.
The
10
minutes
today
is.
Are
we
happy?
Is
this
as
a
first
cut?
Is
there
anything
we
need
to
do
before?
A
We
say
this
is
kind
of
our
first
cut
and,
if
not
like
you
know,
what
do
we
want
to
do
in
terms
of
like
asking
other
collaborators
to
review
comment
or
you
know,
what
do
we
want
to
do
before
we
land
this
and
move
on
or
you
know,
do
we
need
to
actually
do
we
want
to
get
lots
of
broad
input
at
this
point
before
we
land
it
or
do
we
want
to
land
it
use
it
as
a
working
dock
to
kind
of
socialize
later?
What
are
people's
thoughts
on
that
front?.
A
Anybody
other
I
I'd
be
happy
with
that
too,
like
we
could
land
it
and
then
post
a
comment
in
in
the
node
team.
I
forget
what
it
is
but
like
where
we
can.
You
know
we
post
collaborator,
nominations
and
stuff
and
say
hey.
This
is
our
working
list
of
constituencies.
If
you
have
any
comments
suggestions,
you
know
reach
out,
make
prs
that
kind
of
stuff
any
concerns
with
doing
that.
A
A
Okay,
that
sounds
good
if
everybody's
happy
with
that.
So
let's
move
on
to
the
next
issue
we
want
to
dive
into
which
was
number
five,
which
was
prioritizing
technical
values.
C
C
A
A
B
B
A
E
E
And
then
we
have
a
quick
way
of
reducing
this
list
by
saying
which
one
of
us,
which
ones
are
liked
more
by
people
so
essentially
put
you,
have
three
asterisks
place
them
on
the
list:
yep
and
and
then
we
can
rank
them
essentially.
A
E
A
G
G
A
B
F
C
A
A
A
A
A
E
C
E
A
C
And
I'm
very
comfortable,
if
that's
the
direction
we
decide
to
take,
I
think,
as
long
as
we
say,
developer
experience-
and
here
is
how
we
think
you
know
what
we
mean
by
developer
experience
and
I
and
right
things
like
documentation,
approachability
fall
under
it.
I'd
be
perfectly
happy
with
that.
Yeah.
A
Experience
you
know
so
I
think
we
can
add
in
the
because
yeah
I
think
there's
some
some
very
subtle
like
I
know
I
know
the
like
mateo,
I
saw
a
twitter
post
from
you.
Sorry
I
don't
mean
to
call
you
out
or
anything
but
like
there's
a
twitter
post
that
was
kind
of
saying
like
if
we
always
optimize
for
ease
of
the
developers
use.
We
then
cause
issues
in
in
production
right.
E
E
D
A
G
E
Strike
a
balance
here
is
is
great,
because
some
security
minded
person
might
think
that
okay,
I'm
going
to
shape
there
is
a
security
vulnerability
and
I'm
going
to
shape
a
new
fix
for
that
in
node.
That
will
be
perfectly
fine
and
fixed
and
protect
and
95
99
of
the
user,
and
then.
A
E
Because
this
is
a
typical
type
of
question
that
the
tsc
is
getting
asked
all
the
time
so
right
and
those
matters
in
terms
of
the
developer
experience
the
suitability
for
cloud
deployments
and
so
on
for
iot,
like
it
comes
it's
a
typical
question
of
balancing
the
the
those
two
buckets
of
stability,
performance,
diagnostic
and
security
and
developer
experience,
so
it's
which
they
both
have
value.
So
I
don't
know
how
to
so.
E
This
is
a
disclaimer
that
I
need
to
to
to
say
loud
would
make
money
from
it
and
because
they
will
only
be
the
p
that
you
will
need
some
expert
and
pay
people
to
actually
manage
the
beast
in
production.
E
So
it's
one
of
the
greatest
things
of
node.js
has
been
so
far
has
been
that
it
has
stricken
a
good
balance
between
those
two
trends.
G
E
And
I
don't
think
we
should
break
that
right,
so
I
don't
know
how
to
say
this,
but
it's
so
that's
my
type
of
things
and
but
to
be
honest,
it's
like
that.
These
three
blocks,
like
stability,
performance
and
africa
security.
They
are
almost
like
a
second
big
title
to
some
extent
on.
E
F
One
quick
note:
michael:
did
you
just
delete
the
the
two
other
that
were
under.
F
A
A
A
A
C
A
E
It
is
I
I
kind
of
so
there
is
a
there
is
a
catch
here.
Looking
at
what
at
the
pole
on
what
we
are
talking
about.
Okay,
there
is
a
problem
of
these
will
skew
people
into
a
bar
in
in
a
known
innovation
box.
So
this
is
to
me
the
fact
that
doing
this
poll,
so
we
got
this
result
from
this
quick
fall
from
his
programmatic,
but
yeah.
A
A
A
You
know
the
top
two
priorities
are
keeping
things
stable
and
from
the
developer,
experience
making
sure
that
it's
it's
approachable,
that
new
developers
can
can
ramp
up
quickly
and
there's
probably
some
subtlety
to
explain
what
we
mean
by
developer
experience,
because
there
might
be
some
things
like
you
know,
back
to
the
point,
mateo
man
there's
a
balance
with
production,
so
it's
it's
not
necessarily
just
making
it
easy
for
the
developer,
but
maintaining
those
aspects
that
have
achieved
the
it.
You
know
it's
easy
to
pick
up.
You
can
get
started
quickly.
You
can
be
productive.
C
D
C
We
want
a
great
developer
experience
around
security.
What
does
that
mean
right?
We
want
a
great
developer
experience
around
diagnostics.
What
does
that
mean
and
to
me
that
this
is
a
pretty
they're?
Not
sometimes
they
will
be
at
odds
like
for
certain
decisions
but
like
if,
as
long
as
we
as
the
you
know
as
the
the
way
we
look
at
it
is
we're
striving
for
the
best
developer
experience
to
maintain
you
know
a
solid
security
stance,
then
I
think
we've
done
a
really
good
job.
A
Is
we
wouldn't
do
that,
because
if
it
breaks
the
developer
experience
we're
only
going
to
cautiously
make
those
kinds
of
security
changes.
E
A
A
G
A
E
C
You
mentioned:
can
I
ask
in
a
question
you
mentioned
a
few
minutes
ago
that
you're
worried
that
these
top
two
would
stop
innovation,
I
think
or
something
what
was
the
exact
words.
Is
this
sort
of
related?
Do
you
think
in
that?
Yes,.
E
That
is
what
I
want
to
call
about,
so
it's
essentially
the
tendency
of
the.
So
if
you
say
that
developer
experience
and
stability
are
your
top
most
priority,
it
means
you
know,
developer
experience
for
what
we
have
right
now,
while
this
for
me,
it
won't
work
for
the
node
community
for
the
javascript
community,
so
essentially
adopting
esm
adopting
other
technologies
like
we
can
we
get
away
with
from
doing
that
at
all
completely.
F
E
C
E
E
F
I
I
would
also
very
strongly
say
that
this
isn't
like
reflecting
on
what
we've
done
in
the
past.
At
all
I
I
would
say
that
this
is
for
this
group
of
people.
This
is
what
we
strongly
value
and
how
you
know,
given
the
context
of
this
meeting,
which
is
the
next
10
years
of
node,
that
that's
how
we
want
to
drive
things
in
the
future.
I
I
don't
think
it
has
any
impact
on
what
we've
done
in
the
past.
A
A
A
So
I
I
guess
maybe
look
back
to
the
up-to-date
and
current
apis
because
I
don't
think
going
into
like
figuring
out
past
versus
the
future
is.
Is
that
gonna
change
the
discussion
too
much?
It's
like
I,
I
thought
matteo.
You
were
suggesting
that
actually,
as
part
of
developer
experience
right-
and
I
guess
the
question
would
be.
A
E
We
need
to
do
that.
That
is
the
the
key
part
of
so
I
want
to
say
that
there
is
a
pressure
and
so
that
our
target
community
loves
new
approaches,
new
technologies,
trying
new
things
and
if
we
don't
follow
them
and
if
you
don't
provide
a
great
experience
for
those
new
things
right.
E
A
A
Now
the
diving
back
a
little
bit
to
the
comment
on
esm,
I
mean
I
think
the
values
they're
like
it
fits
into
like
the
up-to-date
and
current
apis
technology,
part
of
developer
experience
like
we
wanted
to
to
get
that
so
wes.
You
were
saying,
though,
that
we
didn't
think
we
came
up
with
something
usable
or
what
was
the.
D
C
C
Just
like
performance
can
conflict
with
developer
experience,
but
we
need
to
be
aware
that
by
adding
this
under
developer
experience,
we're
saying
yes,
we
might
be
saying
yes,
there's
a
part
of
it
that
is
developer
experience,
but
also
now
the
top
two
priorities
are
slightly
at
odds.
I
think
they
always
were,
though,.
A
But
but
but
I
I
thought
that
we'd
already
thought
they
were
were
out,
so
that
didn't
worry
me
too
much.
It's
it's
like.
If
you,
what
do
you
think
the
top
priority
was
for
the
s
esm,
shipping
web
compat
modules
like,
but
I
guess
that
that's
if,
if
we've
said
that
up-to-date
and
current
apis
as
part
of
developer
experience
is
still
like
one
aspect
of
developer
experience
was
still
our
top
priority.
C
C
We
look
at
we
look
at
shipping
current
apis
and
technologies
through
the
lens
of
developer
experience.
We
want
to
ship
esm
with
a
good
developer.
Experience
is
the
statement
and,
and
to
me,
that
is
that
would
put
these
as
two
separate
things
right.
I
do
think
it
is
important
that
we
ship
the
features
people
need
to
write
their
applications,
but
I
think
that
developer
experience
around
those
things
is
the
value
that
we're
trying
to
say
is
our
what
we're
uplifting
and
then
like
we
and
then
like.
C
E
It's
it's
so
it's
that
box
needs
to
be
put
somewhere,
because
if,
if
we
don't
call
out
that
we
need
to
like
one
of
the
things
that
so
at
the
for
a
long
time,
node.js
has
been
lagging
behind
on
adoption
of
new
web
apis
promises,
it's
a
big
topic
and
so
on
and
so
forth,
and
those
the
community
and
the
developer
experience
struggled
so
much
by
not
not
having
them
to
some
extent
even
esm.
The
community
has
struggled
so
much
by
no,
not
taking
a
stance
and
not
shipping
json.
E
E
G
A
D
E
F
E
So
it's
and
that's
not
probably
a
good
thing
to
do
so
right.
B
B
You
know
more
in
in
line
with
what
we
have
already
going,
so
wouldn't
that
be
more
of
the
maintenance
or
upgrade
side
rather
than
having
it
to
do
with
something
that
we
want
to
do
as
a
you
know,
like
a
phase
one
kind
of
thing
would
that
be
more
phase
two
or
phase
three?
That's
what
I'm
thinking.
C
E
Going
for
like
explaining
this
a
bit
forward,
it's
it's
the
conundrum
of
an
android
rejection
that.
E
It's
the
conan
room
of
another
rejection,
so
essentially
another
rejection
is
a
for,
for
most
application
is
essentially
a
security
hall.
It
impacts
it
provides
to
some
extent
good
developer
experience.
It
doesn't
crash
your
process.
So
that's
that's
good
developer
experience
for
a
lot
of
people
apparently,
but
it's
it's
adopting
new
apis.
That's
you
know
what
you
do
so
that
is
kind
of
the
key
question
I
don't
know
so
those
are
hard
topics,
but
those
are
things
that
we
need
to
work
on
essentially
anyway,
but.
A
I
think
stability
and
just
you
know,
as
I
look
back
to
how
we
have
behaved,
that's
also
something
we
really
highly
prioritize,
but
we
are,
we
have
been
flexible
in
terms
of
we
will
make
breaking
changes
and
things
like
that.
If
we
think
it's
the
right
thing
in
terms
of
developer
experience
and
and
and
so
forth,
then
I
kind
of
see,
like
you
know,
the
performance
diagnostic
security,
that
sort
of
there's,
probably
a
bucket.
We
could.
We
could
put
that
into
in
terms
of
like
like
when
you
go
to
deploy
your
application.
A
Those
are
all
in
very
important
right,
so
they're
sort
of
like
deployment,
qualities
of
service,
operational
qualities,
operational
qualities.
A
Maybe
we
don't
need
to
to
brain
to
to
figure
that
word,
but
I
think
there's
some
word.
We
could
come
up
that
that
covers
that,
and
I
think
we
do
value
those,
and
then
we
have
you
know
the
up-to-date
and
current
apis
and
technologies,
and
the
questions
like
that,
I
think
wes
you
were
getting
is
like.
Would
we
fundamentally
break
developer
experience,
stability
or
those
operational
qualities
to
get
a
new
api
in
that's
different
from?
E
Let
me
say
if,
if
so,
to
make
an
example
going
back
to
this
example,
the
module
steam
shaped,
we
backported
an
experimental
feature
in
node
12
that
is
breaking
badly.
The
community.
A
C
I
think
just
we
can
just
point
to
that
in
the
future
and
say:
look
we
have
to
revert
this
like
we've
said
these
are
our
values
and
we
value
stability
over
up
date
and
current
apis
to
me,
that
seems
like
a
reasonable
use
of
this
exercise
in
the
future
going
forward,
and
it
you
know
to
me
that
that's
why
I
don't.
I
like
seeing
this
slightly
lower
super
valuable
still
on
our
list
of
of
high
value
items,
but
it's
not
a
part
of
developer
experience
to
me.
A
Well,
obviously,
in
one
hour,
we're
not
going
to
set
the
values
for
the
pro
the
the
project,
but
I
think
coming
up
with
this
list.
That
says
like
here's,
the
starting
list
to
have
those
discussions,
like
you
know,
if,
if
most
of
the
project
values
having
something
up
to
date
versus
stability,
then
you
know,
maybe
things
will
shuffle
around,
but
we
should
start
with
what
we
think
I
mean.
I
don't
think
this
is
completely
out
of
line
with
the
like
what
I've
seen
like.
A
So,
for
example,
I
don't
think
the
modules
team
would
have
argued
to
to
make
a
breaking
change
on
purpose.
A
A
Some
of
these
things
are
never
it's
like
in
the
in
the
we.
Don't
always
do
what
we,
what
we
would
have
done
if
we
planned
it
out
right.
D
A
A
D
D
Yes,
maybe
it
could
be
something
under
lts
support.
I
don't
know
if
we
should
include
it
directly
under
stability.
G
A
C
I
I
would
actually
say
that,
while
there
are
subtle
differences,
I
think
we
should
just
put
web
api
compatibility
like
I
think
we
should
put
like
a
topic
of
like
standards,
new
apis,
up-to-date
technologies.
You
know
adoption
of
new
things
like
sort
of
bucket.
It
says
like
we're.
We
want
to
follow
what
is
going
to
make
the
platform
compatible
with
other
platforms
in
a
reasonable
way
and
and
adopt
those
things
in
a
timely
fashion,
and
that
could
include
it
pulling
things
from
web
apis
pulling
things
from
other
standards
bodies
pulling.
C
You
know,
support
for
specific
patterns
that
that
become
popular.
You
know
that
all
of
that
to
me
seems
like
a
pretty
reasonable
thing
for
one
one
right.
A
D
A
A
I
guess,
because,
like
performance
actually
has
a
bunch
of
different,
like
there's
throughput
size,
that
kind
of
stuff
right,
startup
time,
startup
time,
yes,
startup
time.
D
C
A
Yeah,
like
I
guess
it's
you
know,
are
we
I
I
guess
we
can
capture
this,
we'll
continue
to
think
about
this
and
maybe
we'll
continue
on,
but
I
think
we
have
a
a
pretty
good
first
pass
here.
You
know
in
between.
Maybe
maybe
we
can
open
an
issue
that
capture.
I
can
oh
I'll
open,
an
issue
that
captures
this
and
if
people
can
help
refine,
maybe
again
a
pr
makes
sense,
though,
like
we
could
open
a
pr
to
land
a
document.
A
People
can
comment,
and
we
can,
you
know,
fill
in
some
docs
and
stuff
like
that,
and
then
discuss
that
next
time
again
and
see
how
close
we
are
and
again
it'll
be
like
okay,
do
we
have
something
we're
ready
to
get
broader
feedback
and
input
on
and
that
kind
of
stuff,
because
I
think
there
will
be
you
know
I,
like
you,
said:
we've
we're
reflecting
the
group.
That's
here.
Hopefully
we're
not
way
off
from
the
the
larger
community,
but
you
know
obviously
we'll
need
a
lot
more
discussion.
A
Okay,
thanks
to
everybody's
time,
I'll,
take
the
action
to
open
that
that
pr-
and
if
everybody
can
take
the
action
to
you
know
continue
to
think
about
this,
help
refine
that
pr
into
a
shape
of
something
that
we're
then
ready
to
share
with
the
larger
team
and
we'll
go
from
there.