►
Description
YUI Open Roundtable is a weekly online discussion about anything related to YUI.
A
B
B
So
we
can
get
our
connections
straightened
out
and
clarence
is
here.
We
made
it
all
right,
so
we're
going
to
kick
things
off.
Thank
you,
carity
clarence
and
jeff,
and
our
guest
daniel
stockman
zillow.
I'm
going
to
kick
things
off
with
just
a
quick
notice
of
yy
news.
We
are
trending
toward
a
release
next
week.
Things
are
looking
great.
Build
is
looking
great
now,
no,
no
stable
failures
right
now,
so,
just
in
in
the
housekeeping
news,
things
are
going
great.
B
C
C
Maybe
like
back
on
all
right
yeah
there
we
go,
we
got
you
now
yourselves
all
right,
so
if
I
could
there
so,
as
I
was
saying
yeah
I
work
at
zillow,
it's
a
fun
place.
We
do
lots
of
cool
stuff
about
real
estate,
visualizations,
the
history
of
your
home,
the
estimate
of
your
home,
one
of
the
cooler
things
that
we
do
well,
we
use
d3,
that's
pretty
cool
and
what
d3
does
for
us
is
visualization
of
primarily
graphs
for
now.
C
B
C
C
It
has
a
build
system
that
uses
a
make
file
of
all
things,
but
it
actually
is
just
a
make
file
that
controls
a
bunch
of
node.js
scripts,
which
is
pretty
cool.
This
is,
of
course,
the
default
project.
Make
file.
Can
you
beat
the
building?
Sorry,
can
you
increase
the
font
size
a
little
bit?
Oh
yeah,
this
is
yeah.
This
is
I'll
I'll,
actually
just
go
straight
to
my
code,
so
in
the
wrong
place.
This
is
what
the
build
file
looks
like
locally
when
you
customize
it
like.
C
We
do,
because
so
the
story
behind
this
is
that
the
default
d3.js
has
a
lot
of
stuff.
We
don't
need
and
in
order
to
basically
run
it
in
a
more
optimized
fashion,
we
chose
to
create
our
own
separate
distribution
of
it.
Basically,
in
the
sense
that
we
took
this
huge
long
list
here,
these
files
and
use
their
same
patterns
to
generate
a
a
huge
concat.
Basically,
we
went
down
a
path
of
loading
them
individually
or
trying
to
figure
it
out
with
the
loader,
but
it
ended
up.
C
C
C
Over
the
years
I
mean,
like
those
libraries
I
talked
about
previously
protovis
dojo,
we
all
loaded
those
through
yui
and
what
we're
doing
here
specifically,
is
using
the
apply
config
static
method
to
mix
it
into
the
global
config
create
a
ddt
group.
We
found
this
async
false
here
is
important,
mostly
because
well,
not
in
in
d3's
case.
I
don't.
This
is
not
quite
necessary,
but
it
doesn't
hurt
all
the
same,
because
some
libraries
actually
have
post
processing
like
we
would
load.
C
We
don't
want
it
in
a
combo
convo
request,
because
we
want
to
have
strong
caching.
Most
of
our
custom
code,
like
non-yui
code,
is
all
requested
from
a
series
of
shifting
hashes
to
to
break
cache.
Basically,
during
our
build
process,
the
the
fact
is
well
the
near
brain.
What
we
don't
do
is
like
what
we
do:
reverse
for
yui
and
other
libraries.
C
We
take
advantage
of
the
built-in
file
system,
pathing
that
you
know
versioning,
like
the
version
number
literally,
as
you
see
here,
that's
it's
using
this
version
number
here
as
part
of
the
path
we
change
this
part
as
we
like
move
our
d3
port,
basically
it.
This
is
a.
This
is
a
few
versions
back
as
a
present,
but
it
works
for
us
and
we
also
serve
it
from
our
own
static
domain,
which
is
what
the.
C
C
We
also
don't
have
to
worry
about
any
dependencies,
because
we
don't
do
that
with
our
external
modules,
we're
just
kind
of
implicitly
expecting
that
if
you're
requesting
this,
you
know
what
you're
doing
and
and
the
make
file.
Of
course,
if
other
teams
need
their
own
subsets
they're
encouraged
to
make
their
own
little
special
module
thing,
but
so
far,
there's
only
been
one
team
to
do
a
lot
of
this
stuff,
which
is
the
team
behind
the
home
values
page
and
yes,
so
getting
back
to
the
this
there's.
C
So
this
this
is
the
template,
d3
config
file,
and
it
has
just
an
ant,
replacing
thing
that
we
replace
in
the
lovely
ant
script,
because
yeah
java
and
xml
and
it
works.
This
is
the
build
properties
that
supplies
basically,
our
versioning
like
we
choose
the
process.
Basically,
we
choose,
which
version
to
to
to
kind
of
to
port.
Just
you
know
like
it's,
not
it's
not
forking
it,
but
we
basically
copy
it
down
from
the
github
archive
explode.
It
do
a
bunch
of
processing
on
it
run.
C
D
C
F
C
Yeah
yeah
yeah-
I
can
get
that
so
basically,
and
so
the
this
file
actually
is
individually
loaded
on
the
page
when
it
needs
it,
because
we
chose
not
to
include
it
with
all
of
our
config,
but
basically
there's
a
this
is
like
z-home.
Values
is
our
main
controller.
It's
a
it's
a
base,
subclass
that
does
a
bunch
of
stuff
during,
like
you
know,
if
we're
using
the
render
method
with
an
initializer,
but
how
we
use
it
is
not
explicitly
as
a
dependency
of
this
file.
C
C
The
reason
we
request
it
after
the
initial
load
is
mostly
just
to
allow
other
things
to
get
in
line
in
front
of
that
stuff
in
terms
of
rendering.
So
we
we
have
the
initial
controller
in
the
in
the
first
request
and
then,
when
we
choose
to
initialize
these
charts,
then
it
loads
the
assets
through
this.
Why
not
use
here,
which
basically
is
using
all
these
request
requirements
here
now?
Our
convention
in
these
files
is
the
zd3.
Prefix
is
one
of
our
files
that
depends
on
d3
and
this
particular
file.
C
Zd3
line
chart
is
over
here,
and
it
is
the
one
that
does
have
the
the
requirement
on
d3
home
values
and,
of
course,
this
block.
This
metadata
block
is
actually
located
in
a
centralized
config
file
because
it
would
be
worthless
otherwise
and
in
terms
of
requesting
it
from
our
general
entry
point,
but
the
I
was
up
in
the
up
dirt,
so
interesting
thing
about
d3.
C
C
This
is
not
an
actual
global,
but
in
the
context
of
the
execution
or
the
instantiation
of
a
new
instance,
because
it's
a
wide
up
based
subclass,
that
this
d3
is
shared
across
all
all
instances
and
how
that
gets
assigned
is
in
the
place
where
I
look
at
that
here.
This
is
basically
the
extent
of
a
fanciness
in
terms
of
how
we
load
it,
because
we
can.
We
know
that
when
we
require
something
in
yui,
the
callback
won't
be
called
until
that
file
is
loaded
in
the
case
of
z3.
C
That
means
the
library
is
loaded
to
contrast
with
other
libraries
that
might
do
the
asynchronous
type
stuff
that
you
have
to
wait
for
a
callback,
but
d3
is
all
synchronous,
and
so
every
time
an
instance
of
this
is
created,
it's
assigning
to
this
internal
property
internal
thing
yeah,
you
are.
This
is
your
internal
reference
to
the
external
global
namespace.
C
It
could
be
protected.
I
guess
if,
if
it's
already
assigned,
but
it
doesn't
really
hurt
anything
because,
generally
speaking,
we
only
have
one
or
very
few
instances
of
this
anyway,
so
it
just
assigns
itself
over
to
the
same
instance.
Over
and
over
again,
and
of
course,
we
have
some
lovely
error,
logging
saying
what's
up
if
you
have
a
problem,
a.
G
G
The
only
issue
with
that
is
that
there
is
a
penalty
performance
penalty
because
we
don't
know
the
the
requirements
up
front,
that
we
need
to
go
and
load
one
and
then
trying
to
load
the
requirements
of
of
that
one
and
so
on.
So
it's
going
to
be
a
asynchronous
computation,
basically
right,
why
it's
better
to
in
in
many
cases,
to
compute
the
dependency
graph
and
send
it
to
the
client
side
as
the
method
that
you
have
to
use.
G
So
whenever
you
do
a
use
statement,
it
will
go
ahead
and
compute
everything
that
is
needed
and
loaded
in
parallel
either.
If
you
use
combo,
it
will
load
it
all
in
one
convoy
you
don't
use
combo
like
in
your
case.
You
just
load
all
these
things
in
parallel,
so
there's
a
small
detail
like
there
is
a
performance
penalty.
There
you
can
see.
Probably
in
the
network
panel,
you
will
see
that
they
will
be
loaded
one
by
one
well,.
C
C
That's
the
only
reason
we
have.
I
mean
it's
mostly
laziness
on
my
part.
I
didn't
want
to
have
to
tell
people
to
also
maintain
this
line.
Like
add
new
lines,
there's
no
actual
wrapper
in
this.
The
the
the
file
that's
generated
by
this
make
file
has
no
uyui,
like
you
know
the
yui
dot
add
stuff.
It
doesn't
have
any
of
that.
It's
just
loading.
It
filed
it
yeah,
but
I
I
I
do.
I
see
what
you're
saying
in
terms
of
yeah.
G
Well,
they
don't
have
dependencies.
Yes,
it's
fine,
you
know
we'll
be
just
right
now:
yeah,
okay
and
the
other.
The
other
thing
you
were
talking
about
the
last
one
that
you
showed
the
last
file
that
you
showed.
I
mean
you're
talking
about.
Why
the
why
the
conflict
of
global
to
have
something
that
is
global,
that's
just
fine!
G
We
we
use
that
for
polyfills,
for
example,
so
we
have
a
polyfill
that
maybe
we
want
to
build
it
through
the
loader
I
mean
through
shifter
just
for
getting
the
version
that
we
need,
and
then
you
just
pull
it
into
the
page
and
then
eventually
will
surface
as
a
global.
So
you
just
use
wider
conflict
or
global.
It's
just
fine,
but
if
it
is
something
that
is
internal,
probably
why
that
environment
is
is
a
better
option.
C
C
We
arguably
could
put
this
assignment
actually
in
the
up
at
the
top,
because
yeah
that
that's
interesting,
it's
been
a
while,
since
I
looked
at
this
file
so
that
that
probably
eluded
my
grasp
when
I
last
code
reviewed
this,
but
because
essentially
this
step
in
the
initializer
shouldn't
be
necessary
because
this
entire
module-
never
this
callback
is
never
fired
until
that
synchronous
library
is
loaded
anyway,
so
yeah.
This
is
a
little
bit.
G
C
Yes,
I
wonder
if
my
compatriots
who
worked
in
this
file
are
watching,
but
anyway
yeah.
So
I
was
gonna
raise
another
interesting
thing.
One
of
the
benefits
we
get
from
using
the
base
subclass
is,
of
course,
attributes
and
we
actually
do
use
attributes
in
a
useful
way.
With
you
know,
events
and
whatnot,
but
one
of
the
interesting
things
as
mentioned
d3
code
is,
is
very
chained.
So,
like
you
get
of
course
not
in
this
exam,
that's
the
wrong
one
to
choose.
C
Basically
one
of
the
things
that's
very
common
is
surpass
functions
as
arguments
to
these
things,
so
that
that
when,
when
this
act,
svg
access
is
actually
like.
This
is
the
access
function,
getter,
sorry,
the
yeah.
It
makes
decisions
basically
based
on
the
content
of
the
data
I
mean.
Hence
the
the
name
of
d3
is
data
driven
data
or
documents,
sorry
data-driven
documents
I
even
go
to
the
web
page.
C
C
We
cache
it
because
we
access
it
far
more
frequently
than
it
actually
changes
so
there's
a
whole
bunch
of
different
possibilities.
Here
of
you,
know
dollar
cents,
month
days
or
raw.
So
basically,
in
that
update
function
anytime,
we
update
the
properties
or
attributes
of
this
class
and
we
need
to
update
the
things
that
generate
the
data
callbacks.
This
is
what
we
do
and
then,
when
we're
actually
constructing
the
pieces,
we
go
and
set
these
properties
as
the
return
of
that
and
fun
stuff.
D
D
C
C
No,
this
is
another
basic
question.
I
don't
think
we
actually
do
any
descendant
hierarchy
of
inheritance.
I
mean
from
our
code
like
these
directly,
but
that
is
something
we
could
do
in
the
future.
I
think
that
was
one
of
the
motivations
for
doing
it.
This
way,
we
we
could
arguably
like
so
we
have
this
list
of
the
lion
chart
pie
chart.
I
wonder.
C
There
would
be
a
series
of
possibly
oh,
I
don't
know
now.
This
is
actually
a
much
simpler
as
you'd
expect
chart,
because
it's
just
a
pie
chart
there
are
not
any.
It
does
not
have
any
shared
things
in
it.
So
yeah,
that's
pretty
much.
The
extent
of
I
mean
how
we
use
d3
beyond
well
how
you
actually
use
d3,
which
I
must
admit
I
am
not
as
skilled
at
as
my
co-workers,
but
because
I
was
the
one
who
did
all
the
fancy
make
file
business.
C
C
Yeah
presently
well
outside
of
the
build
job
that
you
know
runs
on
jenkins
box
yeah.
Everything
is
currently
on
the
client
we
have
with
some
of
our
old
dojo
code.
Actually
we
have
this.
What
was
going
on
at
the
time?
Phantomjs
wasn't
mature
enough,
but
we
basically
took
a
headless
okay,
it
look
and
the
output
is
actually
very
similar
to
this.
C
We
took
a
headless
webkit
instance
and
made
see
go
to
the
thing,
so
this
this
chart
here
is
actually
a
screenshot
from
a
headless
phantomjs
instance,
and
this
the
scrubber
thing,
the
thing
that's
going
across.
It
is
a
two
little
points
and
a
line
that
are
moved
on
mouse
move
to
map
to
the
coordinates
of
the
generated
image.
D
C
C
Basically,
what
we're
doing
here
is
the
same
idea.
You
can
actually
also,
I
can
add,
like
my
favorite
neighborhood
fremont,
and
then
you
know
my
hometown
and
wow,
there's
a
difference
but
yeah,
and
this
this
has
more
animation,
because
it's
d3,
because
that's
what
d3
specializes
in
as
that
kind
of
dynamic,
svg,
recomputing,
stuff
and.
C
Yeah,
it's
rest
would
be
would
be
generous,
but
it
it
definitely
is
that
that's
the
ideal,
we're
heading
what
we're
aiming
for,
but
yeah
it
it
it's
it's.
I
believe
a
jsonp
back
end
that
returns
a
big
blob
of
you
know
json
or
json,
or
in
some
cases
the
this
is
actually
the
second
or
third
iteration
of
this
home
values.
Page.
C
When
I
worked
on
it
several
years
ago,
we
were
using
a
custom
data
format,
because
parsing
json
of
a
certain
size
gets
incredibly
expensive,
so
we
were,
like
you
know,
like
basically
comma
separated
values,
but
but
slightly
fancier,
and
so
I
imagine,
depending
on
it,
really
depends
on
on
the
granularity
of
the
graph.
Too.
I
mean
each
of
these
points
on
here
is
a
fair
amount
of
data
and
yeah
json
gets
unwieldy
at
you
know,
sizes
of
upwards
of
you
know
a
couple
hundred
k.
C
C
C
C
Well,
ultimately,
these
are
all
they're
all
dom
elements,
because
it's
spg,
so
I
suspect
it
actually
is
yui
events,
but
without
going
too
deeply
into
the
weeds,
I'm
using
the
resize
throttle.
I
wonder
what
throttle
is
doing.
Throttle
screw,
get
scroll
handler
resize,
not
so
much
yeah.
What
maybe
it.
F
C
C
Yeah,
oh
cool,
but
yeah.
I
I
do
unfortunately
know
off
hand
what
we're
doing
in
terms
of
the
scrubber
or
event
listeners.
That's
probably
a
good
function.
Yeah
data
change,
here's
the
data
change
thing,
but
it
looks
like
the
the
hover
might
be
I'd,
be
very
you
know
in
this
exam.
This
reveals
my
ignorance
of
d3.
C
C
You
have
to
go
back
yeah,
we
could
theoretically,
but
we
I
mean,
were
you
currently
using
three
three
one
or
three
three,
three
eleven
and
I
pretty
sure
that's
a
few
versions
back
like
is
quick
and
ugly
hacked
forecast.
Wait!
No,
that's
branches!
I
want
to
go
to
releases
yeah
three
four
times.
Oh
we're!
You
know,
that's
not
bad.
C
You
know
if
there
was
something
important
in
terms
of
like
you
know
things
we
were
using,
we
could
we
would
definitely
I
mean
we'd,
be
upgrading
it
like
you
know,
at
the
drop
of
a
hat,
and
all
it
would
take,
would
just
be
modifying
this.
You
know
these
properties
here
and
re-running
the
build
drive,
the
new
major
or
miner
yeah
yeah.
C
C
C
C
B
C
Do
the
same
thing
for
yui
that
you're
doing
for
d3d
rip
out
things
that
you
don't
need?
Oh
no!
No!
No!
We
we,
we
load
everything
now
the
the
different,
the
the
what
we
do
for
you
may
notice,
there's
a
there's
ue
gallery
directory
here
and
the
two
and
three
ue2
ue
two
and
three.
We
do
the
same
thing
as
ue3.
We
we
package.
We
deploy
the
whole
thing
for
the
gallery.
C
C
C
Well,
you
know
the
funny
thing,
this
very
page
that
I've
been
just
demonstrating
here
used
like
the
previous
example
of
the
let's
see.
Where
is
it?
Oh,
there's
there's
a
data
table
visible
here
like
based
and
you
can
do
all
sorts
of
fancy.
You
know
sorting
and,
and
you
can,
I
click
on.
I
think
you
can
click
on
them
or
something
I
don't
know
it
there's
a
way
we
used
to
add
them
to
the
thing.
But
so
four
years
ago
this
was
a
ue
2
data
table.
C
I
don't
know
what
it
is
now.
I
would
be
surprised
if
it
still
was,
but
we
do
have
at
least
two
or
three
really,
oh,
oh
the
text
editor,
that's
right!
Our
rich
text,
editor
is
indeed
still
the
ue2
version
and
we
try
to
touch
it
as
little
as
possible,
but
yeah-
and
it's
mostly
I
mean
at
this
point
really
it's
the
the
whole
decision
or
maintenance
versus
rewriting
or
you
know
you
got
my
legacy
stuff
right.
C
Well,
we
we
yeah,
I
mean
by
virtue
of
having
you
know,
we've
like
doubled.
Our
head
count
in
the
last
year,
we've
written
a
lot
of
legacy
code.
You
know
much
more
recent
than
ue
2
already
and
yeah.
It
is
comforting
that
it
still
works.
It
doesn't
really
burden
us.
We
use
that
that
ue,
2
and
3
project
to
basically
allow
us
to
combine
ue2
stuff
through
the
same
combo
lower,
so
that's
cool
and
because
it
never
you
know,
never
changes.
C
C
I
I
have
myself
yeah,
I
tend
to
I
mean
yeah
like
I'll,
do
a
lot
of
stuff
in
in
node
and
whatnot
so
like
I'm,
I'm
definitely
probably
among
the
the
more
progressive
yeah
progressive.
Yes,
that's
a
good
word
devs
in
this
in
this
particular
company
for
javascript
reasons,
I
think,
and
and
like
to
be
quite
honest.
C
I
haven't,
I
haven't
myself
done
direct
feature
development
in
a
little
while,
since
my
role
has
shifted
to
more
of
a
you
know,
tools
and
and
developer
velocity
type
thing
like
my
job
now
is
to
make
others
work.
You
know
better
and
faster
and
more
tests
and
stuff,
and
I
mean
I've.
I've
been
I've
continually
continued
to
be
well
grateful
that
we
use
a
frame
of
like
yui,
because
it
has
so
many
tools
to
to
aid.
That
sort
of
you
know,
documentation
and
and
test
frameworks,
and
my
cracking
voice
and.
B
C
C
C
B
B
D
Hey,
so
do
you
want
to
talk
to
us
a
bit
about
like
some
of
the
tools
that
you've
been
building?
If
you
have
the
type
so
like
I,
I
know
that
you
mentioned,
like
you've,
been
working
more
on
like
the
tooling
side
of
things.
Are
you
using
like
working
with
shifter
or
working
with
front
or
any
other
like
tools
out
there.
C
Yeah
like
I've
personally,
one
of
my
personal
goals
is
to
get
us
onto
shifter
and
grunt
in
terms
of
our
front-end
build,
I
mean
you
may
have
noticed
all
the
xml
I
was
waiting
through.
This
is
kind
of
one
of
those
things.
The
process
has
become
much
easier
since
we
recently
transitioned
our
front
end
code
from
perforce
to
git,
which
was
like
the
last
six
months
of
my
life.
C
Yeah,
I
no
longer
have
to
mortgage
half
my
brain
to
understand,
perforced
and
why
it's
so
painful
but
yeah.
As
a
result,
I
mean
the
the
way
that
we
have
this
huge
multi
multi-track
parallel
future
branches,
lots
of
complexity
that
I'm
hoping
to
basically
modularize,
like
the
big.
The
biggest
thing
holding
us
back
right
now
is
the
sheer
size
of
all
the
code
in
one
big
blob
and
most
teams
touch.
C
You
know,
half
a
dozen,
maybe
20
modules
at
most
out
of
the
several
hundred
that
we
have
it'd
be
really
great
and
it
will
be
really
great
once
we
get
those
chunked
down
into
smaller
bits.
I
I
look
at
it
almost
as
like
an
internal
gallery
in
terms
of
how
they
would
be
organized
and
built
and
packaged
and
depended
on
and
those
sort
of
things.
E
C
You
know
format,
yeah,
javascript,
html
and
css
is
kind
of
crazy,
it's
kind
of
no
longer
just
just
beautifying,
but
it's
all
javascript
doing
it,
and
so,
at
the
same
time
we
last
year
converted
to
using
less
as
our
css
preprocessor
and
as
a
result,
we
had
to
figure
out
a
way
to
build
700
less
files
in
a
reasonable
amount
of
time.
It
turns
out,
if
you,
if
you
build
them
all
sequentially,
which
is
how
less
c
works
right
now.
C
It's
really
crossing
the
streams
there
isn't
right.
I
I
can't
ima.
I
can't
believe
we've
survived
this
long,
calling
a
node
package
from
not
one
but
two
xml
based
build
systems
yeah,
and
so
basically
that's
that's
one
of
my
current.
My
long-term
goals
is
to
kind
of
collapse.
Those
streams
into
you
know
maybe
a
a
maven
target
that
kicks
off
a
series
of
shifter
builds.
Basically
that's
my
goal,
because
I
I
don't
ultimately
because
of
how
our
overall
source
code
I
mean
our
overall
services
are
controlled.
C
C
But
we
got
a
few
steps
in
in
on
that
path,
yet
mostly
related
to
constraining
the
size,
like
the
sheer
size
of
the
number
of
modules
we
have
in
our
central
repository
now.
Our
like
our
our
front
end
code
still
is
a
big
blob
of,
like
you
know,
a
couple
hundred
modules
spread
across
a
dozen
different
product
teams
when.
C
C
You
know
when
I
went
but
to
contrast
and
be
even
more
confusing
when
I
say
modularize,
I
do
mean
a
chunk
of
feature
oriented
one
to
many
and
probably
not
more
than
20
related
modules
that
are
all
used
in
the
same
context
and
they're
separated
into
different
files,
because
that
makes
maintaining
them
and
understanding
them
a
lot
easier.
But
I
don't
quite
I
mean,
in
the
context
of
I
think,
the
correlation
to
the
ue
doc
sense
of
module.
C
Yeah,
oh
and
yeah,
that's
even
more
confusing.
Actually,
there
is
literally
a
one
of
our
front-end
components
like
on
on
the
the
the
server
side
is
called
literally
module,
and
it
is
a
that
the
thing
it
has
a
header-
and
you
know
the
box
thing,
but
that's
really
that
that
is
not
actually
directly
correlated
to
any
given
javascript
file
for
the
most
part
like
as
a
widget
or
whatever
right.
B
C
Well,
I
mean
the
initial
way
that
we
started
using
d3
was
literally
just
loading,
the
the
d3.js
on
the
page
right
after
like
so
we
we
have.
We
combine
all
of
our
config
files
into
our
into
our
seed
and
we
have
a
yuic
that
we
load
before
that,
and
then
we
do
the
yui
that
use
out
at
the
bottom
of
the
page
right.
C
So
we
have
much
more
convenient
way
of
loading,
a
dynamic
or
whatnot
the,
but
from
the
perspective
of
like
how
it
actually
operates,
it's
kind
of
the
same
and
really
it's
because
it's
the
library
that
loads
synchronously
doesn't
do
any
extra
fancy
stuff.
Like
the
google
google
api,
we
don't
have
to
worry
about
callbacks
to
that.
So.
B
C
C
So
yeah,
it's
mostly,
I
mean
the
the
the
period
of
time
that
we
were
using.
The
the
literal
links
to
like
the
the
global
cdn
would
be
when
we
were
still
kind
of
testing
it
out.
We
weren't
quite
sure
yet
if
we
were
committing
it,
and
then
we
got
to
a
certain
point,
we're
like
okay.
We
need
to
actually
pull
this
in
and
make
it
more
performant,
and
that's
when
I
came
in
to
help
mess
up
that
build.
B
C
C
I
think
the
the
primary
thing
I'm
working
on
is
in
tandem
with,
like
the
moving
towards
a
shifter
or
slash.
Grunt-Based
interface
is
just
chunking
up
our
code
better,
like
modularizing
it
in
the
the
ue
doc
sense
of
module
like
so
we
have
a
collection
of
related
components
and
then
knitting
it
back
together
on
the
on
the
consuming
side,
somehow
to
make
our
just
make
our
development
process
faster.
C
B
C
Yeah,
actually,
you
know
not
for
d3
directly,
because
we
just
kind
of
outside
of
the
the
config
thing
that
we're
generating
we
don't
really.
We
didn't
see
a
need
for
a
capacitor
there
so
much,
but
we
do
have
something
similar
to
that.
For
our
usage
of
like
the
the
google
plus
api,
the
the
google
maps
api,
I
picked
the
pinterest
api
there's
a
few
external
apis
and
that's
what
we
literally
call
it.
The
external
api
gives
us
a
way
to.
C
It
almost
feels
like
a
promise,
though
retroactively
like
we
have
this
method
where
we're
like.
I
want
to
use
this
api
and
then
I'll
provide
a
callback,
and
then,
when
that
api
has
called
its
callback
from
the
crazy
url
parameter
scheme
way
of
doing
things,
it
will
then
call
the
callback
is
due
there
and
then
we'll
just
descend
into
this
recursive
loop
of
dude.
I
heard
you
you
like
fall
back,
there's
a
fallback
in
your
callback,
but
it
essentially
in
in
this
external
api
mechanism.
C
We
also
use
the
fire
once
config
for
custom
events
to
allow
any
number
of
potential
consumers
of
this
external
api
to
own.
Like
potentially
once
it's
been
loaded
immediately
call,
whatever
callback
has
been
provided
kind
of
like
a
cheap
cue
in
a
way
in
a
way,
just
in
case
there's
a
nightmare
scenario
where
you
have
half
a
dozen
different
people
who
want
to
access
the
google
plus
api.
B
C
It
in
in
the
context
of
modularizing
our
code
into
smaller
pieces
that
make
it
easier
to
for
different
teams.
You
know
on
different
schedules
right
now.
We
have
this
kind
of
somewhat
monolithic,
bi-weekly
thing
where
it
gets
really.
It
gets
frustrating
at
times
because
we
have
so
much
code
moving
all
at
once
and
the
regr
you
know
test
regression
is
difficult
for
them.
C
C
At
the
same
time,
I'm
trying
to
improve,
because
basically
the
problem,
one
of
the
problems
of
having
a
huge
monolith
of
code
is
that
when
you
run
the
unit
tests,
all
of
them
are
run,
and
that
takes
you
know
probably
three
times
as
long
as
they
should.
But
yeah
they're
always
runs
that's
nice,
but
it
at
the
same
time
makes
it
also
very
difficult
to
pick
up
on.
B
B
C
Well,
other
than
the
obligatory
that
we
are
always
hiring
in
sunny
seattle.
No,
I
I
just
say:
we've
had
a
really
good
relationship
with
yui
over
the
years,
we're
looking
forward
to
just
continuing
to
watch
the
library
grow,
and
hopefully,
one
of
these
days
figuring
out
how
to
contribute
back
in
you
know,
gallery
modules
or
some
other
capacity,
but
yeah
thanks
for
the
opportunity.