►
From YouTube: 2020-12-11- 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
november
12
2020.
we're
going
to
look
at
some
of
the
issues
which
were
tagged
for
the
agenda,
we'll
start
out
with
number
35
323,
which
is
stock
ad
compatibility
interrupt
technical
value,
so
I
know
jeffrey
you've
been
involved.
I
guess
we've,
you
know
what
jeffrey
and.
B
Yeah
this
was
my
suggestion
here
I
can
share
my
screen,
so
we
can
all
look
at
it.
If
that
helps,
I
just
pasted
it
into
the
just
into
the
google
doc
itself,
so
we
could
just
have
a
little
scratch
pad,
so
I
had
opened
sorry.
I
don't
know
if
this
is
supposed
to
be
at
the
bottom
or
where
we're
putting
notes,
but
that.
B
Okay
yeah,
so
I
put,
I
had
to
open
the
pr
into
that,
like
technical
values,
document
adding
that
text,
and
I
had
put
it
as
priority
one-
and
I
did
mention
that
like
later
on
in
the
document,
there
was
something
under
priority:
five
that
was
like
you
know,
interoperate
with
wave
apis
or
something
like
that.
But,
like
basically
what
I
said
in
the
pr
was
basically
like
you
know
we're
a
pretty
prominent
member
of
the
javascript
ecosystem.
B
Interoperability
should
be
like
a
really
top
priority
for
us
and
like
much
higher
than
you
know.
B
Many
of
these
other
things
like,
I
would
argue,
even
higher
than
performance
in
many
in
most
most
circumstances,
and
so
like
this
should
be
really
a
guiding
a
guiding
principle
for
us
that
we,
you
know
that
we
use
this
to
evaluate
new
apis
and
new
features
that
people
want
to
make
in
node,
with
the
aim
of
bringing
future
node
closer
to
the
mainstream
of
javascript,
so
that
there's
less
and
less
javascript
written
for
node,
as
opposed
to
javascript
that
node
can
run
as
well
as
the
browsers
can
run.
B
I
I
recognize
that
this
is
perhaps
not
the
the
ideal
language
for
it,
but
based
on
the
comments
in
that
thread,
I
thought
maybe
it'd
be
easier
to
just
debate
the
specific
wording
over
a
call,
rather
than
going
back
and
forth
on
comments,
but
before
we
even
get
that
far,
we
should
go
back,
go
back
a
step
and
see.
If
we
have,
you
know,
agreement
or
not
about
the
the
overall
intent
here
before
we
pick
her
over
wording.
A
Yeah
my
my
for
my
take
is
like
I
think
in
the
past
discussions
we
did
agree
developer.
Experience
is
like
that's
why
it's
in
the
top
top
priority
right,
and
I
I
agree
that
you
know
part
of
the
developer.
Experience
is
being
close
to
javascript
and
you
know
using
the
same
standards.
I
think
at
least
my
interpretation
is
like
it's
like
how
how
strongly
we
say
that
the
or
where
maybe
you
know
people
have
different
thoughts
is
like
you
know
you
could
read.
The
maximizing
is
like
well
just
the
the
absolute
best
developer.
A
Experience
is
if
it
matches
the
javascript
specs
and
what's
done
in
the
browser,
and
I
think
some
of
the
the
the
actually
sorry
I
have
to
promote
somebody.
The
the
at
least,
like
my
opinion,
is
that's
true,
but
only
up
to
a
point
like
it's
it's
it's
there's
cases
where
it
doesn't
make
sense,
but
for
the
rest
of
the
cases
where
it
does
make
sense,
it
obviously
contributes
to
developer
experience.
A
D
Can
I
add
a
little
a
little
color
here?
I
think
one
of
the-
and
I
made
this
comment.
This
is
after
our
last
meeting.
The
idea
is
one
of
the
ideas
was
to
break
out
a
new
section
to
talk
about
how
some
of
these
values
are
sort
of
cross-cutting.
D
We
kind
of
saw
this
as
being
a
part
of
developer
experience
which
we
did
put
on
the
top
right,
but
it
also
fits
with
some
of
these
other
ones
lowered
and
lower
down,
and
I
think
maybe
there
was
a
miss
in
that
we
we
didn't
really
describe
fully
all
of
the
the
sections
and
how
we
had
talked
about
them
on
the
calls
and-
and
I'm
wondering,
if
maybe
there's
a
way
we
could
just
come
up
with,
instead
of
necessarily
making
this
a
separate
value,
finding
a
way
to
interleave
this
topic
with
the
other
values
and
say
look,
this
is
actually
a
part
of
a
bunch
of
our
values
like
developer
experience,
which
is
our
top
one,
but
it's
also
yeah.
A
But
I
like
I,
I
don't
think
we
need
a
new
value.
It's
it's
that
you
know
it's
just
like.
These
are
examples
of
what,
like
those
bullet
points,
are,
are
not
the
ex
they're
not
like.
This
is
exactly
what
developer
experience
is,
but
they're
trying
to
give
some
insight
into
what
we
think
goes
into
that
right.
So
I
don't
really.
D
B
I
guess
I'm
a
little
confused,
I'm
just
looking
at
the
whole
document.
Now
I
mean
the
fact
that
it
it's
like
you
have
priorities,
one
through
five,
but
then
each
priority
has
like
a
topic.
You
know
like
priority.
One
is
developer
experience
I
like
it.
You
know
you
could
just
have
like
prairie
priorities,
one
through
five,
but
not
necessarily
have
them.
B
A
A
Just
because
it's
priority,
one
doesn't
mean
that
you,
you
then
say
well
all
the
rest
of
them,
don't
matter
but
like
if
you
know,
for
example,
if
you
had
something
which
is
perhaps
you
know
affects
stability,
but
is
really
really
good
for
developer
experience,
then
you
might
make
that
choice
right
kind
of
trying
to
help
in
those
those
things.
I
think,
if
we
pack
in
like
well
priority
one
there's
these
six
different
things,
then
it
becomes.
You
know
almost
impossible
to
to
reason
at
all
like
that.
B
Well,
you
could
refer
the
fifth
one
that
you
already
have
enabling
supporting
external
packages
to
ensure
overall
developer
experience.
I
mean
we
could
like
rewrite
that
one
to
be.
Like
you
know,
external
packages,
you
could
rewrite
it
to
be
like
something
like
you
know:
support
external
packages,
including
sharing
code
with
other
javascript
environments,
or
something
like
that.
B
C
What
I
would
be
concerned
about
longer
term
with
something
here
is,
I
think,
about
like
note
historically
and
the
ideology
of
small
core
right,
like
so
small
quora,
which
was
like
not
super
well
defined
and
maybe
disagreed
upon
by
other
people
kind
of
got
thrown
around
as
like
the
primary
architectural
motivation
when
designing
anything
in
node
and
then
could
be
used
to
essentially
like
shut
down
work
or
say
we
shouldn't
do
this,
and
my
gut
is
michael,
and
you
can
tell
me
if
I'm
wrong
is
like
a
good
part
of
these
motivations
are
to
undermine
that
kind
of
like
anti-pattern
in
note
itself,
but
also
to
have
like
kind
of
clear
motivations
that
we
can
point
to.
C
When
we're
trying
to
make
a
a
decision.
We
could
say
well,
like
here's
our
philosophy,
here's
something
we've
agreed
to.
Would
you
agree
with
everything
that
I've
set
up
until
now
or.
A
Yeah,
I
wouldn't
necessarily
go
to
the
undermining
part,
but
it's
the
like
to
bring
out
what
we
think
is.
A
group
is
important
so
that,
if,
if
we've
got
something,
that's
clearly
developer,
like
really
is
good
for
the
developer
experience
yeah,
but
has
some
impacts
to
things
like
stability
and
operational
qualities
that
we
can
say
you
know
it's
still
going
to
be
a
judgment.
Call
right
like
you
can't
do
something.
That's
that's
great
for
developer
experience
but
means
you've
like
just
broken
half
the
ecosystem
right,
but
it
yeah.
A
C
Of
things
is
the
yeah,
and
so
so
like.
I
think
what
could
be
helpful
here
and
I'm
not
saying
that
this
isn't
what
we
have
been
doing
but
like
if
the
goal
right
now
like
a
goal,
I
personally
care
about
is
ensuring
that
you
know
like
implementing
webstand
standards
and
participating
in.
C
So
it's
good
to
like
ensure-
and
I
think
what
jeff
is
trying
to
accomplish
here-
is
ensuring
that,
like,
like
in
the
modules
team,
for
example,
like
spec
compliance
and
writing,
something
that
was
like
browser
interoperable
was
like.
Actually
our
number
one
goal
right.
We
were
designing
it,
and
so
it
is
possible-
and
I'm
not
saying
that
this
is
what
would
happen,
that
you
know
two
or
three
years
pass.
C
This
kind
of,
like
historical
thought
process
is
maybe
lost,
and
a
few
of
us
have
left
and
now,
like
all
these
changes,
start
landing
that
aren't
in
line
with
that
philosophy
or,
alternatively,
if
we
start
trying
to
look
at
adopting
new
things
like
that,
philosophy
is
not
kept
in
mind.
C
So
I
I
would
imagine
that
the
goal
here,
independent
of
how
it's
accomplished
is
kind
of
ensuring
something
along
the
lines
that,
like
you
know,
we
remain
spec
compliant
to
the
javascript
language
and
that
in
that,
in
in
best
effort,
we
attempt
to
adopt
standards
rather
than
making
proprietary
solutions
to
problems.
I
think
that's,
maybe
like
the
the
core
thing
that
we
care
about
here
and
whether
or
not
this
is
like
a
stack
rank
thing
I
think,
is
a
whole
other
thing,
but
I
think,
what's
what
is
important
from
a
problem
space
here?
C
Not
the
solution
is
that,
like
that,
is
captured
in
such
a
way
that,
like
when
the
people
who
cared
about
this
kind
of
move
on
that
like
in
the
same
way
that
small
core
has
stayed
long
past
that
time
that,
like
you,
know,
javascript
like
being
like,
I
don't
think
right
now.
Anyone
would
argue
we
shouldn't
be
spec
compliant,
but
there
is
arguably
a
world
where,
like
ecma262
no
longer
has
the
weight
that
it
does
and
we
need
to
re-evaluate
that.
C
A
A
lot
of
ways
right
right,
I
I
don't
think
anybody's,
actually
arguing
that,
like
personally,
I
look
at
developer
experience
and
I
100
agree
that
our
compatibility
with
javascript,
to
the
extent
that
we
have
has
been
a
really
big
part
of
the
success.
So
I'm
like
totally
supportive
of
adding
a
line
in
there.
A
I
think
the
the
the
caveat
is
that
it
we
just
need
to
pick
the
wording,
because
it's
not
at
all
costs
and
I
think
that's
where
some
other
people's
concerns
and
it's
not
like
spec
compliance,
always
trumps
everything
else,
but
that
doesn't
mean
that
it
isn't
also
an
important
part
of
the
developer
experience.
So
it's
kind
of
like
you
know,
spec
compliance
except
for
where
it
doesn't
make
sense,
and
that's
where
some
of
my
suggestions
at
least
we're
trying
to
get
at
with
the
like.
A
We
should,
unless
there's
a
really
good
unless
there's
a
good
reason
like
you
know,
performance
or
what
you
know,
there's
there's
there's
always
an
exception
right
and,
and
we
shouldn't
it's-
that
same
thing.
People
were
concerned
about
the
you
know,
people
pointing
this
and
say:
oh
no,
spec
compliance.
You
have
to
do
the
spec
compliant
thing.
You
can't
do
anything
else,
because
that's
what
we've
said
right,
it's
kind
of
like
so
to
acknowledge
that
it's
important
but
give
that
oh.
But
it's
not
it's
not
an
absolute
kind
of
wording
in
there.
C
I
I
guess
like,
and
maybe
maybe
this
is
like
a
separate
thing
altogether,
and
you
can
correct
me
if
my
understanding
is
wrong.
I
think
that
the
fact
that
this
list
has
like
a
hierarchy
and
order
to
it
is
actually
kind
of
one
of
the
things
that
causes
a
problem
here,
because
these
things
are
kind
of
fluid.
C
So
I
don't
know
if
the
order
and
like
working
through
it
in
order
is
like
intentional
or
if
it
was
intentional,
if
that's
like
core,
but
maybe
something
that
could
be
a
solution
here.
Is
you
know
implying
that
all
of
these
are
important
things
and
not
on
a
per
case
basis?
You
really
need
to
think
about
all
of
these
things
holistically
yeah.
A
I
don't,
I
don't
think
that
changes
the
message
here.
We
actually
came
fairly
easily
to
this
sort
of
overall
thing.
I
like
I'm,
you
know
wes
correct
me
if
I'm
wrong
and
but
but
I
think,
like
adding
a
line
under
develop
experience,
which
is
the
priority
one
which
gives
a
nod
to
compatibility,
but
just
with
the
right
wording
is
the
the
way
that
fits
in
and
and
like
basically
is.
You
know,
in
my
mind,
is
a
gap
like
part
of
the
success
and
part
of
what
the
the
community
values
like
developer.
D
Back
just
to
say,
to
address
one
of
miles's
specific
points.
The
reason
I
think
we
we
did
this
structure
was.
We
were
looking
at
the
nice
way
that
the
html
spec
says
like
implementers.
Oh
okay,
I
can't
remember
the
exact
order
of
all
the
things,
but
it's
right.
It's
like
users
over.
D
You
know
everything's
over
purity,
or
something
right
like
whatever
that
that
ordering
that
the
html
spec
has
it's
like
the
really
nice
one
liner
was.
We
wanted,
and,
and
people
use
that
as
a
guideline
when
they're
trying
to
make
decisions
not
as
any
hard
rule.
D
So
we
were
trying
to
come
up
with
significantly
abstract
enough
top
level
things
that
people
could
use
it
as
a
thing
to
say
like
yeah
this
in
this
case,
while
developer
experience
is
sort
of
a
nebulous,
you
know
thing
we
as
a
project
value
it
more
than
the
operational
qualities.
If
it's
meaningfully,
you
know
part
of
the
decision,
and
it's
not
necessarily
that
any
like
we
didn't
want
it
to
be,
like
ultra
specific,
so
that
we
could
have
sort
of
these
meta
discussions
and
use
it
as
like
a
ruler,
or
you
know
right.
D
A
thing
you
just
kind
of
point
at
in
the
distance
right
like
a
I'm
trying
to
think
of
the
right
wording,
you
know
to
you,
don't
necessarily
have
like
it's
not
like
a
guidebook,
and
you
like
read
it
and
follow
it
step
by
step
like
the
goal
is
to
have
some
sort
of
like
high
level
principles,
and
then
we
could
come
up
with
any
given
situation,
how
to
balance
that
decision,
making
using
this
sort
of
rule,
you
know
set
of
hierarchy.
C
Yeah,
I
I
think
it
makes
sense,
and
I'm
I
guess,
like
just
kind
of
part
of
the
the
challenge
here
is
like
the
importance
of
this-
is
biased
by
the
folks
in
the
room
and
the
people
in
the
room
change
over
time,
and
what
I
could
see
ends
up
happening
here
is
like
this
being
used
almost
like
a
written
law
to
say
well,
like
one
always
trumps
two
and
I
can
make
an
argument
about
one
and
then
that's
used
to
kind
of
like
undermine
yeah.
B
B
D
B
D
Would
it
be
valuable
to
go
through
a
like
example?
D
First,
so
that
people
don't
so
that
we
can
influence
people's
interpretation
of
the
the
set
of
you
know
hierarchy
here,
so
that
we
don't
have
that
problem
right
like
instead
of
necessarily
trying
to
like
change
these,
so
that
we
don't
because
somebody's
still
going
to
come
in,
even
if
we
change
them
and
make
them
quote,
unquote,
perfect
somebody's
going
to
come
in
and
do
this
exact
thing
and
read
it
and
go
oh
well,
but
I
think
this
one's
higher
than
that
one
and
like
we
need
to
nitpick
it,
which
I
do
think
we
need
a
nitpick.
D
This
is
a
very
important
conversation
and
I
think
our
presentation
of
these
ideals
is,
I
think
everybody
agrees,
is
probably
going
to
clearly
lead
to
this
sort
of
problematic
future
where
people
use
it.
As
a
as
a
rule
book,
I
mean
not
its
intent,
yeah.
A
C
C
I
trust
you
all
so
I
didn't
like
bother
really
getting
into
it,
but
I
did
have
a
bit
of
a
like
similar
feeling
to
jeff,
but
I
also
trust
that
this
would
be
a
living
document,
but
I
think
I
think,
being
explicit
about
that,
could
help
us
avoid
some
of
the
anti-patterns
that
I've
seen
in
the
project
before
where,
like
you
know,
some
of
these
things
turn
into
laura
that
lore
turns
into
like.
C
I
know
this
isn't
the
case
as
much
anymore,
but
when
I
started
the
project
five
years
ago,
performance
and
small
core
were
used
by
a
subset
of
the
project
to
just
shut
down
work.
They
didn't
care
about,
like
it
was
used
to
like
stop
promises
from
being
a
thing,
and
so
I
I
would
just
like
us
to
make
sure
that
this
is
the
kind
of
thing
that
cannot
be
used
to
to
halt
progress,
which,
I
don't
think
is
the
intent.
But
like.
A
I
know,
but
I
think
it
is
like
if
somebody
came
along
with
something
that
says
and-
and
the
argument
is,
this
is
going
to
destroy
developer
experience
this.
This
is
like.
If
somebody
comes
to
the
project
who
doesn't
know
the
project,
this
will
tell
them
if
you're
going
to
do
something
that
you
know
is
really
bad
for
developer
experience,
probably
not
going
to
go
over
that.
Well,.
C
A
Well
that
yeah,
that's
my
point
like
I'm.
I
just
think
that
if
we
I'd
be
happy,
if
we
just
took
out
maximizing,
I
don't
know
if
wes,
if
that
addresses
your
concern
but
like,
if
it
just
said
compatibility
and
operability
with
browsers
and
other
javascript
environments
where
it
makes
sense
like.
I
think
that.
D
D
D
We
don't
want
to
continually
have
every
one
of
these
conversations
as
an
individual
like
nitpick,
because
they're
all
valid
points
right
like
this
is
a
very
valid
point,
and
then
we
have
to
spend
a
lot
of
time
like
always
pointing
back
to
this
document
and
changing
it
a
little
bit
here,
a
little
bit
there.
If
we
just
put
you
know,
sort
of
this
disclaimer
that
says
like
these
are
examples.
This
is
not
all-encompassing,
you,
you
know,
please
don't
use
this
as
something
you.
D
B
D
Yeah,
I
I,
I
think,
making
more
line
items
under
priority
one,
this
one
being
a
great
example,
I
think,
is
a
fine
addition.
As
long
as
we
also
go
through
the
effort
to
try
to
write
like,
I
think
the
comment
miles
you
said
was
not
normative
like
we
just
need
to
make
sure
that
it.
You
know,
and
I
don't
even
think
at
the
bottom
of
the
document.
I
think
that
should
probably
be
top
of
the.
C
D
Don't
come
in
and
and
read
the
whole
thing
and
go.
I
disagree
with
all
this
reruns
everything
right
like
because
they
might
have
good
reason
for
that
right.
It's
just,
but
that's
not
the
point.
The
point
is
so
that
people
who
come
in
and
are
unfamiliar
with
the
way
the
project
is,
can
like
have
some
sort
of
frame
of
reference
for,
for
you
know,
so
they
don't
come
in,
saying,
look
but
up-to-date
technologies.
You
mean
you
haven't
implemented
this
new
thing.
That's
not
even
built
into
all
the
browsers.
D
Yet
like
it's
on
your
list
and
it's
like
well,
it's
on
our
list
but
like
that,
would
make
for
a
bad
developer
experience
because
it
might
change
a
spec
like
having
this
document
just
helps
us
have
those
conversations
in
a
way
where
we
can
be
on
the
same
page
on
what
the
values
are,
not
necessarily
as
the
like
decision
making
framework.
I
think
that.
B
D
C
So
I
I
think,
maybe
something
god
I
know
way
too
much
about
constitutional
law.
Now.
Joking,
but
like
a
constitutional
scholars,
have
different
ways
of
reading
text
and
there's
like
originalism
right,
which
is
like
the
way
it
was
written
in
the
context
of
the
people
who
wrote
it
is
the
only
way
to
interpret
it
and
then
you
know
there's
other
ways
of
interpreting
things
that
are
like
much
more
like
it's
a
living
document,
and
this
is
something
that
comes
to
like
religion
and
like
how
different
religious
sex
approach
things
as
well.
C
It's
like
anyways
without
getting
too
much
into
that.
I
I
think
what
we're
what
we're
getting
to
right
now,
that
would
be
very
helpful,
would
be
just
like
a
guide
to
understanding
the
doc
at
the
top
setting
that
intention
clear
and
then
I
think,
secondly,
is
making
a
commitment
to
those
seeing
the
doc
that
it's
a
living
dock,
that
it
will
be
reviewed
at
a
certain
cadence
by
the
steering
committee
and
that
further,
that
it
is
something
that
is
open
to
discussion
and
debate
unless
it
isn't.
But
I
think,
like
you.
A
C
And
I
think
that
making
that
very
clear
right
and
committing
to
that
is
important,
because
the
biggest
risk
is
these
things
you
know
become
constitutions,
become
religious
documents
become
like
like
this
is
this?
Is
the
the
cart
not
the
horse?
This
is
like
we're
working
on
a
thing,
so
we're
trying
to
make
it
easier
to
work
on
the
thing
this
shouldn't
be
the
thing
that
makes
it
harder
to
work
on
the
thing
so
yeah.
A
Okay,
so
I
mean
I
think
one
would
be
good
like
if
we
could
agree
on
the
text
that
would
go
for
a
bullet
point
that
would
go
underneath
right,
like
I
think
that
there
was
some
concern
that
the
the
proposal
like
the
maximize
was
a
bit
too
much
on
the
at
all
costs
it
not.
It
must
be.
So
I
think
if
we
soften
that
a
little
bit
and
and
add
something.
A
B
C
One
of
the
things
like
that
that
I
was
saying
there
was
less
about
like
compatibility
with
browsers
right,
but
more
about
like
spec
compliance
with
the
with
the
with
the
javascript
language
and
portab
and
and
portability
of
code,
because
this
doesn't
have
to
do
with
like
hey.
We
support
every
single
api
right.
This
has
to
do
with,
like
the
court
like,
and
this
was
the
the
core
fundamental
thing
that
we
talked
about
in
the
modules
group.
C
If
we
do
things
with
like
our
module
loader,
that
will
never
be
like
interoperable
with
the
browser
then
like
node
is
its
own
thing
and
that
kind
of
like
core
developer
experience
that
like
actually
you
know
what
maybe
there's
another
way
of
putting
this
that,
like
this,
the
skills
of
being
a
javascript
developer
are
like
portable
from
node
to
other
environments.
I
don't
think
that
that's
like
what
we
should
put
down
there
on
the
list,
but
when
we're
thinking
about
developer
experience
like
that
is
one
of
the
fundamental
things
like.
C
C
B
I
think
that's
that's
almost
a
different
point.
I
think
that's
a
really
good
point,
but
I
mean
it's
definitely
speaks
to
developer
experience
that,
like
as
a
developer,
I
don't
need
to
take
a
tutorial
on
javascript
and
then
a
tutorial
on
node,
or
something
like
that.
I
I
think
it's
like
for
me.
What's
most
important
is
like
I
want
us
to
do
things
that,
like
increase
the
share
of
javascript,
that's
written
in
the
world
that
runs
in
node
as
well
as
in
browsers.
B
You
know,
like
we
shouldn't
like,
if
we're
going
to
introduce
a
new
api,
it
should
be
an
api
that
we
can
share
with
browsers,
or
you
know,
that's
compatible
with
browsers
or
something
like
that,
so
that
we're
not
like
node
is
already
probably
the
biggest
defender
in
the
javascript
ecosystem.
For
like
creating
like
a
silo.
You
know
like
there's
all
these
projects
like
browserify
and
I
think
the
challenge.
B
For
getting
node
packages
to
work
in
browsers,
but
that's
always
like
this
conversion
step
like
the
idea,
should
be
that
we
should.
We
want
to
have
that
no
longer
be
the
case
going
forward,
that,
like
code
should
just
be
written
and
it
can
work
in
both
places
and
then
by
definition,
that
speaks
to
miles's
point
that
you
wouldn't
need
to
know
so
much
that's
specific
to
to
node
like
yeah.
B
We're
not
we're
not
going
to
add
a
window
object
or
the
dom
api
and
stuff
like
that,
but
like,
if
we
add
fetch,
for
example,
you
know
well,
it
should
be
the
same
api
as
the
fetch.
The
browsers
has
you
know
what
I
mean
like
that's
the
kind
of
thing
I
wanna
that's
the
kind
of
like
if
I
wanna
influence
this
future
decision.
It's
that
kind
of
thing
like
when
we
add
support
for
fetch
when
we
add
support
for
service
workers.
You
know
we
use
the
same
apis.
C
Yes,
like
the
what
working
group,
the
w3c
in
specific
folks
who
work
there,
are
not
super
on
board
with
worrying
about
nodes
use
cases,
and
so,
like
fetch,
is
a
great
example
there.
C
The
stuff
that's
going
on
right
now,
with
like
small
changes
to
the
url
api,
is
another
example,
the
folks
who
work
as
browser
vendors
who
work
on
things,
especially
in
what
working
group,
but
in
other
specs
as
well,
aren't
thinking
about
node
and
aren't
necessarily
super
flexible
so
like
while
I
live
in
the
same
idealized
world
as
you
wanting
that
to
be
a
reality.
C
I
also
think
we
need
to
be
careful,
and
I
think
this
is
what
mary's
saying
in
the
chat
as
well
about
like
how
we
frame
this,
because
we
could
be
doing
it
in
such
a
way
that,
like
ties,
our
hands
or
like
is
like,
I
think
we
need
to
to
find
a
balance
between
like
what
we
can
accomplish
and
ideally
what
we'd
want
to
accomplish.
Sadly,.
A
D
On
the
other
hand,
I
think
you
might
be
wrong
there.
Okay.
Well
I
mean
we've
had
a
bunch
of
examples
of
this,
and
we
have.
I
mean
the
web
streams,
the
even
the
url
we're
now
having
this
battle.
I
say
battle
we're
having
this
discussion.
It's
a
great
discussion
with
great
points
on
all
sides
about
how
the
url
spec
isn't
fast
enough
to
be
the
basis
for
the
rec.url
and
it's
like
well
is
it
we
have
our
own
url
right
so
like
so,
but.
A
C
B
If
I
could
just
respond
to
an
earlier
point,
though,
it's
like
yeah,
because
we've
been
we've
had
like
in
these
modules
meetings
bradley
is
often
like.
I
think
he
feels
very
bitter
about
whichever
group
what
wg,
maybe
or
tc39
I
forget,
which
and
I'm
just
like
well
but
wait
but
such
and
such
standard
body
is
never
going
to
support
that
and
he's
just
like
so
they're.
What
do
we
care?
B
You
know
and
like
he's
just
like
so
bitter
of
all
the
years
of
dealing
with
them,
that,
like
he
doesn't
care
that
how
how
they
feel
about
it
and
so
on,
or
if
that,
maybe
they
don't
feel
about
it,
because
they
don't
care
about
node.
But
but
I
just
feel
like
I
understand
that
frustration
and
I
feel,
like
you've,
you've
felt
that
two
miles
you've
you've
had
to
battle
these
groups
too,
but
so
I.
B
Don't
care
and
that's
and
ultimately,
users
are
the
losers
in
this
situation.
It's
almost
like
parties
in
congress
bickering
over
things
and
ultimately
the
people
lose.
You
know
like
yeah.
We
don't
have
that.
We
have
the
power
to
ignore
them
if
we
want
to.
But
whenever
we
do
users,
you
know
suffer
stuff.
For
that
consequence.
So.
C
C
But
these
are,
but
these
are
existing
bodies
that
have
use
cases
and
have
goals
that
just
don't
align
with
ours.
It
doesn't
necessarily
make
it
bad,
and
I
think
that
was
something
that
I
was
just
trying
to
point
out
where
it's
like
for
the
what
working
group
and
for
their
url
spec
their
primary
motivation
and
their
primary
care.
There
is
the
browser,
and
the
same
is
true
with
the
console
spec,
and
there
are
ways
in
which
we're
not
like
console.assert
frozen
node
will
never
throw
in
the
browser.
C
I
think
that
that
there
there's
definitely
like
a
balance
to
to
be
had,
and
there
isn't
necessarily
a
right
answer
and
and
truthfully,
if
we
talk
about
dx
as
being
the
most
important
thing
versus
like
standardization,
we
could
look
directly
at
the
way
in
which
we're
talking
about
importing
json
in
our
module.
C
B
Experience
will
be
better
right.
You
could
argue
that
having
a
developer
experience
where
node
allows
import
of
json
and
browsers
don't
or
they
both
allow
it,
but
they
behave.
A
different
way
is
arguably
an
even
worse
developer.
Experience
like
it's
a
worst
developer
experience
for
anyone
who
has
to
you
know,
develop
code
that
runs
in
more
than
just
node.
It's
a.
D
That's
why
I'm
saying
it's
part
of
developer
experience
is
having
interoperability,
but
sometimes
you
may
look
at
the
developer.
Experience
now
and
say:
look
we're
going
to
have
a
worse
one
now,
so
that
we
can
maintain
that
interoperability,
which
will
lead
to
a
better
one
later
and
that
still
fits
fully
within
this
framework
of
thinking
right.
It's
like
we
are
the
goal
of
any
long-term
developer.
Experience
could
be
even
the
way
to
phrase
that
well.
B
Or
another
way
of
putting
it
is
like
what
you're
doing
with
with
url
is
like
the
global
url
object
is
the
same
api
as
in
browsers,
but
then
we
still
offer
the
like
quote-unquote,
better
url
api
that
you
could
import
from
a
module.
That's
fine!
You
know
that's
at
least
not
like
a
foot
gun
where
people
expect
url
to
behave
the
same
way
in
javascript
here
in
javascript
there
you
know
like,
like
the
reason
I
was
like
pressed
to
do.
B
How
is
this
going
to
run
in
a
browser
or
do
browsers
have
this
api,
or
does
this
api
behave
differently
in
browsers,
and
so
they
might
not
value
that
very
highly,
and
that's
why
I
was
trying
to
push
this
in
here
is
like
you
know,
the
node
collaborators
are
just
disproportionately
a
node
centric
group
who
might
not
be
developing
for
browsers,
but
the
users
of
node
are
not
necessarily
like
that.
You
know
what
I
mean
so
this
this
is
not
necessarily
meant.
A
So
you
know
it's
that's
where
I
sort
of
fall
back
to
like,
I
think
you'll
find
people
would
agree
with
like
compatibility
and
interoperability
where
it
makes
sense,
but
I
don't
think
at
least
my
take
of
the
you
know
what
I've
seen
across
the
project
is
you're
not
going
to
have
consensus
on
compatibility
at
any
cost.
B
I'm
not
saying
at
any
cost,
but
you
know
there's
there
are
degrees
of
incompatibility.
B
There's
like
the
url
example
where
we
ship,
both
in
the
and
the
the
incompatible
one
is,
is
needs
to
be
imported
json
modules,
where
the
non-standard
behavior
needs
to
be
enabled
to
the
flag,
like
those
are
the
types
of
things
that
you
know,
I
think
would
be
good
steps
for
us
to
take
in
order
to
have
node
continue
to
be
a
good
citizen
in
the
ecosystem
and
then
be
easier
for
users,
because
node
behaves
more
like
other
javascript
environments.
You
know
if.
C
If
I
can
interject
something,
perhaps
what
we're
having
here
is
a
bit
of
an
impedance
mismatch,
specifically
in
that,
and
maybe
what
we're
seeing
is
different
subsystems
and
different
parts
of
the
project
may
have
different
orders
here.
But
I
think
I
think
this
gets
back
to
like
the
kind
of
stack
ranking
this
and
how
it
can
become
like
a
little
bit.
Difficult
and-
and
maybe
modules
is
an
outlier
here
and
that's.
C
Why,
like
it's
particularly
it's
something
that
is
like
particularly
touchy
for
for
jeff
and
I,
but
but
perhaps
perhaps
like
another
thing
we
can
include
in,
like
a
non-normative
caveat.
Is
that,
like
you
know,
different
working
groups
or
subsystems
may
prioritize
these
things
in
different
ways
or
potentially
even
have
their
own
ideals
that
don't
necessarily
completely
align
with
this
framework.
A
C
The
this
framework
doesn't
necessarily
match
at
all
when
thinking
about
investing
labor
and
time
into
developing
streams,
I'm
trying
to
think
of
extreme
examples
here,
but
you
know,
I
think,
there's
a
difference
between
that
and
like
what
is
the
framework
that
we
use
to
decide
to
introduce
new
apis.
It's
like
different
than
like.
What
do
we
think
about
when
we're
trying
to
maintain
parts
of
the
project.
D
So
I
think
that
it's
clear
we
need
to
add,
like
different
axes
of
how
we
think
about
this
type
of
stuff.
I
think
that's
pretty
clear,
but
I
think
that
the
high
level
goal
was
to
have
a
single
point
that
did
capture
the
the
things
that
work
across
the
whole
project
when
we
started
out
with
this.
Yes,
do
you
see
any
way
we
could
like
you,
keep
on
you?
It
smells.
It
sounds
like
you
come
back
to
the
fact
that
they're
ordered
is
what
it
sounded
like
in
what
you
just
said.
C
I
think
it
could,
unless
the
ordering
is
an
important,
an
important
facet
and
part
of
the
signal
you're
trying
to
get
across,
which
it
seems
to
me
like
developer
experience.
Being
the
most
important
thing
is
like
kind
of
an
important
signal
from
this
document,
and
not
one
that
I
necessarily
disagree
with,
I
think,
similar
to
small
core.
It
gets
into
like
the
nuts
and
bolts
of
like
what
do
we
define
as
that
developer
experience
right.
B
B
D
But,
but
I
think
that's
it:
could
it
could
get
added?
If,
if
you
all
think
it
should
be
added,
we
can
we
can
discuss
adding
it.
It
just
didn't
come
up
in
the
people
who
are
on
that
meeting
that
came
up
with
this
initial
list.
Well,.
D
That
says,
when
you're
thinking
about
specific
problems,
certain
ones
may
be
more
important
than
others.
Here's
an
example
you
know,
and
maybe
we
outline
like
in
in
performance
critical
code
like
performance,
will
be
more
important
than
some
other
things
in
end
user,
apis
that
we
see
people
using
user
experience
should,
or
you
know,
developer
experience
should
be
the
most
important
like
we
could
go
through
an
exercise
and
maybe
outline
a
few
of
those
examples
of
how
to
apply
this
list
and
say,
like
we
do
think,
there's
an
order.
A
C
So
I
I
think
something
that
wes
said
michael
that
really
resonated
with
me.
There,
like,
I
think
about
code
of
conducts
like
one
of
the
things
that
I've
heard
about
writing
a
good
code
of
conduct.
Is
you
don't
want
to
just
start
enumerating
every
single
like
thing
that
can
be
a
violation,
because,
all
of
a
sudden
now
we
have.
D
C
C
So
maybe
there
really
is
something
there
west
to
like,
not
having
the
the
initial
thing
you're,
seeing
being
like
all
of
these
enumerations
and
then
kind
of
having
some
like
like
just
having
that
list
of
like
here
are
like
the
five
things
that
are
most
important
to
node
and
we
can
even
have
the
order
there
then
having
something
that
says
you
know
in
particular
cases.
Some
things
may
be
more
important,
but
I
would
argue
that
in
the
cases
where.
C
But
I
think,
and
I
could
be
wrong-
that
in
almost
every
case
developer
experience
still
just
kind
of
come
out
on
top
because,
like
why
are
we
worried
about
making
performance
so
fast?
Well,
I
guess
actually
there's
a
difference
too.
I
guess
between
like
the
developer,
experience
of
writing
the
thing
and
the
experience
of
the
people
who
are
using
the
thing
which
are
like
two
different
things:
the
people
using.
D
And
we
already
have
that
enumerated
in
our
list
with
node.js
maintainer
experience,
which
is
what
you're
describing
there
right,
which
is
like
we're
building
a
new
api
in
node.
Those
are
the
people
we
say
we
do
need
to
optimize
in
some
ways
for
those
people
right,
the
maintainers,
which
is
different
from.
D
B
C
C
D
Actually,
I
think
you
what
you
described
there
jeffrey.
I
think
we
have
almost
exactly
in
the
constituencies
deal
and
there
we
we
sort
of
try
to
go
into
which
of
these
values
and
which
technical
concerns
apply
in
different
constituency
groups,
because
they're
different
and
we-
and
I
think
that
was
the
goal
of
that
doc-
was
to
try
to
get
to
drill
in
on
like
yeah
yeah
we
get.
We
get
that
like
this
means
different
things
to
different
people.
Here's
maybe
how
we
see
this
applying
differently.
D
A
I
mean
coming
back
to
mile's
point
about,
we
actually
say
some
key
elements.
We
could
actually
soften
that
to
like
some
examples
or
like
they're
they're,
not
meant
to
be
an
exhaustive
list
or
you
know
it's
a
non-exhaustive
list
or
you
know
these
were
things
that
came
out
of
like
in
the
brainstorming.
We
did
these.
A
These
are
specific
things
that
people
mentioned
and
that
we
actually
you
know
workshop
together
and
into
the
what
are
some
of
the
things
that
people
you
know
I
believe,
go
into
developer
experience,
but
it's
not
meant
to
be
an
exist,
an
exhaustive
list
either
right.
So
I
don't
know
if
I
could
see
your
point.
B
B
D
Those
are
components
of
good
developer.
Experience
are
are
very
valid
and
I
don't
think
we
want
to
limit
developer
experience
in
that
way
and
that's
I.
I
really
do
think
we
just
need
to
move
those
bullet
points
so
that
we
don't
get
distracted
by
those
individual
items,
because
you
know
that
wasn't
the
point.
Those
were
just
like
our
lists
that
we
brainstormed
we
just
like,
threw
them
all
into
the
the
bullet
points
and
said
cool
right,
like
this
kind
of,
is
what
we
meant.
A
C
I
think
it's
a
good
idea,
especially
if
we
can
have
examples
or
like
showing
being
able
to
hold
something
in
its
opposite
in
your
head
at
the
whole.
At
the
same
time
is
described
as
like
one
way
of
like
knowing
that
someone's
a
genius-
and
I
think,
being
able
to
show
that
that
is
true
would
be
something
that
would
be
very
useful
for
this
document.
C
Mostly
in
that,
like
prioritizing
developer,
experience
can
be
done
in
a
number
of
different
ways
that
we've
like
discussed
here.
Yeah
and
the
reality
is
it's
about
the
framework.
So
it's
like
I
care
about
speed,
but
it
shouldn't
be
speed
just
for
the
sake
of
being
fast,
it
should
be
speed
for
the
sake
of
developer
experience,
and
I
think,
like
that,
is
kind
of
like
the
key
that
we're
unlocking
here,
which
is
that,
like
and
even
jeff
to
what
we
were
saying,
it's
like
a
worse
developer
experience
today
for
a
long
term,
better
ecosystem
developer.
C
Experience
is
still
like
working
towards
that
goal.
So
I
think,
like
this
is
a
framework.
There
is
really
useful
and
perhaps
like
showing
how
the
same
thing
can
actually
mean.
Two
different
things:
here's
a
time
where
developer
experience
means
it's
slower
and
here's
a
time
where
developers
experience
means
it's
faster
and
here's
a
time
where
it
means
a
worse
developer
experience
today.
Those
are
all
still
working
within
this
framework,
even
if
they're
all
in
conflict
with
each
other
right.
A
C
Could
be
sorry,
jeff
go
for
it.
C
B
C
B
Language
that
I've
highlighted-
maybe
we
could
just
like
agree
on
this
one
bullet
as
if
we're
not
going
to
rewrite
the
whole
document
merge
this
in.
If
we
can
come
to
a
consensus
on
this
and
then
I'm
all,
for
you
know
continuing
the
debate
about
what
this
broader
document
should
be
and
how
it
should
change
and
what
intro
tech
we
should
add
and
so
on.
But
maybe
that
could
be
like
a
follow-up
effort.
C
I
object,
I
think
we
should
rewrite
everything
and
boil
the
ocean
and
there
there
should
be
no
incremental
improvements.
Jeffrey
I'm
sorry.
He
wants
to
add
a
big
bullet
at
the
top
big
core
right.
It's
it's
it's
after
six
o'clock
and
all
my
gloves
are
off.
A
A
D
I
I'm
definitely
especially
I'm
I
don't
think,
there's
a
this
is
why
I
like
the
idea
of
changing
the
document,
because
I
think
this
is
a
great
point,
but
if
we
keep
the
document
structure
the
way
we
are
we're
going
to
have
entire
meetings
dedicated
to
single
points
for
the
right
eternity
of
this
group,
which
I
don't
think
is
very
productive.
Like
I'm
super
slime
like
make
this
line,
add
it
commit
it,
let's
get
it
merged,
but
like
let's
definitely
consider
the
future
of
this,
so
that
we
don't
have
to
bike
shed.
B
D
C
D
Is
like
really
effectively
just
trying
to
like,
like
shed
the
way
it's
worded
or
the
order
or
whatever,
like
that's,
not
going
to
make
those
other
conversations
as
well.
It's
going
to
make
it
harder
in
some
cases,
so
I
want
to
make
sure
that
we
don't
make
this
document
spread
that
pain
around
you
know.
The
goal
should
be
that
it
does
what
you
describe
jeffrey,
which
is
make
those
conversations
just
a
lot
easier.
A
B
A
Know,
but
I
meant
in
the
original
pr
itself
were
there.
I.
B
A
A
C
A
Good
and
I
guess
we'll
wait
to
look
at
those
constituencies
to
the
next
meeting,
yeah
good.
If
anybody
has
comments
or
whatever
thoughts
of
next
step
because
yeah,
hopefully
we
can,
we
can
move
on
to
now
getting
you
know,
get
those
constituencies
done
and
we'll
have
the
groundwork
for
some
of
the
more
detail
like
the
more
technical
type
type
discussions,
but
it
seemed
like
we
need
to
get
these
these
in
place.
First,
so.
D
Yeah
and
for
what
it's
worth
learning
from
this
today's
meeting,
I
think
this
is
super
valuable.
I
would
love
it
if
more
people
were
like
you,
jeffrey
and
went
and
read
this
document
and
said
look
here.
I
think
this
is
this
other
better
way,
because
this,
I
think,
really
challenged
us
because
it
had
been
a
pretty
small
group.
D
You
know
I
think,
admittedly,
and
and
also
a
group
that
I
think
is
not
super
representative
of
the
broad
contributor
base
and
so
having
folks
like
you
come
in
and
say,
like
you
know,
make
these
cases,
I
think,
will
will
make
this
a
lot
better
than
it
is
today.
B
Well,
thank
you
yeah.
I
think
that's
what
that
was
just
so
interesting
about
the
modules
group
and
that
you
know,
because
models
have
such
a
big
impact
across
the
broader
ecosystem.
We
had
a
lot
of
stakeholders
that
were
like
not
node
collaborators
like
leaders
from
typescript,
and
you
know
like
like
package
maintainers,
and
things
like
that.
I
mean
some
of
those.
B
Some
of
the
other
working
groups
have
some
of
that
type
of
stuff
too,
but
you
know
I
haven't
been
on
other
working
groups,
but
I
imagine
that,
like
they're,
probably
much
more
focused
on
technical
aspects
of
how
do
we
implement
this
technology
that
type
of
thing
than
than
talking
about
like
well?
B
What's
the
impact
on
the
ecosystem
and
on
the
community
going
to
be
from
you
know
what
we
build
so
yeah,
maybe
that's
just
been
kind
of
I've
had
a
different
perspective,
so
I'm
kind
of
I'm
kind
of
assuming
that
maybe
a
lot
of
the
other
groups
would
benefit
from
that
kind
of
perspective.
I
guess
that's
what
I'm
trying
to
say
so.
A
A
If
not,
thanks
for
everybody
and
we'll,
hopefully
see
see
everybody
next
time
and
talk
about
the
the
constituency
matrix
that
we
have.