►
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
Hello,
everyone
and
welcome
to
today's
webinar
Java
scripts
are
the
most
important
language
in
your
staff.
My
name
is
danielle
womble
and
I'll,
be
your
moderator,
I
work
on
the
marketing
team
here
at
NPM
and
I'm
excited
to
be
hosting
today's
session.
I'm
pleased
to
introduce
today's
speaker,
Lori
Voss
laureen's,
one
of
our
co-founders
and
chief
data
officer
here
at
NPM.
Lori,
has
been
the
driving
force
behind
the
survey
to
further
understand
the
amazing
things.
A
Developers
are
building
before
I
hand
it
over
to
Lori
I
have
a
few
housekeeping
items
to
cover
about
the
presentation
in
the
bright
talk,
webinar
platform.
First,
today's
webinar
will
be
available
on
demand
after
the
live
session
and
it
is
accessible
through
the
same
link
you're
using
now,
we've
also
added
some
attachments
which
are
available
through
the
attachment
tab
at
the
bottom
of
your
screen.
A
There
you'll
find
today's
deck
a
link
to
the
full
survey,
results
and
other
related
content
content,
including
a
blog
post
and
upcoming
webinar
next
I'd
love
to
hear
from
you
during
today's
presentation.
If
you
have
a
question
for
Lori,
please
feel
free
to
send
it
through
the
ask
a
question
tab
at
the
bottom
of
your
player.
We
will
be
answering
questions
at
the
end
of
the
session.
If
we
don't
get
to
your
question
during
today's
webinar,
we
will
be
sure
to
follow
up
with
you
afterwards
now
over
to
Lori.
B
Thank
You
Danielle,
hello,
everybody
thanks
for
coming
to
our
thanks
for
coming
to
our
webinars
being
the
first
one,
we've
had
in
a
long
time,
I
think
it's
been
the
first
in
two
years,
as
Danielle
said,
my
name
is
Lori
I'm,
the
co-founder
and
chief
data
officer
at
NPM
Inc.
Obviously
we're
going
to
have
a
Q&A
at
the
end,
but
if
there's
anything
that
you
want
to
get
in
touch
with
me
directly
about
those
are
my
contact
details.
B
So
what
are
we
going
to
be
talking
about
today?
Well
we're
going
to
be
talking
about
JavaScript,
which
is
obviously
a
huge
surprise,
but
specifically
we're
going
to
be
talking
about
JavaScript
being
the
most
important
language
in
your
staff,
I'm
going
to
talk
about
why
we
think
that
using
data
that
I've
collected
as
part
of
my
job
and
I'm
also
going
to
get
to
what
that
means
for
you.
So
let's
get
straight
into
it.
B
But
before
we
do
a
quick
word
on
our
sources
for
this
data,
I
use
a
bunch
of
different
places
to
get
data
and
I'm
use.
I
will
usually
mention
where
that
is,
but
our
two
biggest
ones
are
n
PMS
registry
data,
where
we
count
downloads
and
we
measure
trends
and
n
PM's
annual
survey
of
NPM
users,
which
got
over
33,000
respondents
last
year.
So,
if
you
don't
hear
me
quote
where
the
certain
data
is
coming
from,
it's
usually
one
of
those
two.
But
what
I'm
saying
here
is
that
we're
not
just
guessing
about
these
trends?
B
We
are
working
with
real
data,
so
the
first
thing
to
understand
is
that
all
signs
point
to
JavaScript
being
the
single
most
popular
programming
language
in
the
world
by
every
measure
that
we
can
think
of
here's
a
graph
from
the
module
counts
website
of
the
total
numbers
of
modules
in
major
package
managers.
The
NPM
registry
is
twice
as
big
as
the
next-biggest
repository,
which
is
maven.
Obviously
that's
a
little
bit
unfair,
because
javascript
tends
towards
lots
of
small
modules
and
the
other
package
managers.
Don't
so
how
about?
B
If
we
look
at
projects
created
on
github
here
again,
javascript
is
by
far
the
biggest
and
github
also
ranks
javascript
the
highest
in
terms
of
activity,
PRS
issues
and
all
of
its
other
measures,
but
that
just
means
there's
a
lot
of
activity.
What
about
the
actual
number
of
people
involved?
Stack
Overflow
recently
released
the
result
of
its
own
annual
developer
survey.
They
surveyed
over
80,000
developers
worldwide
and
from
that
amazing
trove
of
data
comes
this
graph
of
the
most
used
programming
languages.
B
Javascript
was
first
for
the
seventh
year
in
a
row
at
68
percent
of
developers
and,
of
course,
there's
our
own
stats,
which
say
that
NPM
has
about
11
million
users.
The
NPM
registry
serves
over
2
billion
downloads
per
day
and
it
has
grown
25.
Thousands
percent,
since
NPM
Inc
started
in
2014.
In
fact,
97%
of
the
code
in
a
modern
web
application
is
downloaded
from
NPM
you
or
the
developers
at
your
company
are
writing
just
the
last
3
percent
of
your
application
and
the
other
97
percent
comes
from
us.
B
Of
course,
NPM
is
being
used
by
far
more
than
just
web
applications
in
our
survey
results.
97
percent
of
people
who
use
NPM
said
that
they
were
using
it
to
build
web
applications,
but
77
percent
also
said
that
they're
writing
code
for
servers,
and
there
were
two
big
surprises
here.
46
percent
said
that
they
are
writing
native
apps
and
13
percent
said
that
they
are
doing
embedded
apps.
So,
let's
look
a
little
bit
more.
B
All
of
those
numbers,
the
75th
and
97%
of
NPM
uses
write
for
browsers,
but
browsers
where
99%
of
people
write
for
desktop
websites.
74
percent
of
people
write
for
mobile
websites,
but
only
2%
of
people
write
for
mobile,
but
not
desktop,
which
explains
why
responsive
web
apps
are
such
a
common
part
of
the
developer
experience
these
days.
B
The
survey
also
said
that
77%
of
people
are
writing
server
apps,
but
where?
Where
are
they
deploying
things?
Unsurprisingly,
containers
like
doctor
and
kubernetes
are
everybody
jammed
these
days,
deployment
platforms
like
Heroku
and
net
lafha
are
also
a
big
target
for
people.
Vms
virtual
machines
are
surprisingly
unpopular,
given
that
you
know
just
five
years
ago,
they
used
to
be
the
default
way
to
deploy
code,
and
the
other
surprise
here
was
service
at
33%,
lambda
and
other
cloud
function,
platforms
they're
not
just
for
early
adopters
anymore.
B
The
popularity
of
native
apps,
as
I
said,
was
a
big
surprise
to
us
46%
of
npm
users
when
there
are
11
million
npm
users
there's
so
many
people
to
be
writing
native
applications
in
javascript
one.
That's
really
not
the
you
know
purpose
the
java
script
had
in
mind
when
it
was
invented
by
native
apps.
We
mean
apps
that
run
directly
on
your
desktop
or
directly
on
your
phone.
B
This
graph
on
the
screen
is
the
split
within
that
46%.
So
if
you
take
that
46%
on
these
and
this
split,
you
can
work
out
the
overall
usage,
and
that
means
that
35%
of
NPM
users
are
writing
native
mobile,
apps
and
26%.
Are
writing
native
desktop
apps
in
JavaScript?
These
are
big
big
numbers.
If
you
write
native
apps,
you
are
no
longer
an
edge
case
in
the
JavaScript
world.
You
are
a
first-class
and
npm
wants
to
know
how
to
take
care
of
you.
So
looking
at
all
this
usage,
it's
worth
worth
asking.
B
How
did
all
of
this
happen?
How
did
javascript
go
from
being
a
toy
language
that
people
use
to
do
form
validation
to
the
world's
most
popular
programming,
language,
for
all
sorts
of
applications?
The
answer,
at
least
partly,
is
the
NPM
registry.
A
guy
called
Leo
meyerovich
did
a
study
a
few
years
ago
in
which
he
researched.
Why
people
pick
a
programming
language?
Was
it
the
features
of
that
language?
B
The
speed
was
it
that
their
company
forced
them
to,
but
the
number
one
reason
was
the
availability
of
open
source
libraries
that
helped
them
get
their
job
done.
If
there
is
a
library
that
does
what
you
want,
you
pick
the
language
of
that
library
to
get
your
job
done
faster
and
once
you
start
using
open-source
libraries,
a
positive
feedback
loop
kicks
in
developers
find
open
source,
JavaScript
libraries
that
help
them
get
their
jobs
done
faster.
They
find
them
on
the
NPM
registry,
they
install
them,
and
then
they
write
the
remaining
3%
of
their
applications.
B
They
ship
quickly
and
they
like
that
once
in
a
while,
like
1%
of
the
time
something
they
write,
turns
out
to
be
so
useful
that
they
want
to
be
able
to
use
it
again,
so
they
published
it
to
the
NPM
registry.
This
means
there's
even
more
open
source
on
the
registry,
which
attracts
even
more
people
until
you've
got
11
million
developers,
so
say
you
buy.
All
of
these
stats
you
buy.
The
JavaScript
is
super
popular
and
growing
super
fast.
That
still
hasn't
answered
the
question,
which
is
why
should
you
care?
B
Why
is
it
important
to
you
in
your
stack
today?
The
answer
is
because
you
are
also
using
exponentially
more
JavaScript,
maybe
ten
or
even
five
years
ago
you
only
had
a
handful
of
people
to
your
company
who
wrote
HTML
and
CSS,
and
maybe
some
JavaScript,
but
now
it
is
not
uncommon
for
a
large
company
to
have
hundreds
of
developers
who
do
nothing
but
write
javascript.
All
day
we
went
and
manually
checked
and
we
verified
that
all
one
hundreds
of
Fortune
100
are
using
the
NPM.
B
We
didn't
get
all
the
way
through
the
fortune
500,
but
we
haven't
yet
found
one
who
does
so?
How
much
JavaScript
are
you
using?
We
did
a
survey
of
several
major
financial
firms
and
on
average,
these
big
banks
are
actively
using
about
20,000
unique
NPM
packages,
each
they
download
each
of
those
packages
millions
of
times
every
month
and
banks
are
not
known
as
wild
early
adopters.
B
So
if
that's,
how
much
banks
use
NPM,
you're,
probably
using
even
more
and
one
thing
I
want
to
emphasize-
is
that
using
all
of
this
javascript
is
a
net
good
for
you.
Open
source
code
has
lots
of
users
and
will
frequently
be
higher
quality
than
anything
that
you
wrote
yourself
using
existing
code
helps
you
ship
faster
and
the
reason
all
these
people
use.
All
of
this
javascript
is
because,
generally
speaking,
a
good
idea,
but
it
is
not
without
costs.
B
Another
thing
we
found
when
we
looked
at
eight
of
the
largest
banks
was
that
they
download
a
lot
of
stuff.
It
wasn't
always
safe.
The
eight
banks
downloaded
over
22,000
unique
packages
which
is,
and
they
did
it
more
than
20
million
times
in
a
month
they
downloaded
824
packages
with
vulnerabilities
and
7%
of
those
vulnerabilities
were
critical.
B
Javascript
snuck
into
big
companies
one
day
with
a
little
form,
validation
and
the
next
thing
you
know
you're
spending
a
hundred
million
dollars
a
year
on
JavaScript
devs,
but
you're
not
yet
treating
it
like
a
language.
You
spend
that
much
money
on
it
takes
big
companies
a
while
to
catch
up
to
rapid
change,
like
we've
seen
in
the
world
of
JavaScript.
B
So
by
now,
I'm
hoping
I've
thrown
enough
numbers
and
graphs
at
you
that
you
believe
my
thesis,
which
is
that
javascript,
is
important
to
you.
But
if
you
believe
that
what
does
that
mean
that
you
should
do
it
means
that
it's
time
to
treat
JavaScript
the
same
way,
you
treat
other
vital
languages
in
your
stack,
it
means
spending
some
money
to
improve
the
efficiency
of
using
javascript
and
the
security
of
the
javascript
packages
that
you
use.
Unsurprisingly,
NPM
Inc
has
some
ideas
about
how
you
should
do
that.
B
The
four
key
points
of
professional
JavaScript
are
security,
compliance
collaboration
and
control
and
I'm
going
to
talk
about
each
one
and
what
it
means
to
do
it
professionally.
That's
going
to
involve
mentioning
NPM
Enterprise,
which
is
our
fast
service
for
company
to
use
JavaScript.
But
first,
let's
talk
about
security.
B
Other
languages
have
just
a
handful
of
dependencies
and
security
processes
were
built
for
them,
so
you
might
have
whitelist
or
back
blacklists
of
code.
You
can
and
can't
use.
You
might
be
reasonably
be
expected
to
fill
in
a
form
to
ask
to
use
a
new
library
in
your
project.
You
might
even
believe
that
your
team
would
find
the
time
to
review
the
code
of
an
open-source
package
before
they
use
it.
So
even
with
old
languages
that
was
frankly
a
stretch.
B
None
of
that
is
going
to
work
for
JavaScript
I'm,
not
just
guessing
here,
because
we
have
the
stats
and
also
you
told
us
directly,
you
use
20,000
unique
packages,
you
can't
inspect
them
all
and
you
can't
even
pretend
that
you
do
just
filling
in
the
forms
would
take
a
month
and
you
ship
hundreds
of
times
a
month.
So
there
can't
be
a
manual
anything.
You
can't
just
ignore
the
processes
and
hope
nobody
notices.
You
have
to
throw
out
the
broken
processes
and
adopt
best
practices
for
JavaScript
to
keep
up
with
the
pace
of
continuous
deployment.
B
You
also
have
to
adopt
continuous
security.
Npm
automatically
runs
a
security
scan
every
time
you
do
an
install,
and
you
may
have
seen
those
notices
when
you
did
that
with
NPM
Enterprise.
You
can
get
those
for
all
of
your
dad's.
Instead
of
a
big
security
fire
at
the
end
of
a
sprint,
you
can
notice
and
fix
things
as
you
go.
B
Npm
Enterprise
has
the
best
feed
of
JavaScript
vulnerabilities
in
the
industry.
Features
like
black
lists,
assume
that
your
team
will
hear
about
a
vulnerability
and
want
to
block
it
specifically,
but
in
reality
there's
no
chance
that
you'll
hear
about
a
vulnerability
before
we
do.
We
have
11
million
users
and
we
have
a
report--
vulnerability
button
on
every
single
page.
B
We
hear
about
things
sooner
than
anyone
else
and
NPM
Enterprise
has
a
live
feed
of
those,
and
if
you
build
of
NPM
Enterprise,
you
can
run
audits
on,
builds
and
configure
your
builds
to
fail
if
they
find
vulnerabilities
of
a
specified
severity.
So
you
can
treat
security
scans
as
part
of
your
test
suite
happening
each
on
on
each
and
every
build,
silently,
quickly
and
transparently.
B
The
story
with
compliance
in
JavaScript
is
another
story
of
abandoning
the
old
ways.
Again.
You
have
20,000
packages,
so
you
just
don't
have
the
internal
resources
to
be
doing
this
stuff
yourself.
You'd
have
to
create
lists
of
viable
licenses,
you'd
have
to
pay
lawyers
to
interpret
them,
and
the
situation
with
software
licenses
is
often
fog.
Is
that
the
license
in
package.json?
Is
it
the
one
in
license
context?
What
about
stray
bits
with
copy
pasted
code
that
other
life
that
have
other
licenses?
So
NPM
is
going
to
do
this?
B
For
you,
too,
we
are
currently
working
with
major
firms
to
define
rules
around
what
licenses
are
acceptable
and
accurately
classifying
existing
packages
so
that
you
can
have
continuous
compliance
along
with
everything
else.
I
talked
earlier
about
the
feedback
loop
that
is
propelling
JavaScript
to
the
stars.
The
reason
I
said
it
was
relevant
to
us
here
is
because
the
same
feedback
loop
can
be
used
power
productivity.
In
your
organization.
A
decade
ago,
your
company
probably
employed
only
a
handful
of
people
who
wrote
JavaScript
and
now
it's
likely
that
you
employ
hundreds
of
them.
B
If
you're
a
big
company
and
they're,
probably
writing
quite
similar
things.
They
need
to
be
able
to
find
already
written
code,
they
need
to
be
able
to
reuse
it
easily
and
they
need
to
be
able
to
publish
their
own
with
NPM
enterprise.
You
get
a
website
just
like
NPM,
j/s
comm.
You
can
see
new
packages
as
they're,
published
by
far
foreign
colleagues
all
over
the
world,
and
you
can
create
organizations
and
publish
things
either
within
your
team
or
for
the
whole
company
to
be
able
to
see
just
like
the
NPM
website.
B
You
also
get
full-text
search
of
all
the
public
packages
as
well
as
any
internal
packages.
Every
package
gets
its
own
page
with
a
full
readme,
so
you
don't
have
to
build
up
your
own
documentation,
site
and
package
pages
will
also
show
you
dependents
and
dependencies.
So
you
can
see
who
inside
the
company
is
using
the
software
that
you've
written
and
when
your
dad's
find
code
they
want
to
use,
they
can
just
install
it.
Just
like
any
other
NPM
package.
When
you
install
a
package,
you
don't
need
to
have
a
meeting.
B
You
don't
need
to
coordinate
release
cycles,
you
don't
need
to
satisfy
stakeholders,
you
just
install
the
thing
and
get
on,
and
the
great
thing
is
that
once
you've
installed
it.
If
the
people
inside
your
company
who
have
written
that
package
release
a
security
patch
you'll,
get
it
automatically
and
if
they
release
a
breaking
change,
you
won't.
This
isn't
some
special
new
functionality.
This
is
just
how
NPM
and
semantic
versioning
have
always
worked.
B
This
distributed
decoupled
way
of
developing
its
second
nature
in
the
open-source
world,
and
it
can
work
just
as
well
inside
your
company
increasing
the
velocity
and
quality
of
your
code.
So
all
of
what
I've
been
saying
so
far
sounds
pretty
great,
but
it
also
sounds
kind
of
like
letting
go.
I'm
saying
stop
trying
to
maintain
your
own
vulnerability
database.
Stop
auditing
your
licenses,
one
at
a
time,
take
the
breaks
off
of
your
internal
collaboration.
All
of
this
can
sound
great
to
developers,
but
to
managers
and
IP.
B
It
can
sound
kind
of
scary
the
problem
with
most
attempts
by
company
to
control
what
their
developers
do
is
that
things
get
adversarial.
A
new
tool
is
introduced
so
that
management
can
see.
What's
going
on
or
security
check
is
put
in
place
that
everything
has
to
run
things
through
and
it's
low
step
down
and
developers
hate
it.
But
even
worse
than
slowing
your
team
down
is
that
tools
that
claim
to
provide
control,
but
that
developers
hate
will
give
you
a
false
sense
of
security
developers
can
and
will
work
around
properties.
B
B
Npm
Enterprise
doesn't
have
that
problem
because
NPM
Enterprise
works
just
like
NPM
and
developers
using
NPM.
All
the
time
was
the
problem
you
were
trying
to
solve
in
the
first
place,
developers
love
NPM,
an
NPM
Enterprise
is
just
more
NPM
because
it
in
addition
to
all
of
the
public
modules
it
has
all
of
the
fun
internal
company
modules.
B
So
what
is
it
we
built
into
NPM
Enterprise?
That
gives
you
the
control
that
you
want.
The
first
and
most
obvious
is
single
sign-on
there's
an
S.
There
is
an
enterprise
software
management
tool
that
I
shall
not
name
that
people
actually
pay
money
for
we're
all
package.
Publishers
are
done
by
logging
into
a
single
box
and
publishing
as
a
single
user
and
I
am
frankly
astonished
that
anyone
puts
up
with
that.
B
Our
single
sign-on
works,
as
you
would
expect
any
single
sign-on
to
work.
It
works
with
any
OID
T
provider,
which
is
to
say
all
of
the
ones
that
you'd
expect.
So
you
don't
have
to
be
constantly
managing
your
users.
You
can
even
sign
in
straight
from
the
command
line.
You
just
run
NPM
log
in
and
it
will
open
a
browser
window
where
you
can
log
in
using
your
third-party
office
or
two
factor
auth
or
both
of
the
above.
So
you
and
you
can
require
a
second
factor
to
publish
once
you're
authenticated
in
the
browser.
B
You
also
get
full
visibility,
and,
what's
going
on
in
your
company's
local
NPM
community,
all
of
the
packages
published
every
user
authorized
and
free
invitation
sent
and
accepted
all
of
the
organizations
and
teams
created
and,
of
course,
your
NPM
Enterprise
instance
runs
on
its
own
dedicated
hardware
inside
of
Google's
cloud.
If
you
need
a
different
cloud,
you
can
come
and
talk
to
us.
It
will
run
in
the
legal
jurisdiction
that
you
need
with
strong
guarantees
of
network
and
data
isolation.
A
B
That
so
I
should
mention
the
other
solutions,
but
what
it
boils
down
to
is
this:
unless
you've
already
bought
our
thing,
you
do
not
have
a
thing
that
does
this
Java
and
JavaScript
have
similar
names,
but
using
a
tool
that
was
built
for
Java
to
manage
your
Java
Script
is
like
using
a
hammer
instead
of
a
screwdriver,
because
nails
and
screws
are
both
kind
of
pointing
this
is
the
real
NPM.
It
looks
like
NPM,
it
works
like
NPM
and
developers
love
it
like
they
liable
NPM.
B
So
obviously
it's
a
huge
surprise
that
a
company
recommends
its
own
products,
but
there's
a
reason
it's
good,
and
it's
because
we
focused
on
JavaScript
other
tools
will
try
to
be
all
things
to
all
languages
and
end
up
a
faffing
every
language.
Equally,
we
picked
the
most
important
language
in
your
stack
and
double
down
on
doing
it
properly,
because
it
really
is
a
surprise.
The
data
script
has
become
the
most
important
language
in
use,
but
now
that
that's
true,
you
need
to
focus
on
it.
B
So
to
recap:
javascript
is
very
popular.
It's
popular
for
web
and
server
and
mobile
and
desktop
apps.
You
probably
use
more
than
20
baguette
is
and
you
need
to
secure
them
and
you
need
to
ensure
compliance.
You
want
to
foster
internal
collaboration,
but
you
don't
want
to
lose
control
and
we
built
NPM
Enterprise
to
satisfy
those
needs,
and
that
concludes
the
webinar.
Who's
got
questions.
I
see
a
couple
questions
already
in
there.
B
A
B
Are
a
company
with
being
a
company
since
2014,
but
getting
that
message
out
to
the
world
is
something
we're
still
trying
to
do,
and
the
next
question
is:
will
you
be
doing
another
survey
soon?
Will
you
be
asking
new
questions
based
on
last
year's
finals?
Yes,
well,
this
is
actually
our
second
survey.
We
did
a
survey
in
December
of
2017
and
this
survey
was
done
in
December
of
2018
and
we
did
a
lot
of
refining
of
the
questions
that
we
asked
based
on
the
answers
that
we
got
to
that.
B
A
Great
Thank
You
Lori,
as
mentioned
earlier,
today's
webinar
will
be
available
on
demand
after
the
live
session
and
is
accessible
through
the
same
link
you're
using
now.
We've
also
added
some
related
material,
including
today's
slides,
which
are
available
in
the
attachments
tab
at
the
bottom
of
your
screen.
Don't
miss
our
next
webinar,
where
javascript
is
going
in
2019
next
week
on
Tuesday
air
booth,
April
30th
at
10
a.m.
Pacific
time
12
p.m.
Central
Time
in
1
p.m.
Eastern
Time.
Thank
you
for
joining.