►
Description
Node.js: The New and the Experimental - Bethany Griggs, Red Hat
Node.js core does not have an official roadmap - it’s the sum of the interests and efforts of the contributors that determine the future of the project. The evolution of a new feature in Node.js can take different twists and turns. Some new features land as experimental, to give time to gather user feedback before they’re considered stable. Other features will land as stable from the start. So what’s in the pipeline?
Join the speaker for live Q&A on Slack: Thursday, June 3 from 02:20 - 02:40 PDT / 11:20 - 11:40 CEST, channel - #openjs_world-development
A
A
A
A
You
may
be
surprised
to
learn
that
the
node.js
project
has
no
formal
roadmap.
There's
no
prioritized
task
list,
there's
no
single
corporate
sponsor
and
the
project
is
completely
decentralized
generally.
The
features
and
changes
that
get
added
to
the
runtime
are
some
of
the
interests
and
requirements
of
our
contributors,
but
what's
it
like
not
having
a
road
map?
A
Well,
I
spent
a
short
while
trying
to
come
up
with
a
good
analogy,
and
I
thought
this
one
was
appropriate.
This
is
a
famous
roundabout
or
turning
circle.
In
the
uk
it's
actually
made
up
of
five
smaller
roundabouts
all
arranged
in
a
circle
and,
as
you
can
see,
it
handles
a
heavy
flow
of
traffic
heading
in
all
different
directions.
A
A
A
A
The
project
has
a
medium
blog,
which
is
nodejs.medium.com
where
we
post
any
of
our
major
announcements.
There
are
twitter,
so
node.js
has
its
own
twitter
handle,
but
there
are
also
many
of
the
active
node.js
contributors
are
also
active
on
twitter.
So
that's
also
a
good
place
to
follow
what
folks
are
working
on,
and
you
can
probably
find
some
of
those
folks
at
this
conference.
Speaking
too
and
also
github,
you
could
follow
the
project
on
github
and
its
many
repositories,
but
about
the
github
notifications.
A
If
you
do
subscribe
to
notecore
and
any
of
the
other
repositories
be
warned,
there
is
a
lot
of
activity
and
it's
really
hard
to
keep
up.
You
can
get
several
hundred
notifications
a
day
and,
admittedly,
I
declare
a
notification
bankruptcy
every
week
or
so
and
just
mark
everything
is
right.
I
really
do
rely
on
like
the
participating
notifications
to
keep
track
of
what
I
need
your
address.
A
Rather
than
keep
up
with
the
massive
notifications.
There
are
some
specific
efforts
you
could
follow.
So,
despite
having
no
roadmap,
there
are
still
longer-term
efforts
and
planning
within
the
project.
For
example,
we
have
working
groups
dedicated
to
certain
areas
of
the
project
and
these
groups
act
as
task
forces
for
pushing
certain
subject
areas
forward.
A
For
example,
in
the
past
we
had
a
module's
effort
focused
on
driving
the
end
script,
module's
implementation.
As
a
note,
if
you're
looking
to
get
involved
in
a
project,
a
good
way
is
to
look
at
these
working
groups,
see
if
any
of
them
align
with
your
interests
and
join
one
of
them.
They
all
have
github
repositories
with
their
own
tasks
and
issues,
and
many
of
them
also
have
a
publicly
streamed
video
meetings
that
you're
free
to
join
and
pass
it
in
as
well
as
teams
and
working
groups.
A
The
project
also
has
what
we
call
strategic
initiatives.
These
are
agreed
initiatives
that
the
project
hopes
to
make
progress
on
again,
there's
not
really
a
priority
list
or
deadline.
These
are
just
some
important
goals
we've
listed
and
we
think
it
would
be
useful
to
track
the
status
on
these
over
time
and
try
and
figure
out
ways.
We
can
help
address
these
initiatives.
A
And
similarly,
under
the
community
we
have
some
more
community
focused
strategic
initiatives,
and
it
includes
things
like
internationalization,
mentorship
and
others
such
as
outreach
and
website
redesign
again.
These
are
good
areas
to
look
at
if
you're
interested
in
getting
involved
in
the
project
and
one
effort
I'd
like
to
call
that,
in
particular,
is
the
next
10
evan.
A
This
team
came
together
last
year
to
focus
on
making
the
next
10
years
there
was
no
js
is
successful,
was
the
last.
So
what
we've
done
within
this
group
is:
we've
spent
some
time
looking
back
on
the
successes
of
the
project
over
the
past
decade,
and
we've
also
tried
to
determine
the
values
and
constituencies
of
the
project.
A
A
Within
our
release
schedule
we
have
three
defined
release
phases,
current
active
long-term
support
and
maintenance,
and
it's
during
the
current
phase
that
the
release
line
will
pick
up
most
of
the
non-major
changes
that
land
on
node.js
call
main
branch
during
the
active
long-term
support
phase.
Only
new
features
fixes
and
updates
that
have
been
ordered
by
the
lgs
team
and
have
been
considered
appropriate
and
stable
land
and
in
maintenance
that
tends
to
be
limited
to
critical
bug,
fixes
and
security
updates.
A
A
and
typically
for
current,
you
can
expect
about
one
release
every
two
weeks
after
some
time.
You
can
then
expect
the
new
features
that
have
landed
in
the
current
release,
line
to
come
back
into
the
long
term
support,
but
not
all
the
features
will
make
it
back
into
long-term
supported
release
lines.
Some
will
be
considered
too
unstable
to
be
brought
back,
and
sometimes
the
code
delta
in
the
release
lines,
it's
just
too
large
to
be
able
to
feasibly
bring
that
feature
back.
A
So
if
you
ever
just
want
to
gauge
roughly
when
the
next
release
will
be
on
each
of
the
given
release,
lines
check
out
these
issues
and
you
should
get
an
indication
all
of
them
of
course,
subject
to
release,
availability
and
two
things.
I'd
like
to
call
out
from
the
release
schedule
is
node.js.
10
is
now
end
of
life.
It
went
end
of
life
at
the
end
of
april
2021.
So
if
you're
using
that
be
aware
that
there
are
no
more
security
fixes
being
given
to
that
release
line.
A
A
A
That's
a
bit
about
how
you
can
follow
what's
coming
next
and
how
features
end
up
in
the
various
release
lines.
What
about
new
features?
How
do
you
know
when
a
feature
is
safe
to
use
in
your
production
applications,
but
notice
project
provides
a
stability
index
throughout
the
api
documentation.
There
are
indicators
of
stability
for
each
api.
A
At
the
moment
there
are
four
stability
levels:
stability,
zero,
deprecated
stability,
one
experimental
stability,
two
stable
and
stability,
three
legacy,
which
has
only
recently
been
added
so
digging
into
those
specific
0
deprecated
an
api
can
be
the
documentation
or
runtime
deprecated,
as
you
can
expect.
A
documentation.
Deprecation
is
just
that.
An
indication
in
the
api
docs
that
given
api
is
deprecated,
and
this
is
an
example
of
the
deprecation
of
socket
buffer
size-
includes
a
deprecation
id.
The
version
that
introduced
deprecation
and
documentation
deprecations
can
land
in
minor
releases
of
node.
A
A
The
nodejs
does
provide
a
pending
deprecation
process
flag,
so
some
documentation
only
deprecations
will
trigger
a
runtime
warning
when
launched
with
this
flag.
So
if
you
want
to
see
whether
you're
using
any
of
the
deprecated
apis,
you
can
start
your
node
process
with
this
flag
and
you
should
start
to
see
warnings
coming
through.
If
you
are
using
an
api,
that's
amount
for
deprecation.
A
We
also
have
runtime
deprecations,
a
runtime
deprecation
will
by
default,
generate
a
process
warning
that
will
be
printed
to
standard
error.
The
first
time
the
deprecated
api
is
used.
This
here
is
an
example,
one
that
may
be
familiar.
The
unhandled
promise
rejection
warning
that
you
may
have
found
familiar
node
versions,
14
and
under
and
because
a
runtime
warning
is
an
observable
change.
It
actually
prints
something
to
standard
hour.
A
A
That's
emitting
a
warning
may
end
up
being
removed
so
by
using
this
regularly
you're,
essentially
just
taking
your
problem
down
the
road
and
there's
also
the
throw
deprecation,
and
that
takes
a
more
extreme
state
of
throwing
an
error
when
you
hit
a
deprecation
one,
and
I
personally
would
treat
these
as
kind
of
like
smoke
test.
I
just
occasionally
run
my
apps
with
these
to
to
see
whether
any
new
applications
have
been
introduced
will
impact
my
project.
A
This
is
because
you
should
be
using
the
strict
version
of
each
of
these
apis
where
possible.
There
is
a
slight
caveat
if
you
are
using
the
strict
mode
over
set,
then
it's
okay
to
use
the
equal.
It's
only
the
non-strict
mode,
non-strict
apis
that
are
marked
as
legacy
but
again
they're
indicated
as
legacy
as
we
don't
plan
to
remove
them,
because
we
think
it
will
cause
too
much
disruption.
A
Apis
they're
also
legacy,
and
then
some
others
include
process
hr
time,
the
query,
string,
module
and
the
url
ipi
and
for
the
url
api
you
should
be
using
the
newer
wg
url
api
instead,
so
on
to
experimental
features.
No
chess
project
stability
index
states
that
experimental
apis
may
change.
Behavior.
A
The
traditional
semantic
version
contract
that
we
try
to
adhere
to
everywhere
else
does
not
apply
to
experimental
features
even
in
long-term
supported
releases,
and
this
is
why
we
tend
to
say
use
experimental
features
with
caution,
especially
in
production
workloads,
because
the
api
may
change
even
in
lts,
and
why
do
some
features
landers
experiment
when
others
don't
well?
In
some
cases,
the
most
suitable
api
design
may
not
be
agreed
upon
upfront.
A
And
there
are
a
number
of
whole
core
modules
in
mode
that
are
still
designated
as
experimental
and
when
I
say
core
modules,
I'm
referring
to
the
ones
that
are
built
into
the
runtime
itself,
like
fs
and
http,
and
all
of
these
are
still
experimental.
As
of
note
1610,
so
one
of
the
first
experimental
core
modules
is
the
async
hooks
module.
A
The
asynchronous
module
provides
an
api
for
you
to
track
asynchronous
resource.
What's
an
asynchronous
resource.
These
are
things
like
promises,
timeouts,
immediates
and
ticks,
and
in
particular,
within
this
experimental
module.
I'd
like
to
call
out
the
async
local
storage
class
and
this
class
is
used
to
create
asynchronous
state
within
callbacks
and
promise
chains,
and
this
example
simulates
how
it
might
be
used
within
a
web
server.
A
So
the
get
store
returns,
the
values
specific
to
the
async
flow.
The
orders
are
relevant.
It
will
always
get
the
right
one
for
that
async
context,
and
this
is
particularly
useful
for
application
performance
monitoring,
and
there
are
also
discussions
within
the
project
at
the
moment
about
whether
it's
the
right
time
to
elevate
async
local
storage
to
stable
status.
A
The
diagnostics
channel
module
provides
an
api
to
create
name
channels
to
report
message,
data
for
diagnostic
purposes,
and
the
intention
is
that
you
create
numerous
channels
to
report
your
messages
through
and
then
you
can
subscribe
to
receive
those
messages
and
the
use
case.
For
this
is
say
you
have
an
app
that
runs
some
sql
queries.
A
You
could
create
a
dedicated
channel
for
those
to
be
pushed
to
and
you
could
subscribe
to
that
same
channel
to
receive
them
and
just
like
call
out.
This
was
recently
brought
back
to
the
note
14
release
line.
So
the
latest
note
14
release
will
include
this,
and
then
we
have
the
experimental
inspector
module.
As
the
name
suggests.
This
module
provides
an
api
for
interacting
with
the
va
inspector
and
in
this
example,
we're
using
the
inspector
module
to
interact
with
the
inspector
programmatically
to
profile
cpu
and
the
way
you
use
this
you've
required
modules.
A
A
Similarly,
we
have
the
experimental
trace
events,
module
and
this
module
provides
a
mechanism
for
you
to
centralize
tracing
information
generated
by
v8,
node
core
and
even
your
own
application
code
and
again
it's
a
case
of
importing
the
module
enabling
and
disabling
the
trace
at
the
appropriate
point
in
your
code,
and
the
output
of
this
will
be
a
trace
log
file
that
you
can
open
in
the
frame
tracing
window,
and
then
we
have
the
experimental
web
crypto
api.
This
is
an
implementation
with
the
node
of
the
web
crypto
api.
A
A
A
So
you
can
optionally
supply
your
own
custom
loader
and
it
will
customize
how
the
atmosphere
modules
are
loaded.
Note
that
it
will
not
change
anything
to
do
with
how
common
js
modules
are
loaded
and
there's
actually
been.
A
new
team
kicked
off
within
the
project
to
focus
on
defining
the
specification
so
that
eventually
we
can
reach
a
stable
implementation.
A
This
means
that
english
script
modules
can
await
resources
causing
other
modules
to
import
them
to
have
to
wait
before
they
start
evaluating
their
body
and
what
are
the
use
cases
for
this?
Well,
these
are
some
of
the
use
cases
called
out
by
the
tc39
proposal,
and
that
includes
dynamic
dependency,
pathing
resource
initialization
and
also
dependency
fallbacks.
So
you
can
try
to
import
x
if
that
fails
in
port
white,
and
then
we
have
policies.
A
A
This
means
that
when
you
try
to
start
your
process,
these
checks
will
happen
and
an
error
will
occur
if
it
fails
to
check-
and
this
has
actually
been
the
nodejust
core
for
a
couple
of
years
now
then
there's
a
range
of
other
experimental
apis.
This
includes
the
buffer
blob
api
events.
Capture
rejections,
some
of
the
module
related
apis
under
the
vm
core
module
and
broadcast
channel
within
the
workers,
implementation.
A
A
And
then
we
have
some
very
experimental
features:
they're
hidden
behind
build
time
flags
to
use
these
features,
you'd
have
to
compile
node.js
yourself
from
source,
and
why
do
we
expose
some
features
in
this
way?
But
it's
predominantly
so.
We
can
work
on
crafting
the
very
early
implementation
details
of
the
feature
have
it
built
and
tested
in
rci
without
them
yet
being
released.
A
A
For
example,
if
a
security
issue
requires
us
to
make
a
breaking
api
change,
and
we
only
do
that
where
absolutely
necessary
how
do
features
graduate
from
experimental
to
stable?
Well,
it's
really
when
the
contributors
most
involved
in
the
feature
have
confidence
in
the
api
and
don't
believe
that
major
further
changes
are
likely.
A
A
A
And
there
are
a
number
of
new
stable
features
in
the
latest
releases.
These
include
abort
controller,
so
this
provides
cancellation
and
the
boarding
on
some
of
our
promise-based
apis
and
there's
an
ongoing
effort
to
incorporate
it
across
more
apis,
and
it's
also
recently
been
back
ported
to
note
14..
A
We
also
have
source
map.
V3
support,
source
maps
provide
a
method
for
translating
from
generated
source
back
to
the
original,
and
this
is
aimed
to
alleviate
some
of
the
observability
challenges
we
have
when
folks
are
using
alternative
flavors
of
javascript
like
typescript,
and
then
we
have
the
promisified
timers
api,
and
this
api
provides
an
alternative
set
of
time
functions
that
can
return,
promise
objects,
and
then
we
always.
We
also
have
v8
9.0,
and
it's
viral.
A
A
So
if
you're
interested
I'd
like
to
encourage
you
to
take
a
look,
try
out
and
provide
feedback
on
some
of
the
experimental
features
in
node.js,
maybe
don't
rush
to
use
them
in
your
critical
applications.
Just
yet,
with
that
I'd
like
to
wish
you
all
an
enjoyable
rest
of
the
conference,
I
look
forward
to
joining
you
all
in
the
q.
A.