►
From YouTube: YUI In the Wild #5 with Pat Cavit from ArenaNet
Description
YUI In the Wild discussions with YUI community members about how they use YUI.
A
A
A
B
It
away
okay,
so
I
haven't
actually
been
able
to
watch
any
of
these
thus
far.
So
this
is
going
to
be
an
exciting
adventure
and
making
sure
I
get
things
right,
but
the
way
this
was
described
is
me
coming
on
and
talking
about
sort
of
how
we
use
Yui
what
we
use
Yui
for
problems,
we've
had
solutions,
we've
come
up
with
those
sorts
of
things.
Is
that
still
accurate
yeah.
B
B
Running
Yui
and
there's
sort
of
longer-term
plans
to
actually
build
more
of
the
game
UI
on
top
of
web
tech,
as
opposed
to
using
a
native
layer,
rendering
system
that
we
have
so
I
mean
we
use
Yui
on
all
of
our
sites
everywhere
from
the
big
marketing
sites.
Guildwars
2.com,
our
homepage.
Well,
actually,
our
homepage
doesn't
use
it
for
reasons
that
I
can
get
into
later.
But
you
know
all
the
whole
registration
flow
there.
B
We
go
through
all
of
our
internal
tools,
use
it
and
then,
like
I
said,
we
also
have
currently
three
customized
web
sites
that
we
have
that
are
designed
to
run
inside
the
game
itself
and
provide
aspects
of
the
game.
Api
and
those
all
use,
Yui,
plus
a
bunch
of
really
exciting
stuff.
Wow
they're
really
exciting,
as
may
be
over
selling
it,
but
you
get
to
do
fun.
Things
like
styling
form
controls
using
the
shadow,
DOM
and
stuff,
which
you
don't
generally
have
a
reason
to
do
out
on
the
web.
B
In
fact,
it's
probably
not
a
great
idea
to
change
how
check
boxes
and
stuff
look
on
people,
but
when
you're
building
game
you
I,
you
want
it
to
look
like
the
rest
of
the
UI,
so
you
get
to
go
into
that
and
how
far
can
you
take
a
button
and
making
sure
text
inputs
have
all
the
right
shadows
and
borders
and
stuff
so
that
gets
a
little
interesting,
less
Yui
related
more
just.
This
is
CSS
that
looks
completely
bananas,
but
still
fun.
April,
quick,
Marco,
Marco.
B
Vegas
and
then
sort
of
a
new
class
of
places
where
we're
using
Yui
that's
just
coming
up
is
this
concept
of
more
like
an
embedded
solely
client-side
application.
The
first
one
of
those
is
just
now
shipping
for
as
part
of
guild
wars.
2
in
China
then
did
we
just
rewrote
the
launcher.
I
said
we
that
guy
on
my
team
did
I
didn't
write
any
of
the
code
for
it,
but
it's
all
white
out
at
powered,
and
it's
pretty
neat
to
see.
B
That's
not
active
for
the
North
America
European
version
of
the
game
yet,
but
that'll
be
coming
out,
probably
late
in
this
later
in
the
summer,
or
so,
as
we
get
a
chance
to
work
on
them
and
then
you
know,
like
I've,
seen
longer
term
we're
going
to
start
actually
building
sort
of.
Let's
call
it
first
class
game
you
I
with
web
technology.
We
use
an
embedded
browser
currently
called
also
miam.
It's
been
okay,
but
it's
not
updating
terribly
quickly.
B
A
B
Webkit
yeah
I,
so
I've
done
some
personal
stuff
on
top
of
node
WebKit.
It's
not
anything
that
we're
doing
at
ArenaNet,
yet
I
think
it's
cool.
It's
got
some
weird
rough
edges,
though,
especially
with
how
the
node,
JavaScript
and
Dom
JavaScript
interact.
That
makes
things
a
little
exciting
from
time
to
time,
but
yeah
like
I
for
fun,
wrote
a
little
Twitter
client
on
top
of
node
WebKit
and
used
Yui
there
that
actually
had
a
really
interesting.
Why
do
I
got
you
in
that?
B
Why
you
I,
assumed
it
was
running
on
top
of
node
and
that
blew
up
spectacularly
in
node
WebKit,
so
I
had
to
actually
go
in
and
muck
with
y-you
eyes
internal
flags
telling
it
was
a
node
and
lying
to
it
and
telling
that
there
was
no
note
available
and
just
use
the
regular
loader,
because
I
wanted
all
the
mywi
UI
code
to
run
in
the
browser
context.
Not
the
note
context
and
set
it
up
good.
B
So,
just
weird
little
hiccups
like
that
inside
no
WebKit
make
things
probably
harder
than
they
should
be
right
now
and
from
what
I've
been
able
to
tell
the
writing
test
story
is
still
kind
of
a
nightmare,
but
it's
coming
along
and
it's
a
cool
project
I
hope
they
continue
with
it.
I
would
like
to
use
it
here
for
something
I,
don't
know
what
that
might
be,
though,
because
it's
it's
not
something.
B
That's
embeddable
right
now,
where
something
like
coherent
you
I,
we
can
embed
inside,
are
executable
eventually
and
do
in
process
rendering
from
that
it's
very,
very
fast,
and
so
we
can
render
to
essentially
a
texture
on
top
of
the
game
and
draw
all
of
our
UI
layer
there
in
HTML,
using
CSS
and
and
stuff.
So
that
should
be
pretty
exciting,
where
you've
got
to
work
out
a
few
kinks.
Still,
though,
yep.
A
B
Like
to
see
I
I'm
always
curious
what
people
have
done
on
top
of
node
wicket
to
get
around
sort
of
the
stuff
that
I
wrened
into,
and
I
was
working
on
it
signed
by
no
means
an
expert
I've
built
one
little
app
on
top
of
it,
but
it
seems
cool
I.
Just
it's
got
a
lot
of
rough
edges
still,
unfortunately,
it
definitely
seems,
like
somebody's
sort
of
you
know
fun
side
project
and
could
use
a
little
bit
more
polish
on
anything.
What
was
the
new
runtime
you're
running.
A
B
B
I
believe
it's
roaming
like
carmem
32,
so
it's
relatively
recent,
especially
compared
to
the
previous
product
we
are
using,
which
I
said
is
still
on
chromium
18
so
like
that
puts
us
squarely
into
sort
of
that
weird
flexbox
middle
ground
that
doesn't
really
work
anyways
and
so
obviously
for
doing
game.
You
I
where
it
has
to
scale
to
multiple
resolutions,
and
we
are
you.
I
actually
has
three
different
sizes
that
could
scale
to
as
well,
just
as
an
option
for
users
on
flex
box
is
huge
for
that.
B
Little
bit,
where
we're
already
building
some
stuff
on
it,
like
the
new
china
launcher,
is
on
top
of
coherent
and
we've
actually
been
waiting
for
it
to
be
a
little
bit
more
compatible
with
our
mac
implementation.
Before
we
start
shipping
it
broadly
because
we
don't
want
to
leave
people
running
the
mac
version
to
gw2
out
in
the
cold
when
we
start
building
all
this
new
stuff.
On
top
of
it
so
and
then
I
mean
I.
B
B
Alright,
so
now
we're
seeing
ourselves
so
the
first
thing
I
want
to
talk
about
sort
of
the
thing
that
I've
worked.
The
most
on,
probably,
is
what
what
I
call
the
configure,
which
is
a
terrible
name
but
I'm
a
programmer,
not
a
namer,
and
what
that
is
is
so
the
way
Yui
is
built.
Anybody
who's,
built,
Yui
or
worked
with
it
in
the
past
knows
this.
Is
that
modules
are
unwrapped?
They
don't
have
the
Yui
add
stuff
around
them
by
default,
and
then
the
Builder.
B
A
B
Absolutely,
and
especially
back
when
the
Builder
was
all
am
based.
That
was
a
kind
of
a
slow
process
to
run.
So
if
you
were
trying
to
build
a
module
and
making
lots
of
small
changes,
and
you
had
to
run
against
the
built
version,
because
you
wanted
to
use
it
as
a
proper
module
and
include
it
with
loader
and
everything
you'd
have
to
build
it.
B
Every
time
which
made
me
completely
crazy
and
so
I
decided
to
build
a
little
tool
that
would
you
pointed
a
directory
of
Yui
modules
that
are
already
wrapped
in
their
yui
dot
at
call,
so
they've
got
their
module
name
defined
they've
got
other
requirements
to
find
anything
else
they
need
and
what
it
does
is
it
takes
that
it
parses
them
into
an
ast
pulls
out.
The
specific
pieces
of
information
needs
to
know
and
then
builds
a
config
object
for
you
and
we're
using
this
across
most
of
our
sites.
B
Now
what
I
like
about
it
is
that
you
don't
have
to
run
the
tool
all
the
time
once
you've
got
your
modules
metadata
set
up
you're
effectively
done,
and
you
can
just
go
ahead
and
not
worry
about
it
until
your
requirements
change.
Then
you
run
the
tool
again.
It
regenerates
your
config
and
you're
done
with
it.
It's
essentially
the
exact
opposite
of
how
the
Yui
build
stuff
works,
but
it
was
a
much
better
fit
for
how
we
wanted
to
be
building
things.
B
Or
something
like
that,
yeah
it
I
started
working
on
it
before
shifter
came
out,
I'm
still
I've
played
with
shifter
a
little
bit,
but
it
never
worked
quite
right
for
me
same
with
yogi,
so
I
admit
to
not
being
his
familiar
with
those
tools.
I
would
maybe
like
to
be,
but
we're
at
the
point
now:
err
I,
really
I,
really
like
using
this
tool
for
doing
the
Yui
config
stuff.
B
I
like
having
each
individual
module,
be
a
complete
ready
to
go
package
all
the
time
along
with
all
of
its
metadata
and
then
generating
the
config
from
that,
as
opposed
to
having
a
separate
file
that
has
the
modules
metadata
in
it,
because
it's
nice,
when
you're
working
with
a
module
you've
already
got
the
requires
right
there.
You
can
see
exactly
what
it
needs.
It
looks
like
the
module
will
look
like
when
it's
delivered,
I
mean
obviously
short
of
compression
or
something,
but
it's
still
pretty
similar
to
what
you'll
be
delivering
to
the
end.
B
C
B
B
This
is
is
showing
a
quick
example:
here's
a
folder
structure,
here's
what
a
generic
sort
of
Yui
module
looks
like
and
when
you
do
that
it
spits
out
this
Yui
config
object
that
has
it
puts
everything
into
groups
based
off
folder
names
by
default,
sets
up
base
for
you
and
then
sets
up
the
modules,
and
you
can
see
they
show
up
what
they're
requires.
It
offers
a
bunch
of
other
stuff.
You
can
use
it
to
add.
B
Configure
our
loader
configure
information
for
CSS
files
as
well,
which
we
use
in
a
lot
of
our
wideout
app
stuff,
is
at
the
point
where
you're
building
a
JavaScript
application
with
white
app.
You
know
you,
don't
you
don't
need
to
have
all
the
CSS
there
there's
about
really
good
fallback
solution
for
that,
so
you
might
as
well
have
loader
load
in
your
CSS
on
demand,
and
that
way
you
can
have
like
the
way
we
you
tend.
You
tend
to
build
stuff.
B
B
It
depends
on
as
well
as
its
CSS,
so
that
you
sort
of
get
it
all
as
much
as
possible
within
the
single
request
or
two
requests
if
you've
got
CSS
there
and
so
we're
loading
entire
parts
of
our
applications
on
demand,
and
then
the
this
is
just
showing
you
that
if
you've
got
CSS,
it'll
create
a
CSS
group
and
said
the
the
type
and
stuff
properly.
So
that's
something
that
I've
been
working
on
for
a
while,
like
I
said
we
use
it
all
over
the
place
here.
B
I
use
it
in
my
personal
projects
because
again,
that's
just
the
way
I
prefer
to
develop
shifter
totally.
You
know
does
this
for
the
main,
Yui
library
and
I
assume
most
people
using
Yui,
but
I
want
to
bring
this
up
and
if
you
guys
are
getting
me
a
platform
to
talk
about
the
way
that
I
like
to
build
Yui
modules,
I'm
just
going
to
go
ahead
and
do
it
all.
A
B
So
I
don't
bring
the
backhoe
here
while
we're
talking
yeah,
so
we've
been
tracking
that
pretty
closely
es6
modules
or
something
that
our
team
is
definitely
interested
in
and
they're.
Certainly
you
know
everybody's
got
their
own
level
of
interest.
Some
folks
are
very,
very
interested,
while
other
folks
are
just
sort
of
watching
it
to
see
how
it
shakes
out
I'm
very
curious
to
see
where
that
ends
up,
though
I've
been
watching
Juan's,
check-ins
related
to
that
and
stuff
and
charities
changes
to
loader
and
so
I'm
very
curious
to
see
what
that
ends
up.
B
Looking
like
and
sort
of
what
the
module
story
is
like.
After
that,
we've
got
enough
large
applications
that
it's
going
to
be
a
while
before
we
can
spend
the
time
to
really
transition
them
over
to
es6
style
modules,
being
trans
piled
and
dealing
with
imports
and
exports
and
stuff.
But
it's
a
place.
We
would
certainly
like
to
get
to
eventually,
since
that's
where
it's
going:
anyways,
no
reason
not
to
yeah.
C
B
Yeah,
so
that's
my
spiel
on
configure
and
then
let's
see
what
else
so
and
talk
about
dullard
a
little
bit,
which
is
the
build
tool
that
we're
using
here
and
there's
kind
of
a
long
story.
Around
white
deloitte
exists
and
we're
not
just
using
something
like
grunts,
but
if
I
can
shorten
it
up
as
much
as
possible.
It's
because
I
don't
like
build
systems
that
are
all
configuration
based
and
that's
that's
grunt,
and
it
makes
me
crazy
because
the
configuration
stuff
ends
up
looking
a
little
nuts
and
every
task
does
it
differently.
B
So
we've
got
a
very
simple
async
task
runner.
Essentially
that
is
designed
so
that
tasks
are
just
code,
there's
not
a
whole
lot
of
configuration
to
them.
You
can
configure
it,
but
we
try
to
avoid
it
and
it
just
tries
to
keep
things
as
simple
as
possible
while
you're
building
it.
Of
course,
you
know
that
that
doesn't
always
happen,
and
sometimes
you
have
to
do
some
configuration.
But
this
is
this
JSON
version
here.
B
C
B
Where
you
can.
You
know
tail
logs
and
and
run
other
tasks
and
stuff
out
of
it.
So
because
it's
so
simple
and
sort
of
not
opinionated
about
a
lot
of
things.
It's
pretty
powerful,
but
not
that
I
expect
the
ability
to
start
on
a
new
build
system,
especially
with
everybody
going
nuts
over
gulp.
But
this
is
what.
B
A
lot
of
the
way
that
we
build
our
sites
isn't
super
conducive
to
the
sort
of
read
files
off
disc,
get
a
stream
put
files
somewhere
else.
We
actually
really
want
to
be
able
to
move
the
entire
site
to
a
temporary
location,
because
we
do
a
lot
of
transforms
on
files
sometimes
multiple
times,
and
so
at
least,
for
the
way
that
the
build
system
is
set
up
now
gulf
would
not
be
a
great
solution
for
us.
B
It
may
be
in
the
future
and
I'm,
certainly
interested
in
the
fact
that
they've
broken
out
the
sort
of
streaming
API
aspect
of
it.
I
think
having
that
it's
done
module
so
that
you
can
use
that
anywhere
is
cool
and
totally
something
that
we
could
pull
into.
For
instance,
some
of
our
dollar
tasks.
But
you
know
our
dollar
bills
already
are
pretty
fast
and
switching
to
an
entirely
new
system
that
isn't
quite
what
we
need
doesn't
gain
us
a
whole
lot.
But
I
do
like
the
gulp.
A
B
Can
see
yeah,
so
a
dollar
task
is
just
an
exported
function
that
can
take
one
or
two
arguments:
there's
a
shared
config
object
and
then,
if
it's
an
async
task,
you
pass
the
callback
and
then
call
when
you're
done.
There's
some
other
stuff
around
it.
But
it
really
is
very,
very
simple
and
very,
very
stripped
down
we're
sorry
go
ahead.
Is
it
running
Yui
as
well
as
it
running
on
dis
j?
So
we
actually
pull
in
Yui
for
a
couple
of
our
dollar
tasks.
B
It
doesn't
doesn't
use
any
promises,
yet
promises
are
really
nice
for
simple
async
calls
I
feel
like
promises
really
start
to
fall
down
when
you're
doing
like
chained
calls
and
stuff
I.
Don't
really
like
the
return
new
promise
sort
of
thing
where
you've
got
a
promise
inside
of
a
promise
inside
of
a
promise,
it
works,
I've
experimented
with
it
a
couple
times,
and
it's
okay,
but
I
really
prefer
the
simplicity
of
something
like
callbacks
for
these
sorts
of
very
simple
tasks
that
are
doing
sort
of
one
very
focused
thing.
All.
A
B
And
so
I
mean
we
certainly
have
plenty
of
a
sink
built
tasks
that
do
random
asynchronous
things
to
make
them
a
little
bit
faster.
But
we
definitely
because
it
is
a
bill
task
and
it
runs
fast
enough
tends
to
just
be
lazy
and
use
a
lot
of
sync
methods
for
stuff.
It
just
makes
life
easier
and
the
code
easier
to
follow
if
you're
new
to
the
build
system.
B
So
there's
that
that's
like
I
said
doesn't
do
a
whole
lot,
but
that
is
the
thing
it
does
so,
let's
see
and
then
so,
let's
get
into
actual
Yui
modules
that
we
use
kind
of
all
over
the
place.
These
are
mostly
used
inside
of
our
our
wideout
app
instances.
This
seems
to
be
where
we've
written
the
most
sort
of
custom
modules
to
sort
of
help
make
the
experience
a
little
better,
a
little
bit
better
or
help
sort
of
smooth
over
some
rough
spots.
B
So
one
of
the
first
ones
that
I
really
wrote
for
this
stuff
is
this
view,
parent
extension-
and
I
actually
just
as
you
can
see
just
today-
actually
turned
it
into
its
own
github
repo.
So
it's
easier
to
look
at
so
far.
It's
lives
in
gist
and
there's
like
at
least
two
versions
in
our
code,
ace
and
there's
at
least
one
other
version
in
one
of
my
other
github,
repos
and
so
I.
B
Finally,
just
put
it
up
here
in
its
own
repo,
so
can
have
examples
and
stuff,
but
it's
an
extension
and
what
it
does
is
it
gives
you
it's
designed
to
be
mixed
into
a
whiteout
view,
instance
or
white
app,
because
why
not
app
is
really
just
an
extended.
Why
not
view
when
does
it
gives
you?
A
children
attribute
which
you
can
is
takes
an
object
of
other
white
I've
views.
It
uses
the
a
op
stuff.
Why
not
do
before,
or
why
to
do
after?
B
Excuse
me
that,
when,
after
the
parent
view
is
rendered,
it'll
go
and
render
all
the
children
and
take
the
output
of
that
rendering
and
stuff
it
into
the
parent
using
a
data
attributes,
so
you
can
see
it'll
look
for
like
this
data.
Child
attribute
in
this
is
carousel,
so
the
result
of
rendering
the
carousel
its
container
will
be
shoved.
Inside
of
this
div
same
here
with
the
featured
and
hot
and
sidebar,
there's.
B
These
examples
Wow
yeah
these
this
is
just
regular
HTML.
It
is
a
little
bit
except
on
this
way.
The
parent
view
doesn't
have
to
contain
events
for
all
these
different
things,
and
so
the
parent,
you
can
stay
much
simpler
and
you
can
sort
of
break
out
the
logic
for
each
discrete
part
of
the
page
into
a
child
view.
B
B
Yeah
so
every
view
still
has
its
own
events.
Hash.
Every
view
is
still
a
delegate
handler
for
itself,
and
so
they
tend
they
catch
their
own
events,
and
then
each
child
is
added.
It
has.
It
has
the
parent
added
as
a
bubble
target,
so
any
custom
events
that
they're
firing
will
bubble
up
to
the
parent,
so
the
parent
can
do
sort
of
meta
event,
management
or
meta
lifecycle
stuff
based
on
what
its
children
are
doing.
It's
really
simple.
B
Actually
we
can
just
go
look
at
the
code
for
this
there's
not
a
whole
lot
to
it,
but
so
you
see
we
set
up.
The
address
has
got
its
prototype.
It
initializes
it.
You
know,
watches
for
its
children
to
change
in
response
to
that,
and
then
after
render
gets
called
on
the
parent
view,
it
calls
render
children
and
then
it
also
just
renders
it
oh
yeah.
D
B
Judges
are
aren't
actually
intended
to
communicate
directly
on
you.
You
could
certainly
make
that
happen
by
having
them
fire
events
the
bubble
up
to
the
parent
view,
but
it's
not
specifically
intended
to
you
that
the
children
or
sort
of
thought
of
as
their
own
discrete
unit
of
functionality,
they
may
be
listening
for
events
on
a
model.
They
all
have
a
reference
to
the
parent,
so
they
could
be.
They
get
our
attribute
added
to
them.
That's
a
reference
to
their
parent
view,
so
they
could
be
responding
to
stuff
there.
B
A
B
Far
as
I
know,
you
could
nest
it.
We've
never
needed
to
do
that,
though,
but
there's
nothing
about
it.
That
should
keep
it
from
be
not
being
nestable.
You
could
totally
mix
it
into
otherwise
I've
view
instances
that
are
being
added
as
children
of
other
parents,
and
it
should
all
work
correctly,
but
I
haven't
actually
tried
it
because
we
haven't
had
a
need
for
that.
Yet,
but
again
it's
it's
very
generic
and
very
simple,
so
I
would
expect
that
it
would
work.
I
just
haven't
had
a
to
try
it.
What.
A
B
And
it
helps
in
delegating
responsibilities
for
building
sort
of
a
chunk
of
application
functionality.
If
you
can
do
this
and
not
have
the
one
main
view
have
to
be,
you
know
hundreds
of
lines
of
code
long
because
it
can
be
break.
It
can
do
a
few
general
things
and
then
stuff
can
be
broken
down
dead
children.
We
was
trying
to
think
if
I
could
pull
up
an
example
and
show
you,
but
I
don't
have
anything
handy
and
I'm
not
logged
in
right
now,
because
I
this
is
my.
B
B
B
A
B
Let's
see
okay,
so
let
me
screen
share
two
different
angle:
hangouts
cool,
alright.
So
let's
try
that
that's
shown
up
I
see
yeah.
It
is
yeah
okay.
So
this
is
the
in-game
store
if
we
call
it
the
gem
store.
This
is
all
white
app,
and
so,
if
you
look
this
upper
carousel
here,
that's
sort
of
like
the
featured
carousel
is
so
that's
a
child
view.
This
carousel
down
here
is
its
own
child
view.
B
This
recent
purchases
tab
over
here,
its
own
child
view
and
I
believe
this
search
box
is
also
a
child
view
of
the
top
level
app
itself
that
owns
this
whole
space.
So
and
then,
if
you
were
to
change
tabs,
this
nav
is
fixed
and
I.
Don't
think
that's
actually
a
child
view.
I
think
that's
just
the
app
containers
pointed
somewhere
else,
but
you
can
see
like
because
the
search
box
is
still
part
of
the
app
it's
essentially
persistent
and
then
you've
got
the
different
sections
down
here.
B
B
Yeah,
usually
you're
working
on
one
view
at
a
time.
Sometimes
you
have
reason
to
jump
back
and
forth
between
a
couple
of
them,
but
generally
you're,
working
on
a
section
of
time
or
you're
doing
layout
amongst
all
of
them,
at
which
case
you're
working
up
at
the
parent
view
level
and
making
sure
that
all
the
different
containers
for
each
child
view
are
set
up
correctly
and
styled
correctly,
so
that
they're
laying
out
the
right
way.
So.
D
B
B
B
Then
the
items
in
the
model
list
are
essentially
search
results
and
we
wanted
to
be
able
to
do
progressive
loading
on
that
stuff
so
that
we
didn't
have
to
load
in
potentially
hundreds
of
items
all
at
once
or
only
load
50
and
then
do
pagination
on
it,
because
that's
not
a
concept
that
our
game
uses
ologist.
You
can
scroll
through
everything,
so
I
wrote
a
little
mano.
Lyst
extension
called
model
list
more
that
it
adds
a
more
function
to
it.
B
B
B
It
just
delegates
that
to
the
sink
layer,
I'm,
sorry,
here's
what
I
was
talking
about-
we're
just
calling
ad
with
silent.
True
you'd,
be
both
the
fonda
yeah,
of
course,
better
cool,
yeah,
okay,
so
yeah.
It
calls
that
it's,
it
forces
silent
on
the
true,
because
it's
going
to
fire
this
more
event
a
little
bit
later
and
set
up
the
event
facade
for
it.
B
It
of
course,
also
supports
the
usual
callback
style,
but
all
the
information
about
how
many
more
to
load
or
anything
else,
is
handled
in
the
sink
layer,
and
you
can
see
this
just
delegates
to
the
sink
method,
just
like
all
the
other
model
and
model
lists
and
clear
stuff
does
so
really
all
this
is.
Is
it's
effectively
a
copy
of
the
load
method,
plus
some
extra
logic
down
here
to
not
clear
out
the
model
list?
B
When
you
add
the
new
responses
in
so
that
you
can
just
keep
on
adding
more
to
the
end
of
the
model
list,
if
you
really
want
to
get
silly
and
since
add
supports
an
index
where
you
can
add
them
to,
you
could
also
put
them
at
the
front
of
the
list.
If
you
wanted
to,
we
haven't
had
a
use
case
for
that
in
any
of
our
guild
wars,
2
stuff,
but
I
do
that
inside
my
little
twitter
app
on
node
WebKit.
B
A
B
Absolutely
we
like
I,
said
our
actual
real-life
use
cases
for
this,
yet
are
all
capped
at
a
low
enough
number,
either
due
to
design
requirements
that
we
don't
want
to
show
you
literally
thousands
of
infinite
scrolling
search
results,
because
that's
not
useful
or
because
categories
in
the
gem
store
or
have
it
most
like
50
to
75
items.
Yet
I
haven't
had
a
need
to
do
a
lot
of
memory
management
around
that
and
be
able
to
sort
of
have
a
sliding
window
of
models
or
anything.
B
B
It
depends
on
the
way
we've
got
the
gem
store
set
up.
It
knows
how
many
items
it
can
have
and
it
uses
the
node
scroll
info
plugin
to
know
when
it's
getting
close
to
the
end
of
the
items
it
does
have
and
then
it'll
go
ask
for
more
and
then
once
it's
got
all
of
the
items
that
could
possibly
need
it
stops
asking
for
any
more
because
it
doesn't
need
any
more
cool.
A
B
B
B
B
C
B
You
can
get
it
there
and
I
can
paste
it
in
the
hangout
chat.
That'll
I,
don't
know
you
know,
I'll
go
to
their
equipping
them
and
that's
in
its
in
the
hangout
chat.
So
maybe
you
can
pop
that
in
IRC.
For
me
since
I
closed
it
down,
I,
don't
need
distractions
from
hecklers
while
doing
this.
This
is
so
over.
These
are
like
you
die
and.
B
B
B
B
True
I
could
I
need
to
go,
look
up
and
see
what's
actually
involved
in
that
because
it's
been
a
while
I
do
have
some
gallery
modules,
but
it's
been
a
long
time.
So,
let's
see
covered
view
parent
and
model
this
more
okay.
So
the
next
one
is
even
simpler
and
dumber,
which
you
know
is
good
or
bad.
Take
your
pick,
but
let's
go
ahead
and
talk
about
view
classes
because
God
screen-sharing,
sorry,
sick.
B
B
So
you
can
see
is
a
really
simple
of
an
example
of
using
white
base
create
to
create,
extend
to
why
not
view
and
get
a
new
constructor
and
we
mix
in
our
view,
class
extension.
We
tell
it
hey
at
this.
Foo
googas
CSS
classes
to
it
and
then
provide
the
world's
lamest
render
function,
and
then
we
render
it.
We
get
some
actual
useful
classes
on
here
it
some
app
view
is
the
default.
Then
you
get
the
name
of
the
view
which
is
defined
here.
So
you
can
see
my
dive
view.
B
A
B
Sucked
in
with
the
class
name
is
changed,
but
we've
got
a
couple
projects,
internal
tools
and
the
like
that
use
bootstrap
and
really
like
to
switch
those
over
to
peer
just
because
even
I
spent
way
too
much
time
trimming
down
the
parts
of
bootstrap
to
just
what
we
want
it,
because
it
is
so
big
and
just
ridiculously
all
encompassing,
and
we
really
just
wanted
buttons
and
grids
and
table
styles
and
very
simple
things.
So
would
you
believe
that
that
there
are
people
that
even
want
it
smaller
than
what
it
is?
B
D
B
You
would
see
probably
four
or
five
different
extents
mixed
into
most
of
our
white
I
views,
and
you
have
to
be
a
little
bit
careful
to
make
sure
the
extensions
aren't
stomping
all
over
each
other,
because
they're
not
namespace
like
plugins,
but
by
and
large,
it's
not
terribly
hard
to
do
and
you
it's
nice
having
these
small
R
easel,
it's
a
functionality
that
we
can
add
to
our
view
instances
and
not
have
to
keep
repeating
ourselves.
Essentially
awesome.
Yeah
yeah.
A
B
C
B
We
call
our
ad
view
classes
thing
which
actually
goes
and
gets
it
and
your
gets
its
container
and
then
goes
and
updates
the
class
and
stuff,
and
so
that's
going
to
be
hard
to
make
generic,
but
there's
no
reason
that
these
sorts
of
ideas
couldn't
be
made
more
generic.
If
we
were
to
a
switch
to
a
system
that
was
less
Yui
dependent,
I
guess
you
know,
if
started
using
more
of
the
es6
stuff
and
moving
away
from
all
the
Yui
paradigm.
So.
A
B
And
that's
totally
true
and
we'll
probably
get
there
when
we
start
actually
using
the
es6
loader
stuff,
that's
being
added,
but
it's
going
to
be
a
while
for
that,
like
I,
said
we're
watching
it
pretty
closely,
but
not
having
started
doing
any
real
experiments
with
it.
Yet
what
kind
of
really
cycle
do
you
guys
go
on
when
it's
ready
to
go?
So
that's
that's
being
a
little
flip,
I,
suppose
the
in-game
stuff,
the
we
call
it.
B
The
commerce
annal
the
gem
store
and
the
Indian
game,
auction
house
and
stuff
tends
to
be
on
much
more
of
a
much
stricter,
really
cycle
like
they've
got
a
proper
full
q
ace
pass
for
it
and
stuff
and
everything
we
do
obviously
go
through.
Devastates,
live
and
sometimes
even
a
few
more
branches
if
necessary,
but
I,
know
I
pushed
an
update
to
one
of
our
websites
this
morning
the
changed
and
fixed
a
bunch
of
stuff
and
we
it
I,
started
working
on
it
a
couple
days
ago
and
it
was
ready
to
go
in
QA.
B
B
I
mean
I'd
rather
be
shipping
lots
of
code
frequently
as
opposed
to
big
updates
every
now,
and
then
we
don't
always
do
that.
I
think
before
not
before
yesterday
it
had
been
about
three
weeks
since
we've
done
a
live
deployed
just
because
we
had
been
working
on
a
bunch
of
longer-term
projects,
but
in
general
the
hope
is
that
we're
pushing
small
updates,
often
because
that
way
of
something
breaks,
it's
much
easier
to
roll
back
small
updates
to.
B
B
So
we
can
write
our
tests
and
something
like
mocha
that
we're
all
pretty
comfortable
with
and
then
run
that
against
the
whole
suite
of
browsers
using
the
selenium
grid
stuff
and
the
the
webdriver
protocol.
So
we'll
see
it's
still
just
an
idea
and,
like
I
said
currently
we're
running
all
of
our
testing.
We've
got
a
node
based
test
runner
that
kicks
off
a
bunch
of
instances
of
ask
for
jason
phantom
Jas,
which
is
okay.
We
run
our
tests
against
it's
actually
a
siloed
off
environment.
It's
not
you
know
they
don't
run
against
dev.
B
They
don't
run
against
any
of
the
branches.
They've
got
their
own,
they
run
against
the
code
in
the
databases
and
everything,
but
they've
spent
up
our
entire
platform
to
do
that,
against
with
a
brand-new
clean
database
and
create
a
bunch
of
accounts
and
stuff.
So
it's
a
little
bit
exciting.
Writing
tests
against
that.
And
since
you
can't
just
go
against
all
the
live
sites
like
you'd
expect,
so
it
adds
some
wrinkles
to
it.
A
B
Last
thing-
and
it's
probably
the
simplest
thing-
I
bet
I
handle
this
yui
already
has
a
lazy
image
loader,
but
it
does
a
lot
and
after
Ryan
wrote
the
notes,
scroll
info
plugin
I
wanted
to
see
just
how
hard
it
would
be
to
write
a
lazy
image
loader
on
top
of
that,
and
it
turns
out
it's
really
easy
and
pretty
great
it
was
actually
a
little
a
little
big
for
a
while
cuz.
There
was
a
bug
in
note
scroll
info,
but
you
know
true
to
his
word.
He
fixed
that
pretty
quickly
and
so
hey.
B
Let's
look
at
the
code,
because
this
is
pretty
fine,
so
you
know
you
plug
it.
It
gets
a
reference
to
the
host
and
plugs
in
the
scroll
info
stuff.
It
listens
for
scrolling
up
and
scrolling
down,
and
then
it
goes
and
figures
out
which
image
node
or
which
notes
even
it
should
probably
just
search
for
images.
But
right
now,
it's
even
probably
too
simple,
goes
and
finds
all
the
notes
that
are
on
screen
and
moves
the
data
source
attribute
to
the
source
attribute
and
then
cleans
up
after
itself.
B
But
we
use
this
for
those
that
sort
of
infinite
scrolling
situation
or
even
anywhere,
where
we're
showing
a
long
list
of
things,
and
we
know
that,
but
we're
not
worried
too
much
about
progressive
enhancement,
cuz
it's.
Why
top
app
instance
or
anything
like
that
to
just
lazy
load
as
many
images
as
possible.
You
can
set
a
threshold
and
pixels
inside
notes,
scroll
info
and
just.
B
B
He
wrote
it
to
be
really
really
efficient
and
really
really
fast,
because
I
believe
he
was
writing
it
for
something
at
smugmug
where
he
was
dealing
with
thousands
of
images
being
loaded
in
search,
results
and
stuff
and
so
hooking
into
that
lets
us
now
we're
not
doing
a
ton
with
it
now,
but
it
lets
us
have
complete
control
over
it
and
the
Yui
sort
of
image,
lazy,
loader.
It
does
a
lot
around
like
groups
and
triggered
loading
and
stuff
that
we
just
don't
eat.
B
A
B
Sort
of
the
way
I
think
about
that
stuff
is
that
it
should
be
up
in
the
gallery
and
have
people
using
it
and
deciding
they
like
it.
But
I
don't
actually
know
what
the
process
is
for
taking
a
module
that
was
written
outside
of
the
core
library
and
then
sort
of
promoting
it
up
to
the
core
Yui
library.
Maybe
there's
documentation
on
that
on
github
I,
just
haven't
gotten
looked
for
some
time.
D
B
B
A
But
this
kind
of
thing,
like
I,
didn't
find
some
like.
This
is
great
because
they're,
you
know
there
were
probably
a
lot
of
things
that
set
my
why
that
would
benefit
from
knowing
about
each
other.
You
know,
like
things
were
created,
you
know
individually,
and
then
they
get
up
there
and
you
like
there's
nothing
like
all
synthesis,
going
on
sure.
B
B
A
Sp
so
anyway,
this
is
just
a
good
example.
I
me,
one
of
the
things
we're
trying
to
do
is
we're
wanting
to
seek
out
and
find
like
folks,
like
you
who
you
know,
really
know
us,
you
can
deep
dive
into
specific
component
and
I
contribute
back
to
that.
So,
like
I,
want
you
to
consider
like
doing
it
when
you
do
things
like
this,
this
opens
a
door
to
you
becoming
like
an
official
contributor,
so
you
like
I've
check-in
access.
A
B
Well,
I
mean
I'd
be
happy
to
contribute
more
stuff
to
the
library.
You
know
I've
fixed
some
bugs
here
and
there,
but-
and
I
think
I
made
the
mistake
of
signing
up
to
take
paginator
off
Luke's
hands
a
while
ago
and
found
out
what
they
actually
use
cases.
Requirements
were
for
that
and
bailed
pretty
quickly,
but
yeah
I
would
love
to
contribute
any
of
this
stuff.
B
B
Once
we
start
getting
like
actual
web
UI
in
the
game,
whether
it's
Yui
or
not-
and
you
know-
that's-
probably
going
to
be
our
default
stance,
because
everything
we
do
is
why
you
I,
but
the
plan
is
once
we
have
a
better
idea
of
exactly
what
that
environment
looks
like
takeout,
you
know
maybe
a
week
or
two
and
just
have
everybody,
try
and
build
stuff
top
of
different
things
and
figure
out
what
we
liked.
What
we
didn't
like
and
sort
of
see.
B
Okay,
do
we
build
all
this
on
top
of
Yui
and
just
build
the
parts
that
Yui
is
missing?
You
know
one
of
the
things
that
we've
been
looking
at
a
lot
is:
how
do
we
do
data
binding?
So
one
of
the
guys
on
my
team
has
built
a
ractive
adapter
for
a
why
you
I
model
so
that
you
can
use
reactive
with
models
which
is
pretty
neat
I
wish
I
had
a
link
to
that.
Jay
has
been
handy,
so
I
could
show
you
guys
that,
but
you
know
just
stuff
like
that.
B
Like
what
I
you
know,
data
binding
was
talked
about
a
long
time
ago,
Luke
at
a
PR
for
it
that
kind
of
went
back
and
forth
and
then
I
pretty
sure
you
just
closed,
because
you
have
time
to
work
on
it.
So
when
we
start
working
on
game,
you
I
data
binding
is
going
to
be
really
important
because
we're
going
to
be
doing
a
lot
of
it.
So
what
solution
is
the
best
for
that?
Is
it
something
like
angular?
Is
it
something
like
ember?
Is
it
something
like
react?
B
Building
that
sort
of
you
I
in
the
static
environment,
like
that
or
you
know
exactly
what
you're
dealing
with
you,
get
to
do
a
lot
of
cool
stuff
that
you
don't
necessarily
get
to
do
out
on
like
the
real
actual
web,
and
so
that's
been
fun
and
you
get
to
use
sort
of
all
the
newest
greatest
most
likely
to
break
on
you
technologies
and
stuff
and
really
interesting
ways.
So
it's
it's
a
cool
thing
to
be
doing
and
something
that
once
we're
doing
more
of
it,
we'd
like
to
talk
about
so.
B
Yeah,
so
we're
we're
integrating
coherent
UI,
which
is
its
chromium
plus
some
custom
code,
they've
done
to
enable
all
sorts
of
things
to
essentially
a
you
know,
an
embedded
browser
for
native
code,
we're
using
it
inside
of
our
game
engine
right
now.
It's
bundled
in
the
client,
so
yeah
it's
in
the
client.
So
that's
crazy
Wow.
So
we
already
have
a
sort
of
an
older
version
of
chromium
embedded
that
we
use
to
host
stuff,
like
the
gem
store.
B
That
I
was
showing
earlier,
like
in
inside
of
our
game,
the
gem
store
and
the
auction
house,
and
then
one
other
thing
are
all
actually
web
apps
they're
just
pulled
up
with
an
embedded
browser.
The
cool
thing
about
coherent
is
it's
very
much
targeted
more
towards
like
actually
drawing
UI
on
top
of
it,
and
so
the
plan
is
for
us
to
be
slowly
moving
towards
new
UI
that
we're
doing
to
be
built
on
this
coherent
layer
using
web
technology.
B
It's
like
I
said
we're
not
exactly
sure
what
a
web
technology
we're
gonna
build
that
on
top
of
in
terms
of
JavaScript,
libraries
and
stuff,
but
certainly
since
everybody
on
the
team
is
familiar
and
has
lots
and
lots
of
experience
with
Yui
at
this
point.
That's
where
we're
going
to
start
with
and
then
we'll
figure
out
what
makes
sense
and
what
we.
What
we
need
and
then
Yui
doesn't
provide
and
sort
of
have
a
bigger
talk
about
that.
But
here's.
A
B
B
D
B
Yeah
I
would
love
I
the
more
examples
of
data
binding
in
Yui
and
externally
that
we
can
get
our
hands
on
to
see
what
we
like
and
what
we
don't
like
the
better,
because
you
know
I
I,
don't
want
to
say
for
certain
we're
gonna
end
up
building
our
own,
but
we'll
see
we
got
a
lot
of
opinions
on
the
team
and
usually
it's
hard
to
get
a
consensus
on
a
single
thing.
So
we
may
end
up
building
our
own.
That
takes
the
best
pieces
of
all
of
them.
A
B
Well,
so
that's
actually
an
interesting
topic
because,
aside
from
autocomplete
and
a
little
bit
of
experimentation
with
data
table,
I
don't
think
we
actually
use
any
y
UI
widgets
right
now
across
most
of
our
sites.
It's
it's
just
been
the
thing
where
the
controls
we
need
are
just
different
enough
that
we
end
up
having
to
build
them
ourselves.
Oh
except
the
carousels
I'm
like
the
gem
storing
stuff,
are
crap
I,
can't
think
of
the
component.
B
Now
the
one
that
Derek
was
wrote,
sorry
Rove,
you
yeah,
those
are
scroll
views
with
some
extra
code
late
on
layered
on
top
of
them
to
you,
know
disabled
swiping
and
add
the
navigator
and
stuff,
but
so
yeah
our
carousels
or
scroll
views.
But
aside
from
that
and
autocomplete
list
or
just
base
autocomplete
for
like
type
down
filtering
and
stuff,
we
actually
haven't
used
a
whole
lot
of
y
UI
widgets
and
that's
something
that
will
have
to
be
looking
at.
B
B
Yes,
the
the
current
tack
that
we're
taking
is
that
we're
offering
api's
on
that
people
can
use
to
build
experiences,
because
we
don't
really
have
enough
honestly,
like
warm
bodies
to
build
that
sort
of
stuff
ourselves
right
now,
so
we
started
offering
up
a
bunch
of
api's.
We
offer
like
map
tiles
for
the
in-game
map
and
events
stuff.
B
That's
all
why
not
a
panel
using
a
lot
of
the
stuff
that
I've
shown
today,
so
it's
not
going
to
be
coming
soon,
but
it's
certainly
something
that
we'd
like
to
do
because
having
good
developers
site
seem
is
pretty
high
on
our
wish
list
and
also
important
for
getting
people
able
to
use
and
understand
the
API
as
easily
it's
like
having
a
bunch
of
sticky
forum.
Threads
is
ok
for
now,
but
it's
not
great
I'm.
A
B
B
A
A
Okay,
well
I'm
really
appreciate
you
coming
today
and
then
you
say
you
know:
I
didn't
have
a
lot
of
stuff
shown
with
you
had
tremendous
amounts
of
stuff
actually
yeah.
Definitely
it's
all
really
awesome
and
I
definitely
left
like
the
way
you're
dealing
with
like
the
like
the
the
wide
view.
Parents,
don't
like
that.