►
Description
Recording from the Next 10 years of Node.js at the OpenJS collaborator summit
A
A
Okay
right
so
I
put
together
a
little
bit
of
an
outline.
We
can
talk
about
that
see
what
we
think
makes
sense.
I
suspect
we
won't
get
through.
All
of
this,
we
were
thinking
of
planning.
This
is
like
a
multi
session
discussion,
but
this
can
be
a
good
kickoff.
My
thinking
and
discussion
that
we
had
before
is
we
could
start
it
with
a
retrospective.
In
terms
of
you
know,
what
kind
of
things
went
well
in
the
past
ten
years?
What
were
the
keys
to
success
is
what
worked
in
the
management
project?
A
A
But
in
the
box
document
that
I've
shared
put
together,
what
we
think
was
most
important
to
talk
about
to
kick
things
off
and
after
that
five
minutes
come
back
review
that
decide.
You
know
exactly
what
we're
going
to
dive
into
details
on
so
doing
that
both
for
the
retrospective
and
for
those
looking
forward.
Does
that
sound
good
to
people.
A
A
D
A
A
A
A
D
E
A
F
F
G
A
A
A
D
A
D
A
D
A
A
D
D
H
A
G
I
D
H
A
A
Javascript
is
the
main
language
in
the
front
end.
It's
easy
for
developers
develop
things
the
back
end
small,
but
useful
enough
core
consensus
seeking
model
focus
on
community
freedom
reviews
do
things
that
we
would
not
new
features
that
originally
had
professed
the
project
make
people
like
that
was
striving
ecosystem,
Weibull
software
very
stable,
fast
to
use
and
easy
use,
ease
of
welcoming
new
contributors
to
the
project
and
widespread
adoption
of
NPM
registry
March.
All
coupled
and
open
source
on
github
allowed
real
collaboration,
value
being
transparency.
A
A
I
think
we
can
improve
how
we
handle
contentious
issues,
good
documentation
using
github
as
a
platform
for
organizing
meeting
calls
or
effects
well
decisions,
whatever
process
delayed
promises
in
core
did
not
work
well.
That
should
have
been
pursued
aggressively
or
years
earlier.
The
merger
was:
are
you
allowing
the
adoption
of
a
different
released
cadence
and
the
rapid
adoption
of
Neuer
JavaScript
features?
The
actual
IO
nodejs
version
leap
itself
was
a
bit
of
a
disaster.
I,
don't
really
know
what
was
going
on
it
made
it.
It
look
like
the
previous
governments
have
been
wobbly.
A
Okay,
so
I
think
at
this
point
we
have
you
know
another
15
minutes
or
so,
and
it's
kind
of
what's
the
best
way
to
sort
of
summarize
this
into
something
that
will
inform
what
we
think
we
should
be
doing
going
forward.
I
think
you
know
in
terms
of
the
what
worked
and
what
didn't
work,
there's
a
few
things
which
are.
Maybe
we
should
pull
it
in
to
what
didn't
work
in
one
area
and
what
did
work.
A
D
A
D
A
Okay,
cuz
yeah,
we'll
want
to
export
that
and
put
it
into
the
the
minutes.
I
mean
in
terms
of
looking
at
it.
You
know
if
we
look
at
some
of
the
key
themes
just
so
that
we
think
about
them.
Maybe
we
can
pull
those
out
into
the
doc.
Can
I
get
this
into
here?
So
in
terms
of
like
what
do
we
want
to
keep
in
mind,
as
we.
A
B
E
B
A
So
I
think
we
we
only
have
a
seven
more
minutes
for
this
initial
section,
but
I
think
I
put
on
one
of
the
topics
for
later,
like
in
the
second
half
looking
forward.
It
seems
like
consensus
seeking
would
be
one
of
the
six
topics.
Maybe
we
should
dive
into
some
more
detail
on.
Does
that
make
sense
to
people.
C
C
Malece
II
that
list
right
now
having
some
system
issues
I'm
doing
it,
but
our
meetings
are
we're
still
we're
still
having
some
listen,
follow
getting
a
you
know,
a
really
good
diversity
of
folks
and
participating
actively
in
the
meetings
this.
If
we
look
at
this,
this
call
right
in
terms
of
who
the
attending
I
think
we
have
like
maybe
one
or
two
women
and
the
rest
are
all
all
guys,
not
a
great
diversity
of
time.
Time
zones
represented
right.
A
Guess
the
like
out
of
this
one,
it
would
almost
be
like
if
we
could
come
up
with
water,
that
we
have
the
key
things.
So
we
want
to
keep
doing
the
things
that
were
successful,
maintain
the
things
we
think
that
were
the
key
values
which
were
supported
the
success
and
then
figure
out
how
to
improve
the
things
which
I
didn't
work.
A
C
All
right,
I'll
go,
then
you
go
I'll
make
it
quick.
The
one
thing
that
I
will
point
out
from
the
survey
results
is
the
one
thing
that
people
express
the
most
amount
of
frustration
with
is
all
process
oriented
stuff
around
how
we
have
our
conversation.
So
we've
already
mentioned
this.
You
know,
how
would
you
determine
consensus
and
I
would
do
the
meetings
I
would
have
to
say
that
it
based
on
everything
I've
seen
they're.
Really
the
priority
comes
down
to
that
over
everything
else.
H
A
C
We
could
we
could
spend
an
hour
to
talking
about
the
the
collaborator
survey
results
around
small
yeah.
One
thing
that
you
know
in
that
report
that
there
absolutely
was
no
consensus
on
whatsoever
right,
the
in
terms
of
priority
and
how
we're
doing
on
it.
You
know
it's
pretty
much
even
across
the
board.
Yep.
A
Yeah
I
know
I,
think
we're
split
in
terms
of
some
people
still
believe
small
core.
Other
people
are
like
well,
no,
we
should
be
adding
more,
and
so
that's
definitely
like.
As
we
look
for
it's
probably
one
of
the
key
things
we
should
talk
about
so
we're
down
to
two
minutes
for
this
section,
any
other
key
things.
People
want
to
call
up
from
having
sort
of
looked
at
this
thought
a
little
bit
about.
H
And
not
brought
in
there
either,
which
is
similar
to
small
core,
in
my
opinion,
is
compliance
with
like
browser
specifications.
This
has
come
up
a
bunch
because
of
the
demo
stuff
where
people
are
like
yeah,
but
look
danos
fought
trying
to
like
follow
as
a
guiding
principle
browser,
specs
and
I.
Don't
know
if
we
have
a
statement
on
that
or
I.
H
A
A
Okay,
so
I
think
I
think
we're
at
time
for
this
section.
So
now,
let's
flip
over
to
the
next
section,
which
is
like
looking
forward
now,
we
have
this
this
long
list
of
topics
you
know
grouped
into
technical
management
of
the
project,
building
no
js'
dependencies
safety
net,
key
technology
trends,
no
Jess
readiness
as
an
enterprise-grade
runtime,
no
GS
and
JavaScript
landscape,
growing,
nodejs
and
I'd
have
to
look
to
see
where
and
if
these
the
things
we've
just
talked
about
are
as
well.
A
So
there's
this
list
at
the
top
consensus
seeking
how
we
have
our
conversations,
what
I
had
in
mind
and
I
don't
know
like.
Maybe
it's
too
aggressive
to
try
and
you
know,
do
six
topics
in
20
minutes
and
10
minutes
each.
Maybe
three
topics
in
20
minutes
so
I'm,
you
know
whatever
people
think
make
sense
there,
but
I
think
now.
What
we
want
to
do
is
as
sort
of
a
kickoff
pick.
You
know
some
number
of
topics
we
can
do
it
again.
You
get
Darcy
sup
another
board.
A
In
this
case,
we
know
we'll
get
people
to
put
in
their
top
ones
and
rank
them
and
then
vote
for
the
others,
and
we
can
figure
out
what
those
those
topics
would
be.
So
first
of
all
is
like.
Would
people
prefer
fewer
topics
with
more
time?
Stick
top
six
or
six
topics?
You
know
three
topics,
20
minutes
or
say
six
topics,
ten
minutes.
What
do
people
think
is
make
sense.
A
D
A
We
we
start
out
with
and
will
then
dive
into
those
ones,
hoping
with
in
the
last
few
minutes
the
last
20
minutes
of
actions
we
can
include.
How
do
we
continue
these
conversations,
because,
obviously
we
will
not
have
covered
everything
that
we
really
should
have
should
talk
about
in
terms
of
making
sure
we've
got
a
plan
and
and
view
of
the
future.
F
A
D
A
E
C
A
A
Okay,
so
it
looks
like
we've
got
key
technology
trends,
no
GS.
What
gets
in
does
not
get
into
small
core
and
more,
and
should
we
have
a
roadmap
priority
list
as
the
top
closely
followed
by
community
in
terms
of
teaching
and
showing
people
how
to
contribute
to
core
and
then
all
the
rest.
So
I
guess
in
terms
of
picking
three
we've
got
three
top
ones:
oops
No
so
which
one
do
we
want
to
start
with?
I
guess
why
don't
we
start
with
the
key
technology?
Transit
nodejs
since
that
got
the
most
votes?
B
Can
start
with
an
icebreaker
on
typescript
at
least
I
think
the
typescript
is
very
heavily
used
in
the
ecosystem,
and
it's
something
we
need
to
definitely
support,
but
due
to
the
nature
of
typescript,
I
feel
very
strongly
that
we
should
not
include
the
compiler
in
nodes.
Core
typescript
does
have
breaking
changes
that
we
historically
have
been
adverse
to
and
over
its
lifetime,
and
it
will
continue
to
have
those
also.
B
B
Ensuring
that
we
actually
have
some
guidance
for
the
people,
creating
the
node
type
definitions.
To
my
knowledge,
we
don't
really
interact
with
that
at
all.
They
also
don't
consider
a
node
currently
to
be
a
runtime
target.
It
node
is
a
library
option,
basically
just
having
better
integration
with
type
scripts
and
flow
of
things.
B
You
can
see.
Friction
that
I
worry
about
with
that.
With
things
like
type
script,
refuses
to
output,
a
variety
of
things
for
the
ESM
implementation
and
node,
even
though
they
were
part,
they
also
have
decorators
that
they
ship
that
are
not
compliant
with
modern
decorator
proposals
that
they're
not
going
to
remove.
So
we
know
that
that'll
be
a
breaking
change
in
the
future
and
those
are
the
kinds
of
things
that
make
me
wary
of
ever,
including
the
compiler
itself
in
I.
E
Wanted
to
add,
as
well
I
mean
try.
Script
is
both
incapable
at
the
moment
of
fully
typing
all
JavaScript
values,
and
also
like
is
there's
like
there
are
very
kind
of
fundamental
inaccuracies
in
the
way
it
tries
to
type
JavaScript
that
it
would
be
very
concerning
to
me,
if
note
like,
like
it's
totally
fine,
if
node
is
trying
to
make
sure
that
fake
scrip
users
have
a
good
experience.
E
In
note,
that
is
fine,
but
if
node
in
any
way
sort
of
commits
to
typescript,
then
that
what
concerns
me
because
texture
it
doesn't
like
it,
didn't
get
it
into
subset
of
JavaScript.
It
isn't
actually
accurately
typing
JavaScript
and
like,
although
these
things
are
pretend
are
arguably
bugs
like
until
they're
fixed,
you
know
or
like
some
of
them
are
planned
to
be
fixed.
In
other
words,
like
you,
can't
have
symbols
as
property
keys
for
examples
like
it's
indexable
property
keys,
so
it's
I
think
it
would
be
I.
E
A
E
E
E
Why
I
think
it's
a
bad
idea
for
packages
to
ship
their
own
types
is
like
the
it's
really
hard
to
define
cember
around
two
surfaces,
the
value
space
in
the
type
space
and
node
already
I.
Don't
know
if
the
word
struggles,
but
already
puts
a
lot
of
effort
into
defining.
How
semver
applies
to
nodes.
Ap
is
to
have
to
us
to
not
just
duplicate
that
effort
for
the
types
but
also
figure
out
how
the
two
of
those
interoperate
seems
like
an
intractable
problem.
A
So
I
don't
think
we
have
time
to
dive
into
you
know
each
technology
in
depth,
I
wonder
on
the
typescript
front
of
how
many
people
would
you
know
how
many
people
would
would
say
that
it's
important
to
the
success
as
we
go
forward
for
the
next
ten
years
of
node
to
figure
out,
you
know
the
nodes,
typescript
story.
What
we
should
be
doing-
and
you
know
like
is
it-
is
it
that
you
know
like
I,
suggested
it's
like
hey.
A
C
Think
it's
critical
that
we
very
ly
define
have
a
definition
about
what
we
mean
when
we
say
note,
has
type
African
support.
What
is
the
scope
of
that?
What
is
the
limit
of
that
right?
You
know,
and
at
least
gives
us
a
way
of
framing
a
conversation.
If
somebody
comes
to
us
and
say
a
ad
types
could
support
or
do
this
or
do
that
it
gives
us
some
bounds
where
we
can
say
yeah.
C
That's
if
that's
something
we're
you
know
that
belongs
in
courses
just
something
that
doesn't
right
now
we
have
very
whole
conversation,
very
vague
and
nebulous
and
there's
very
little,
and
then
the
boundaries
of
all
of
us
are
very
fuzzy
about
what
exactly
this
type
scripts
important
note.
Actually,
so
we
have
to
clarify
that
before
we
can
move
on.
A
Right
I
think
I
think
what
I
hear
is
like
we've
got
to
figure
out
the
node
type
typescript
story,
which
could
be
anything
from
nothing
to
like
I.
Don't
think,
there's
one
answer
to
what
you
just
said,
but
I
think
is.
We
should
come
up
with
wheat.
What
we
think
the
right
answer
is
that
is
that
fair,
yeah.
C
F
A
F
F
J
B
So
Mikey
about
why
didn't
want
to
include
the
compiler
is
whatever
support
matrix.
We
have
for
typescript.
We
need
to
beware
of
what
forwards
incompatibilities
we
are
adopting.
So
type
syrup
has
known
forwards.
Incompatibilities
like
decorators
know,
whenever
decorators
land
in
JavaScript
the
language
itself,
they
will
not
work
how
they
work
in
typescript,
all
right.
Okay,.
B
A
B
A
G
But
if
we
support
that
and
we
have
our
own-
you
know
our
own
API
is
like
nappy.
You
know
integrated
into
that.
We
can
start
to
really.
You
know
integrate
note
or
things
can
integrate
into
node.
That
you
know
would
not
previously
have
been
possible,
or
you
know
just
like
you
can
start
to
sort
of
plug-and-play
node
with
lots
of
other
things.
That
would
you
would
not
normally
do,
which
I
think
makes
it.
You
know
powerful
in
terms
of
being
able
to
really
extend
node
then
use
it
in
different
environments.
B
So
why
isn't
has
some
interesting
advantages?
So
we've
spent
a
lot
of
time
courting
C++
code
to
JavaScript
and
that
generally
comes
with
performance
or
garbage
collection
penalties.
Doing
so
I
would
be
very
much
on
the
side
of
we
need
to
take
a
serious
look
at
having
built-in
modules
written
in
wasum.
Some
of
the
defensive
coding
styles
we've
started
to
adopt
are
tedious
and
could
be
worked
around
if
we
used,
while.
E
Would
be
I
still
prefer
as
much
of
note
as
possible
to
be
in
JavaScript
it's
late,
but
I
would
much
rather
see,
wasn't
and
C++
if
and
it
seems
like
an
important
standard
to
support,
especially
given
that
it's
gonna
ship
in
browsers
along
the
JavaScript
and
be
equally
usable
at
some
point,
it
seems
like
it's
pretty
critical.
That
notice
have
just
the
same
amount
of
usability
around.
Why
some
of
the
browsers
do.
C
G
Huazi
is
sort
of
okay,
so
Razzie
is
not
a
monolithic
api.
It's
broken
up
into
chunks
that,
like
different,
you
know,
do
can
support
so
like
a
lap.
You
know
your
Linux
kernel
running
as
he
might
have
like
networking,
or
you
know
your
watch
might
have
bluetooth
so
like
browsers,
are
committed
to
shipping
certain
parts
of
huazhi.
In
that
sense,.
E
B
Think
the
important
part
for
huazi
is
there's
some
stuff
about
how
permissions
are
and
bindings
are
automatically
injected
when
you
instantiate
a
module,
everybody
doing.
Huazi
has
the
same
kind
of
basic
template
for
that.
Also
huazi
has
a
specific
FFI
model
being
introduced
called
interface
types,
and
that
affects
things
like
running
a
web
assembly
binary
directly.
G
A
E
J
Change
the
priority
order,
I
personally,
believe
that
wasn't
is
important
and
for
the
next
ten
years
differently.
But
it's
not
going
to
have
as
widespread
usage
as
typescript
is.
Typescript
is
just
basic
thing
that
everyone
wants
to
run
and
they
don't
want
to
think
about
it
anymore.
They
just
want
to
start
up
the
application
and
have
something
running.
C
A
Yeah
I
think
that
that
may
be
a
longer-term
thing
than
a
shorter
term
thing
everybody
has
looked
at
it
has
said
you
can
only
do
a
subset
with
wasum
that
you
can
do
with
current
modules
native
modules
yeah,
but
longer-term.
You
know
you
know.
If
that's
what
what
I'd
really
like
to
see
is
a
path
where
you
can.
You
can
basically
build
your
add-on
using
the
same
tools
and,
if
you're
doing
something
that
so
wasn't
is
the
subset
that
will
run
under
wasum.
A
You
can
compile
it
as
was
them
and
it
works,
or
if
it's
something
that
you
need
to
run,
isn't
it
as
a
like
awesome
can't
do,
then
you
can
build
it
as
an
API
add-on
and
it
and
it
works,
and
if
that
line
changes
you
can
simply
recompile
it,
and
now
it's
the
Wazza
module
right,
but
I
think
so
I
think
at
this
point
we
should
spend
our
last
few
minutes
on
you
know.
Those
are
two
good
examples
of
things
that
I
think
we
see
you're
important.
C
E
Might
also
be
useful
to
look
at
browser
api's
and
decide
if
the
there
is
a
possible
core
subset
that
both
browsers
in
node
could
share,
because,
like
fetch
itself
like
there's
like
as
an
example,
deals
with
you
know,
and
the
current
URL
and
all
sorts
of
stuff
that
just
contests
don't
exist
in
node,
but
90%
of
a
fetch
or
whatever.
The
number
is
works
just
great
in
node
and
so
like.
It
would
be
great
if
there
was
some
common
subset
that
that
the
browser's
a
node
could
all
have
and
then
fetch
would
be.
The
browser.
C
And
in
this
we
break
that
down
in
terms
of
okay.
What
are
the
core
components
of
fetch
that
are
needed
in
it,
enable
it
without
actually
going
all
the
way
so
things
like
event
target,
which
we
just
landed
port
controller
file,
blob
right,
these
things
are
all
primitives
that
could
exist
in
no,
they
don't
hang
out.
You
know
the
definitely
very
relevant
to
note,
whereas
you
know
fetch
fetch
implementation
could
easily
be
user
way
and
implement
it
implemented
on
top
of
these
core
pieces
in
them.
A
So
I
think
the
this
sounds
like
I.
Think
James
tell
me
if
I'm
characterizing
it
wrong,
but
like
an
again
like
a
key
success,
factor
could
be
figuring
out.
Defining
are
like
nodes
approach
to
supporting
browser.
Ap
is
like
it
shouldn't
be
that
we
like.
We
should
have
a
plan
that
says:
okay,
there's
browser
API.
Yes,
we
think
it's
really
important
to
be
compatible.
If
so,
what
are
we
doing
so
that,
like
when
new
AP
eyes
come
out,
do
we
like?
Do
we
try
and
keep
track
of
those?
J
J
When
it
comes
to
Dan,
maybe
like
faster
adoption,
then
what
we
do
mostly
otherwise,
so
it
was
event
target
and
I
believe
we
are
quite
fast,
but
when
it
comes
to
example,
fetch
or
WebSocket,
it's
a
very
long
ongoing
discussion
without
actually
finding
any
solution
or
consensus
on
it
and,
and
that
probably
will
drive
away.
People
at
some
point
might
drive
them
away
right.
A
C
I
would
actually
move
WebSockets
at
this
upper
category
that
you
have
networking
and
more
standards.
I
would
put
WebSockets
there.
I
would
put
the
ongoing
work
around
quick
right.
I
mean
quick,
quick
as
for
progressing,
but
it's
still
something.
That's
still
a
lot
to
do
you
know,
so
you
know
we
definitely
need
to
be
looking
at
those
and
coming
up
with
a
strategy.
I
think.
A
C
Like
that,
I
was
just
one
of
the
key
themes
with
the
networking
standards
is
I
I
want.
We
really
have
to
avoid
having
to
have
a
new
surface
area,
API,
surface
area
for
every
web
protocol
and
having
hp1
API
hb2,
API,
I'm
dreading,
and
you
know
any
possibility
of
having
having
to
have
an
HD,
3,
API
and
the
reason
we've
had
to
have
these
separate.
C
I
A
B
Even
like
new
browser
standards,
where
they
are
always
touted
is
doing
things
kind
of
in
flexible
ways.
You
just
write
it
without
a
tool
or
starting
to
adopt
things
like
import.
Maps
people
are
using
tools
like
typescript
the
things
that
compile
the
wasone
for
node.
We
don't
really
have
a
support
story
for
what
people
can
do
ahead
of
time
with
node.
B
A
J
For
the
next
year's,
also,
we
should
strive
for
simplicity
in
all
our
IP
is
sometimes
node.
Api
is
tend
to
be
more
complex,
it's
often
historical
and
yeah.
Now
we
should,
for
example,
focus
more
on
the
promised
API
is
to
implement
them
everywhere,
so
that
people
are
able
to
use
them
right
away
instead
of
having
into
promising
findings
on
their
own.
Most
people
do
not
even
know
about
our
utility
function.
J
J
Better,
like
better
debugging
experience
with
events.
This
is
a
long
ongoing
thing
that
we
do
not
have
stack
traces
for
the
async
API
and
it
should
be
that
simple.
You
know
sometimes
we
discussing
in
the
diagnostic
working
group
and
try
to
figure
out
complex
situations,
but
this
is
way
too
complex
for
98%
of
all
developers
who
use
nodes
and
it
would
be
great
to
reach-
maybe,
let's
say
50%
of
the
developers
and
to
do
so
it
has
to
be
really
really
simple
and
it
just
be
there
pretty
much.
A
Okay,
I
think.
Unfortunately,
we
got
to
move
to
the
next,
the
next
section,
but
we
could,
you
know
I
think
we
should.
We
can
capture
this
and
we
should
come
back
and
continue
this
sort
of
planning
for
the
for
what
we,
what
we
think
and
I
think
each
one
of
these
almost
need
to
dive
a
deep
dive,
but
the
next
topic
was
what
gets
in
does
not
get
in
small
core.
A
B
So
the
web
has
a
thing
actually
on
their
HTML
design,
principles,
which
I
would
love
if
we
could
adopt
I'm
going
to
put
the
link
here
and
in
the
dock
in
particular.
It
has
something
called
the
priority
of
constituencies,
Oh
words
which
basically
gives
a
hierarchy
of
design
priorities,
so
I
just
want
to
read
it
for
a
sec.
It'll
only
take
a
minute
in
the
case
of
conflict,
prioritize
users
over
authors
over
implementers
over
specifiers
over
purity,
and
so
we
don't
really
have
any
such
thing.
B
This
is
like
one
sentence
that
I
think
node
would
benefit
greatly
from
adopting
over
the
next
ten
years
figuring
out.
What
our
actual
priorities
are.
We
often
come
into
conflicts
of
people
stating
things
our
performance
problems
but
benefit
users,
and
we
also
come
into
things
where
we
reject
features,
because
it
affects
a
benchmark
in
a
way
that
might
be
odd.
B
I
would
say
we
don't
have
any
guidance
even
for
collaborators
like
myself,
I've
been
around,
you
know
10
ish
years
almost,
and
we
still
face
problems
of
this
nature
like
we
had
an
issue
of
PR
thread
about
moving
loaders
into
a
thread,
and
we
simply
don't
have
any
sort
of
technical
document
that
we
can
refer
to
or
any
method
to
produce
design
decisions
that
can
be
referenced
later.
We
just
kind
of
point
to
old,
PRS
and
so
there's
no
central
place
to
have
a
guiding
principle,
and
so
we
get
into
conflict
in
those
PRS
about.
A
Think
I'd
add
to
that.
Like
there's
been
some
some
discussion
recently
around
like
how
do
we
avoid
duplicate
effort-
and
you
know
I
think
related.
Also
like
larger
changes,
you
know
people
can
invest
a
lot
of
time
and
then
you
know
people
come
up
with
like
concerns,
complaints
and
like
I,
think
that
kind
of
fits
together
did.
A
B
B
It
doesn't
really
say
anything
about
them,
they're
doing
it
for
their
own
personal
needs,
but
we
have
implicit
contracts
by
you
know
ordering
the
fs
calls
of
how
commonjs
work
that
the
ego
system
now
depends
upon,
and
we
have
no
design
principles
stating
that
that
is
a
safe
thing
to
do,
and
we
also
don't
have
something
stating
that
they
should
not
do.
That.
B
J
E
Hope
no
to
adopt
these
principles
I
think,
like
officially
I,
think
it
would
be
a
very
good
thing
and
to
Michael
I
think
you
were
talking
about
like
legacy
code
and
stuff
to
me
that
that
falls
into
the
users.
Part
of
the
constituencies
raises
the
existing
users
that
are
using
existing
api's
are
the
top
priority,
even
if
those
api's
are
not
good
for
the
rest
of
the
constituencies.
B
But
this
was
a
road
map
when
we're
talking
about
users,
when
we
have
a
guidance
of
who
we're
trying
to
serve
with
PRS
and
core,
we
aren't
just
adding
api's
that
add
new
features
to
core.
Sometimes
we're
trying
to
make
api's
that
make
users
have
a
more
enjoyable
experience
or
a
more
bug
free
experience
with
node.
Currently,
when
we,
when
we
try
to
prioritize
things,
part
of
the
issues
we
get
into
is
we
don't
have
an
underlying
roadmap
of
what
we
are
trying
to
accomplish
the
macro
level,
we're
always
at
the
PR
level.
B
With
this
code,
like
you
are
saying,
you
come
in
with
a
PR,
you've
already
done
work
just
to
get
the
PR
out
there,
and
then
people
are
only
viewing
it
at
the
macro
level
at
the
implementation,
not
as
an
overall
design
story
of.
Oh,
if
we
add
this,
that
leads
towards
something
else.
So
we
did
this
with
abort
controller,
really
well,
I
think
we
added
abort
controller
with
an
underlying
expectation
that
we
would
be
using
it
in
other
api's
and
we
simply
for
some
utilities,
aren't
gonna.
B
A
Right
I
think
maybe
you
like
it.
We
also
might
be
getting
to
some
terminology
here
in
that
I
yeah
I
see
I
I'm,
starting
to
see
where
you're
getting
at
now.
In
that
our
roadmap
need
not
be.
We
want
to
put
in
feature
X
feature
why
it's
more
of
a
these
are
what
we
think
is
important.
It's
important
to
improve.
A
You
know
the
debug
ability,
slash
diagnostic
sides
of
things.
It's
important
to
you
know
make.
If
we
decided
this,
you
know
make
provide
a
good
experience
for
typescript
users.
It's
a
and
then
you
can
tie
individual
PRS
to
one
of
those,
and
if
it's
in
support
of
that,
then
it's
it's
more
aligned
than
if
it's
not
aligned
with
one
of
those
things
is
that.
B
Exactly-
and
it
also
gives
kind
of
a
solution
to
a
problem-
I
see
sometimes
with
these
smaller
PRS.
If
you
introduce
a
small
feature,
it's
often
pushed
out
to
user
landfill
and
pushing
things
out
to
user
land
means
that
they
aren't
available
to
all
the
people
in
core
and
core
can't
utilize
that
functionality
either
or
recommend
it.
Even
in
our
Docs,
we
don't,
we
don't
recommend
you
use
these
ecosystem
modules,
which
people
rely
on
so
much
a.
K
K
That's
any
of
the
users
of
the
API
actually
want,
like
almost
every
user
of
asing
cooks
actually
wants
a
single
local
storage,
or
something
like
that,
but
because
of
the
small
core
philosophy
like
and
the
like,
intense
focus
on,
like
everything's
got
to
be
like
the
best
performance
possible.
Like
I
agree
like
like
trying
to
have
the
best
performance
you
can
is
good
and
like
to
an
extent
I
agree
in
small
core
idea,
but
I
also
feel
that's.
K
It's
like
III
think
you
kind
of
have
to
like
figure
out
what
the
users
actually
need
and
figure
out.
Well,
can
this
be
fully
implemented
in
user
land?
And
if
so,
then
let
them
do
that
if
it
needs
to
be
implemented
in
core
than
do
that.
There's
some
cases
where,
like
it
a
sink,
it's
a
global
storage
in
its
current
design
could
be
implemented
purely
in
user
land
using
the
eights
and
Cooke
staff,
but
they
sink
cooks,
stuff
and
all
the
stuff
around.
That
is
kind
of
terrible
to
use
directly.
K
Having
that
integrated
into
core
just
functions
a
lot
better
and
there's
a
lot
more
opportunity
for
it
to
be
optimized
like
it's
currently
layered
on
top
of
a
some
clocks.
But
we
could
swap
out
a
bunch
of
the
internals
of
a
sink
local
storage
to
make
it
more
deeply
integrated
and
make
it's
better
performing
API
because
it
being
layered
on
top
of
a
sand
caucus
is
just
an
implementation
detail
that
much.
A
K
C
You
know
we
yeah
with
that.
We
don't
really
have
a
policy.
We've
gotta
figure
this
out.
How
do
we
bring
one
thing
out
of
experimental
if
it's
based
on
another
thing?
That
is
experimental
because
our
guarantee-
or
you
know
the
thing,
the
thing
that
experimental
is
is
we
could
decide
to
pull
that
entirely
at
any
point
in
time
and
there
are
no
semper
guarantees,
so
we
would
have
to
you
know
if
suddenly
we
unexpected
something
and
then
something
we
have
to
completely
change
the
thing.
C
A
I
think
it's
like,
if
we
say
an
API
is
non
experimental.
The
fact
that
it
relies
on
things
that
are
our
experimental
now
becomes
our
problem
right
like
wish.
We
can't
say:
oh
sorry,
it
relies
on
something
that
was
experimental.
Therefore,
you
know
it's
like
we're
like
saying.
If
we,
if
we
say
if
we
get
rid
of
facing
Kooks,
because
they
were
experimental,
we'd
need
to
find
that
other
implementation.
K
A
So
I
think
again
we're
we're
running
out
of
time,
so
we
should
probably
move
on
to
the
next
topic,
but
it
sounds
like
putting
together
like
from
this
discussion.
It
sounds
like
there's
there's
interest
in
trying
to
put
together
possibly
putting
together
a
road
map,
but
if
the
road
map,
not
being
what
people
might
think
as
a
road
map
but
more
like
here-
are
here
the
things
we
think
are
important
to
the
success
the
success
going
forward.
A
F
F
C
Yeah
I
mean
you
know
we
have
we
have
user
using
like
oh,
that's,
they're,
relying
on
it
on
what's
there,
but
it's
never
been
great.
It's
never
but
great
performance.
It's
always
had
all
kinds
of
of
issues.
For
instance,
right
now,
there's
there's
an
abort
that
happens.
If
you
are
using
worker
threads
and
stuff
gets
thrown
out
there
they're
going
into
there's
all
cuz.
It
there's
all
kind
of
thread
safety
issues
there.
The
whole
thing
needs
to
be
completely
redone,
so
that
that's
one
thing
we
actually
need
some
investment
yeah.
A
A
At
sort
of
that
sort
of
high-level
here's
our
themes
and
then
you
can
slot
in
specific
things
to
those
themes
that
when
people
have
time,
like
those
things,
take
somebody
as
a
champion
to
push
forward
right.
But
we
probably
agree
on
the
themes
without
having
to
have
people
committed
to
do
each
one
of
them.
A
H
Well,
I
mentioned
it
originally
and
I
had
a
couple
of
things
that
I
was
thinking
of.
Specifically,
we've
had
a
couple
of
conversations
in
the
webserver
frameworks
team
about
api's
that
are
present
in
all
the
frameworks
and
whether
those
should
be
brought
into
core
and
there's
been
a
bunch
of
pros
and
cons
listed,
which
I
think
are
valid.
You
know
the.
If
we
move
it
into
core,
then
that
means
there
needs
to
be
people
available
to
support
it.
H
Performance
concerns
a
whole
bunch
of
things
like
that,
but
in
the
end,
if
every
single
framework
needs
to
do
it
on
their
own
and
and
there's
reasons
why
those
don't
always
end
up
being
shared
implementations,
sometimes
they
do
but
a
lot
of
times
they
don't.
It
just
seems
like
we're,
basically
telling
users
you
can't
use
just
the
HTTP
module
like
you
in
order
to
implement
anything
real,
you
still
have
to
go
and
use
a
framework.
H
A
H
Then
all
the
frameworks
would
still
have
their
sugar
and
there
are
different
ways
of
you
know
having
a
higher
level
API,
but
they
could
all
delete
all
of
that
code,
they've
written
themselves
and
then
to
transition
over
to,
depending
on
the
core
version
right
like
there's
a
lot
of
sugar
methods
on
express
that
just
it's
what
everybody
wants.
You
know
their
president
festa
fide
their
president
express
their
president
rousseff.
I
like.
Why
are
they
not
just
the
HTTP
api
in
core
I.
A
H
You're
saying
it's
a
different
thing:
okay,
so
the
users
it
would
help
would
be
the
ones
who
don't
want
to
use
a
framework.
So
what
we've
the
world
we
have
today?
Is
we
tell
everybody?
You
basically
have
to
use
a
framework
to
do
anything
in
a
real
HTTP
server
right,
you
know
it's.
The
current
thing
doesn't
even
give
you
like
setting
content
length
like
things
that
are
required
to
be
spec
compliant
right,
like
you
have
to
handle
all
of
that
yourself.
H
If
we
up
level
the
HTTP
API
a
little
bit
to
be
more
like
what
fast,
if
I
and
Express
provide
for
you
out
of
the
box,
then
the
benefit
would
be
to
the
users
who
don't,
for
whatever
reason,
want
the
full
kit
and
kaboodle
that
comes
along
with
a
framework,
but
still
want
something
that
they
can
functionally
build
on
top
of
alright,
so
it
be
changing
the
user
base
a
bit.
I.
J
+1
that
especially
sometimes
maybe
and
people
do
not
want
to
have
and
to
think
about
which
framework
they
have
to
choose.
You
know
this
is
actually
a
really
difficult
decision
for
a
lot
of
developers,
so
taking
a
net
decision
from
them
and
giving
them
at
least
the
basic
framework
or
a
basic
thing
that
they
can
work
with
for
the
average
cases.
That
would
be
great,
and-
and
this
applies
not
only
into
web
frameworks,
so
we
have
very,
very
low-level
file
system.
J
Api
is,
we
do
add
new
ones
at
the
moment,
but
they
do
not
tend
to
be
a
user
friendly
all
the
time
and,
for
example,
we
add
another
option,
some
like
that
people
do
not
know
what
options
we
have
and
would
be
great
to
have
a
specific
I,
don't
know
like
area
of
AP.
Is
there
more
high
level
instead
about
a
little
level
ones,
and
most
people
would
probably
care
about
those
most
and
not
used
a
little
level
ones.
H
J
C
Now,
at
the
same
time,
though,
we
have
modules
out
there
that
are
downloaded.
You
know
millions
of
times
like
is
Windows
when
we
already
have
in
core
you
can
just
do
you
know,
check
to
see
if
you're
running
on
Windows
let
existing
API.
So
just
because
we
have
an
API
in
core
that
does
something
doesn't
mean
ecosystem
is
going
to
make
use
of
it,
not
think
that
I
might
as
well
so.
J
J
It
is
understandable
to
everyone,
and
that
is
also
found
by
the
google
search
engine
and
the
last
point-
it's
probably
the
worst
one,
because
most
people
still
end
up
on
Stack
Overflow
with
examples
and
and
that's
why
they
do
not
know
that
things
in
core
already
supported
out-of-the-box,
then
soso
documentation
is
a
very
big
point
and
also
change
marks
or
a
change
locks.
We
are
starting
to
change
that
so
that
they
are
really
well
readable
by
anyone
pretty
much
to
provide
examples
from
the
changed.
J
H
And
so
one
comment
on
the
many
of
these
packages
that
have
millions
of
downloads
but
have
corresponding
core
api's
part
of
that
work.
I
think
is
just
working
with
the
community
may
of
maintainer
x'
like
this
is
where
I
think,
having
some
outreach,
because
I
bet
you
any
money:
it's
not
people
directly,
it's
not
end-users
directly,
depending
on
his
windows.
It's
a
framework
depending
on
his
windows
and
shipping,
that
to
all
of
their
users
right
could
be
webpack.
H
Some
works
way
down,
and
all
we
really
need
to
do
is
just
talk
to
the
people
who
maintain
the
transitive
underneath
web
pack
and
say:
look
you
know,
let's
start
moving
people
now,
you've
dropped
support
for
version
that
didn't
have
it,
but
we're
not
actively
doing
that
right.
In
most
of
these
cases,.
L
B
If
you
actually
have
a
central
point
where
the
ecosystem
of
framework
authors
and
people
not
using
frameworks
can
like
standardize,
some
API,
which
for
us,
unfortunately,
is
core
itself,
you
get
the
ability
to
kind
of
have
people
reliably,
do
things
across
different
frameworks
across
all
usages
of
node
right
now.
If
you
pick
up
a
book
about
node
like
node
in
action
which
I
had
a
part
of,
we
had
to
pick
specific
modules
on
how
to
do
things
and
some
frameworks
do
not
use
those
modules.
So
people
using
those
frameworks,
those
chapters
are
worthless
to
them.
B
H
H
Experience
is
incredibly
important
and
if
we
can
get
a
user
experience
or
I
mean
I
should
say,
developer
experience
right,
that
that
people
don't
need
to
go
and
choose
that
module,
because
they
are
not
qualified
to
make
that
decision.
In
most
cases
right
like
when
we're
talking
about,
does
it
properly
support
range
requests
or
something
like
yeah.
An
end-user
should
never
be
making
that
decision.
But
today,
if
they're
trying
to
use
HTTP
directly
the
node
core
version,
they
have
to
write
and
that's
where
I
think
we
can
make.
H
We
could
make
a
clear
statement
that
if
it
is
part
of
a
standard
that
that
you
know
an
HTTP
spec
standard
or
something
like
that-
and
it
is
widely
deployed
currently
in
frameworks-
and
it
prove
provides
better
user
experience,
even
if
it's
not
made
better
by
being
in
core
and
has
a
perfectly
viable
user
land
experience.
I
still
think
it's
worth
considering
bringing
those
things
in
and
having
a
more
open
opinion
on
that.
C
And
if
we
say
standard
library
there's,
it
is
also
important
to
make
a
distinction
between
some
something
that
is
in
live
right,
which
is
part
of
our
core
implementation
versus
something
that
is
a
vendored
in
of
entered
in
dependency.
What
we
could
say
here
is,
if
you
know
for
these,
these
things
that
are
part
of
this
standard
live
right.
A
A
H
C
H
So
even
though
it's
in
a
separate
github
or
get
still
follows
all
of
the
same
governance,
things
and
I
think
that's
one
benefit
that
hasn't
been
talked
about
yet,
which
specifically
I'm
interested
in
is
moving
like.
If
we
move
things
from
it
like
a
express
ownership
under
the
node
org
I
think
it
would
open
up
the
contributor
base
a
lot
more
than
it
is
under
the
current
Express.
May
you
know
the
way
we
structure,
contributions
and
stuff
like
that
and
I.
Think
that's
one.
Another
big
benefit
sort
of
a
paved
path.
Yeah.
A
Unfortunately,
I
think
we
only
have
five
minutes
left
I.
Think
that's
a
like
that
whole
small,
small,
core,
but
I
think
it's
it's
good
to
expand
the
discussion
in
terms
of
it's
not
just
what
gets
in
or
out,
and
the
technical
basis
is
like
what
should
be
this.
Why?
What's
the
problem
we're
trying
to
solve
right,
which
is
I,
think
we've
talked
about
a
few
things
that
are
potentially
solved
by
putting
them
in
core,
but
there
are
other
ways
and
it's
coming
to
like
what
should
we
be
doing
as
a
project
to
solve
that
problem?
A
L
C
Yeah
I
think
it's
a
strong
argument
for
not
actually
bringing
it
under
the
main
core
umbrella.
You
know
if
we
maintain
them
as
separate
pieces
brought
together
under
kind
of
a
common
standard
like
umbrella,
they
can
still
be
managed
as
small
individual
projects
for
Bannock
in
small
pieces,
hopefully
far
less
intimidating
than
coming
into
node
master
right
and
dropping
something
in
there
right.
It.
K
Only
a
better
balance
to
me,
there's
a
bunch
of
projects
that,
like
I
I,
feel
like
don't
necessarily
need
to
be
like
in
core,
in
the
sense
that
it's
like
in
the
binary,
but
have
a
problem
of
someone
like
it.
If
something
is
in
node
core,
there's
a
certain
level
of
trust
in
it,
whereas,
if
something's
like
out
in
the
ecosystem,
who
knows
what
it
is
like
a
good
example
of
that
is
like
UUID
modules
like
there's
hundreds
of
them,
most
of
them
are
terrible,
they'd
like
it.
K
If
we
had
like
just
one
year.you
ID
module.
It
was
like
that
this
is
the
good
one
that
it's
like
actually
expect
a
combined
use.
This
then
people
could
just
reach
for
a
bass
and
like
there's
tons
of
stuff
that
tries
to
use
you,
you
IDs,
there's
tons
of
apps
out
there
that
just
grab
whatever
package
and
because
a
lot
of
them
are
so
bad
that
there's
like
major
issues.
Some
of
them
have
cryptographic
instability
and,
like
all
sorts
of
things
like
that,
which
can
cause
like
lots
of
problems
in
your
app
I.
A
So
unfortunately,
I
think
we're
at
our
time
it
was
a
great
discussion.
I
think
we
should
continue
on.
In
fact,
we
went
a
little
bit
past
I'm,
not
sure
we
have
time
for
next
actions
too
many
specific
next
actions,
but
I'm,
hoping
that
everybody
who
here
was
in
you
know
would
think
we
had
a
really
good
conversation.
A
A
A
Know
set
up
another
following
session
for
two
hours
put
a
little
bit
of
the
recap:
I
think
some
of
these
things
we
can
start
shaping
into
you
know
some
ideas
of
you
know
what
we
might
in
terms.
You
know
those
themes
we
should
put
together
and
so
forth.
So
I
might
try
to
cut
at
that,
and
you
know,
however,
hopefully
everybody
can
help
to
then
craft
it
from
there.
Okay,.