►
From YouTube: Node.js Tooling Group Meeting
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
Okay,
so
today
we
have
Daniel
from
tc39
who
came
in
and
dropped
an
issue
and
says
he
wants
to
collect
some
feedback,
something
from
outreach
groups,
just
I'm,
not
sure
exactly
what
he
wants
to
ask.
So
that's.
Why
he's
here
and
I'd
like
to
put
him
on
the
spot
and
start
with
whatever
questions
you
might
have
for
our
group
so
have
at
it
Daniel.
B
B
But
it's
one
thing
that
I've
been
doing
in
the
past
is
going
through
proposals,
technical
issues
in
proposals
in
tc39
and
summarizing
them
and
asking
people
if
they
have
comments
that
are
technical
suggestions
that
we
should
bring
to
the
committee
and
so
I'm
wondering
if
that
kind
of
thing
would
be
interesting.
For
this.
C
C
The
other
topic,
on
my
mind
that
might
touch
on
tc39
is
source
maps
which
I
was
going
to
bring
up
at
some
point
in
this
conversation
today
like
if
there's
any
specific
I,
know
v8,
there's
a
planning
on
implementing
source
maps
this
year,
I'm
curious.
If
it's
to
spec
any
spec,
though
so
it's
gonna
bring
that
up
too
yeah.
B
C
Oh,
that's
good
to
know
I.
Think
in
general,
though
I
mean
certainly
anything
that
would
be.
You
know
effect
a
note.
It
would
be
amazing
to
have
a
summary
in
this
meeting
so
that
we
don't
have
to
read
through.
You
know
all
of
the
all
of
the
actual
documents
and
can
just
have
an
expert
kind
of
give
us
the
talking
points.
C
B
C
C
That
sounds
amazing.
It
would
be
good
to
have
that
crosstalk
happening.
I
think
what
we
could
maybe
do
on
our
end
to
is
is
to
this
meeting
I
like
I.
You
know,
we
know
a
bunch
of
folks
who
work
on
babble
when
we
know
a
few
folks
who
work
on
learn
and
some
of
the
other
tools
to
in
the
community
would
be
good,
I
think
to
get
more
of
a
cross
representation
to
this
meeting,
which,
because
I
think
that
bring
you
more
value
as
well.
B
C
Yeah
I
think
I
mean
the
reality.
Is
that,
like
a
lot
of
what
people
are
using
node.js
for
is
rating
tooling,
so
you
know
once
there's
a
front
end
on
that
transpiler
or
that
test
coverage
library
or
that
unit
testing
library.
Like
you
a
lot
of
time,
the
see
lies
written
in
node,
so
having
more
of
a
connect
there
I
think
is
glad
you
reached
out
to
us.
This
is
what
I'm
saying.
D
So
if
there
was
a
standard,
at
least
you
know
some
common
ground
and
the
other
thing
which
is
I
might
not
enter
it
now.
Maybe
it's
not
tc39,
but
like
a
metaphor
for
four
or
five
four
five
system,
although
most
of
the
work
is
done
for
the
web
and
we
have
URLs
tools,
work
with
file
systems
and
some
standard
AC
standards
around.
That
might
be
very
interesting
also
for
us.
B
There
is
a
an
emerging
set
of
proposed
web
standards
that
tries
to
reduce
the
need
for
that,
and
one
thing
that
I
that
I
personally,
don't
know
is
what
the
what
the
tooling
ecosystem
will
look
like
for
supporting
those.
So
there's
the
the
web
package,
or
it's
also
called
bundled
exchange
proposal
which
is
being
implemented
in
in
Chrome.
But
it's
not
yet
it's
not
yet
standard,
but
it's
being
prototypes
and
what
bundled
Exchange
does
is
allow
a
number
of
different
resources
to
be
bundled
into
one
single
thing
that
sent
over
the
network.
B
So
the
hope
with
hep-2
push
was
that
that
would
resolve
this,
that
that
would
make
it
cheap
to
send
over
a
bunch
of
different
things,
but
there
were
a
number
of
different
issues
with
heb
to
push
including
compatibility
across
browsers,
but
also
the
difficulty
of
configuring.
It
so
bundle
exchange
it's
more
into
workflow
of
you,
create
a
bundle
and
you
serve
it
and
that
bundle
could
include
not
just
JavaScript
and
CSS
in
HTML,
but
also
images
or
or
video
or
whatever
different
resources.
B
D
B
B
C
Great
to
me,
I
think
like
what
I
think
of
this
from
the
point
of
view
of
the
NPM
community,
where
I've
worked
for
years,
the
web
pack
creates
a
lot
of
confusion
for
peoples
and
and
the
other
bottlers
do
so.
It's
so
like
kind
of
moving
towards
a
standard
that,
just
in
a
centralized
place,
addresses
some
of
the
confusion
in
the
community
around
like
what
order
do
I
need
to
bundle
in
what
like
what
transforms
doing
heat
I,
think
that's.
D
It
might
not
be
a
DC
issue,
but
I
think
the
first
question
people
who
are
starting
to
deal
with
tools,
especially
now
in
the
lambda
ages.
Why
can't
I
webpack
my
my
back
end
and
that's
because
it's
not
the
standard
it
it's
an
involved
solution
for
a
very
specific
problem,
and
did
you
only
think
that
I
would
ask
that
I
would
ask
the
committee
39
is
to
think
about?
B
Tc39
definitely
tries
to
avoid
a
coupling
to
the
web,
maybe
even
well,
for
my
tastes
sometimes
may
be
a
little
bit
excessively.
What
web
package
is
not
being
defined,
bundled
exchange
is
not
being
defined
in
tc39,
but
rather
it's
part
of
the
w3c
web
incubator,
community
group
and
it's
being
championed
by
Google
with
the
standards
eventually
going
to
some
w3c
working
groups
and
some
IETF
working
groups.
It's
sort
of
on
top
of
the
definition
of
JavaScript
itself.
B
B
Import
Maps
is
also
being
developed
in
the
webbing.
You
better
community
group,
which
means
it's
it's
pretty
early.
It's
not
yet
it's
not
yet
a
standard,
but
it's
being
investigated
closely
by
different
by
different
web
browsers,
but
it's
also
not
at
the
JavaScript
level,
but
at
the
at
the
web
level.
B
C
Our
eyes
are
standard,
and
that
makes
sense,
but
can
we
make
them
more
palatable
through
a
set
of
API
is
maybe
too
existing
node
ecosystem
around
to
living
like
that
I
think
that
would
start
to
solve.
Bundling
for
some
bundling
problems,
some
module
system
problems
and
would
help
to
kind
of
move
the
you
know
these
tools
built
for
operating
systems
closer
to
a
bunch
of
standards
that
that
do
sometimes
are
more
web-centric.
C
B
B
As
far
as
these
very
important,
so
fires
I
think
import
Maps
is
intended
to
be
what
bridges
that
gap
and
I
I'm
not
an
expert
in
known
modules,
but
my
understanding
was
that
it's
not
just
about
whether
it's
files
on
a
file
system,
but
also
the
difference
in
costs
that
in
the
web,
you
can't
afford
to
try
different
file
locations.
The
way
that
it's
possible
in
node
or
just
sort
of
the
evolved
over
time,
nature
of
the
node
module
resolution
algorithm
totally.
C
Totally
fair
I,
just
think
when
you
talk
about
tooling,
like
we
have
this
corpus
of
nine
hundred
thousand
modules
that
have
been
written
in
one
way
and
like
finding
a
way
to
move
towards
the
perfect.
Without
leaving
behind
these,
you
know
millions
and
millions
and
millions
of
lines
of
code
that
already
exist-
and
this
is
this
is
kind
of.
This-
is
an
interest
of
mine
because
it
stinks
having
modules
behind
a
flag
and
gradual
Ike
I
mean
of
meta
like
how
can
we
make
tooling
better
and
the
ecosystem
is
like?
B
Right
so
it's
there's
a
lot
of
interesting
issues
going
on.
We
develop
different
things
in
different
standards
bodies
and
we
all
try
to
work
together,
but
it's
it
can
be
hard
to
decide
where
to
propose
a
standard
for
what
thing,
because
different
standards
bodies
you
get
the
expertise
of
different
people,
but
in
my
conversations
recently
I've
been
asking
a
number
of
different
people
involved
in
standards,
what
they
would
if
they
would
be
interested
in
getting
more
feedback
from
node
and
the
answer
from.
Basically,
everybody
has
been.
B
C
That
makes
perfect
sense
to
do
so
going
forward
like
what
do
you
think
a
good
way
to
kind
of
have
this
open
dialog
is
because
I
think
you
know
everyone
involved
in
the
tooling
worker
group.
We
have
opinions,
we
can
work
on
various
tools,
we'd
like
to
give
that
feedback
and
like
I,
wonder
if
there's
a
better
way
than
every
three
weeks,
I've
been
representative
I.
Guess
there
I
don't
know
any
recommendations.
You
have
to
work
on
that
dialogue,
I.
B
B
C
Think,
what's
kind
of
interesting
with
the
node
community.
Two
is
really
we
have
that,
like
we
have
the
core
node
collaborators
and
who
are
kind
of
a
more
node
centric
view
of
reality,
and
then
we
do
have
the
NPM
ecosystem
and
I
do
in
full
disclosure
I
work
for
NPM.
So
you
know,
NPM
has
its
own
set
of
concerns.
We're,
like
we've
got
this
giant
module
ecosystem
that
you
know
it's
really
valuable
and
interesting,
but
doesn't
always
agree
on
every
cent
with
the
direction
node
would
like
to
be
going
in
and
then
throw
into
that.
C
C
B
Something
I
think
would
be
really
valuable
is
if
we
can
get
more
people
from
tooling
involved
in
prototyping
different
things
using
these
emerging
standards,
and
that
would
probably
be
a
great
way
to
identify
issues
early
on
before
they
get
widely
shipped,
so
that
so
they
can
be
resolved,
because
if,
if
something
is
already
shipping
to
the
web,
then
it's
very
hard
to
change
it
because
people
could
be
relying
on
it.
That's.
C
B
C
Similar
to
kind
of
how
babbled
will
do
that
right
because
one
thing
that
comes
to
my
mind
like
we
amongst
us,
we
know
a
lot
of
package
makers
so
like
we
could
be
reaching
out
to
someone
working
on
a
web
pack
and
say:
hey.
We
think,
there's
this
emergent
specification
that
might
make
bundling
easier.
Would
you
be
willing
to
make
a
command-line
tool
that
just
uses
this
emergent
standard?
That
may
be
a
bad
example,
because
it's
not
tc39
so.
A
B
B
B
B
Something
that's
like
babel
for
using
these,
for
using
these
new
features,
I'm
thinking
about
something
that's
like
Babel,
but
sort
of
in
a
in
a
different
sense.
You
know
how
today
with
Babel
preset-
and
you
can
say,
I'm
only
going
to
compile
my
website
so
that
it
works
for
the
more
recent
browsers
and
then
your
bundle
size
might
be
smaller
because
it
might
not
have
to
compile
away
async/await
or
some
things
like
that
that
end
up
blowing
up
the
code,
so
in
particular
with
something
like
web
packaged,
bundled
exchange
or
import
Maps.
B
The
the
building
step
doesn't
have
to
be
as
intensive.
The
building
step
can
output
things
that
are
closer
to
the
original
source
code,
and
so
that's
that's
the
kind
of
experimentation
that
I
think
we
need
with
some
of
these
technologies
that
are
specifically
designed
to
make
the
chilling
more
lightweight
cool.
C
You
know
it's
I,
think
a
really
good
example
is
I've
been
championing,
so
v8
exposes
test
coverage.
Now
it's
it's
not
a
standard
honestly
wonder
if
we
could
advocate
that
we
start
to
standardize
it
better,
but
TLDR
chrome
in
v8
have
built-in
test
coverage
now
and
I
built
this
little
tool
called
c8
which
just
exposes
it.
C
This
exposes,
through
the
inspector
the
test
coverage
this
like
feature
that
won't
that
was
in
the
browser,
but
not
in
node
land,
and
now
it
is
tool
it's
janky,
because
it's
a
brand
new
feature
and
they're
all
emergent
specs,
but
I
bet
we
could
be
doing
this
for
a
bunch
of
other
things.
I
think
that's
a
really
cool
idea,
because
it
lets
people
get
a
taste
of
these
features.
I
love
it
because
it
lets
people
get
a
taste
of
some
of
these
emergent
features
because
well
here's
well
find
frustrate.
Let
me
share
frustration.
C
Like
one
of
the
issues
was
you
know
what
we
want,
that
we
want
to
be
able
to
move
forward
our
existing
ecosystem
of
900,000
packages.
It's
and
there's
you
know,
and
and
then
someone
would
inevitably
answer
well,
you
could
use
packaged
Maps
to
do
this
and
it
would
give
you
the
same
imports.
Well
then,
you're
like
well
geez,
like
you're,
asking
us
to
use
a
feature.
C
That's
only
slightly
emerged
and
there's
no
tooling
to
actually
even
try
this
feature
out
yet
would
be
if
we
actually
had
some
tooling
built
around
these
emergent
standards
that
allow
you
to
try
it
out.
Then
it's
it's
like
a
way
to
say:
oh
yeah,
we
I
guess
this
could
be
a
way
to
move
some
of
these
packages
forward
and
by
the
way,
here's
a
tool
that
actually
does
this
so
I
think
it's.
It
can
be
a
good
way
of
taking
something
where
it's
like.
C
B
I
think
that
sounds
like
a
great
vision
like
I
spend
enough
time
arguing
in
tc39
itself.
I
didn't
come
here
to
to
go
and
argue,
I
wanted
to
talk
about
like
positive
ways
forward
about
these
things,
and
that
sounds
like
you're
great
one,
but
it's
clear
that
building
these
practical
tools
is
not
a
sure
way
to
get
people
not
to
be
upset
at
you.
C
That's
exactly
how
I
feel
like
I
think
like
it's
frustrating
when
someone
comes
in
to
what's
right,
it
is
like.
Well,
you
don't
need
to
be
worried
because
we
have
this
emergent
standard
that
will
solve
the
problem.
It's
way
less
frustrating!
If
someone
comes
in
and
says,
look
here's
this
tool
that
is
written
to
this
emergent
standard
and
look
how
easy
it
makes
to
do
what
you're
talking
about
just
really
flips
the
conversation.
B
A
I'm
curious
about
ok,
so
if
we
have
these
these
experimental
tools
out
there-
and
maybe
it's
this
thing,
this
package-
myth
thing,
maybe
whatever
it
is,
how
do
we
get?
How
do
you?
How
does
tc39
know
that?
Ok,
this
tool
exists
and
it's
it's
a
prototype
and
it's
and
people
are
using
it
and
it
works
for
them.
How
do
we
get
that
feedback
back
to
you
or
how
does
tc39
know
that,
once
you
know
experimental
toolings,
but
out
there,
people
are
trying
to
use
it.
How
does
tc39
know
that
it's
it's
actually
helpful?
B
If
people
have
had
experience
with
a
proposal,
whether
positive
or
negative,
what
I
would
encourage
you
to
do
is
to
file
an
issue
in
github
on
the
proposal
repository
and
describe
how
it
works
and
describe
whether
it
work
for
you
whether
it
didn't
work
for
you.
I
know
that
issues
are
kind
of
a
funny
way
to
say
that
something
works,
but
really,
as
a
proposal
champion,
these
sorts
of
posts
about
what
worked
or
what
did
he
work.
Both
of
them
are
really
valuable.
B
I
think
people
get
the
idea
that
when
they,
when
they
do
see
something
about
the
proposal,
they
have
to
bring
it
to
an
abstract
level
and
say:
ok,
fundamentally,
this
is
wrong
because
of
that,
when
really
the
more
interesting
thing
is
more,
how
did
this
work
for
your
use
cases
so
and
from
there?
It's
it's
mostly
a
process
of
working
with
the
proposal
champions
if
it's
hard
to
get
through
to
the
proposal
champions,
and
you
can
talk
to
other
people
involved
in
the
case
of
well.
B
This
is
confusing
because
at
certain
points
in
time
it
was
called
like
module
maps
or
package
name
maps
and
now
import
maps.
That
proposal
isn't
being
developed
in
tc39,
it's
being
developed
more
among
browser
vendors.
So
it's
because
it's
not
it's
not
in
a
particular
standards
can
be
yet
seen.
It's
in
ycg,
so
discussing
that
with
with
them
is,
is
probably
the
more
the
more.
A
I
feel
like
that
puts
a
lot
of
burden
on
the
people
trying
to
give
feedback
I
feel
like
it
would
be
more
helpful.
If
you
know
there
was
like
a
suggestion
box
that
we
could
drop
something
in
in
and
TC
30
and
I
could
take
that
and
forward
it
to
the
correct
people,
or
you
know,
having
a
town
hall
or
a
discussion
like
this
even
would
be
great,
where
I
don't
have
to
know.
B
We're
thinking
about
for
tc39
is
sitting
up
discourse.
Ycg
already
has
a
discourse
and
that's
a
forum
for
more
kinds
of
freeform
discussion,
a
challenge
which
I'm
sure
you
all
faces
as
open
source
open
source
project,
maintainer
Zoar
contributors
is
actually
extracting
the
the
quality
feedback
out
of
it.
Sometimes
people
come
in
with
a
kind
of
aggressively
negative
stance
about
things
and
there's
something
about
the
format
of
github.
That
seems
to
especially
encourage
this
and
then
make
it
hard
to
get
the
the
more
nuanced
things
so
I
hope
the
discourse
could
be
helpful.
C
I
think
the
recommendation
I
would
make
is
I
think
why
I
jumped
at
your
idea.
That
would
be
fun
to
rate
some
tooling.
Is
that
you
actual
action
of
making
even
an
imperfect
tool?
I
think
makes
a
a
lot
more
impact
than
just
discussion
discussion.
You
know
there
are
way
too
much
discussion,
but
actually
like
it,
like
the
babble
I,
think.
C
That's
part
of
why
babbles
been
so
incredible
for
moving
forward
the
moving
for
JavaScript
it's
because
you
naturally
play
with
an
emergent
standard
and
see
how
the
feature
feels
it
just
makes
a
huge
difference
right.
So
I'd
rather
see
more
like
making
little
toys
that
let
us
test
something
like
module
matching,
that's
not
tc39,
or
you
know
more
projects
like
what
babel
facilitates
and
less
conversation,
because
I
think
the
conversation
can
be
where
it
devolves
into
just
arguing
about
the
perfect
solution
without
actually
getting
anything
done.
B
Yeah
and
with
with
import
maps,
you
actually
can
try
out
a
polyfill
I
mean
in
the
in
the
import
Maps
repository,
there's
sort
of
a
reference
implementation
under
development
and
in
parallel
guy
Bedford
has
a
shim
port,
or
a
variant
of
that
that
that
does
some
of
the
same
some
of
the
same
things,
but
with
a
parallel
implementation
and
as
well
sort
of
things
that
make
dynamic
import
work
in
the
browser
for
the
browser
doesn't
support
it.
There's
there's
a
lot
of
experimentation
going
on
here,
but
I
want
to
I
hope.
E
D
B
B
But
what
do
we
do
about
different
pieces
of,
for
example,
the
standard
library
we
have
things
like
until
the
internationalization
standard
library
as
part
of
gc3
writings
work,
whereas
other
common
libraries
that
are
shared
between
the
web
and
node,
like
URL
or
txt
encoder,
are
outside
and
developed
in
what
week
I
think
it's.
It's
ultimately
kind
of
a
blurry
line
between
these
things
and
I
want
to
just
promote
alignment
across
the
ecosystem,
regardless
of
which
different
standards
venue.
C
A
B
I'm,
not
sure
if
that
would
be
an
appealing
media
to
the
people
here.
The
the
discussion
that
we
had,
we
had
a
we
had
a
one-off
call
to
discuss
how
node
could
be
more
involved
in
standards,
but
this
was
more
with
node
core
people
and
we
decided
not
to
make
any
particular
standing
meeting,
but
instead
to
have
a
few
threads
where
we
could
discuss
things.
B
And
then,
when
we
get
to
a
point
where
we
have
something
substantial
that
we
want
to
come
to
a
conclusion
on,
then
maybe
we
would
establish
a
call
to
discuss
one
particular
proposed
standard.
So
I'm
not
sure.
Does
that
format
sound
good
for
you
or
do
you
think
we
should
do
something
separate
to
specifically
engaged
cooling
I.
A
C
Think
that
I
think
I
think
just
making
maybe
making
it
like.
This
has
been
great
because
it's
kind
of
a
good
brain
dump
its
first
time,
Daniels
been
on
the
call,
but
but
maybe
having
like
a
really
great
to
continue
to
have
a
representative.
But
you
know,
you've
haven't,
maybe
only
be
a
small
part
of
the
agenda,
and
so
if
that
means,
we
have
a
second
call
occasionally
just
to
get
a
few
folks
together.
I
think
that
could
be
good
honestly
I
would
say
like
we
do
have.
Npm
does
have
one
representative
on
tc39.
C
You
know
I'm
about
to
go
to
work
after
this
call,
so
I'll
bring
it
up
with
the
folks,
because
I
think
the
promise
I
want
to
see
more
communication
between
everyone,
because
I
think
when
you
go
when
you
go
back
to
your
project,
you're
like
tc39,
doesn't
understand,
node
or
node
doesn't
understand.
Npm
like
that.
Does
enough
with
these
obnoxious
threads
there's
absolutely
no
reason
for
it.
Oh.
A
B
C
A
A
All
right
well,
thank
you,
then
Daniel
for
for
for
dropping
in
and
having
this
talk
with
us
yeah,
don't
don't
feel
bad
I
I,
don't
I,
don't
feel
like
I,
don't
feel
bad
that
you
know
we're
almost
out
of
time
or
anything.
So
as
far
as
other
agenda
items,
you
know
there
wasn't
too
much.
One
thing
I
wanted
to
bring
up
was
yeah,
so
this
meeting
is
every
three
weeks
which
I'm
not
sure
I
like
that.
A
But
if
the
do
the
reason
it's
every
three
weeks
is
because
we're
conflicting
with
some
other
group
at
this
timeslot
on
a
Tuesday
and
they
meet
every
three
weeks.
And
so
you
know
if
we
want
to
keep
this
timeslot,
essentially
we're
not
going
to
be
alive
on
YouTube
unless
we
meet
every
three
weeks
now,
I,
don't
know
what
the
reason
is
why
we
can't
have
two
live
streams
happening
at
once,
but
that's
that
it
you
know
does.
Does
anybody
want
to
meet
more
often
than
every
three
weeks.
C
Three
weeks,
but
I
do
get
it
like.
Full
disclosure
like
Chris
and
I,
will
Chuck
talk
and
chat
outside
of
our
meetings,
so
I
feel
like
I'm,
a
bit
of
and
I
do
with
other
people
in
the
tooling
community,
so
maybe
making
our
sock
more
official,
like
maybe
switching
to
the
node,
tooling
and
maybe
switching
to
the
actual.
Whatever
the
node
1
is
yeah.
A
A
E
I
was
gonna
point
that
out
I'm
also
in
the
package.
Maintenance
working
group
and
I
tend
to
see
more
chatter
in
in
the
in
the
channels.
Now
that
we've
established
it
as
one
of
the
I
guess
not
official,
but
you
know
trying
to
get
more
in
real
time.
Converse
happening
there.
I
just
joined,
of
course,
the
towing
the
other
day,
just
because
I
felt
it
was
very
in
line
to
what
we're
doing
a
lot
in
the
package.
Maintenance
working
group,
as
far
as
like
revolving
around
based
practices
and
tooling
comes
up
so
I
figured.
E
C
C
D
E
C
E
C
We
have
all
these
interesting
characters
from
from
MPM
history,
who
don't
necessarily
get
as
involved
in
node
as
they
could
and
definitely
don't
get
us
involved
in
tc39
as
they
could.
So
if
we
could
work
our
networks
and
get
some
of
them
chatting
with
this
more
I
think
that
could
be
valuable.
Daniel
yeah.
E
B
We
have
a
big
history
of
Bradley
being
sort
of
one
of
the
well
four
for
a
while.
He
was
the
only
person
who
would
come
to
tc39
and
and
say
he
was
representing
notes,
concerns
and
so
yeah
and
he's
done
a
he's
done
a
great
job
and
in
addition,
as
we
brought
in
the
interaction
I,
am
learning
about
more
diversity
of
opinions
and
more
different
kinds
of
concerns
within
note,
and
so
that's
yeah.
It's
been
really
good.
E
F
C
F
A
No,
so
nothing,
nothing
pressing,
I
didn't
want
to
mention
really
quick
that
you
know
there
was
something
about
you
know.
Rim
raff
might
be
easier
to
implement.
If
we
had
I,
don't
know
it's
like
new
receipt
ceiling
support
but
what's
holding
in
spec
right
now
is
a
couple
of
IBM's
platforms
or
their
architectures,
and
so
I
talked
to
Sam
Roberts,
and
he
mentioned
that
I.
A
Don't
he
just
had
some
concerns?
He
wasn't
really.
He
wasn't
convinced
a
lower-level
R
implementation
would
a
be
any
faster
than
than
one
implemented
in
JavaScript,
because
that's
the
he'd,
you
know
it's
not
where
the
bottleneck
is.
You
know,
the
bottleneck
is
IO
and
you
know
the
the
other.
The
other
thing
is
then
he
wasn't
sure
that
oh
yeah
yeah
it.
The
other
thing,
of
course,
is
a
pain
about
to
implement
so,
but
we
knew
that
already
so
you
know-
maybe
maybe
you
know
we
can
just
kind
of
it.
A
C
In
coverage,
which
was
Nev,
that's
been
a
long-term
project,
it's
got
some
bugs,
so
hopefully,
people
pitch
in
on
the
v8
end
of
things,
but
my
new
pet
thing
that
I
think
is
gonna.
Have
a
wider
appeal
to
just
tooling
in
general.
Is
I
really
want
to
start
solving
the
source
Maps
problem
better
because
anyone
who's
using
source
Maps
in
typescript
or
Babel
or
whatever
gets
their
error
number,
is
completely
shuffled
around
once
the
in
exception
throws
because
node
doesn't
have
good
source
map
handling
so
long
story
short.
C
B
Really
think
part
of
the
issue
with
source
Maps
is
the
lack
of
a
proper
standard
for
them.
I
mean
part
of
it
is
not
having
support
everywhere,
but
part
of
it
is
that
the
edge
cases
differ
in
certain
places,
and
this
is
the
kind
of
thing
that
standards
can
tighten
down,
because
there
are
several
implementations
of
the
same
interface
and
standards
can
can
be
a
venue
for
helping
them
agree.
Well,.