►
From YouTube: Radical Modularity - Aria Stewart, npm, Inc.
Description
Radical Modularity - Aria Stewart, npm, Inc.
A
A
But
my
I'm
not
going
to
talk
about
n
p.m.
today
I'm
going
to
talk
about
a
particular
kind
of
modularity,
a
particular
way
of
writing
software
that
I
think
is
powerful
and
I'm
going
to
try
and
bring
few
new
ideas
to
how
we
break
up
software
projects,
and
I
think
that
it
actually
is
going
to
affect
how
we
interact
and
talk
with
each
other
as
well.
A
A
A
There's
a
separation
between
the
module
and
the
system
and
I'm
not
saying
how
far,
but
the
fact
that
there
is
a
separation
between
the
module
in
the
rest
of
the
system
is
an
important
distinguishing
feature,
and
we
can
talk
about
the
interface
and
I'm
going
to
get
into
that
later
and
there's
a
lot
of
kind
of
interfaces
to
software,
but
the
bit
that
I
think
is
really
interesting,
as
the
word
defined.
This
means
that
we've
made
some
decisions
regarding
this
module.
A
Here's
a
refined
definition,
a
piece
of
software
with
a
defined
interface
between
and
a
name
that
can
be
shared
with
others,
because
I
work
for
npm
and
I've
been
making
open
source.
My
entire
professional
career
I've
also
got
a
particular
bunch
of
things
that
I
mean
when
I
say
a
module.
I
won't
advocate
sharing
everything,
because
this
is
a
talk
on
radical
modularity.
Not
radical
openness,
but
sharing
is
an
important
part.
A
A
This
happens
when
we
name
a
file,
it
happens
when
we
name
a
package.
A
name
is
the
handle
we
can
grab
on
to
something
with
mentally
and
we
can
start
treating
it
independently.
A
defined
interface
is
the
first
step
of
that
independence.
It's
a
boundary
that
gives
the
thing
that
separation
from
its
internal
life
and
its
external
life
things
inside
a
module,
can
get
a
relationship
with
that
boundary
and
things
outside
of
it
get
a
relationship
with
that
boundary,
but
they
don't
directly
interact.
A
A
Now
not
every
module
gets
published
or
even
becomes
a
package
on
the
registry.
We
usually
push
things
up
to
github
really
early,
but
source
control
isn't
the
same
thing
as
publishing
a
module
for
others
to
consume,
even
if
they're,
both
just
ways
to
store
particular
sets
of
bytes,
even
just
separating
things
into
an
into
a
separate
file,
naming
it
and
that's
the
naming
and
choosing
what
constitutes
the
interface
to
the
rest
of
the
system
that
counts
as
module
is
a
shin.
A
Now
names
are
powerful.
We
can
commit
to
names
a
little
bit
more
firmly
when
we
publish
them
and
give
them
version
numbers
we've
actually
put
a
little
bit
of
effort
into
that,
and
but
that's
not
required.
A
module
can
exist
just
as
a
file
passed
around.
It
can
exist
as
a
file
inside
of
a
project.
Not
yet,
given
that
separate
life
entirely
self,
sustaining
open-source
projects
are
kind
of
an
interesting
thing
here,
because
they
have
to
be
bigger
than
a
tiny
module.
A
How
many
of
you
use
any
of
sub
stacks
modules,
everybody
in
the
room
probably
does
indirectly
or
how
about
one
of
Sandra's
or
SS
those
modules,
there's
no
single
open
source
project,
their
nose,
no
large
open
source
organization
driving
those,
and
so
those
modules
sit
with
the
attention
of
one
or
two
people
who
care
about
a
bug
in
them.
If
you
want
to
create
a
self-sustaining,
open
source
project,
you
need
a
bigger
unit,
but
that
doesn't
mean
that
you
have
to
have
a
mano
repo
and
a
giant
project
with
a
single
masthead.
A
A
A
few
ragged
edges
writes
a
few
test
cases,
or
maybe
they
left
in
a
library
box
or
somebody
else
to
discover
when
we're
not
using
them
anymore,
maybe
they're
published,
maybe
they'd
ly,
use
them
loved,
maybe
they're
just
sitting
there
in
the
registry.
For
that
one
person
who
needs
that
exact
piece
of
code.
Maybe
they
end
up
in
the
scrap
heap
for
our
late
ourselves
to
build
something
from
picking
a
name
for
a
small
module
is
easier
than
picking
a
name
for
a
big
module,
because
the
small
modules
name
is
generally
what
it
does.
A
A
Not
only
that,
but
then
the
explosion
of
social
openness
that
came
with
it
has
cated
kind
of
an
orthogonal
movement
to
the
free
software
movement,
but
it's
not
as
concerned
about
it
about
copyright
law
and
open
engineering,
but
sharing
ideas
and
techniques
and
as
a
side
effect
of
that
software
engineering
now
includes
the
practice
of
software
as
an
art,
I
practice
code
as
an
art.
In
addition
to
engineering.
A
That
means
that
quite
often
I'm
trying
to
make
a
statement
about
how
the
world
should
be
in
how
I
work
a
good
portion
of
art
is
making
concepts
visible
in
the
land
of
the
abstract.
That
means
making
it
named.
That
means
giving
a
thing
a
name,
so
you
can
discuss
it
and
it
becomes
a
thing
you
can
interact
with
and
experience.
A
We
can
create
a
module
of
code
only
to
abandon
it
later.
It's
actually,
okay,
once
it
served
its
purpose.
It's
okay
to
let
things
go.
People
complain
about
dead
code
on
the
NPM
registry,
but
those
are
old
projects.
Quite
often
they're
pieces
of
old
ways
of
developing
and
the
historians
among
us
are
actually
they
find
a
few
gems.
Their
old
projects
that
you
can
actually
reconstruct
things
from
the
note
at
two
days
and
they
still
work
if
you
get
the
right
runtime.
A
We
have
to
respect
the
tension,
though,
between
art
and
engineering.
Sometimes
we
do
things
to
show
instability
or
to
test
a
limit.
We
see
this
to
the
people
who
publish
security
exploits
as
as
a
module.
It
is
possible
to
do
damage
both
culturally
and
technically,
with
what
we
create,
and
sometimes
we
just
simply
create
to
delight
each
other
to
play
with
so
play
with
the
fashions
of
the
day.
A
One
of
the
interesting
differences
between
software
artifacts
as
a
medium
of
art
contrasted
with
all
of
the
other
kinds
of
art,
is
that
despite
working
and
kept
in
a
very
definite
medium
bits
are
absolute.
What
we
make
is
never
finished.
It
exists
in
our
culture
and
software
creation
is
totally
a
culture,
it's
a
culture
of
its
own
and
as
web
workers
in
particular,
working
and
working
as
artists.
A
A
A
But
what
I
want
to
ask
today
is
what
happens
when
you
make
everything
a
module?
What
happens
when
you
break
off
all
of
the
pieces
that
you
can
and
publish
them,
where
that's
appropriate
and
share
those
names
and
let
others
wield
the
power
of
those
pieces
of
code?
What
does
this
do
to
our
culture
as
programmers.
A
Now
I'm
going
to
get
to
practical
for
a
moment,
I
talk
about
NPM
a
lot,
but
this
can
actually
be
extended.
Majha,
loot,
breaking
things
into
node
modules
is
not
the
only
way
modular
I
software
api's
can
be
modular
component
systems.
Even
design
can
be
modular
start
trying
to
think
in
modules.
What
is
the
boundaries
between
these
things?
A
But
when
I
started
a
10pm,
we
had
a
monolith
of
old
CSS
built
up
the
kind
of
growth
by
accretion
that
you
get
during
most
web
software
projects,
especially
during
a
hurried
start
up.
A
lot
of
styles
that
were
positive.
We
were
were
unused
and
a
lot
of
pieces
and
parts
that
dependent
upon
each
other.
Since
then,
and
with
a
huge
shout
out
to
Nicole
Sullivan
and
a
huge
body
of
work
on
this
seriously
go
watch
her
talk.
Our
best
practices
are
killing
us.
A
If
you
work
with
CSS,
we
started
tearing
apart
the
site
and
rebuilding
it
and
get,
and
we
actually
modularize
our
CSS.
We
break
it
out
into
actual
separate
node
modules,
and
these
modules
have
defined
interfaces
between
each
other.
This
piece
provides
this
kind
of
a
class.
This
piece
requires
this
other
kind
of
class
to
be
present.
A
A
It's
a
pretty
simple
module
that
just
scans
through
your
node
modules,
folder
and
concatenates
all
of
the
pieces
in
dependency
order
when
it
finds
styles
in
them,
it's
kind
of
a
inelegant
tool,
but
it
works
pretty
well
for
us
and
we've
actually
annotated
those
dependencies
into
the
CSS.
So
the
the
tables
module
requires
the
basic
Styles
module.
The
dialogue
boxes
component
requires
the
rest
and
we
started
being
able
to
grapple
these
things
individually.
A
We
can
actually
identify
when
these
modules
go
unused,
because
they're
small
enough
and
achievable
pieces
that
we
can
say
we
aren't
using
that
piece
anymore
and
we
actually
have
something
to
refer
to
rather
than
lines.
97,
33,
36
and
1200
onward
are
unused.
So
it's
much
easier
way
to
deal
with
things.
I
just
another
tool
called
post
CSS
import
that
lets.
You
extend
the
import
statements
in
CSS
and
to
use
the
monoid
module
system
and
that's
actually
really
powerful.
I.
Think
I,
like
this
approach,
a
little
bit
better
than
the
one
we're
using.
A
So
we
may
abandon
dr.
Frankenstein
at
some
point
and
switch
over
both
of
these
systems.
Do
one
really
interesting
thing
is
that
they
they
follow
local
references
inside
the
modules
that
are
published,
and
so
you
can
actually
include
assets
in
these
packages.
So
when
we
install
CSS
that
require
image
files,
those
image
files
get
moved
into
our
final
build
folders
along
with
it,
so
that
we
can
end
the
references
adjusted
so
that
they'll
stay
valid
in
another
context.
A
That's
super
powerful
now
because
we
can
actually
get
those
images
and
that
dependency
between
those
pieces
abstracted
away
and
they
become
part
of
the
module
and
not
part
of
our
day-to-day
interactions
with
it,
and
we
don't
have
to
think
quite
so
hard
about,
what's
required
to
run
this
particular
piece
of
code
and
by
reducing
that
API
surface
area,
we've
made
things
more
reliable
as
we're
developing
now
CSS
has
pitfalls.
It's
still
a
single
global
browser,
namespace,
a
single
heap
of
rules
to
apply,
and
it's
not
a
clean
interface.
There
is.
A
But
what
happens
if
we
extend
this
into
other
file
formats?
Svg
files
can
have
local
references.
They
don't
actually
work
everywhere,
because
their
security
concerns
and
a
lot
of
unimplemented
features
and
browsers
where
it
won't
chase
these
references,
because
it
nobody
has
done
the
work
to
make
sure
that
they're
secure
in
the
context
they
would
be
executed.
So
there's
a
lot
of
missing
features,
but
we
can
use
pre
processing
tools
too.
A
So
what
if
we
were
to
break
up
large
animations
into
small
modules,
a
single
sprite
here
singles
right
there
and
include
them
by
local
reference
and
then
build
build
up
a
larger
and
larger
system.
Here.
What
is
the
interface
to
an
SVG
file,
the
text
of
it,
the
parched
HTML,
just
the
filename,
a
10pm?
We
actually
use
our
icons.
We
actually
post
process
icon
files
into
we
can
both
in
line
them
into
the
HTML
and
do
a
lot
of
caching
so
that
we
we're
no
longer
using
CSS
fonts.
For
this.
A
Now
we
don't
just
build
raw
HTML
anymore,
we'll
use
template
existence
to
break
our
HTML
apart,
we've
already
not
learned
to
modularize
HTML,
but
in
the
process
of
reworking
the
NPM
website,
we
had
components
whose
CSS
was
the
the
interface
to
that
was
the
HTML.
You
had
to
create
that's
a
fragile
interface.
Every
time
we
changed
what
HTML
was
required
to
instantiate
the
component.
That
component
required
a
major
breaking
change
and
we
had
to
update
all
of
the
colors
so
that
all
of
the
users
of
that
module.
A
If
by
putting
the
templates
inside
of
a
module,
we
can
now
move
that
boundary
inside
that
system,
and
now
the
color
just
calls
a
single
hidden.
In
our
case,
it's
the
handlebars
template
and
by
calling
just
the
template
as
if
that's
the
defined
interface,
we
don't
have
to
think
about
the
specifics.
Combining
the
CSS
in
the
template.
A
You'll
remember
that
IRA
mentioned
SVG
icons.
It
turns
out
that
in
lining
small
icons
is
one
of
the
most
efficient
ways
to
use
them,
but
it
doesn't
scale
very
well
in
development
process
if
you're
actually
manually
inlining
the
alternatives
of
icon
fonts
are
really
kind
of
brittle.
You
have
to
do
a
lot
of
hacking
to
make
it
work
with
all
of
the
different
runtimes.
A
A
And
then
there's
something
that
happened
to
an
our
ecosystem.
How
many
of
you
feel
like
react
to
something
that
just
happened
to
you,
like
it
kind
of
it
just
came
up
out
of
nowhere.
Okay,
there's
a
few
react.
There's
a
reason
that
react.
Talks
have
been
really
popular
for
the
last
couple
of
years.
It
really
did
make
a
radical
shift
in
how
we
design
web
frameworks
it
really.
It
was
a
very
provocative
module.
A
But
more
importantly
than
all
of
the
functional
programming
and
things
that
has
brought
it
actually
brought
a
lot
of
talk
about
modularity
it
did
this
covertly
it
nobody
ever
thought
say
we
want
react
because
we
want
modules,
but
what
it
did
was
by
breaking
things
out
into
es6
components.
In
particular,
we
now
have
people
publishing,
react
components
on
the
registry
in
rather
quite
a
large
number,
and
they
have
a
rich
interface.
They
have
a
there's.
A
programmatic
interface
now
to
HTML
that
can
be
is
flexible
enough
that
we
can
find
a
durable
interface.
A
A
A
A
One
team
can
create
one
module
and
another
team
can
create
another,
and
as
long
as
there's
a
communication
about
the
boundary,
it
gives
both
the
freedom
to
innovate
within
their
space
without
having
to
consult
the
other
teams,
and
this
led
to
a
lot
of
folks
at
PayPal,
doing
a
lot
of
interesting
internationalisation,
work,
breaking
the
files
up
separately
and
having
separate
life
cycles
and
separate
workflows
and
referring
to
them
by
name.
We
were
able
to
scale
up
that
process
and
simplify
how
much
we
worked
on
it.
A
We
can
even
make
modules
that
are
nothing
but
known
good
configuration
of
other
modules
combined
and
tested,
but
that
last
one
on
the
list
is
really
interesting.
Kyle
Mitchell
is
a
lawyer.
He
work.
He
does
a
little
bit
of
work
for
NPM,
but
he's
a
lot
of
soft
ferns
work
to
draft
legal
texts
and
in
so
doing,
he's
published
a
lot
of
tiny
modules
on
the
registry,
mostly
they're,
JSON
files.
A
A
module
can
be
as
simple
as
just
a
JSON
file,
but
they
are
cleanly
licensed
and
well
versioned
pieces
of
legal
language
that
he
uses
to
build
up
contracts
in
to
fill
forms,
and
they
are
he's
using
tested,
tried,
phrasings
and
storing
them
in
a
place
that
other
he
and
others
can
refer
to
sounds
kind
of
familiar
in.
Like
software
development
right
text
itself
can
be
a
module
with
an
interface,
even
if
that
interface
is
just
that
you're
going
to
have
to
take
this
bit
of
text
and
concatenate
it
to
make
sentences.
A
But
now
I
can
actually
show
you
how
to
make
a
modular
system
how
to
exploit
the
node
resolve
or
algorithm
to
build
something
that
gives
you
this
kind
of
power
that
we've
got
from
node
modules
and
take
it
to
other
languages
in
other
contexts.
The
kind
of
the
underappreciated
feature
of
node
modules
is
that
they
nest
this
really
bugs
the
windows
users
back
with
NPM
too,
and
you
ended
up
with
those
really
deep
paths
that
you
couldn't
delete
now.
Np
m3
has.
A
Unnecessary
solve
module
which
will
look
up
a
file
in
a
package.
It
doesn't
matter
where
that
package
is
relative
to
the
calling
code.
It
does
the
work
needed
for
that.
This
will
look
up
the
Bologna
SVG
file
and
the
lunch
and
meet
the
mad
science.
Luncheon
meats
package
and
it'll
find
it
a
matter
where
it
got
in
the
tree
and
that's
our
primitive
building
block
for
building
a
modular
system.
A
There's
no
other
things.
That's
common
to!
Do
you
add
a
field
to
package.json
that
for
a
different
kind
of
file,
dr.
Frankenstein
looks
at
the
style
property
rather
than
the
main
property
in
the
package.json.
So
now
a
package
can
be
two
kinds
of
module
at
wants.
It
can
be
both
javascript
code
and
it
can
include
the
related
CSS
all
in
one
package,
so
we
can
actually
make
some
guarantees
in
our
module
loader
that
the
dependencies
will
be
isolated.
They'll
be
duplicated
as
much
as
possible
that
local
paths
are
relative
to
the
file.
A
That's
the
important
one
if
we
can
and
that
there's
a
single
entry
point
I
love
that
the
local
mod
looked,
the
each
module
refers
to
things
by
local
paths,
because
that
means
that
you
no
longer
have
to
be
aware:
the
global
namespace,
when
you're
building
a
module,
you
can
focus
on
the
task
at
hand.
A
lot
of
people
thought
this.
They
wanted.
A
But
then,
if
everything
is
a
module,
what
can
we
do
with
that?
We
have
simplified
things
enough
to
start
giving
our
programs
of
vocabulary
to
start
extending
themselves
we're
starting
we're
starting
to
talk
about
building
software,
not
as
developers,
but
even
as
users.
Out
of
modules,
we
already
see
this
in
the
atom
editor
using
packages
stored
in
the
NPM
registry
and
we're
seeing
this
in
the
hyper
term.
An
entire
terminal,
editor
or
a
terminal
window
built
out
of
node
technologies
and
with
the
extensions
are
published
as
modules
on
the
registry.
A
Can
modules
be
remotely
and
or
even
remotely
loaded
packages
be
first
class
objects
in
our
system
that
we
refer
to
in
our
programs
or
what
about
generating
new
modules
as
a
user
builds
their
and
works
on
their
own
system
and
they
themselves
can
publish
their
extensions.
What
kind
of
interfaces
can
we
give
web
services?
How
do
we
apply
modularity
and
web
services
data
sets
with
guarantees
about
how
they'll
develop
in
the
future
there's
other
kinds
of
modules
here
and
how
radically
can
we
simplify
the
interface
of
something
so
that
it's
has
some
longevity?
A
One
of
the
most
influential
concepts
in
my
career
was
the
the
phrase
that
you
a
lot
of
her
about
eunuchs,
that
everything
is
a
file,
that's
a
lie,
but
there's
a
lot
of
things
in
UNIX
that
aren't
files,
IPC
and
system
calls
and
locks,
but
they're
the
key
concept.
There
is
that
with
a
very
tiny
primitive
if
everything
is
a
file
or
a
pipe,
that
is
a
durable
interface,
it's
going
to
last
a
long
time,
password
files.
A
A
Those
interfaces
are
durable
and
they
last
forever
system
calls
have
not
changed
a
lot
in
40
years
because
they
were
done
done
right
in
the
first
place
or
done
very
close
to
right
and
they
were
they
become
very,
very
durable,
I
love
to
pick
on
UNIX,
because
it's
got
so
much
ancient
craft
in
there,
but
that
it's
literally
one
of
the
elegant
systems.
Another
way
we
another
radically
simple
technique
for
modular
izing
came
from
the
rack
web
server
library
for
Ruby.
A
It
reduced
the
interactions
between
a
web
for
a
back
end
web
framework
and
the
web
server
to
a
single
function,
call
environment
variables
in
a
status
code,
a
body
out
and
by
reducing
it
to
that
single
function.
Call
it
took
off
very,
very
popularly
and
now
all
of
the
Ruby
web
servers
use,
rack,
node
streams,
they're,
very
generic,
primitive,
and
so
we've
seen
thousands
and
thousands
and
thousands
of
modules,
because
it
has
a
generic
and
relatively
simple
interface,
but
I
hope
you
learned
something
today
and
I
hope
you're
inspired
to
think
about
things
differently.