►
From YouTube: Next 10 years of Node.js - Sep 2 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
A
Let's
just
look
here.
That
is
issue
number
15.
If
anybody
wants
to
go,
take
a
look
there.
The
main
things
that
have
been
tagged
for
the
issue
is
prioritizing
technical
values
and
the
value
directions
for
core
we'd
started
with
the
direction
on
the
technic.
On
the
you
know,
some
of
the
technology
and
so
forth
that
we
needed
to
to
look
at
in
terms
of
things
like
wasm
typescript,
other
other
things.
A
A
So
that's
been,
you
know
we
worked
on
that
the
last
couple
weeks,
the
issues
where
we've
been
capturing,
that
is
number
two
and
in
particular,
there's
a
pr
that
came
out
of
the
last
one
pr11
which
I'll
share
on
the
screen
here,
which
has
you
know
what
we've
been
talking
about
in
terms
of
the
the
values
and
the
priority
level.
A
So
we
have
a
few
new
people
who
weren't
in
the
previous
discussions.
I
don't
know
if
there's
you
know
you
have,
questions
want
to.
C
First
well,
mine
was
not
really
a
question
more.
I
would
just
say
that
maybe,
if
you
michael
want
to
recap
the
last
couple
of
meetings,
I've
been
to
the
first
one
in
the
summit,
but
I
haven't
been
back
ever
since
so
maybe
just
recap:
the
last
few
meetings.
What
has
been
the
activity.
A
Right
so
that
you
know
basically,
we've
been
working
on
coming
up
with
well.
Actually,
here
there
is
we
look
in
here
we
were
starting.
You
know
we
were
trying
to
to
look
at
the
the
values.
So
the
one
thing
we
needed
to
do
was
you
know,
talk
about
the
consistencies
like
so
who,
who
are
the
the
different
groups
that
we
need
to
factor
in
to
the
values
and
what
we
do
in
the
project.
So
we
actually,
you
know,
worked
on
and
came
up
with
this
list
which
we've
landed
in
terms
of
you
know.
A
We
have
our
direct
end
users.
We
have
applica
people
who
operate
applications,
we
have
application
developers,
we
have
library,
package,
authors
and
we
have
node.js
cord
maintainers
and
those
are
the
different
consistencies
that
we
believe
we
should
keep
in
mind
when
we're
thinking
about
the
values,
the
technology
directions.
You
know
what
we
need
to
do
to
make
us
successful
in
the
next
10
years.
A
So
that's
one
of
the
things
that
we
we
did
in
in
the
previous
meetings.
We
then
also
worked
on
this
value
and
prioritization
the
values
and
prior
prioritization.
So
we
talked
about
you
know
the
technical
values
and
you
know
spent
quite
a
bit
of
time
going
through
these
to
say
what
are
the
technical
values
we
did.
Like
a
you
know,
one
of
those
boards
where
everybody
you
know
puts
in
blindly
with
values
that
they
think
are
important,
have
been
important
to
the
project
and
to
the
success
of
the
project.
A
Everybody
tagged
them
with,
like
their
top
three
or
four.
We
went
through
the
whole
process
of
you
know,
then
filtering
that
down
and
and
and
combining
them,
and
I
think
you
can
look
at
if
you
went
back
and
looked
at
the
the
issues
for
those
previous
meetings.
So
if
you
went
back
and
look
at
the
closed
issues.
A
Let's
say:
let's
just
finding
the
is
this:
the
last
one.
There
should
be
a
link
here,
I'm
trying
to
think
where
we
put
the
link
to
the
google
doc,
where
we
did
a
bunch
of
that.
C
A
A
You
know
we
started
out
thinking
it's
going
to
be
really
hard
to
order
them,
but
in
the
end,
through
the
discussions
we
actually
came
out
with
this
ordering,
which
was
like
you
know,
really,
we've
prioritized
developer
experience
over
stability
over
operational
qualities
over
technology
and
api
currency
awesome,
and
so
you
know
I
you
know
I
took
the
action
out
of
that
to
say:
okay
I'll
write
write
this
up,
which
we
did
and
you
know
we
need
to
fill
out.
You
know
developer
experience
a
little
bit
more.
A
The
question
that
was
posed
here
is
like
maintainer
experience
has
been
discussed
in
some
other
meetings,
not
not
in
this
meeting.
It
was
the
web
frameworks
meeting.
There's
some
discussion
of
this
and
you
know
the
the
I
think
the
point
being
made
was,
if
that
the
the
maintainer
experience
is
too
poor,
we're
not
going
to
have
people
working
in
particular
areas.
So
you
know
just
to
pick
one
you
know
at
random.
If
I
don't,
I
don't
want
to
pick
on
anybody,
but,
like
so
you
know,
say
modules,
say:
n
api,
say
http.
A
If
any
one
of
those
is
really
painful
to
maintain
we're
not
going
to
have
maintainers,
so
it's
important
that
we
make
sure
that
that
maintainer
experience
is
is
good
as
well,
and
I
guess
the
question
would
be
like
you
know
from
the
people
here.
How
do
we
think
that
fits
into
the
that
list
that
we
already
have
identified.
D
I
I
don't
think
it
fits
into
any
of
them.
I
don't.
I
think
there
was
a
suggestion
of
putting
it
under
developer
experience,
but
I
don't
think
we
can
because
often
the
maintainer
experience
and
developer
experience
can,
if
you
lump
them
together,
but
they
often
contradict
each
other.
In
some
cases
like
I
guess,
a
crude
example
would
be
hey
for
a
developer
for
a
maintainer
it'd
be
really
good.
D
C
Have
you
had
the
discussion
on
how
this
maintainer
experience
is
different
from
just
the
regular
developer
experience.
A
A
So
I
I
would
almost
like
I
kind
of
agree
it's
a
different
thing
like
it's.
It's
about,
you
know,
making
it
a
priority
to
make
sure
the
code
that
we
have
is
maintainable
and
that
when
you
come
to
the
project
you
know
you
technically,
you
have
a
good
experience.
C
Okay,
so
it's
maintainers
in
term
in
the
sense
of
node.js
collaborators.
C
Yeah,
okay,
all
right
yeah,
because
you
mentioned
the
web
framework
group.
I
thought
it
was
just
package
maintainers
from
the.
A
A
A
D
D
I
think
three
and
four
are
very
close,
but
that
again
that's
my
opinion,
so
I
think
it's
fine
to
leave
them
there.
A
We
could
move
on
to
now
like
getting
a
a
better
description
of
the
developer
experience
of
the
different
area.
You
know,
what
do
we
mean
by
these
different
areas
to
make
sure
it's
it's
clear.
A
So
what
do
people
think
you
know
factors
into
developer?
What
are
the
key
things?
You
know
that
we
should
call
it
for
developer.
C
A
E
A
A
Either
either
or
both
any
other
kinds
of
tools
that
you
can
think
of.
C
C
About
like
user
land
kind
of
tools,
that
is
definitely
like
essential
for
the
developer
experience
these
days,
like
you
know
all
kinds
of
tooling
like
from
from
old,
german
or
npm
to
like
web
packs
or
roll
up,
you
know
react
all
the
toolings
that
we
have
or
maybe
not
react
in
the
context
on
ojs.
But
you
got
my
point
like.
C
A
So
yeah,
so
I
think
that's
a
good
one
like
good
support
for
external
tuning.
Webpack
react
et
cetera,
good
and,
as
it
would
be
good
to
say,
good
api
support
or
what's
the.
E
A
F
A
G
So
I'm
not
sure
if
that's
what
we
mean
by
tooling
helps
the
developer
experience
and
we
ship
certain
things
to
the
community
that
improve
that
developer
experience
today.
And
we
want
to
continue
to
do
that
and
or
if
it's
just
more
of
a
listen
to
the
community
right.
A
H
G
Close
you
want
to
be
careful
not
to
like
overlap
with
like
technology
and
api
currency
right,
so
the
developer
experience.
You
know
if
we're
saying
that
we
improve
that
by
the
types
of
tool
tooling
that
we
ship.
I
guess
that
you
know
that
also,
I
think,
goes
hand
in
hand
with
like
the
fact
that
the
technology
and
the
api
surface
surfaces
we
have
or
also
improve
the
developer
experience.
F
F
G
Let
me
read
so
developers
bundling
api
components
which
reduce
friction
of
using
them
yeah,
I
mean
yeah
again
we're
shipping
to
shipping
tools
that
help
improve
the
developer,
experience
right,
develop
development
experience
and,
and
that's
the
developer,
experience
of
working
with
node
right
yeah,
giving
you
giving
you
and
and
user
lands
tools
to
create
further
further
tooling
on
top
of,
but
also
so
that
includes
like
some
default
package
management
capabilities,
but
also
some
default.
H
A
A
A
Well,
not
even
knowing
about
it,
but
like
it,
you
know
the
sim.
The
same
reason
you
could
be
say
like
hey,
we
bundle
npm
as
a
package
manager
because
you
know
having
it.
There
already
improves
the
developer
experience
right
and
you
can
argue
you
know
for
the
different
for
different
things.
You
can
argue
why
it
improves
the
developer
experience
or
not
like,
for
example,
you
know
bundling
in
the
debugger
or
maybe
like
you
know,
not
having
it
bundled.
Maybe
that's
just
impossible
right
like
that,
one.
A
That
kind
of
tooling,
I
think,
might
come
under
the
operational
kind
of
qualities.
But
you
know
the
things
like
the
rimraf
or
whatever
right
you
could,
and
it
was
an
external
module
for
a
long
time
or
the
same
thing
with
the
context.
Local
storage,
api,
but
like
we
start
to
bring
things
in
when
we
think
it
significantly
improves
the
developer
experience
to
have
it
as
part
of
core
versus.
G
So
it's
kind
of
interesting
because,
like
like
technology
and
api
currency
to
me,
because
we
keep
almost
like
touching
on
that
right,
but
that's
to
me
not
necessarily
really
a
value,
whereas,
like
developer,
improved
developer,
experience
would
be
a
really
outright
value
like
that's
something
that
we're
valuing
going
forward
and
as
a
artifact
of
work
to
to
improve
developer
experience,
we
get
better,
tooling,
better
apis.
We
include
start
to
bring
back
into
our
standard
lib
user,
lan
type
type,
ideas
and
concepts
that
like
improve,
that
right.
G
A
Or
you
know
in
this
case
it
would
have
been
like
from
previous
discussions.
We
would
have
put
that
under
technology
and
api
currency
it
doesn't
necessarily
improve
the
developer
experience,
but
it's
still
relevant
in
that.
You
know
you
need
to
cover
the
new
technologies,
add
new
surface
area
to
stay
up
to
date
and
be
current.
A
C
Yeah,
I
think,
I
think
also
the
other
thing
we're
missing
here,
like
maybe
two
steps
back,
it's
we're
just
defining
the
values
right,
so
it
should
be
just
like
the
guiding
value
like
we
don't
need.
I
feel
like
now
we're
digging
too
much
into
technical
details
like.
C
A
C
Making
decisions-
I
imagine-
that's
gonna-
be
the
most
valuable
right
to
have
this.
A
H
C
No
yeah-
I
still.
I
still
have
my
extend
my
previous
point,
but
it
would
be
like
a
more
generic
vague,
such
as
enabling
user
land
tooling
right
as
a
value
that
we
should
keep
in
mind
for
in
order
to
provide
a
better
developer
experience.
A
A
A
A
A
A
A
G
G
A
A
A
G
H
F
A
F
F
B
G
A
A
F
G
H
A
G
A
Think
we
have
a
consensus
on
what
that
would
mean,
like
I
I
wouldn't
say,
yeah
just
size,
always
trump
speed
or
vice
versa,
and
I
guess
all
this
is
never
like
always
anyway,
but
I
think
it
would
be
yeah
like
I
don't.
I
I'm
not
sure
that
we
would
be
able
to
say
like
in
this
case.
I
think
we're
saying
you
know:
developer
experience
should
trump
size.
So
if
we
were
to,
if
we
were
to
say
well,
I
can
make
it
really
really
small,
but
it
decreases
developer
experience.
G
A
A
A
A
A
A
G
G
Like
up
to
date,
yeah,
I
don't
know
modern,
you
could
say
modern
apis.
You
could
say
yeah.
H
G
Right
maintain
standard
apis
with.
E
G
A
G
B
G
A
A
A
I'm
just
not
sure
100
in
my
mind
what
I've
seen
the
project
sort
of
reflect
on
that
front
and
also
what
we
think
me
is
important
going
forward
right
like
you.
Could
you
could
take
the
tact
that
hey?
We
just
wait,
but
I
don't
think,
to
be
honest,
I
don't
think
that's
kind
of
the
approach
the
node
project
takes
is
more
like.
Let's
bring
new
things
in
earlier
than
later
right.
A
G
G
Well,
the
tool
like
in
tooling
specifically
like
where
we're
just
coming
around
to
adding
some,
I
guess
like
nice,
to
have
file
system
operations
like
that,
like
rim
wrap,
like
you
noted,
like
right
or
our
recursive
like
chmod,
or
like
any
kind
of
like
things
like
that,
where
it's
like.
Oh
well,
this
stuff
lives
in
like
unix
product
postx,
and
it's
like.
Oh,
we
should
have
these
methods
and
this
capability
by
default.
G
G
Think
that
we
are
a
bit
of
a
laggard
in
that
example,
and
and
examples
like
that,
where
we
take
a
long
time
to
adopt
those,
whereas
you
know,
I
think,
we're
probably
more
aggressive
on
on
things
that
like
like.
I
think
even
yes,
I'm
like
like
there's
not
a
lot
of
like
web
browsers
where
people
are
shipping,
like
a
lot
of
modules
like
today,
right
like
right.
G
A
A
The
case
has
been
made
recently,
that
that
helps
developer
experience
and
that's
why
it's
starting
to
come
in
and
you
know
maybe
before
it
was
like,
we
valued
small,
core
versus
developer
experience,
and
that's
you
know,
so
it
wasn't
necessarily
that
it
was
a
hey
here's,
a
new
technology
like
wasm
or
like
es6
modules,
and
we
said
well,
let's
wait
to
see
how
that
stabilizes
right.
It
was
kind
of
a
different
thing
in
that
case,
where
it
wasn't,
it
wasn't
about
adopting
a
new
technology.
A
A
G
G
F
A
A
But
I
think
this
is
looking
pretty
good
with
the
work
we
did
today
and
you
know,
maybe
we
we,
you
know,
get
a
little
bit
more
feedback
through
github
and
it
might
be
ready
to
pr
this
into
node
core
if,
if
people
agree
awesome
and
we'll
certainly
get
a
lot
more
conversation
discussion
going
there,
but
we
can
go
from
there.
A
Yeah
looks
good
okay.
Well
thanks
for
everybody's
time,
and
we
will
see
you
in
github
and
and
then
hopefully,
in
the
next
meeting
in
a
couple
times
talk
to
everybody.