►
Description
Morning Keynote- Node.js Core State of the Union - James Snell, IBM
A
Okay,
how's
everyone
doing
I'm
gonna
walk
up,
so
I
am
Genesis.
Now
I
am
on
the
the
node
core
technical
team,
a
mom
also
ibm's
technical
lead
for
node
I,
get
to
work
on
node
full-time
every
day,
which
is
fantastic
I'm
here
to
talk
a
little
bit
about
where
node
core
has
been
over
the
past
year
and
a
little
bit
about
where
we're
going.
A
There's
a
lot
of
material,
so
I'm
gonna
kind
of
be
going
through
it
fairly
quickly,
but
I
wanted
to
kind
of
reflect
a
little
bit
on
where
we've
been
so
I
got
started
with
node
January
2015
and
at
that
time,
in
node
core
the
core
contributor
base
had
shrunk
down
to
about
fourteen
active
participants,
most
of
which
were
in
the
United
States,
actually
most
of
which
were
on
the
west
coast.
United
States,
and
we
had
a
few
hundred.
A
You
know
folks
participating
internationally,
but
it
had
really
shrunk
down
to
a
very
small
group
today
and
I
made
this
slide
like
two
weeks
ago,
we've
added
two
more
since
then
they're,
eight
there's
you
know,
87
contributors
would
commit
access
and
the
total
contributions
is
is
now
over.
A
thousand
individuals
over
over
nodes
lifetime,
that
is,
a
increase
of
just
over
400
people,
since
node
V,
zero
twelve
got
was
released.
So
it's
been
phenomenal
growth
in
the
community,
we're
nowhere
near
where
we
want
to
be
here.
We
want
more
contributors.
We
want
to
grow
this.
A
The
number
of
people
with
commit
access.
We
want
to
increase
the
diversity
above
the
community
globally
right.
We
want
anyone
who
can
contribute
to
the
project
who
wants
to
contribute
to
the
project
to
be
able
to
do
so.
So
some
some
great
things
going
on
with
the
community,
but
a
lot
more
work
to
do
now.
There
are
476.
The
numbers
may
vary
like
I
said:
I
put
these
numbers
together
two
weeks
ago
in
the
github
organization,
103
github
repositories,
92
github
teams
and
over
4,000
Forks
of
projects
where
people
are
out
there
working.
A
Really
like
these
numbers,
so
since
version
4
and
Michael
mentioned
that
version,
4
was
out
exactly
a
year
ago
yesterday,
since
that
time
there
have
been
27,000
commits
or
not
27,
two
point:
seven
thousand
commits
on
master
half
of
those
have
all
been
focused
on
tests
and
performance
and
documentation
right,
which
is
pretty
phenomenal.
15
percent
focus
on
updated,
tooling
dependencies
version.
5
only
had
17
member
major
and
version
6
only
had
90
semper
major
commits
out
of
the
2.7
thousand
all
right.
A
So
that
means
that
there's
been
a
huge
amount
of
focus
on
just
stabilizing
the
core,
making
making
the
tests
better
making
the
performance
better
of
you
know,
fixing
bugs
very
few
actual
breaking
changes,
and
if
you
look
at
the
transition,
you
know
for
those
of
you
who
have
who
may
have
transitioned
from
0
10
or
0
12
to
4
it's
kind
of
a
painful
process
right.
There
was
there's
a
significant
number
of
changes
there
that
made
that
a
little
more
difficult,
but
the
the
transition
from
from
4
to
6
is.
A
A
The
really
interesting
thing
about
this
is
when
we
launched
the
foundation,
one
of
the
key
goals
was
to
make
the
contribution
process
as
open
and
as
liberal
as
possible.
We
didn't
want
to
have
any
kind
of
gating
factors
of
individuals
right
that
they
could
basically
block
what
was
happening
right.
We
just
wanted
to
open
up.
If
you
wanted
to
contribute,
you
could
and
what
we
found
as
soon
as
we
did.
A
A
Operations
per
second,
the
second
graph
is
our
startup
times.
You
can
see
that
you
know
the
newer
versions
take
a
little
longer
to
start
up
and
shut
down,
because
we're
doing
more
so
more
optimizations
there,
so
that,
while
things
are
running,
it's
more
performant,
but
these
numbers
are
tracked
like
that
every
single
day-
and
it's
definitely
a
the
this
site-
is
it's
a
new
resource
from
our
benchmarking
working
group?
It
it's
fantastic
way
of
getting
just
kind
of
see.
Where
note
is
that
or
yeah
right
now
we
have
a
new
canary
in
the
goldmine
tool.
A
A
A
He
and
he
has
a
talk,
I
think
either
later
on
today
or
mark
him
exactly
what
it
is,
but
he
has
a
talk
on
some
of
the
lessons
learned
and
some
of
the
experiences
with
this
tool.
The
thing
I
wanted
to
point
out
about
this
is
that
this
is
installable
from
NPM
you're,
just
npm
install',
CIT
GM.
You
can
run
these
tests
yourself,
it'll
test.
A
This
is
another
great
one.
I
love
this
every
non-trivial
commit.
We
run
our
CI
check
on
on
everything
other
than
Doc's
right.
So,
if
you
know
the
docs
change,
okay,
we'll
go
ahead
and
skip
it,
but
every
commit
will
run
on
all
of
these
platforms
every
time
right
and
will
usually
run
every
pull
request
on
the
on
these
actually
several
times.
If
it's,
if
it's
non-trivial,
just
to
make
sure
that
things
aren't
breaking
the
the
infrastructure
team,
the
build
team
is.
A
There
is
a
huge
amount
of
credit
for
this
for
setting
up
this
infrastructure,
it's
pretty
pretty
impressive.
What
they've
done
one
of
the
one
of
the
more
impressive
aspects
of
it
is
the
raspberry
pie,
farm
I,
think
rod
rod
bag.
One
of
the
other
contributors
in
his
garage
has
a
whole
bunch
of
raspberry
PI's
all
set
up,
and
it's
right.
It's
it's
pretty
pretty
impressive
and
we'll
run
all
of
the
tests
there
as
well
on
every
commit
so
releases.
We've
had
a
hundred
and
twenty
node
releases
since
January
2000
2015.
A
Those
do
include
all
of
the
io
GS
releases.
If
you're
not
aware,
when
we
did
merge
the
projects,
we
decided
to
count
all
of
the
I
adjust
releases
as
proper
node
releases,
so
bringing
them
all
together.
This
is
all
the
release
lines:
0
10
0,
12,
4,
&,
6,
4,
5
6.
All
of
these
been
120
of
those
31
have
been
to
version
4,
0,
10,
0
12,
under
our
long-term
support
plan.
A
We'll
talk
a
little
bit
more
about
that
in
a
second,
we
have
a
new
major
release
every
six
months,
so
October
and
April
even-numbered
releases
are
in
April,
so
we
just
had
v6
come
out
last
last
April
we
have
v7
coming
up
here
and
on
October.
The
even
number
releases
are
the
ones
that
go
under
our
LCS
plan.
The
odd
number,
like
version
5,
those
are
only
going
to
be
supported
for
a
max
of
maybe
nine
months
right.
A
A
So
right
now
current
releases
we
have
6.5
is
our.
Is
our
current
stable,
current
long-term
support
branches,
4.5
and
0
10
and
0
12
are
both
in
maintenance.
Now,
if
you're
still
using
0,
10
0
12
anybody
still
using
those
alright
upgrade
justjust,
do
it?
0
10
expires
at
the
end
of
October
and
0.
12
expires
at
the
end
of
the
year
and
the
main
reason
for
that
is
after
the
31st
of
December.
We
won't
be
able
to
get
any
more
open,
SSL
updates
for
those
versions,
and
you
know
so
we
won't
be.
A
A
You
have
some
time,
but
version
6
is
supposed
to
go
into
LCS
in
October
and
those
will
overlap
there
intentionally
overlap,
because,
if
you're
a
business
using
relying
on
node,
we
want
to
give
you
a
transition
time
where
you
can
go
from
1
LTS
release
to
another
LTS
release
with,
hopefully
with
minimal
breakage,
so
the
next
v6
the
code
name,
will
be
boron.
We
assign
code
names
based
on
the
the
periodic
table.
Boron
was
the
winning.
It
was
the
winning
vote
here.
A
That'll
come
out
October,
it's
gonna
be
late
October,
because
we're
waiting
on
the
new
version
of
v8-
and
this
is
this-
is
fun.
We're
gonna,
be
shipping
with
v8
version
5.4,
which
means
LCS
will
go.
It'll
go
to
LCS
with
the
arms
I
know.
I'm
fly
for
is
going
to
be
in
Spurgeon.
Seven
six
is
going
to
have
a
is
in
5.1
and
we
want
to
make
sure
that
everything
is
work
with
burdensome
before
this
goes
over
sevens.
Gonna
have
the
5.4.
Is
it
the
first
time
we're
going
to
be
doing
beta
releases?
A
The
first
beta
will
be
out
next
week.
It
will
have
the
beta
version
of
v8
5.4.
This
one's
only
going
to
be
supported
for
until
June
2017.
It's
an
odd-numbered
release,
so
we're
looking
about
at
about
9
months,
ok
and,
of
course
v8
in
2017.
Ok,
so
I
am
really
pushing
hard
here.
We
need
to
have
Google
and
give
us
v8
version
v8
for
node,
V,
8,
V,
8,
V,
8
and
v8.
This
is
going
to
be
epic
if
we
can
pull
this
off,
so
we
really
have
to
do
this.
A
Realistically,
it's
probably
gonna
be
something
boring
like
you
know,
v8
v6
or
something,
but
we're
gonna,
I'm
gonna
try
to
get
there
I'm
lobbying
hard
for
it.
So
where
are
we
going
and
I
wanna
contact
with
this?
We
don't
have
much
time
so
I'm
have
to
breeze
through
quite
a
bit
of
this
and
I
want
to
talk
about
some
of
the
things
that
we're
working
on
in
core
right,
so
better
web
standards
support
better
jobs
for
languages,
support
and
a
few
other
things.
So,
let's
let
me
kind
of
start
getting
through
it.
A
Web
standards
node
has
always
been
a
a
platform
for
web
development.
Right
we've
had
eight
HTTP
implementation
in
there
we
do.
You
are
all
parsing.
The
problem
is,
is
that
well
it's
been
good.
There
were
a
number
of
shortcuts
taken
to
the
implementation,
to
get
performance
right
and
we're
and
we're
taking
an
effort
now
to
really
start
to
improve
the
standards,
compliance
within
node
and
hopefully
in
a
way
that
doesn't
sacrifice
performance.
It's
it's
it's
not
a
it's,
not
a
trivial
problem.
A
One
of
the
things
we're
working
on
is
what
WG,
URL
parsing
so
making
URL
parsing
and
node
consistent
with,
what's
currently
in
browsers,
so
it'll
be
the
same
URL
object
in
both
right,
so
you
don't
have
two
different
api's
for
that.
We're
also
looking
at
better
suspect
compliance
for
HTTP
one.
The
HTTP
implementation
has
been
a
rich
source
of
security
issues
with
a
node
for
the
past
year.
In
fact,
almost
all
of
our
security
releases
have
dealt
with
HP
issues,
so
we're
working
on
hardening
that
up
and
we're
also
working
on
http/2.
A
This
is
an
ongoing
conversation
now
exactly
how
we
will
do
this
I'll
be
talking
about
it
a
little
bit
more
later
today
and
hopefully
a
little
bit
more
during
the
collaboration
summit.
That's
just
that!
That's
this
weekend
about
getting
hb2
in
there
within
within
the
next
year.
So
continued
improvements
to
language
standards.
Promises
async/await
in
es6
modules,
specifically
with
v8
version,
5.4
and
node,
will
get
something
like
98%
of
es6
language
features
that
just
work
right.
The
things
that
are
still
a
problem
spot
are
promises.
A
We
still
have
some
work
to
do
on
promises,
promises,
don't
work
with
no
debugging
right
now,
basically,
they're
basically
implemented
as
a
black
box.
We
can't
see
inside
them
to
do
any
of
the
debugging
work
that
we
need.
It's
been
an
ongoing
problem
and
we're
looking
to
get
that
solved.
The
other
thing
we're
looking
at
is
making
and
figuring
out
ways
to
get
the
node
API
compatible
with
promises.
It's
been
a
number
of
conversations
there.
A
You
know
you
know:
do
we
just
want
to
start
supporting
it
within
the
API
or
make
it
easier
for
the
existing
API
to
work
to
be
used
as
promises?
So
there's
the
number
of
ongoing
conversations.
It's
not
very,
very
non-trivial.
Another
non-trivial
problem
reaches
six
modules.
Anybody's
been
following
this
conversation.
It's
you
understand,
there's
a
lot
of
of
things
here.
The
way
es6
modules
are
currently
designed,
they're
not
compatible
with
the
the
current
way.
Node
does
module
sit
that
you
know
it
is
an
event
model
and
we
can't
simply
just
implement.
A
What's
tc39
the
standards
group
that
defines
java
scripts,
we
can't
implement
what
they've
defined
as
it
currently
stands,
without
breaking
node
as
it
currently
works,
and
we
don't
want
to
do
that.
We're
not
going
to
do
that.
We
have
to
preserve
the
stability
of
the
platform
right
and
the
stability
of
that
platform.
Trump's
getting
new
features
in
quickly,
so
we
were
working
on
it.
We
will
continue
to
evolve.
A
We
have
a
number
of
conversations
going
on
with
tc39
to
figure
out
how
we
can
better
represent
the
knee
of
the
node
community
and
the
node
users
within
that
group.
So
we
can
have
evolved
this
spec,
so
we
can
get
modules
working
so
be
patient.
We
know
everyone
wants
them,
there's
a
large
developer
community
that
wants
modules
and
they're
asking
us
for
it
before
this
trying
to
figure
out
when
we're
going
to
when
we're
gonna
get
this
in
it's
going
to
take
some
time.
So
please
be
patient
with
us.
A
If
you
have
any
ideas,
thoughts
on
how
this
should
work,
please
come
to
us
and
let
us
know
some
other
things
we're
working
on
these
kind
of
low
level,
so
I'm
gonna
kind
of
go
through
these
quickly
async
hook.
It's
a
way
of
getting
insight
into
what's
happening
with
the
the
node
event
loop,
we're
working
on
multiple
isolates
the
workers
and
one
fun.
One
is
a
new
native
module
API.
A
So
if
you
want
to
you
know
kind
of
look,
you
can
go
to
and
have
the
URL,
so
you
can
kind
of
go
and
read
up
on
more
detail.
Some
of
these
conversations
are
a
bit
longer.
It's
quite
a
bit
going
on.
Async
Oakland
is
definitely
an
important
one.
Most
Blythe.
Let's
this
one,
not
a
lot
of
stuff
going
on
publicly
I
know.
Ben
nor
dice
has
been
working
on
this
quite
a
bit,
and
hopefully
you
know
we'll
have
some
more
details
on
exactly
how
this
is
going
to
work.
A
The
new
native
module
API
is
good,
so
native
modules.
Right
now
this
may
be
a
little
bit
hard
to
read.
Native
modules
right
now
depend
directly
on
the
v8
API
right.
What
we're
basically
doing
is
trying
to
make
it
so
that
native
module
developers
can
write
add-ons
that
do
not
bind
directly
to
v8
all
right
and
they
go
through
this
abstraction
API
that
allows
us
to
update
versions
of
v8
faster
on
the
back
end
without
breaking
native
modules.
So
the
you
know,
whenever
we
update
it,
you
don't
have
to
actually
go
through
and
recompile.
A
You
don't
have
to
go
through
and
reinstall
everything
things
just
continue
to
work.
Another
benefit
of
this
is
that
we
can
get
other
VMs
in
there
like
the
chakra
work,
where
that
is
being
integrated.
Much
easier
in
these.
These
native
modules
can
work
against
those
other
VMs,
also
without
being
having
to
be
modified
right,
so
that
work
is
going
to
static
error
codes.
This
is
another
one.
Every
node
error
will
have
a
static
error
code
rather
than
having
to
depend
on
just
the
error
message:
uvlink
key
streams.
A
This
is
pretty
low
level,
but
this
is
yeah
a
much
more
powerful
streams,
API
for
native
native
model
development
and,
of
course,
a
multiple
VM
work.
There
were
the
work
is
underway
to
make
no
truly
agnostic
as
to
what
VM
is
used
under
the
covers.
We
will
still
continue
to
ship
v8
as
the
default
engine
for
the
foreseeable
future.
There's
been
no
plans
to
change
that
default,
but
we
do
want
to
make
it
possible
for
developers
to
easily
use
these
other
other
platforms
and
improved.
Embedding
Michael
talked
about
electron.
A
This
one's
huge,
this
one's
very,
very
important,
we're
starting
to
get
much
more
involvement
from
the
community
of
folks
who
are
looking
to
embed
node
into
other
things,
and
a
number
of
improvements
have
been
made
to
this
and
we're
going
to
continue
to
make
those
improvements
improved
internationalization.
So
we
have
the
incl
object.
We
have.
The
ability
to
you
know,
do
basic
formatting
of
numbers
and
in
dates
we're
also
going
to
be
doing
things
like
allowing
a
buffer
to
be
re-encoded
right,
as
is
it.
A
You
know
from
from
one
cartridge
that
to
another
there's,
you
know
an
api
for
that,
there's
other
API
for
doing
some
more
locale,
specific
work,
character,
properties,
there's
a
number
of
things
that
are
being
that
are
being
looked
at
here.
To
make
it,
you
know,
node
out
of
the
box
easier
to
work
with
international
if
you're
into
post-mortem
debugging,
it's
ever
been
my
forte
I,
don't
like
looking
at
those
the
the
the
heap
dumps,
but
we
are
looking
at
a
common
heap,
dump
format,
improved
analysis,
tooling,
there's
a
new
project
called
node
report.
A
A
So
a
couple
of
links,
if
you
want
to
kind
of
follow
up
on
that,
there
is
now
the
chrome
inspector
in
there.
So
we
Google
came
to
us
and
asked
you
know
hey
what
would
you
think
if
we
just
put
our
inspector
protocol
in
core
I
like
sure,
go
ahead?
It's
now
when
there
was
an
experimental
feature
with
with
the
goal
of
ultimately
replacing
the
debugger
that's
built
into
node,
but
waiting
on
basically
is
for
other
tools
to
start
picking
up
and
make
sure
that
that
it's
not
work.
A
It's
not
just
chrome
that
people
have
to
use
that
they
can
use
any
debugger
tool
that
they
want,
but
the
basics
are
already
in
there
and
it,
and
it
does
work
quite
well
and
this
one's
also
cool
we're
looking
at
a
new
electron
based
installer
for
node.
So
that's
some
great
work
going
on.
There
come
help
us
there's
a
lot
to
do.
We
have
a
number
of
open
issues
where
we
want
new
contributors
as
much
as
possible
to
come.
A
There's
some
remark
is
a
good
first
contribution
Saturday
morning
we're
having
a
workshop
here
for
people
who
want
to
get
involved
with
node
and
start
learning
to
contribute,
there's
going
to
be
a
number
of
the
the
core
contributors
here
to
work
as
mentors
for
that
and
also
you
know,
bringing
it
back
to
community
there's
so
much
more
that
we
have
to
do
to
make
this
community
more
diverse.
And
it's
going
to
be
a
number
of
talks
about
this.
A
There
is
a
new
effort
right
now
that
the
core
technical
steering
committee
has
asked
the
foundation
to
basically
put
the
other
proposal
for
how
do
we
improve
the
diversity
inclusivity
of
the
of
the
node
project?
We're
looking
for
input
on
that,
you
can
talk
to
Tracy,
Hines
and
Michael
Moore
on
on
that
stuff.
So
that's
it
on
behalf
of
myself,
some
all
the
core
contributors.
So
thank
you
so.