►
From YouTube: 2020-10-01-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
years
of
node
team
meeting
for
this
week
we
will
follow
our
agenda,
although
I
think
we
agreed
last
time
the
focus
is
going
to
be
on.
A
B
I
I
can
say
a
quick
word
on
the
next
10
years,
planning
of
node
we've
been
having
a
lot
of
conversations
over
at
the
web
server
frameworks
team
on
the,
and
we
haven't
really
phrased
his
next
10
years
of
the
http
apis,
but
that's
effectively
what
we
are
planning.
So
if
anybody
is
interested
in
those
conversations
we
have
regular
meetings
and-
and
it's
very
much
in
the
same
vein
as
this
conversation
of
like
you
know:
what
are
our
values?
What
are
our
technical
values?
What
types
of
api
do
we
want
to
design?
B
Do
they
fit
with
those
values?
We're
at
a,
I
think,
a
really
early
stage,
which
is
sort
of
fun
if
you're
able
to
join
in
the
conversation.
A
A
Okay,
any
other
announcements.
A
A
B
How
do
you
question
it's?
Not
that
I
don't
have
a
problem
necessarily
because
I
think
it's
pretty
good,
but
so
in
the
conversation
on
the
import
maps,
one
of
the
things
that
got
brought
up
multiple
times
was
that
the
spec
is
not
mature
enough
for
node
to
commit
to
building
it.
So
if
we
say
this
as
a
value,
then
how
do
we
rectify
those
kind
of
questions
where
it's
a
browser
standard,
but
it's
on
the
browser
standard
track
which
we
don't
have
control
over.
B
A
B
B
I
guess
I'm
just
trying
to
say
like
if
we
add
that
on
that
we're
gonna
have
to
pick
a
line
somewhere
and
and
it's
a
it's
a
much
fuzzier
conversation.
I
think
than
some
of
the
other
points
we
have
as
like
technical
values.
So
I'm
just
worried
that
if
we
add
that
people
are
going
to
be
like
well
look
this
thing's
on
standards
track.
I
know
it's
really
early
but
like
it
aligns
with
your
value,
you
have
to
implement
it
right
or
right.
C
If
it's,
if
it's
on
standard
track
and
it's
something
that
is
relevant
to
what
we're
doing,
I
think
we
should
just
be
involved
in
that
conversation
if
we're,
if
we're
just
letting
some
standard,
be
pushed
entirely
on
the
browser
side
and
not
having
any
participation
from
our
side,
it's
kind
of
our
own
fault.
If
we
end
up
like
a
couple
years
later,
it's
like
mature
to
the
point
that
it's
ready
to
be
accepted
and
then
suddenly
we're
like.
Oh,
this
doesn't
work
for
us
like
that's
kind
of
on
us.
A
A
C
There's
there's
also
been
like
certain
cases
where
I
feel
like
it's
somewhat
been
like
one
direction
flow
of
things
like
everything
comes
down
from
standards
to
us,
but
less
so
the
other
direction.
When
there's
actually
been
things
that
got
into
node.
That
actually
makes
sense
at
wider
javascript
level,
and
we
just
never
took
it
to
standards
to
try
and
do
anything
with
it.
Like
there's
been
things
like
there's
now
like
usb
support
in
browsers,
and
we
had
some
like
node
ecosystem
modules
that
did
that
long
before
that,
and
we
never
thought
hey.
A
So
yeah-
I
just
I'm
thinking
about
that
like
in
terms
of
how
that
would
be.
That's
basically
saying
we
want
to
be
more
proactive
on
influencing
standards.
A
A
E
C
Like
one
directional
relationship,
though
it's
like,
they
are
giving
us
the
web
api
and
we
consume
us.
We
make
our
thing
compatible
with
it,
but
do
they
make
their
thing
compatible
with
what
we
make?
It
doesn't
really
say
anything
with
that
that
statement
so
having
something
to
kind
of
imply
a
bit
more
of
a
two-directional
relationship.
I
think,
would.
C
A
I
I
think
I
agree,
I'm
not
sure
I
think
that
could
be
a
separate
pr
to
add
something
else
in
like
this.
One
is
specifically
under
the
developer
experience
section
indicating
that
you
know
part
developer
experience
that
was
that
made
node
successful
was
being
compatible
with
browsers
and
other
javascript
environments,
and
I
kind
of
agree
on
that.
A
Right
so
I
guess
wes
you're,
just
mentioning
that
in
terms
of
phrasing
it
you
were
thinking
yeah
softening
the
phrasing
might
help
a
bit
too.
B
Yeah,
I
I
was
just
thinking
about
you,
know
what
mary
was
saying
in
the
chat,
and
I
think
that
there's
there's
always
going
to
be
conflicts
in
some
regards
with
the
values,
and
I
think
you
know
in
a
case
where
it's
a
web
standard
is
so
immature
that
it's
really
likely
to
change
and
going
to
cause
more
hurt
on
the
stability
or
experience.
Maybe
like
yeah
totally.
I
think
we
need
to
find
a
balance
there
on
any
individual
issue.
My
worry
with
the
phrasing
was
that
it
was
pretty
strongly
stance
right.
E
A
Right,
that's
what
I
was
kind
of
thinking
when
I
like
the
the
original
that
pr
had
done
had
suggested
that,
like
maximizing
compatibility,
interoperability
with
browse
and
there's
javascript
environments-
and
I
was
kind
of
saying,
like
maybe
yeah
softening-
that,
where
like
where
it
makes
sense,
would
make
sense.
Okay,
there's
too
many
make
sense,
but
yeah.
A
A
A
F
A
D
I
mean
I,
I
guess,
maybe
speaking
for
some
of
those
folks,
perhaps
there's
something
to
say
around,
like
stages
in
tc39
or
what
what
wig?
I
don't
know
what
wakes
process
at
all
but,
like
you
know,
we're
not
gonna
ship,
something
that's
stage
one
or
two,
and
it
has
to
have
been
three
for
quite
a
while
or
like
we'll
only
ship
stage.
Four
or
something
like
that.
D
I
don't
know
somehow
tying
into
the
standards
process
potentially
could
be
a
path
to
that,
especially
since
the
open,
js
foundation
now
has
an
avenue
for
us
to
directly
participate
and
also,
I
think,
I've
seen
a
lot
higher
participation
from
folks
in
the
project,
largely
because
they're
able
to
be
sponsored
by
their
companies.
D
A
That's
true,
but
I
think
that
would
be
more
in
the
as
west
mentioned,
there's
going
to
be
lots
of
trade-offs
and
conflicts
like.
I
would
use
that
more
in
the
well
yeah
it's
if
it's
a
stage,
four
standard,
it's
more
compelling
than
it's
the
stage
one
standard
because,
like
we
still
value
stability,
so
so
yes,
it's
worth
being
compatible,
but
it's
a
bit
too
early
to
be
compatible
right.
D
Right
and
I
mean
it's
stage,
one
like
literally
it's
going
to
break
like
that
is
the
expectation
there
and
so,
like
you
know,
stage
three
and
four
are
like
roughly
when
you
can
start
kind
of
carrying
and
stage
four
is
like
it's
already
in
the
platform
like
there's
nothing
to
do.
It's
never
changing.
D
B
Certainly
a
very
good
point
in
terms
of
yeah
just
a
little
bit
as
soon
as
we
add
it
to
the
values.
These
are
the
conversations
that
people
are
going
to
start
having
right,
because
they're
going
to
point
to
the
values
and
say:
look
you
all
said
it's
your
value
and
and
then
they're
going
to
come
with
the
what
wig
stuff-
and
I
don't
think
I
don't
know
what
the
stages
are
either,
but
that
was
one
of
the
specific
concerns
people
had
in
the
thread
for
the
for
the
import
maps
was
like
look.
B
B
It
might
provide
value,
I
can't
say
I
also
thought
the
stuff
about
well,
it's
a
what
wig
standard
was
a
little
bit,
maybe
over
overly
stated
in
that
thread,
so
I
maybe
that
doesn't
happen
very
often,
and
it
was
just
this
one
specific
case
where
that
got
brought
up,
but
I
think
it
came
from
history
of
the
url
one
as
well
right,
because
that
was
standard
as
well
that
got
implemented
anyway.
B
A
I
think,
like
you,
know
again
we're
it's
getting
pretty
specific
like
I,
I
think
that,
like
the
you
know
the
value
that
the
project
kind
of
overall
does
value
being
compatible
with
like
if
there's,
if
there's
a
standard,
and
it
makes
sense-
I
don't
see
people
arguing
to
say
hey,
we
should
go.
Do
something
else
right.
B
C
He
has
streams,
is
different
enough
from
node
and
has
like
different
enough
performance
characteristics
specifically
that,
like
we
mostly
would
not.
I
probably
would
not
want
to
have
es
streams
as
the
default
in
node,
but
for
compatibility
purposes
like
it
would
be
cool
if
we
could
just
plug
in
some
browser-centric
library
and
it
just
works
or
if
we
write
something.
That's
node
centric
and
mostly
works
with
node
streams.
B
C
B
C
I
I
feel
like
core
should
be
able
to
like
switch
between
the
browser
and
its
own
recommendation
where
necessary,
it's
like.
If
we
try,
if
we
try
to
like
use
stream
pipe
and
pipe
into
something
that
is
not
a
node
stream,
it's
an
es
stream.
It
should
understand
how
to
do
that.
A
I
think
maybe
we
should
you
know,
I
guess
well,
I
just
want
to
let's,
let's
say
we
time
box
the
discussion
on
this
to
another
five
minutes,
so
that
we
do
have
time
for
a
few
things
on
other
things
on
the
agenda.
C
A
C
C
It's
maybe
not
as
nice,
like
from
a
performance
perspective
as
if
we
were
just
piping
between
one
node
streaming
another,
but
it
has
a
compatibility
advantage
that
someone
can
just
take
this
browser-focused
library
and
plug
it
in
and
it
just
works,
and
it
makes
things
easier
to
develop
that
way.
Even
if
it's
not
ideal.
B
I've
been
some
a
similar
example.
Is
the
service
workers
api
as
sort
of
a
approach
to
handling
http
requests?
Like
there's,
you
know
specs
around
that
I've
been
sort
of
looking
at
them
as
inspiration
for
some
of
the
http
work
and
there's
certain
areas
where
it
just
like
clearly
wouldn't
make
sense.
E
A
A
Standards
is
one
way
where
that
you
know
that
you
know
they
implement
standards
and
we
can
implement
the
same
standards
but
there's
sort
of
other
areas
where
it
may
not
be
part
of
a
standard,
but
it
would
still
make
sense
for
us
to
be
compatible
and
there's
cases
where
they're
standard.
They
are
standards,
but
that
doesn't
mean
it
there's
any
more.
That
doesn't
immediately
say
it
makes
sense
for
us.
It's
still
that
makes
sense
applies.
A
A
A
A
Okay,
so
it
sounds
like
you
know.
What
would
probably
make
sense
is
for
people
to
jump
into
that
issue,
and
you
know
we
can
continue
the
comment.
I
I
posted
in
what
we
my
first
suggestion,
but
then
I
posted
oh,
I
I
sort
of
jumped
the
gun,
so
if,
if
people
here
can
kind
of
jump
in
there
with
suggestions
or
tweaks
that
they
think
pushes
in
the
right
direction,
that
would
be
good
because
I
think
there's.
I
personally
think
there's
something
there
like.
A
Move
on
to
the
next
issue,
which
I
think
mary,
maybe
you
can
take-
is
the
revisit
the
time
slots.
G
Yes,
so
I
opened
a
doodle
a
few
weeks
ago.
I
think.
G
Be
super
happy
about
feeling
it,
but
I'm
gonna
basically
chat.
We
need
more
answers
before
coming
to
a
new
time.
G
G
A
Sounds
good,
the
the
other
issue
beside
the
one
that
we
want
to
focus
today's
meeting
on
is
the
next
10
years
for
collaborators.
A
I
think
that
one
probably
needs
like
you
know
the
bulk
of
a
meeting
as
well,
so
I'd
propose
as
long
as
you're.
Okay
with
that
mary
to
push
that
off
till
next
meeting.
G
A
Sounds
good
okay,
so,
let's
dive
in
then
to
the
needs
wants
of
constituencies.
I
think
we,
you
know
we
were
looking
at
the
next
steps
after
the
values
and
the
conclusion
we
kind
of
came
to
is
we
need
to
to
better
define
what
is
it
that
the
constituencies
that
we
have
listed
actually
need.
So
the
plan
is
is
to
set
up
a
let's
set
up
a
fun
retro
type
board.
So
since
our
expert
isn't
here.
A
A
Okay,
public
boards,
okay,
I
have
to
verify
my
email,
so
just
give
me
one
more.
A
H
H
Sorry,
I'm
just
okay,
I'm
looking
at
templates.
A
A
Okay,
what's
is
there
like
us,
okay
suggest
a
new
template.
A
Okay
can
I
I
can
re-edit
it
anyway.
I
guess
so
I
will
guess
in
terms
of
the
board.
I
think
what
would
make
sense
is
if
we
put
in
the
the
needs
like
the
each
of
the
constituents,
and
then
we
can
kind
of
all
fill
in
what
we
think
the
needs
are
well,
so
people
I'll
start
doing
that.
If
people
have
other
suggestions,
let
me
know.
H
H
A
A
B
A
I'll
take
a
nose,
yeah,
okay!
So
that's
yes!
Okay!
So
let's
spend
say:
let's
start
with
five
minutes,
we'll
see
where
we're
at
in
five
minutes,
I
think
there's
even
like
some.
There
is
a
timer
there.
Okay,
five
minutes,
we'll
start
with
that,
and
if
people
aren't
done,
we
can
add
more
time.
But
let's
start
with
that,
and
have
everybody
add
in
with
what
we
think
each
of
these
groups.
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
G
H
A
G
So
diagnostics,
tools,
diagnostic
signals,
monitoring
tools.
They
were
handling
adobe's
capability.
I
think
we
can
solve
them
because
they
are
these
observability
or
handling
diagnostics.
Bulk,
okay
needs
for
operations.
A
Sounds
good
error
handling
so
resource
hardware
from
support
good
process.
A
A
Necessarily,
the
only
thing
I
do
see
is
that,
like
reasonable
resource
usage,
we
have
an
application
operators
and
direct
end
users,
but
I
guess
that
we
can
easily
have
the
same
need
across
different
constituencies.
A
A
Looking
through
the
application
operators.
Are
there
any
others
here
that
we
think
go
together.
A
A
A
B
At
least
two
in
there
on
like
dependency
management
stories,.
B
C
B
A
E
Let
me
see
it
depends
what
more
contribution
workflow
automation.
I
think
it
could
be
also
linked
to
a
good
user
experience
with
ci.
E
H
G
It's
different
there's
a
lot
more.
We
can
automate
besides
ci,
for
example,
commit
query,
is
contribution,
automation
and
it's
not
related
to
ci,
it's
implemented
on
reactions,
but
it's
not
related
to
continuous
integration.
C
Go
ahead,
I'm
the
one
out
of
the
contribution,
workflow,
automation
and,
like
my
thinking
was,
you
know
a
lot
more
of
the
stuff
like
just
beyond
the
ci
like
ci
is
part
of
it.
I
think,
but
there's
just
a
lot
of
processes
around
to
like
wait.
We
can
have
like
an
automated
thing
to
check
if
the
person
is
assigned
c,
cla
or
right.
C
I
get
any
of
those
sorts
of
things
like
all
these,
like
extra
little
automation,
things
that
we
can
plug
in
that
just
makes
the
whole
contribution
process
faster
and
like
if
we
can
like
like
run
the
lender
and
like
give
feedback
immediately
to
tell
a
user
like
yeah.
C
You
need
to
like
fix
these
couple
things
and
just
try
and
like
make
it
as
clear
as
possible
and
as
quick
as
possible
to
just
communicate
like
especially
to
a
new
user
like
yeah,
we
have
linting
in
the
github
actions
somewhere,
and
you
can
maybe
go
find
it
if
you
know
where
to
look
for
it,
but
just
like
the
more
we
can
present
to
someone
trying
to
contribute
faster
and
the
more,
we
can
just
identify
the
process
better.
A
E
G
A
G
A
In
the
ci
right-
yes,
yeah
so
we're
at
time,
but
I
think
we've
got
a
good
start
here.
What
I'd
suggest
is,
I
don't
know
if
I
can
not
quite
sure
what
to
do
but
like
I
think
we
can
continue
to
add
things
and
like
so,
if
we
think
of
things
between
now
and
the
next
meeting
in
terms
of
other
things
we
we
can
add,
we
could
do
that
and
then
you
know
next
meeting
I
you
know
we
could
go
through.
I
maybe
a
little
bit
of
the.
E
B
E
B
C
A
That's
kind
of
what
I
did
is
like
when
I
had
one
I
thought
applied
to
more
than
one.
I
put
it
in
a
couple
columns,
so
I
I
think
that
way
it
does
work,
because
I
I
I
could
see
a
table
like
that
being
pretty
useful
if
it's
like
x's
across
the
board.
It's
like.
Okay,
that's
something
that's
important
to
everybody,
so
we
should.
D
A
We
can
do
that
voting
to
see
if
they're,
you
know,
which
ones
we
should
highlight
is
the
highest,
because
I
guess
you
know
we
we
might
need
to
boil
it
down
to
some
like
we
can't
have
a
hundred
for
each
list,
although
we
don't
have
that
yet
so,
but
we
can
then
start
working
on
like
how
we
convert
this
into
something
that
would
be
written
in
terms
of
you
know
what
we
think
they
all
need.