►
From YouTube: 2020-04-08-Next 10 years of Node.js
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
node.js
next
10
team
meeting
for
april
8th
2021,
we
were
just
having
a
discussion
as
as
people
kind
of
joined
the
meeting
we
weren't
sure
if
we
were
going
to
have
enough
for
the
meeting.
So
what
we
do
so
we're
we're
starting
the
live
stream.
A
couple
things
I
want
to
just
mention
before
we
move
back
to
the
conversation
that
we
were
having
the
first
one
was,
is
that
we've
had
about
500
responses
to
our
survey,
so
I
think
that's
doing
pretty
good.
A
A
Okay,
if
that
sounds
good
I'll
go
ahead,
and
let
rachel
know
that,
but
I'm
really
happy
and
thanks
to
anybody
who's
listening
like
for
people,
who've
responded.
That's
a
great
response
to
have.
2500
people
give
us
that
data,
and
so
we
should
have
that
in
the
next
few
weeks
to
look
at
and
use
to
to
validate
the
work
that
we've
been
doing
here.
The
second
one
was
it's.
A
You
know
we
moved
the
meeting
to
this
time,
but
it
seems
like
it's
more
challenging
to
a
number
of
the
the
members
and
so
I'll
take
the
action
to
open
a
new
issue
to
move
the
time
to
some
other
time,
because
the
last
few
times
we
we
haven't
really
been
reaching
critical
mass
and
then
three
we'll
move
back
then
to
the
discussion,
and
I
think
this
came
out
from
some
of
the
discussion
in
the
earlier
tsc
meeting
around
primordials
and
security
and
it
led
to
the
discussion
around
security
fits
in
and
and
trade-offs
and
all
that
kind
of
stuff
in
terms
of
the
next
10,
and
I
think
that's
a
it's
a
very
good
thing
for
us
to
to
factor
in
because
I
don't
think
we've
raised
that
as
a
as
one
of
the
things
which
could
be
critical
to
the
you
know
the
next
10
years
of
evolution
of
node
in
terms
of
not
necessarily
the
specifics,
but
that
we
have
a
good
handle
on
what
our
model
is.
A
So
I
think
back
to
you
bradley
you
were,
you
were
saying
sort
of
there's
the
trade-off
in
terms
on
the
security
side
of
things
right.
B
B
So
we
do
have
the
constituencies
and
whenever
two
constituencies
are
all
at
odds
with
each
other,
individuals
could
have
different
priorities
for
each
of
the
constituencies
right.
A
B
In
the
previous
call,
we
had
a
a
priority
of
performance
over
a
priority
for
robustness
or
security.
However,
you
want
to
see
it.
B
We
don't
have
a
clear
definition
of
security
in
node
chrome
has
a
very
specific
definition
of
security,
so
things
like
almost
all
the
mpm
cves
are
not
considered
security
problems
by
the
chrome
project,
because
chrome
has
scoped
it
just
to
basically
exploits
on
their
code
generation
side
of
things.
So
if
your
website
has
a
bug
and
it
leaks
credit
cards
because
of
some
usage
of
a
javascript
api,
they
would
never
consider
that
a
security
problem.
B
This
was
brought
up
briefly
in
the
previous
tsc
meeting
just
a
little
bit
ago
that
if
people
do
weird
things
in
their
third-party
modules
like
is
that
something
that
node
needs
to
consider
a
security
problem
and
like
we
don't
have
a
clear
definition
of
what
that
is.
B
B
So
we
do
have
that
open
pr
on
node
about
making
policies
more
compatible
with
import
maps
and
basically
no
security
person
ever
wants
you
to
use
that
pr's
features.
B
A
A
To
the
java
security
model
and,
like
you
know,
as
far
as
I
understand,
most
people
run
with
that
disabled
because
in
the
environment
that
they've
they're
running
it
in
it's,
not
an
it's,
not
an
issue
to
do
that
right,
and
so
you
know,
while
on
on
the
face,
the
people
might
be
like
well,
why?
Why
could
you
just
disable
the
security
manager
right?
It
actually
makes
sense
for
a
large
number
of
deployments.
B
Yeah
so,
like
you
said,
most
people
by
default
run
without
any
sort
of
sandboxing
or
stuff
like
that,
even
if
you
run
with
sandboxing
by
default
kind
of
what
dino
does
people
tend
to
just
enable
the
flags
that
make
it
run,
so
you
might
still
have
eslint,
you
know
using
http
just
just
because
some
portion
of
it
does
or
you
ran
some
plug-in.
That
does
for
some
reason,
so
security
features
are
almost
always.
Opt-In
and
performance
features
are
almost
always
opt-out
in
some
way,
and
so
these
are
very
different
approaches.
B
At
least
in
javascript,
so
I
think
what
we
could
do
is
like
darcy
recommended.
We
write
up
some
documents
of
use
cases
where
a
compromise
made
sense
so
that,
instead
of
going
through
and
eventually
bubbling
up
to
the
tsc
and
just
getting
kind
of
individual
opinions,
they
can
think
more
towards
what
compromises
could
be
had.
Rather
than
a
blanket
statement
of
we
should
or
we
should
not.
C
I'm
going
to
drop
here,
but
just
to
top
up
on
that
like
and
my
comment
that
I
made
there,
it
might
be
good
just
just
as
a
practice
start
documenting
when
we
know
to
identify
when
we
know
that
there's
two
of
these
values
that
we've
identified,
let's
say
performance
and
security
that
are
at
odds
in
pr
and
some
set
of
work,
that's
being
presented
and
when
we
choose
like
like
we
decide
like
you
know,
speed
is
going
to
win
over
here.
Performance
is
going
to
win
over
here.
C
We
just
document
that
somewhere
and
we
just
continue
to
like
like
create
a
collection
of
data
decision
making
data
like
data
set,
so
that
over
time,
like
really,
we
don't
have
to
like
draw
a
line
in
the
sand
today.
But
we
could
really
say:
what's
the
project
actually
care
about
and
if
we
just
document
the
decision
making
at
least
we'll
you
know
in
a
year
from
now,
you
would
see
hey
look.
It
seems
that
we
always
care
about
performance
over
security,
like
that.
C
Just
the
dis
way
that
we're
making
decisions
that
just
naturally
comes
out
of
that
data
set
like
if
we
start
documenting
you
know
you
know
that
right.
So
I'm
not
sure
how
we
can
do
that
or
if
it's
just
you
know
in
prs,
we're
always
saying
that
this
is
a
feature
that
is
improving,
let's
say
performance
or
through
improving
stability
or
it's
improving.
C
You
know
whatever
it
is
and
start
documenting
like
the
and
labeling,
even
maybe
prs
that
way
and
and
then
at
least
we'll
have
like
the
information
like
about
what
it
seems
like
organically
is
happening
versus
trying
to
you
know,
impose
like
yeah,
impose
sort
of
like
values,
sort
of
see
what
the
organic
values
are,
because
we
just
don't
know
today,
we
don't
know
why
things
are
winning,
but
maybe
we
can
see
a
trend
if
we
start
to
bubble
up,
like
the
you
know
that
data,
so
that
was
kind
of
like
my
idea,
with
hey
at
least
right
now.
C
We
could
also
document
some
historical
use
cases
where
we
we
see
these
two
things
were
at
odds
and
what
one
but
be
good
just
to
as
a
practice
from
here
on
out
start
to
try
to
document
each
time
that
there
was
like
you
know.
Obviously,
like
folks
had
lots
of
discourse.
It
wasn't
like
wasn't
an
easy
pr
to
like
get
pulled
in.
There
wasn't
a
future
that
just
landed
like
everybody
agreed
on.
C
A
I
just
there's
a
summer
a
summary
of
what
you're
saying
I
think
we
may,
as
a
group
say,
one
of
the
key
things
for
continued
success
is
to
is
to
figure
out
how
to
make
the
you
know
the
processes
and
data
and
all
that
kind
of
stuff,
for
making
those
to
make
trying
to
make
those
decisions
easier
and
based
more
on
past
experience
versus
you
know,
an
individual
discussion.
Every
time
kind
of
thing.
C
Yeah,
I
just
want
to
see
the
trend
like
like
I
would
love
to
see
just
like
100
decisions
were
made
in
the
project
in
the
last
month
and
and
they
reflected
on
this
category
like
performance
or
they
like
they
like
leaned.
This
way
against,
maybe
something
else
like
like
right
like
if
there
was
that
if
there
was
two
competing
things
that
like
he's
like
what
won
out
each
time
so
yeah
I
gotta
drop
but
yeah
talk
to
you
all
soon.
Okay,
thanks.
A
A
Anymore,
you
know
if
we
come
out
with
like
here
the
top
five
things.
The
project
we
think
is
important
for
the
for
the
ongoing
success,
and
this
is
one
of
them.
Then
you
know
that
might
bring
some
attention
to
like
okay.
What
is
it?
I
don't
know
what
the
answer
is:
it's
practical
but
like,
okay,
let's
think
about
that
and
see
if
we
can
move
forward.
B
B
Node
weekly
or
something
yeah
that
kind
of
stuff
and
blog
posts
things
like
that.
A
lot
of
them
talk
about
new
features,
a
lot
of
them
talk
about
performance
and
they
also
talk
about
security
releases.
B
There
are
very
few
that
discuss
the
details
of
security
releases,
which
is
fine,
but
I
think
there's
some
interesting
stuff
that
we
could
do
there
where
just
like.
Instead
of
going
through
and
being
proactive
about
it,
we
could
be
reactionary
and
just
be
like.
Oh,
this
was
interesting
enough
that
it
kind
of
got
spread
around
the
community.
We
should
document
why
afterwards
right,
because
I
think
being
proactive
about
it-
is
a
lot
of
effort.
B
Yeah
so,
and
that
could
lead
to
people
feeling
more
like
we're
engaging.
So
like
people
were
interested
in
this
topic
and
then
we
could
be
like,
since
people
were
interested
in
this,
we
can
explain
why.
B
So
mateo
I
keep
picking
on
him,
but
he
went
through-
and
he
kind
of
explained
this
http
regression
this
past
week
and
how
he
found
it.
What
he
thought
it
was
and
a
good
example
of
this
is
like
the
performance
regression
commit
for.
One
of
them
was
actually
the
the
message
of
the
commit
was
not
the
correct
sub
system
right.
B
A
B
Oh
literally
debug
log,
when
you
make
one
it
gives
you
a
callback
function
to
replace
it
after
its
first
use.
That's
it!
It
was
just
missing
that.
A
A
B
A
B
A
B
B
A
B
A
Yeah,
I
think
I
think
in
like
mateo's
major
comment:
was
that
we're
not
getting
the
right
people
cc'd
on
them,
and
so
I
I
don't
know
if
that's
what,
where
the
like,
the
the
the
prefix
not
being
right
part,
is
the
concern
it's
like.
How
do
we
make
sure
that,
if
we're
changing
code
in
http,
that
team
gets
to
take
is
aware,
gets
to
take
a
look-
and
you
know,
does
the
sniff
test,
because
they
can
probably
do
the
best
job
on
that
right?.
B
So
this
is
also
interesting
here,
because
this
specific
commit
is
like
it's
it's
the
golden
child,
it's
it's
like,
even
it's
in
http,
but
the
problem
comes
from
util
and
it's
labeled,
something
else.
It's
it's
like
just
absolute
chaos,
which
makes
it
amazing,
because
it
gives
you
a
lot
more
thought
process
to
work
through.
You
have
like
identify
if,
if
the
right
people
reviewed
this
pr,
that
should
probably
be
step
one
and
just
go
to
them
so
that
you
can
go
there
before
you
escalate
it
to
the
tsc.
C
B
B
A
B
A
Okay,
just
also
looking
at
the
the
other
things
we've
been
working
on
in
terms
of
the
technical
brainstorming
list.
I
think
we've
got
some
more
feedback
in
terms
of
the
the
the
board
that
we
posted
for
the.
A
Time
yeah,
I
definitely
do
see
and
I
see
more.
Let
me
just
sort
order
by.
A
A
A
Okay,
so
that
seems
to
be
like
yeah.
You
know
that
that
we
had
three
from
the
the
group
when
we
brainstormed
and
it's
up
to
12.
serverless
webassembly
has
obviously
got
a
fair
amount.
A
B
A
A
Commented
so
I've
added
your
input
yeah!
Please
do
so!
I'm
just
commenting
on
the
the
discussion
item
that,
like
in
about
a
week
we'll
start
to
working
with
the
results
and
so
that
in
advance
for
next
meeting,
we
can
actually
go
through
it
as
a
larger
team
and
review
that
and
figure
out
what
we're
gonna
do.
Based
on
that.
B
Yeah,
I
can,
you
know,
open
up
a
couple
of
issues
and
I
think
maybe
go
ahead.
I
think
we
need
to
split
out
reactive
versus
proactive
workflows
entirely.
A
B
Which
is
kind
of
part
of
the
model
itself,
we
can
open
up
one
on
a
playbook
for
investigating
these
conflicts.
I
would
say,
because.
A
I
think
I
I
think
that's
a
good
like
that's
a
part
of
the
solution,
but
I'd
try
and
also
just
say,
like
here's,
the
problem
that
we
think
is
important
to
solve
for
ongoing
success,
and
then
you
could
say
in
a
playbook
is
like
the
way
that
we're
thinking
is.
You
know,
maybe
a
practical
way
to
do
that.
A
A
A
That's
kind
of
like
the
we
want
to
do
that
and
then
you
know
the
you
know
like
building
a
play.
Playbook
is,
is
probably
a
practical
way
or
whatever
other
we
can
discuss
whatever
other
ways
to
achieve.
That
would
be
because
I
think
that
do
you
think
that
captures
kind
of
what
we
think
is
important
to
do.
A
I'm
not
too
picky
with
words
sure
that
one
just
seems
like
it's.
It's
like
that's
the
root
of
what
we
want
to
do,
sort
of
how
we
do
it.
We've
got
to
figure
out
still
and
could
have
a
couple
different
things
even,
but
that
does
you
know
in
terms
of
the
we
haven't
actually
gone
through
it
from
that
lens,
so
we
might
even
want
to
do
that
at
some
point
is
like
what
do
we?
What
do
we
struggle
with
today
right,
like
we've,
been
thinking
about
what
do?
A
What
are
our
values
where
the
constituencies
need,
but
another
lens
of
looking
like
you
know
what
we
need
to
do
and
going
forward
is
like
well,
what
do
we
currently
struggle
with
and
what
slows
us
down
right,
because
I
think
this
one
kind
of
is
fairly
obvious
when
you
think
about
it.
From
that
perspective,.
B
Yeah
slowing
us
down
is
interesting
because
we
can
slow
down
to
so
there's
a
phrase
that
charlie
robbins
likes.
Is
you
move
slow
to
go
fast,
so
there's
there's
definitely
something
about
long-term
speed
versus
short-term
speed
that,
I
think,
would
be
hard
to
capture
if
we,
if
we
went
the
route
of
trying
to
state
of
this,
is
something
that
slows
us
down,
because
it
could
slow
us
down
in
the
short
term
but
prevent
us
from
having
problems
in
the
long
term.
A
Yeah,
I
I
agree
so
yeah.
I
know
what
you're
saying
at
least
this
description.
Basically,
I
think
we
struggle
with
making
decisions
and
being
comfortable
that
we're
doing
them
at
like
because
you're
I
I
totally
agree
like
you
know
you
could
make
decisions
too
fast
too
right,
like
I
think
we
struggle
with
making
them
and
being
comfortable
we're
doing
them
in
in
an
appropriate
time
frame.
Whatever
that
happens,
to
be
right,.
B
A
A
A
No,
I
think
because
yeah,
I
think,
starting
to
build
a
list
of
we've
got
some
like
the
technical
priorities,
we'll
be
able
to
pull
some
of
that
out
of
these
this,
this
one
brainstorm
but
capturing
some
of
these
things
is
like
these
could
be
key
things
that
are
part
of
the
success
and
issues.
So
we
can
talk
about
them
capture.
What
we've
already
talked
about
and
not
forget
them.
This
would
be
good.
A
Yeah,
I
know
exactly
like
I
think
in
this
repo.
I
could
kind
of
see
that
at
some
point
we
want
to
boil
it
down
to
like
here
the
top
five
things.
Maybe
that
we
think
are
important
to
do
right
and
you
know
yes,
there
is
this
list
of
20
and
you
know,
but
these
are
the
five
we
think
the
projects
should
focus
on
and
at
that
point
we'll
need
the
broader
input
and-
and
maybe
even
we,
you
know,
we
get
the
broader
input
to
help
choose
those.
A
But
we
should
build
up
that
list
here
and
then
we
can
take
a
sort
of
a
hopefully
a
a
well
explained
list
to
the
broader
group
kind
of
like
we
did
for
the
technical
ones.
A
Okay,
that
sounds
good.
I
I
think
that's
are
there
other
things
we
should
discuss?
I
think,
like
I
think,
on
the
the
technical
areas,
we
should
wait
till
we
get
a
little
bit
more
input
given
that
extra
week
to
sort
of
dive
into
that.
We
only
have
six
minutes
anyway
in
terms
of
the
survey
we'll
next
time.
We'll
have
some
data
on
on
from
that
as
well.
A
If
not,
maybe
we'll
close
out
and
we'll
we'll,
if
everybody
can
look
out
for
that
issue
on
the
meeting
times
and
then
we'll
try
and
get
that
updated
to
make
sure
we
get
more
more
people
as
well.
So.