►
From YouTube: Next 10 years of Node.js - July 29 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
our
second
node.js
sort
of
next
10
years
of
node
team
working
session.
A
We
are
going
from
the
issue
that
was
created
in
the
repo
and
everything
that
the
sort
of
logistics
that
we
discussed
last
time.
It
is
issue
number
hold
on.
Let's
see
if
I
can
get
that
issue
number
sorry
having
trouble
scrolling.
A
Issue
number
three:
I'm
just
gonna
add
that
to
the
minutes,
so
we
just
got
the
repo
set
up,
and
the
only
thing
that
was
tagged
for
the
agenda
was
the
things
that
we
discussed
last
week,
which
was
the
values
direction
directions
document
for
core
issue
number
two.
I
will
open
that
up.
A
The
initial
comments
around
what
it
would
look
like
included.
You
know,
including
a
bit
of
a
mission,
you
know
the
values
of
the
project
and
a
priority
list
of
those
prior
those
values
kind
of
a
con
constituency
of
priorities.
I
think
it's
been
called
and
then
you
know
the
key
technical
areas,
and
so
I
I
agreed
to
open
this
issue
and
then
we
would
continue
to.
A
We
thought
we
would
continue
to
to
work
on
that
to
figure
out
what
that
sort
of
the
what
we
think
that
document
should
be
called
and
what
it
should
look
like.
So
unless
other
people
have
other
suggestions,
that's
probably
a
good
place
to
start
for
today,
and
then
we
can.
You
know
if
we
finish
that
we
can
think
about
what
other
areas
we
want
to
start
to
dive
into.
Does
that
make
sense
to
everybody.
A
Okay,
so
you
know
picking
up
the
the
the
sort
of
structure
you
know
are
there.
People
have
had
thoughts
on
on
that.
What
would
we
call
this
document.
A
D
E
A
E
So
I
the
the
the
I'm
thinking
of
mission
statement,
a
lot
from,
like
you
know,
like
companies,
their
teams
or
whatever
will
often
publish
something
like
this,
and
it
sort
of
includes
that.
Okay,
you
know
it
is
a
little
bit
of
both
anyway.
I
I
don't
think
the
name
of
it
is
going
to.
A
C
A
A
A
Okay,
so
then,
in
terms
of
content
you
know:
do
we
want
to
try
and
write?
You
know,
fill
out
the
the
sort
of
top-level
mission
part
or
dive
into
like
the
values.
A
E
It's
surprisingly
hard
to
find,
I
think
somebody
found
a
link
to
it.
I
I
did
this
search
just
last
week
right
right
and
I
it
took
me
a
while
to
dig
it
up.
I
thought
there
was
a
link.
A
B
F
A
E
A
E
I'm
sure
everybody's
reading
it,
but
one
thing
I
I
think
you
know
we
don't
necessarily
have
to
follow
this
guide,
but
I
do
think
so
we
don't
have
as
many
layers
I
would
say,
but
I
do
think
saying
something
like-
and
this
is
also
a
this-
is
also
a
values
as
far
as
technology
goes.
I
think
we
should
also
make
clear
that
there
are
values
that
are
not
necessarily
going
to
drive
technical
decisions,
but
should
drive
discussions
or
you
know
how
how
we
approach
inclusivity
or,
like
those
kind
of
things
right.
E
A
G
A
Right,
okay,
so
that
that
yeah,
so
this
is
purely
around
the
technical
values
which
is
good
to
make,
make
make
sure
that
that's,
we
clarify
that
up
front.
A
A
D
Do
we
still
have
access
to
the
fun
retro
board
that
darcy
set
up
is
that
from
the
previous
minutes.
A
It's
the
link
to
it
is
somewhere
you
you're
thinking
of
using
it
or
thinking
about
looking
at
this.
What
was
there.
D
A
A
A
F
One
thing
I've
been
thinking
is,
for
example,
prioritizing
your
user
experience
is
that
he
is
very
important
to
the
project
in
my
opinion,
but
it's
not
going
to
be
possible
to
prioritize
it
over
security
or
performance.
For
example.
On
every
case,
it
will
probably
probably
be
possible
in
some
cases,
so
I
I'm
not
entirely
sure
if
we
can
have
a
hard
rule
of
x
over
y
over
z,
for
example.
I.
A
A
E
A
A
Sorry,
yes,
participants,
I'm
looking
yep.
A
H
A
We're
talking
about
technical
values,
okay,
and
if
you
go
to
the
minutes,
we're
typing
them
in
under
the
the
section
you'll
see
them.
There's.
H
H
G
A
E
A
Yeah,
it's
the
spacing,
and
the
stars
are
the
only
thing
that
really
matter
to
me.
The
rest
gets
stripped
out
when
I
convert
it
into
the.
B
A
A
E
E
A
E
A
E
There's
library,
authors,
so
this
is
where
I'm
do
those
count
as
end
users
or
do
those
are
do
we
want
some
sort
of
separate
category
for,
like
a
library
author
to
me,
is
like
more
invested
in
the
community
yep,
whereas
an
end
users
more
like
well,
I
kind
of
I
touch
it
sometimes,
but
I
don't
necessarily
like
there's
like
another
step
right
library,
authors
sort
of
are
more
invested.
A
E
So
technically
the
people
who
are
most
building
on
top
of
the
core
apis
are
the
library
and
package
maintainers
right
right.
Although
everybody
uses
them
too
right.
I
that's
what
I'm
trying
to
say.
I
don't
think
so,
a
front-end
tool,
author!
Probably
if
you
go
look
at
the
webpack,
configs,
sorry
not
tool.
Author
user
right,
end
consumer,
like
if
you
look
at
webpack
config,
it
might
only
use
like
require
and
path
like
that's
a
common
right
thing.
So
like
would
you
even
really
consider
them?
A
E
D
A
E
I
think
there's
like
hobby
developers
who
build
like
one
thing.
You
know
if
you
think
about
the
growth
of
node,
like
a
lot
of
it,
has
been
due
to
the
fact
that
a
hobby
developer
can
pick
it
up
and
write
some
iot
thing
or
write
some
distributed
system
experiment
and
to
me
those
are
sort
of
they're.
They
don't
fit
neatly
into
a
front-end
tool.
Consumer
back-end
server
type
thing,
but
they
they
might
like
right
do
a
wide
swath
of
types
of
work.
E
E
Maybe
maybe
actually
doing
how
do
you
structure
it?
That
makes
the
most
sense
yeah,
there's
different
concerns
for
a
enterprise
level
versus
yeah
professional,
I
think,
is
a
good
word
too,
because
it
also
avoids
the
loaded.
A
A
A
I
think
it's
good
we
can
like
put
as
many
of
those
in
there
and
then
as
we
go
through
the
discussions.
It's
like,
would
we
actually
you
know
prior?
Would
we
call
out
any
of
those
individually
versus
end
users
right
like
calling
out
the
pac
library
pocket
package
authors?
I
think
it's
a
good
start,
I'm
not
sure
if
we
need
to
pull
out
any
of
the
other
ones.
E
That
makes
sense-
maybe
I
guess
I
was
just
trying
to
think
of
the
difference,
but
maybe
just
calling
it
application
developers
would
would
be
a
good
sorry,
for
I
was
thinking
for
the
combination
of.
G
E
E
That
that
makes
sense,
because
then,
because
then
application
developers
there
could
also
be
like
you
know,
different
from
an
application
would
be
like
a
tool
author
and
they
maybe
aren't
publishing
it
as
a
library
but
they're.
Just
writing
a
small
node
script
to
automate
something
right
like
it's
just
a
one-off.
G
E
That's
not
a
library,
that's
sort
of
a
slightly
different
experience
than
an
application
developer
might
have
sorry,
I'm
sort
of
brain
dumping.
Anybody
can
come
yeah.
A
A
I
guess
there
is
like
you
know,
like
application
developers,
there
can
be
like
application,
deployers
lawyers
operators.
A
Are
important
to
you
know
an
application
keeping
up
and
running
and
to
the
like.
You
know
the
success
of
note
if
it's
import,
if
it's
impossible
to
operate
a
node
application,
even
if
it's
quick
to
develop
that
doesn't
isn't
going
to
be
so
good.
A
Devops
seems
to
confuse
things
for
me,
like
I
haven't,
like
that's
you're,
basically
saying
you're
going
to
be
a
developer
and
an
operator
right,
so
I
don't
know
that
it's
strictly
devops
people,
it's
anybody
who
would
end
up
having
to
operate
it
after
it's
built
that
could,
depending
on
your
model
that
could
be
developers.
Often,
though,
it's
like
a
separate
team
who's,
you
know
actually
deploys
the
applications
into
the
production.
Environments
has
access
to
them
and
I
don't
think
at
least
from
from
what
I've
seen.
That's
completely
changed.
H
Michael,
I
can.
I
can
actually
help
you
out,
because
why
I
was
a
developer
and
then
I
got
switched
to
devops,
so
I
can
actually
help
you
it's
more
about
like
right
now.
What
we
do
is
more
about
building
pipelines
and
deploying
asking
it
and
giving
it
to
the
developers
to
deploy
it
themselves.
So
you
basically
set
up
like
all
the
whole
processes
of
the
build
deploy
like
for
testing
like
you
build
up
the
pipeline
and
then
we
just
give
it
to
them,
and
then
we
maintain
the
servers.
H
A
And
that's
still
kind
of
what
I've
seen
over
the
years.
Is
that,
like
there's
the
developer,
who
focuses
on
building
the
system
itself
and
then
there's
you
know
a
group
who
focuses
on
making
sure
it's
continues
to
run
correctly
and
are
the
first
point
of
contact
if
things
go
wrong
and
then
pull
the
developers
in
to
help
when
it's
clear,
it's
something
and
you
know
a
bug
in
the
code
versus
something
in
the
infrastructure.
H
H
H
E
We
think
operations
is
more
important
than
the
developer
experience.
That
will
help
us
sort
of
give
clarity
here,
whereas,
like
the
nuance
of
well
there's
all
these
other
things
like
now.
If,
if
network
engineers
needed
hooks
into
node
core
to
get
their
job
done,
then
maybe
I
think
we'd
call
them
out
as
a
end
constituency,
but
I
don't
think
they
do.
I
think
that
operators
and
developers
are
pretty
clear,
big
buckets.
A
A
We
have
application
developers
who
then
pull
those
together
into
like
the
end
solutions
that
actually
are
run,
and
then
we
have
operators
who
who
actually
run
those.
You
know
help
to
run
those
things
and
then
we
have
end
users,
and
I
guess
the
question
then
is
like
what
are
the
end
you
I
I
can
like
now.
I'm
thinking
that
like,
for
example,
in
the
case
where
we
have
applications
developed
and
then
operators
running
them
end
users
don't
really
play
into
that
so
much
anymore.
E
Yeah
that
end
user
might
still
have
some
level
of
interaction
with
node.
In
that
you
know
today
they
need
to
install
node.
You
know-
and
I
think
that's
valid,
but
I
also
think
there
might
be
a
feature
where
they
don't
have
to
install
node.
E
You
know
if
you
bundle
it
as
a
binary
all
with
your
hip
thing,
but
I
still
think
them
understanding
that
they
are
using
a
javascript
runtime
or
something
may
have
some
value
for
us
to.
A
E
A
A
A
A
C
G
G
E
All
the
way
from
the
center
all
the
way
out,
then
great,
but
if
you
have
to
make
a
concession
right,
try
to
make
the
end
user
experience,
direct,
end
user
or
whatever
great
and
then
work
back
from
there,
but
I
think
in
some
cases
the
way
we've
broken
this
out.
I
actually
think
that
it's
better
to
make
so
like
I
would
put
developers.
A
E
E
I
mean
I'm
sort
of
gonna
make
a
joke
here,
but,
like
isn't
that
good,
we've
already
hooked
them.
You
know
that
again
it's
a
joke,
they've
already
written
their
app
and
node.
Now
we've
got
a
hook
at
that
point.
It's
just
a
matter
of
working
out
the
details.
E
E
A
But
really
developers
are
package,
authors
as
well
right
and,
and
we
could
like
you
know,
you
could
say
that
developers
include
and-
and
I
guess
you
really
want
end
users
in
here
right
and
users
over.
E
I'm
not
entirely
sure
this
format
is
going
to
bear
the
same
amount
of
fruit
as
it
does
for
the
html
spec
about
this
because
package
authors,
while
they
might
be
developers,
there's
two
boats
right.
I
do
think
valuing
application
developers
over
package.
Authors
is
sort
of
a
false
dichotomy
right
because
there's
a
when
you
say
package,
authors
there's
a
whole
nother
realm
of
things
that
just
don't
even
apply
when
you're
writing
an
application
that
we
want
to
have
an
experience
around
right,
so
saying
that
we
value
them
over.
E
H
E
A
A
E
Stock,
I
mean
just
to
be
aware,
though,
if
you
say
push
the
work
up
the
stack,
if
we
say
more
work
for
core
maintainers,
then
what
we're
saying
is
not
small
core
right.
So
like
sometimes
these
things.
If
we
want
this
to
be
the
foundation
of
our
right
mission
statement
that
then
it
will
directly
conflict
with
things
that
people
have
strong
opinions
on
on
the
higher
up
stuff.
Like
like
what
the
small
core
look
like,
I'm
not
opposed
to
making
that.
E
But
I
think
we,
you
know,
we
we've
spent
a
fair
amount
of
time
on
just
this
part,
and
if
we
find
that
everybody
agrees
that
maintain
maintaining
a
small
core
is
supremely
valuable.
Then
at
that
point,
no
we're
saying
that
we
value
core
maintainers
over
library,
authors
right
right,
because
just
instead
we're
no
we're
going
to
push
the
complexity
on
to
the
library
authors
right.
A
A
A
How
would
we
value
those
things
because
it's
kind
of
like
I
think
I
think
that
at
least
having
like
a
hey?
This
is
where
we
that
we
could
actually
say
like
here
are
some
possibilities
and
then,
as
we
work
through
the
different
values
that
may
actually
you
know,
some
of
them
support
one
versus
the
other
as
well.
Right.
A
H
A
A
Okay,
so
I'd
say,
given
that
we
have
only
a
few
minutes
left.
Maybe
we
should
leave
today's
discussion
at
that
and
then
next
time
dive
into
these
values
and
and
sort
of
figure
out,
which
ones
we
think
would
be
prioritized
over
others
and
sort
of
use
that
to
drive
the
direction
next.
Does
that
make
sense
to
people.
A
E
E
A
A
A
A
Okay-
and
we
are
at
time
so
I
think
that
that
was
a
good
start
thanks
for
everybody
for
spending
the
time,
though,
maybe
the
one
thing
we
should
do
is
I
just
chose
the
time
for
this
one.
A
I
guess
I
will
just
rotate
like
pick
the
next
one
in
the
tsc
rotation
list,
provided
it
doesn't
conflict
with
the
tse1,
in
which
case
I
would
just
skip
and
go
to
the
next
one.
Does
that
sound.
A
A
Okay,
so
I'll
go
ahead
and
go
ahead
and
do
that
and
I'll
add
it
to
the
to
the
calendar
for
two
weeks
from
now,
thanks
for
everybody's
time
and
we'll
talk
to
everybody
later.