►
From YouTube: YUI In the Wild #11 with Simon Hojberg on ES6 Modules
Description
YUI Open Roundtables cover topics of interest to front end developers with an emphasis on YUI
A
A
B
A
B
Okay,
so
just
yeah
kind
of
puts
these
in
a
weird
order
that
not
the
order
that
you
create
them
in,
but
that's
weird
anyway.
So
this
is
an
example
of
a
good
old
school
yui
model,
a
simple
module
that
uses
another
module
called
my
other
model,
there's
a
comma
missing
there,
but
you
get
the
gist
and
es6
module
that
this.
This
module
in
es6
would
look
like
this.
Instead.
C
D
E
B
B
B
C
B
D
D
I
think
it
works
because
we
kind
of
made
it
made
it
work,
but
I
think
your
ways
is
a
bit
more
correct
in
the
in
the
sense
that
you
don't
expect
it
to
be
a
named
export.
You
just
assume
it's
in
the
y
yeah,
okay,
exactly
and
as
as
we
live
in
this
like
middle
ground
between
yui
and
es6
modules.
I
think
it's
the
right
way
to
go.
C
You're
on
irc
right
simon,
yes,
here
I'll
paste
in
why
the
yui
channel
something
you
can
open.
If
you
want
to
click
on
that
tab,
it's
what
I
was
so
see
at
the
top
there,
okay
and
then,
and
then
you
you
can
see
it
used
on
line
five
there
right-
and
in
this
case
I'm
I'm
using
base
dot
build
because
I
know
I
want
the
create
function
off
of
the
base
module.
C
B
A
B
Right
so
I
work
for
swipely
swipely
is
we
process
payments
for
restaurants
and
and
smaller
brick
and
mortar
shops
or
medium-sized
brick-and-mortar
shops,
and
provide
a
bunch
of
analytics
for
them?
We
kind
of
like
provide
e-commerce
analytics
type
things
for
for
a
brick
and
mortar
thing.
Payment
processing
give
give
the
the
customers
our
merchants
a
very
good
insight
into
to
how
to
run
their
business
and
how
to
improve
so
so
that
is
the
portal
they
have.
B
We
call
the
portal
is
a
single
page
application
using
yoi
we're
also
using
some
some
react
yeah
we
just
started
using
es6,
so
we
have
it's.
It's
fairly
large
we've
been
working
on
it
for
a
few
years
now,
and
I
think
when
I
tweeted
this
originally,
I
said
we
had
535
modules,
which
probably
is
those
correct
or
thereabouts
and
yeah.
I
basically
had
to
change
by
hand
all
those
modules
to
this
from
this
to
to
year
6
and
it
took
a
while,
but
was
totally
worth
it.
B
C
Well,
no,
I
I
just
meant
like
so
so.
A
cool
thing
I've
been
seeing
is
some
there's
been
some
people
writing
build
tool,
wrappers
that
that
will
analyze
your
modules
using
like
esprima,
which
is,
I
believe,
what
the
square
transpiler
is
currently
using
to
understand
what
all
the
imports
are
and
but
then
look
at
your
entire
set
of
modules
that
you're
compiling
and
make
sure
there's
something
that
exports
those
those
things.
C
Basically
the
graph
and
actually
one
has
been
working
on
something
similar
to
generate
a
graph
of
all
the
imports
and
exports
which
then
you
can
go
through
and
do
like
a
verification,
step
and
just
flag
like
even
at
build
time.
Saying
oh
there's
going
to
be
a
problem
in
this
module
you're
asking
for
something
that
it
doesn't
export.
You
know
those
kind
of
things.
B
B
F
That's
a
cool
idea
yeah,
although
I
think
to
be
able
to
use
such
tools
to
do
that,
verification,
probably
you
will
have
to
use
relative
path
or
something
to
differentiate
modules
that
are
coming
from
yui
from
modules
that
are
coming
from
your
application.
That
would
be
tricky.
So
I
wonder
what
on
line
number
four
on
that
file
that
you
have
up
and
there
normally
what?
What
you're?
Assuming
that,
why
it's
going
to
be
there
and
it
is
going
to
be
there,
you
compile
to
yui,
but
it's
not
going
to
be
there.
F
F
B
B
But
but
yeah
I
mean
we
have
a
bunch
of
places
where
we
like
differ
slightly
in
syntax
from
others
like.
Sometimes
we,
instead
of
having
assigning
my
model
to
a
variable
here,
we
assign
it
directly
to
y
dot
my
model,
like
there's
a
bunch
of
bunch
of
variations
that
are
possible.
That
makes
it
a
little
bit
more
challenging
to
write
something
that
that
converts.
It.
B
Well,
okay,
so
that's
a
great
question.
I
think
I
think,
moving
to
es6
modules
right
now
is
a
no-brainer
for
for
any
application
that
there's
no
doubt
that
this
in
some
way
or
another,
will
be
in
the
in
the
language
natively,
and
there
are
tools
now
that
enables
us
to
to
get
started
right
away
so
yeah
we
just
felt
like
okay,
this
is
cool.
Let's
just
jump
on
board.
E
F
A
F
Does
it
work?
Okay,
yeah?
I
was
saying
that
well,
obviously,
you
are
now
in
a
much
better
position
because
you
happen
to
use
some
pieces
from
yui,
but
your
entire
application
is
now
yui
specific.
You
can
compile
in
the
future
to
something
else.
You
have
replacement
for
those
bits
from
yui
you
you
will
be
able
to
to
to
produce
an
application
that
is
not
tied
to
you
at
all.
B
C
B
F
D
B
D
B
F
F
The
one
of
the
reasons
why
using
the
destination
is
is
good
because
you
can
gather
files
from
different
places
and
do
build
process
to
put
them
all
into
the
same
folder
and
then
analyze
the
folder
and
get
the
graph
for
the
folder.
That's
that's
probably
one
of
the
good
reasons
of
doing
that,
but
in
the
future
we
might
want
to
use
the
source
for
for
different
reasons,
including
the
one
that
one
mentioned.
F
B
C
So
one
other
just
one
other
point
about
this-
is
that,
with
with
the
way
that
that
you're
doing
this
and
the
way
that
you've
done
this
in
the
past-
and
I
know
like
pat
cabot,
I
believe,
has
something
similar
it.
You
have
to
execute
all
of
the
code
to
do
this,
like
you
actually
have
to
run
it
to
run
through
all
the
functions
of
the
yui
add
calls,
whereas,
with
the
doing
it.
B
C
Sure,
but
I
guess
what
you
have
to
do
is
actually
execute
the
yui
ad
call,
whereas
with
the
es6
modules
you
just
have
to
parse
them,
you
don't
actually
have
to
run
any
code,
which
is
which
should
in
theory,
be
be
faster.
Maybe
because,
like
the
parse
step
should
be
you'd
have
to
happen
in
v8,
just
like
it's
going
to
have
to
happen,
and
yes,
prima
or
whatever,
assuming
v8s,
is
probably
faster,
but
but
but
then
you
have
to
do
this
additional
thing
of
executing.
So
that's
another
thing.
C
I
guess
that
of
the
static
analysis.
Aspect
of
the
es6
modules
is
a
nice
benefit
that
we,
you
know.
Eventually,
all
the
tools
can
start
leveraging
better
like
js
hint
could
tell
you,
in
your
editor,
like
oh
you're,
trying
to
import
something
that
a
name
that
this
other
module
that
you're
trying
to
bring
it
in
from,
doesn't
actually
export
it.
And
then
you
can.
You
know,
imagine
that
happening
at
some
point.
D
Right
so
yeah,
it
should
be
fast
enough
for
something
like
jslin
to
to
do,
but
but
but
also
like
in
the
case
that
I
was
just
saying.
If
you're
compiling
to
come
on
js,
then
there's
no
callback
there
and
you
can't
actually
run
anything
without
running
the
code
which
may
have
some
implications
so
yeah.
So.
F
You
do
you
do
right.
You
can
always
create
a
context
and
execute
in
that
context,
which
is
what
we
do
by
the
way
in
yeah
or
stuff
yeah,
but
but
yeah.
I
think
point
I
can
put
point
take
it
that
in
the
future
we
might
want
to
use
the
source
and
add
more
things
like
code
code,
decode,
elimination
and
crazy
stuff
that
we
can
do
later
on
with
the
statical
verifiable
files
that
you
will
have.
C
D
D
C
H
C
A
B
C
C
This,
like
walled
garden,
essentially
that
that
yui
really
is
it's
forces
people
into
in
a
way
and
and
really
try
to
open
it
up,
so
that
code
written
as
es6
modules
can
be
easily
used
within
yui,
and
this
is
the
whole
in
understanding
imports
explicit
imports,
explicit
exports
having
the
require,
which
is
somewhat
similar
to
like
what
will
eventually
be
system.import
in
in
browsers
and
and
and
really
getting
getting
to
that
point
and
then
in
terms
of
leveraging
other
es6
features.
I
I
think
what
we'll
look?
C
What
I
don't
imagine
is
us
like.
If
we
were
to
go
through
and
rewrite
all
of
our
all
the
yui
modules,
we
probably
try
to
use
some
tool
to
do
it
just
because
then
we
would
try
to
work
on
something
that
then
other
people
can
use.
So
we
would
spend
probably
way
more
time
than
you
did
trying
to
get
the
tool
to
work
where
we
could
just
go
through
our
like
100
modules
or
whatever
by
hand
and
do
it
quicker.
C
But
but
that
way,
then
it
can
scale
out
to
other
teams
being
able
to
use.
So
I
think
we
would
want
to
look
at
things
like
that
if
we
were
to
convert
code
over
but
then
in
terms
of
leveraging
a
lot
of
the
new
features,
the
one
thing
that
we're
probably
not
going
to
be
switching
yui
to
to
doing
all
that.
C
I
forget
if
we
figured
out
if
there's
a
roadblock
for
that
or
not
but
yeah,
so
so
stuff
like
that
is,
is
really
what
we're
we're
thinking
and
then
one
one
of
the
things
that
we've
we've
realized
from
yui.
That
I
think
we
want
to
move
past
and
other
code
that
we're
working
on
other
libraries
is
to
embrace
more
using
polyfills
and
using
standard,
built-ins
and
polyfilling
them.
If
they
don't
exist,
then
creating
these
wrapping
apis,
like
we
have
like
wide
out
array
dot
each
and
the
problem
is,
is
once
you
have
code.
C
That
starts
depending
on
that.
You
have
this
like
hard
dependency
on
all
of
all
of
yui,
and-
and
you
see
this
happening
in
like
in
the
node
community,
with
underscore
low
dash
where
people
are
just
wanting
to
use
like
a
merge
function
and
they
they
pull
in
all
of
low
dash.
Well,
there's
going
to
be
object
out
of
sign
or
merge,
or
what
is
it?
What
is
the
standard
thing
that
it's
called
extend
a
sign
so
far?
I
think
yeah
and
so
object.
C
If
you
care
about
non-es5
browsers,
for
instance,
would
be
one
thing
and
and
that
way
you
start
removing
these
like
very
basic
dependencies,
that
you
have
on
yui
start
using
more
of
the
bigger
stuff.
But
then,
like
maybe
class
syntax
comes
around
and
you're
realizing
that
you're
really
just
using
maybe
bass,
because
you
want
to
write
classes
in
a
slightly
more
convenient
way.
But
maybe
you
want.
C
Question
yeah,
but
in
terms
of
like
us,
going
through
all
the
yui
code
and
rewriting
it
all
to
do
that,
I
don't
think
that
there
will
be
like
that
big
of
a
win
of
doing
that.
I
think
what
what's
more
important
is
for
application
code.
That
depends
on
yui
to
be
doing
that
kind
of
work
and
rewriting
work
like
you're.
A
B
C
I
think
that
that's
that's
a
good
thing
and,
and
the
standardization
process
causes
like
a
lot
of
these
compatibility,
interoperability,
things
to
be
figured
out,
and
that's
really
what
what
I
think
we
would
want
to
encourage
people
to
do
and
try
to
make
sure
yui
can
help
with
making
sure
that
people's
application
code
bases
are
very
interoperable.
So
when
you
choose
yui
is
sort
of
the
main
thing
you're
you're,
building
your
application
around,
because
you
like
the
loader
you
like
having
modules
you
like
all
the
other,
tooling
and
documentation
stuff.
C
Yeah,
that's
that's
kind
of
what
I
mean
it's
it's
tbd
at
this
point,
but
but
that
that
seems
like
the
path.
A
lot
of
the
path
forward
is
to
instead
of
new
features
being
added
as
globals
or
on
the
global
object
that
they'll
become
modules
themselves.
So,
if
you
want
to,
you
know,
use
some
new
feature
like
big
num
or
any
any
of
these
kind
of
other
things
you
could
expect
being
added
under
modules.
You
would
just
import
them
in
your
code
and
so
so
yeah.
That's
that's!
C
C
Okay,
well
in
terms
of
the
the
node
stuff,
I
mean
they
they
they
are
also
going
to
be
dealing
with
this
backwards.
Compatibility
thing
so
require
a
node.
It
seems
like
it's
going
to
be
sticking
around,
that
it's
unlikely
that
they
can
get
rid
of
that
they.
It
would
be
probably
the
demise
of
the
entire
project
or
platform
that
they
did
so
they
would
have
to
maintain
it
in
some
fashion.
C
But
what
would
be
great
is
that
that
was
implemented
on
top
of
of
es6
modules
or
those
were
at
the
core,
and
there
may
be
some
new
api
for
interacting
with
things
that
way
and
that,
and
that
would
be
almost
really
similar
to
like
what
we're
doing
in
yui.
Is
you
know
you
can,
but
they
would
be
able
to
make
it
just
work.
C
So
that's
pretty
important,
I
think,
for
the
longevity
of
node
for
that
to
be
the
case,
because
the
language
is
going
to
be
changing
a
lot
in
es6
and
es7
once
all
these
features
are
implemented
and
for
node
to
not
have
those.
Now
it's
going
to
feel
like
you
know
the
ie
of
javascript
development
or
you
can't
use
all
the
new
shiny
and
fancy
things
and
solve
the
problems.
The
way
that
you
do
in
the
other
runtimes
right.
It's
usually
the
reverse.
C
Now,
where
it's
really
nice,
that
hey
you
can
assume
that
it's
only
is
every
every
node
process
is
an
es5
runtime.
So
that's
great!
You
have
to
worry
about
silly
things
like
not
being
able
to
loop
over
arrays
before
each
and
just
very
basic
things
that
you
can't
do
in
the
browser
if
you
care
about
old
ie.
So
that's
one
thing
that
I
that
I
hope
to
see.
C
F
Users
will
all
developers
will
start
using
something
like
system.import
and
they
will
be
able
to
import
esx
modules
natively
if
it's
supported
by
eba
directly,
but
then
having
a
a
system.info.
That
also
knows
how
to
recognize
that
this
module
is
really
not
a
yes
motor,
but
a
legacy
come
on
js
module
and
go
and
get
it
for
you
and
support
that
interoperability
between
them.
But
we'll
see
what
happens
in
the
future.
F
The
other
way
around
is
going
to
be
pretty
messy,
because
we
we
have
tried
with
the
transpilers
and
all
that
it
is
going
to
be
messy,
so
hopefully
that
that
will
be
the
way
like
just
people
relying
on
system
import,
just
in
the
same
way
that
they
will
do
it
on
the
on
the
browser
using
system
import
as
well
pause.
It.
A
B
Yeah,
like
I
said,
the
biggest
problem
we
really
ran
into
was
places
where
we
did
not
explicitly
have
requires
in
place,
because
we
simply
forgot
them
and
the
system
worked
because
some
other
module
required
them.
So
that
was
a
very
big
gotcha
for
us
that
yeah
provided
a
bunch
of
problems
yeah
other
than
that
it
was
just
mainly
just
a
lot
of
manual
work,
just
kind
of
just
converting
things.
Luckily,
we
had
all
our
modules
were
were
named
as
the
folder
structure,
but
using
colons
instead
of
slashes.
B
I
think
the
version
we
picked
up
when
we
started
using
yui
didn't
support
slashes
in
the
module
name.
So
that's
why
he
had
colons.
So
a
lot
of
work
was
just
replacing
that
with
slashes,
so
that
was
simple
instead
of
having
to
like
figure
out
exactly
to
convert
like
a
very
simple
module
name
to
a
full
path,
and
I
think
the
file
path
is
what
the
es6
module
transpiler
does
by
default.
I
think
you
can
supply
it
an
actual
name,
but
I
haven't
looked
into
that.
F
Yeah,
you
are
way
better
at
this
point,
because
now
you
can
start
using
recast
to
continue
modifying
those
those
modules
and
make
them
to
use
new
features
and
potentially,
like
eric
said,
like
the
classes
and
stuff
like
that,
you
can
now
start
using
recast,
because
you
are
now
just
a
yes
module
and
that
would
be.
That
would
be
pretty
easy.
I
guess.
B
F
You
can
do
whatever
you
want
there,
but
but
I
mean
like
what
I'm
trying
to
say.
The
the
big
overhead
here
is
for
people
to
trans
to
to
go
and
change
all
the
source
to
get
into
the
state
where
they
can
have
es
modules
working
and
then
from
there.
It's
going
to
be
easy
for
everyone
to
just
simply
evolve
that
code
over
time
with
tools
and
and
things
like
recast.
B
C
Yeah,
that's
a
that's
why
I
think
it
that's.
I
was
curious
if
you
saw
like
a
lot
of
clear
patterns
that
came
out
of
at
least
your
source
code,
and
then
it's
interesting
to
hear
where
a
few
of
the
gotchas
were,
because
I
think
that
that
that
would
be
something
that
we
would
probably
you
know
we
could
invest
in
on
on.
Our
team
would
be
to
to
come
up
with
the
like
recast
script,
that
that
could
do
this
sort
of
thing
for
everybody
and
do
it
in
a
couple
of
seconds.
C
B
B
It
feels
awesome,
I
think
it's
it
took
a
while
to
just
get
rid
of
the
to
get
out
of
the
mindset
of
the
bars
at
the
top
of
your
file
or
top
of
your
function,
but
but
yeah.
Now
it's
just
natural
and
we
use
cons
way
more
than
we
use
lead.
Actually,
we
kind
of
use
cons,
that's
a
way
to
indicate
that
this
variable
is
immutable
or
whatever,
even
though
that's
not
true,
but
yeah.
H
C
Yeah
and
and
charity,
in
terms
of
your
your
question
about
the
the
classes,
I
think
that
they'll
probably
be
a
little
further
off
like
I
don't
know,
if
you
remember
at
the
last
just
a
39
meeting,
you're
just
talking
about
decorators
and
and
that
I
think,
will
be
kind
of
the
required
thing.
You
would
need
to
really
have
this
sort
of
hooks
and
feature
fidelity,
or
at
least
like
the
the
look
of
the
source
code,
that
somebody's
typing
can
match
better.
D
Yeah
yeah,
I
think
the
grayers
would
work
for
stuff
like
y
dot
attribute
but
like
assuming,
you
have
wider
attribute
if
you
wanted
to
use
class
syntax,
while
still
using
the
get
and
set
methods.
The
big
biggest
problem
is
still
like
already
set
like
bass.create,
and
I
think
he's
writing
that.
Maybe
we
can
get
away
with
a
way
of
using
es6
classes
to
generate
something
that
at
least
behaves
similar
to
basic,
create.
B
Yeah
sure
so
I
I
think
I
I
think,
there's
there's
no
reason
not
to
use
es6
modules
in
in
both
yui,
but
also,
if
you're,
if
you're
starting
some
new
library
that
you
want
to
open
source.
Like
you
see
it's
very
common
to
see
underscore,
for
instance,
exporting
two
different
module
systems
in
the
bottom
of
their
file,
and
I
see
no
reason
why
not
cutting
that
and
just
using
year
six
and
let
the
developer
transpile
to
his
or
her
module
system
directly.