►
From YouTube: YUI Open RoundTable August 29, 2013
Description
YUI Open RoundTable August 29, 2013
A
We
are
broadcasting
yeah,
so
I
want
to
thanks.
Thank
you.
Everyone
for
coming
to
our
newest
Yui,
open
round
table
it's
August
twenty-ninth.
We
have
some
special
guests
this
week
and
I
also
want
to
do
in
some
introduction.
First,
so
we
have
a
new
hire,
no
I
whitey
Ezekiel
Rodriguez,
who
is
joining
us
from
where
your
head
cool
he's
still
like
finding
himself
right
now,
there's
no
documentation
kind
of
looking
around
so.
A
And
that
that's
awesome,
because
this
shows
how
like
the
first
is
like
github,
can
be
a
great
tool
for
like
hiring,
because,
instead
of
hiring
somebody
and
not
knowing
anything
about
them,
you
actually
could
serial
code
changes
real
work,
and
that
was
a
big
influence
on
on
being
here.
So
right,
Jenny
sort
of
put
me
through
that
test.
A
You
know
yeah,
so
at
the
moment
I'm
going
to
post
the
link
up
everyone
so
before
I
do
that
I'm
introduce
our
sort
of
topic
for
this
week,
which
is
Eric
and
clearance
you're
going
to
talk
about
the
app
framework
and
go
through
the
impetus
for
this.
Was
we
had
a
forum
post
that
basically
asked?
What's
the
state
of
the
a
framework
and
Eric
and
Clarence
thought
that
was
a
good
sore
a
rallying
call
ago
and
find
out
what's
going
on
so
I'll?
Let
you
guys
talk
about
that
as
I
yeah.
B
So,
basically,
for
all
of
you
are
like
falling
on
the
Yui
forums.
We
had
one
user
Simon,
who
basically
was
asking
about
what
the
stay
of
the
app
framework
was
and
compared
to
like
a
lot
of
other
frameworks.
He
was
saying
that
he
wasn't
seeing
that
much
progress
on
Hugh
say
a
die.
Do
is
that
data
binding
was
something
that
we
were
looking
into
you
before
that
framework,
but
there
hasn't
been
much
progress
on
it
since
a
few
months
ago.
C
All
right
yeah,
we
we
had
them
I
created
a
list
before
of
tickets
that
that
were
sort
of
like
the
the
last
time
you
went
through
thinking
about
what
features
you
wanted
to
add
and
now
like
clearance
and
I
both
have
time
to
go
through
and
start
doing
the
stuff,
but
I
actually
can't
get
to
it.
I
think
within
who
redirects
that
we
have
set
up
on
the
website
to
redirect
you
to
github
issues,
I
can't
get
to
it.
C
So
I
can
figure
that
out,
but
yeah
I
know
generally
what
what
the
deal
was.
Okay,
yeah
do
we
want
so
the
one
example
you
were
talking
about.
Clarence
was
around
a
an
example
which
basically
used.
I
believe
it
was
related
to
currency
or
temperature.
C
It
was
temperature-related
so
like
there,
it
was
like
a
temperature
conversion
example
where
you
would
put
in
like
the
Celsius
or,
and
there
would
be
Celsius,
Kelvin
and
Fahrenheit
and
when
you
would
enter
in
a
value
in
one,
the
other
ones
would
update,
and
so
this
was
like
a
perfect
candidate
for
for
what
you
would
want
to
maybe
use
like
data
binding
for
to
help
deal
with
reconciling
the
the
changes
that
are
coming
in
through
a
form,
input
and
being
able
to
update
the
other
values
in
association,
but
not
cause
like
an
infinite
loop,
where
things
are
constantly
trying
to
update
them.
C
C
B
I'll
give
us
a
quick
summary
for
like
people
that
aren't
familiar
with,
like
the
whole
data
binding
thing.
So
the
idea
with
data
binding
is
that
you
would
be
able
to
bind
a
specific
like
data
structure.
So,
for
example,
you
would
be
able
to
bind
your
model
attributes
over
to
a
specific
like
Dom
elements
or
part
of
a
template,
for
instance.
B
So
the
idea
would
be
that
whenever
your
model
updates,
then
so
when
your
template
and
that's
something
that
would
be
really
useful,
because
that
makes
you
not
have
to
do
some
of
the
dom
manipulation
you
would
need
to
do
like
template.
Dot
render
such
and
such
every
single
time-
and
you
wouldn't
need
to
like
manually
wire
up
advance
to
listen
for
changes
on
your
model.
Another
use
case.
A
D
B
A
C
Does
it
also
to
like
another
benefit?
Is
this
nice
declarative
relationship
between
a
some
item
in
in
the
UI
and
some
data
backing
data
object
or
backing
data
attribute
and
being
able
to
connect
those
together
where
you
can
think
a
little
more
high-level
about
the
user
interface,
your
building
and
then
a
framework
or
library
can
optimize
the
details
of
how
those
two
things
are
connected,
but
hopefully
still
provide
some
escape
hatches
for
people
who
need
to
go
in
and
do
something
custom
and.
B
To
talk
about
like
some
of
the
more
like
history
doesn't
done,
involving
like
Yui
and
data
binding,
so
Luke's
poll
request
was
like
the
first
like
attempted
on
trying
to
implement
data
binding
into
Yui
and
the
ideal
with
Luke's
data
mining
plugin
was
that
it
would
be
able
to
work
with
almost
any
objects
in
my
life.
It
would
be
able
to
work
with
widgets.
It
would
be
able
to
work
with
models,
and
you
can
also
even
declaratively.
B
Do
it
in
your
HTML,
so
you
can
find
you
could
just
put
some
Marco
HTML
and
say,
like
I,
want
to
do.
Digga
bind
this
property
on
my
model
and
not
be
something
that
would
work
out,
and
so
that's
that
was
filed
under
issue.
Do
you
remember?
No
I
was
ancient,
though,
was
quite
a
ways
back
I
don't
have
that
number.
B
So
it's
pull
request
386
and
with
that
that
was
Allison
had
some
compatibility
for
progressive
enhancement,
which
is
something
that
we
do
need
to
support,
especially
even
though
we
have
all
this
like
JavaScript
on.
We
still
needs
to
be
able
to
support
older
browsers.
That
way,
there's
also
like
prior.
B
Of
sneak
up
with
is
one
right:
oh
well,
yeah
that
design
it
so
we'll
talk
more
about
that
in
just
the
bed,
but
so
the
under
Yui
based
data,
binding
library
was
it's
not
open
source,
but
it
was
presented
at
ue
conf
last
year,
so
miata
and
that
one's
being
used
at
Yahoo,
Finance
right
now
and
what
they
did
was
that
was
still
directly
on
top
of
the
app
framework,
and
for
that
one.
That's
also
done
like
completely
declaratively
using
HTML.
B
So
you
would
spine
what
a
specific,
like
specific
part
of
your
HTML
to
a
model
store
and
that
model
store
would
be
able
to
like
reach
out
and
grab
the
data
for
the
model
that
you
need
it.
And
so
those
are
like
the
two
ways
of
doing
like
data
binding
I
said
none
of
them
are
really
available
available.
B
Yet
so
to
keep
going
on
like
what
I
start
to
do
was
I
start
to
take
a
look
at
some
of
like
the
different
frameworks
that
already
implemented
data
binding
right
now,
and
so
that
included
angular,
ember
Batman
and
a
few
of
plugins
for
backbone
and
which
is
the
framework
that
the
Yui
app
framework
is
most
similar
to
and
I
try
to
take
a
look
at
how
they
did
data
binding
and
those
frameworks,
and
so
I
don't
know
eric.
C
B
Exactly
and
forum
almost
all
dose,
they
basically
have
some
sort
of
like
data
binding
it,
and
the
idea
is
that
you
would
put
a
lot
of
your
data
binding
attributes
into
your
HTML
markup,
and
you
would
be
able
to
find
a
certain
like
find
a
rendering
of
that
element
to
a
model.
In
that
way.
He
looked
at.
B
Gotta
figure
desktop,
oh
yeah,
sure,
actually,
okay,.
B
If
that
was
something
that
you
really
wanted
to
do,
and
so
how
I
wanted
to
integrate
that
into
Yui
was
that
we
would
be
able
to
make
something
that
would
be
an
extension
of
view
would
be
a
view
mix
in
so
with
how
you
use
models.
Think
that
rests
right
now
or
some
of
the
other
model
synchronization
plug
in
10
minute.
So,
like
mouth
ain't
got
local,
you
would
just
be
able
to
do
the
same
thing
of
a
view
so
mix
the
extension.
B
B
So
ideal
how
you
would
do
it
is
like
I
said
before
you
and
mixed
in
your
data,
binding
extension
with
your
view,
and
so
it
would
just
be
in
a
simple
extension.
It's
exactly
how
you
would
use
modeling
thought
rest
right
now.
I
said
instead
of
a
mile
mixin,
it's
a
few
mixing,
and
so
what
this
does
is.
It
adds
an
additional
objects
into
your
view
called
bindings,
and
so
what
findings
to
this
is
that
it
binds
a
specific
Dom
selector
to
a
specific
model
attribute.
B
So
in
this
case
title
the
title,
the
element
of
the
idea
of
title
binds
to
the
model
model
attribute
of
title
and
offer
would
bind
to
offer
name
and
so
that
you
can
also
do
computer
properties.
B
In
this
case,
you
could
a
set
an
element
of
an
idea
of
header
and
you
would
be
able
to
specify
different
functions
such
as
observe,
and
in
this
case,
this
array
of
attributes
would
mean
that
whenever
you
have
a
change
I'm
both
on
either
title
or
offer
me,
it
would
be
rendered
that
specific
element
and
so,
for
example,
how
this
would
work
is
that
will
use
the
most
like
common
data,
binding
example.
It's
that
whenever
you
change
offer
and
whenever
you
change
title,
then
this
entire
header
would
also
change.
B
So,
for
example,
if
I
change
the
title
to
the
old
man
tennessee,
this
would
also
immediately
update
so
there's
four
forms.
This
data
binding
plug-in,
does
two-way
data
binding,
which
is
whenever
your
model
changes.
This
will
reflect
the
change
inside
of
your
view
and
whenever
your
view
changes.
So
in
this
case,
whenever
I
change,
whatever
was
in
title,
it
would
also
reflect
the
change
inside
of
the
mall.
B
So
yeah,
so
that's!
Basically,
this
is
yes,
something
that's
going
to
be
coming
out
in
the
gallery
within
the
next
month
and
I'll
also
follow
it
all
with
a
blog
post
as
soon
as
it's
out
and
the
idea
behind
it
is
that
I'll
have
a
comparison
of
how
you
would
make
an
example.
You've
seen
the
regular
app
framework
and
how
much
simpler
it
is
doing
it
with
my
data,
binding
plugin.
The
those
elements
need
to
be
exist
at
the
point
where
you're
creating
this
so
yeah.
That's
for
data
binding
you
would.
B
B
Also,
looking
into
exploring
this
data
binding,
even
converter,
I
know,
Luke
has
something
that
works
with
both
model
and
widget,
and
a
lot
of
different
JavaScript
objects
right
now,
and
that's
something
that
I
think
has
a
lot
of
value
and
that's
something
that
we'll
keep
working
on.
So
we
can
create
an
even
better
data,
binding
plugin
that
works
with
all
of
Yui,
not
just
models.
C
B
So
there's
also
a
lot
of
like
low
level
stuff
that
I'll
be
working
on
in
the
next
print
so
stuff
that
modifies
some
of
the
event
components
that
we
have
right
now,
such
as,
like
event,
value
change
and
as
soon
as
I
get
those
merchant
accor
update,
the
the
gallery.
Module
I
have
to
work
with
those
new
things.
I
add
into
course
whoa.
So
with
no
time
do
you
think
you'll
have
this
out.
B
B
A
B
So
yeah,
so
that's
mostly
why
I
have
for
data
binding
for
now
we'll
definitely
keep
taking.
B
So
how's
this
time
back
into
the
overall
app
framework.
Okay.
So
how
does
that
tie
back
in
so
with
the
overall
afrin
without
they?
One
of
the
key
features
that
Simon
mission
was
missing.
Was
data
binding,
and
he
didn't
really
like
the
idea
of
having
to
render
his
own,
like
templates
and
Dom
elements
by
hand
every
single
time,
and
so
that's
something
that
I'll
be
focused
on
during
the
next
month
and
in
springs
continuing
past
this
to
just
making
it
easier
and
easier.
C
Yeah
I
guess
a
couple
things
that,
like
I'm
thinking,
is
in
applications
where
people
may
want
to
have
some
sort
of
controller
intermediary
that
actually
changes
the
model.
C
B
So
there
is
also
like
a
few
like
concurrency
issues
that
would
probably
want
to
consider
when
we're
dealing
with
like
synchronizing
data
over
like
a
remote
later
so,
for
example,
if
you're
having
a
rest
api
or
hitting
a
remote
database
or
anything,
that's
basically
not
going
to
be
synchronous.
That's
going
to
be
something
that
we
need
to
figure
out
like.
B
What's
the
best
way
to
do
a
data,
synchronization
layer
and
I
think
this
actually
like
a
leet
well
to
our
next
topic,
which
is
how
models
and
malice
work
right
now
and
the
idea
that
do
we
want
to
start
splitting
off
a
data
synchronization
layer
away
from
how
we
actually
store
the
data
inside
of
inside
of
JavaScript
right
now.
B
So
yeah.
C
Oh
I
mean
so
there's
some
there's
some
like
in
direction
there
now,
where
you
like
people,
can
implement
the
to
Jason
method,
to
transform
the
way
that
the
model
wants
the
D
to
represent
the
data
into
the
way
that
the
sink
layer
needs
the
data
represented.
So
there's
that
that
transformation
hook
that's
available.
What
were
you
thinking
that
to
go
beyond
that?
Well,.
B
I
guess
like
first
of
all,
maybe
we
should
like
just
give
some
background
on
this
light.
Do
you
want
to
talk
about
like
the
whole
model
and
malice
performance
improvements
that
we
were
trying
to
go
for?
Oh.
C
So
that
way,
if
somebody
is
simply
using
a
model
list
to
load
data
from
a
REST
API
and
then
render
that
directly
in
some
template
that
we,
you
don't
have
to
go
to
intermediate
model
X
before
then
going
like
starting
with
a
JSON
object,
going
to
model
objects
than
going
back
to
Jason.
To
avoid
that
intermediate
creation
of
all
these
more
heavyweight
model
objects,
and
instead,
just
you
know,
apply
the
jason
directly
to
the
template.
So
we
were
looking
at
like
how
we
could
apply
these
concepts.
C
B
The
idea
was
I
was
trying
to
create
smart
ma
Louis,
and
what
I
want
to
do
was
I
want
to
make
it
so
that,
if
you're,
if
you
were
just
trying
to
do
what
Eric
was
saying,
which
is
just
to
get
the
synchronized
to
data
from
a
sink
later
and
then
just
immediately
turn
out
those
models
and
render
them
as
a
template,
it
wouldn't
basically
convert
it
into
models.
It
would
just
keep
it
as
regular
JavaScript
objects
in
memory
until
you
were
able
to.
B
B
The
problem
that
we
realized
and
there's
a
very
long
discussion
on
you
even
trip
about
that,
was
that
when
we,
because
of
how
mollis
works
right
now,
it's
very
difficult
to
do
that
and
maintain
backwards
compatibility
at
the
same
time,
and
we
know
that,
like
a
lot
of
people
are
already
using
mollis
and
building
on
top
of
my
list
too,
and
don't
even
building
like
bigger
frame
works
on
top
of
the
Yui
a
framework.
So
that's
something
that
we
didn't
want
to
do.
B
We
didn't
want
to
break
easy
and
so
Ryan
suggested
Ryan
and
want
to
just
a
few
different
things
which
were
talking
about
different
approaches
that
we
could
start
taking,
which
the
app
framework
and
some
of
them
do.
We
know
link
again
yeah.
B
Okay,
I'm,
not
all
right
and
so
basically
sums
of
proposals
that
Orion
mention
or
the
idea
that
it's
I'm
there
go
yeah
and
some
of
the
proposals
that
Ryan
mentioned
was
like.
We
said
before,
separating
the
how
we
get
how
we
do
data
synchronization
with
how
we
actually
like
sore
JavaScript
data
and
using
components
such
as
like.
Why
not
tree
to
manage
like
you
hierarchies
and
different
options
like
those.
B
B
Like
the
idea,
how
suggested
was
using
a
wideout
property,
which
is
a
why
I
component
in
smug
months,
version
of
white
rock,
which
is
just
a
thin
layer?
Over
Y
dot
define
property,
and
in
that
case
you
would
be
able
to
use
regular
JavaScript
objects
and
you
would
be
able
to
do
getters
and
setters
using
thought
property
strived
and
having
to
use
the
get
and
set
API
that
we
have
right
now.
B
C
My
feeling
about
that
is
that
they
get
inside
api's
are
actually
valuable
and
what
they
communicate
and
that
I
can
see
in
one
talked
about
this
as
well.
I
believe
it
was
a
different
thread
where,
where
this
kind
of
came
up
with
this
idea
of
you
like
how
attribute
right
now
or
any
base
based
object,
has
this
underlying
state
object
it
uses
for
a
backing
store
to
have
that
thing?
C
C
B
Basically,
while
thinking
of
was
making
them
more
like
generic
API
on
top
of
on
top
of
how,
on
top
of
like
I,
owe
or
even
just
some
sort
of
like
standard
data
accessing
interface
that
we
can
use
and
I
was
hoping
that
we
would
be
able
to
use
that
using
promises.
For
instance,
like
a
very
simple
promises
based
API
to
just
to
get
data,
set
data,
delete
data
and
update
data,
just
something
really
simple
and
a
really
simple,
like
API
class,
that
we
can
use
to
do
that.
B
B
Okay,
hi
my
name
at
this
time,
so
yeah
so
I
love
to
get
your
feedback
on
this,
like
one
of
the
things
that
I
was
thinking
about,
making
was
making
a
very
simple
like
just
a
generic
data
access
interface
and
make
it
all
promises
space.
So
I
was
wondering
like
what
you
would
think
about
doing
something
like
that.
F
I
can
quite
get
the
picture
what
you're
thinking,
but
each
other's
process
is
that
they're
expensive
to
to
play,
so
I
won't
use
promises
for
for
something
like
I
do,
a
change
just,
but
maybe
for
up
global
change,
but
but
it
still
armed
we're
talking
about
a
things
that
changed
state
and
communicate
the
way
error
when
they
change
it
and
promises
are
actually
four
bodies
that
don't
change
if
they
read
the
value.
I
want
the
two
way
to
create
them.
They
stay
that
way.
B
So
one
of
the
things
that
I
guess
I'll
give
a
more
specific
amps
specific
example.
So
once
you
finish
that
angularjs
and
my
soul
shall
protect
you
yeah
sorry.
B
They
have
a
idea
of
this
resource
API
and
the
resource
API
is
really
simple.
The
idea
behind
the
resource
API
is
that
everything
is
promised
based
and
so
and
the
object
that's
returned
has
all
these
functions,
that
all
return
promises,
so
Dave
get
save
query,
remove
and
the
league
and
the
idea
behind
that
is
that
so
you
would
be
able
to
chain
actions
in
this
way.
B
So
if
I
want
to
say
like
get
all
the
objects
with
like
I,
don't
know
with
a
class
of
this
and
then
update
done
with
this
value,
you
would
be
able
to
change
that
using
promises
and
I
want
to
build
something
like
this,
but
make
it
generic
so
that
it
works
with
things
other
than
rest
api's,
something
that
works
with
any
sort
of
data
storage
right,
whether
it's
asynchronous
like
a
REST,
API
or
synchronous
like
local
storage,
yeah.
C
C
Then,
how
would
this
connect
in
with
like
with
the
model
objects
like?
How
are
you
thinking
that
would
work?
Would
it
be
completely
like,
like
on
its
own,
where
somebody
manually
wires
these
two
things
up
or
would
the
model
like
class
contain
some
sort
of
resource
instance
that
it
would
use
or
possibly
yes,
I
will
I
was
thinking.
B
E
B
B
B
C
That's
where
I
was
wondering
if
what
you're
trying
to
say
is
that
you
can
imagine
creating
your
model
subclass
and
then
defining
even
on
the
prototype.
If
you
wanted
an
instance
of
one
of
these
resource
classes,
that
uses
like
in,
like
the
one
you're
showing
or
similar
to
model
sink
rest,
how
it
uses
this
now,
like
these
placeholders
in
some
URL
or
some
resource
identifier,
and
then
what
it
could
do
is.
C
You
would
have
one
instance
for
the
entire
class
and
then
the
save
would
basically
you
know,
I'm
guessing
save
in
this
case,
you
give
it
some
data,
I,
don't
know
how
they're
linking
together
and
the
thing
you're
showing,
but
essentially
what
you
could
do
is
end
up,
creating
a
new
request
for
that
resource
inside
of
the
models
Sinclair,
that's
using
this,
and
that
way
it
could
be
independent
of
what
Sinclair
you're
using
because
it's
just
this
one
of
these
resource
objects.
I'll
expose
the
same
interface
exactly.
A
B
F
Something
that
that
I
think
trying
to
get
into
we
talked
about
it
with
Caribbean
Citians
or
something
about
a
why
the
DB
yeah
way
of
tweaking
a
JavaScript
are
two
dresses
that
database
underneath
it
could
make
a
red
sock
to
rest
api
or
talk
to
the
video
conf.
I
look
at
the
storage.
B
Exactly
I
think
you
did
like
a
lot
of
work
on
that
too.
So,
if
you
have
like
I,
do
you
still
have
your
own,
but
just
that
you
had
from
a
while
back
like
if
you
want
to
show
that
like
that
would
be.
We
could
talk
about
like
how
we
can
start
integrating
like
different
things
together.
So
I.
F
Think
either
the
only
thing
that
sorry
I
was
just
wanting
anything
go
ahead:
yeah,
okay,
the
only
thing
that
I
better
go
to
write
was
some
an
abstraction
layer
or
two
different
types
of
of
databases.
Like
a
index
TV
well
secure,
I,
local
storage,
we
still
needed
there
did
the
work
to
to
work
on
our
recipe,
ice
and
I'm
to
attract
different
kind
of
I.
F
All
stuff,
like
this
latency
conversation,
a
lot
of
things
we
talked
about,
so
it
just
say
the
basic
abstraction
layer
over
a
web
databases,
but
I
think
Satyan
had
something
worked
out
on
that
that
he
hadn't
open
source.
Yet
so
it's
the
one
that
we
should
be
talking.
So
thank
you.
Yeah.
C
You
know
I,
think
that
would
be
interesting
to
look
at
for
the
the
database
abstraction
stuff,
but
I
wonder
if
this
thing
would
still
sit
on
top
of
that.
That
would
be
like
a
low-level
library
that
that
this
sort
of
thing
clearance
is
talking
about.
Could
leverage?
Are
you
Clarence?
Are
you
talking
about
the
rest
resource
in
here
the
one
yeah,
but
I
watch
the
job.
If
you
go
to
that
one
is
that,
though
I
forget,
if
that's
the
thing
I
wrote
one
of
these
like
a
few
years
ago.
B
Sorry,
sorry
I
totally
miss
what
you
said.
Could
you
know.
A
B
The
idea
behind
it
by
separating
out
how
we
synchronize
data
with
how
you
actually
have
a
day
later,
you
would
be
able
to
if
you
want
to
have
like
a
simple
use
case
such
as,
like
we
talked
about
before
loading
data
from
some
external
source
and
then
just
rendering
it
directly.
You
don't
need
to
go
through
the
entire,
creating
a
model
list
creating
a
mullis,
because
that
would
be
expensive,
and
in
this
case
this
would
just
keep
everything
in
plain,
JavaScript
objects,
and
you
would
be
able
to
handle
like
that.
B
C
B
A
B
This
morning,
if
you
wanted
to
like
the
idea
of
so
I
guess
right
now,
it's
hard
to
switch
between
model
extensions
like
switch
between
Sinclair's,
as
unless
you
use
this
multiple
model
same
gallery
module.
So
if
you
had
like
a
different
resource,
module
like
mine,
now
I
make
that
a
lot
easier
right,
cuz
you're,
putting
yourself
filled
in
between
yeah,
exactly.
C
C
You
could
swap
it
out,
it
would
affect
all
of
them
or
you
could
give
each
instance
its
own
copy
of
a
resource
object
if
you
needed
to
for
some
reason,
yeah
like
if
it
wasn't
generic
and
offer
you
had
to
do
something
different
yeah,
it
seems
that
seems
good
to
do
it
would
it
gives
us
a
chance
to
read
like
especially
for
the
one
that
would
use
X
hrs
to
revamp
all
that
code?
That's
trying
to
do
X,
hrs
with
cores
and
all
that
fun
stuff.
B
F
No
I
think
they're
very
much
a
gay
for
for
a
scene
player
on
the
browser,
I'm,
not
sure,
oh
well,
I
I
think
it
would
have
been
a
lot
on
how
you
use
it
if
you're
going
to
do
it
on
in
old,
but
the
there
are
things
that
can
be
done
to
improve
their
performance,
but
everything
that
I've
tried
so
far
I
slowly
reduce
our
marginal
gains.
So
I
hadn't
run
into
anything
that
that's
radically
better,
because.
A
F
F
F
C
So
the
only
thing
we
were
we've
been
looking
at
is
like
when
on
the
server
like,
if
you
you
want,
one
approach
could
be
to
use
just
standard
JavaScript
functions
in
a
callback
mechanism
like
a
node,
but
then,
if
you
have
like
a
ton
of
asynchronous
stuff
going
on
that,
can
get
complicated
the
next
step.
A
lot
of
times
is
for
people
to
use
something
like
the
async
library
in
nodejs.
C
It's
one
of
the
most
popular
modules
or
another
approach
you
could
take
for,
especially
for
like
the
implementation
details
of
some
API
is
to
use
promises
to
manage
your
values
and
use
it
as
a
control
flow
library,
and
people
were
wondering
what
the
performance
impact
would
be,
and
it's
clear
that
that
the
you
know
the
basic
JavaScript
functions
are
going
to
be.
You
can
write
those
to
be
the
most
performant,
but
the
trade-off
there
is
like
how
well
your
code
is
maintainable
like.
C
Is
it
just
crazy
that
you
go
back
to
the
week
later
and
you
have
no
idea
what
it's
doing
and
then
we
are
looking
at
like
I
started,
looking
at
the
implementation
details
of
a
sink
and
it's
actually
very
complex
like
it's?
Not
it's
not
very
simple.
Oh
does
a
lot
of
stuff,
and
then
you
look
at
like
the
implementation
of
like
what
you
did
with
promises
and
they
seem
somewhat
on
par
as
long
as
the
timing,
the
timer
mechanism,
to
make
it
a
sink.
C
B
F
B
Do
you
think
it
would
be
able
to
help
me
out
with
that
light?
Well,
we
would
like
to
like
really
benchmark
like
the
performance
of
just
like
regular
call
backs
versus
promises
in
this
case.
That's
something
that
we
really
wanted
to
do,
especially
on
JSI.
So
that's
something
that
would
be
really
nice
to
have
you.
C
B
All
right,
I,
guess
I
think
we've
talked
a
lot
about
this
I
guess
we
should
start
talking
about
more
like
concrete
stuff
like
I,
guess,
Eric.
You
have
like
a
where
we
should
talk
about
like
what
we
want
to
work
on
for
next
print
since,
like
we
just
had
a
release,
so
we're
going
to
start
working
on
more
like
why
do
I
app
framework
stuff
for
the
coming
release?
So
do
you
want
to
start
off
with
that
yeah.
C
So
the
the
primary
thing
so,
okay,
so
first
of
all,
we
got
in
some
new
feet
a
new
feature
in
a
into
router
to
be
able
to
handle
router
parameter.
So
this
can
help
with
validation
and
formatting
of
parameter
values.
This
is
like,
if
you
imagine,
a
route,
that's
posts
with
some
ID
to
you
know
to
show
some.
You
know
a
route
handler
that
can
show
any
post
and
it's
based
on
the
ID,
but
maybe
that
ID
needs
to
be
a
number
you
can
use
on
your
router
instance.
C
You
can
say
router,
dot,
/
am
and
and
name
it
like
post
ID
and
then
give
a
like
a
function
that
does
parse
int
on
the
string
value
and
make
sure
that
it's
a
number.
And
so
we
added
this
in
and
one
of
the
primary
reasons
is
in
single
page
applications
that
have
an
initial
page
being
rendered
on
the
server
and
passing
along
the
configuration
and
state
data
that
the
client
side
of
the
application
needs
to
take
over
control
and
run
from
there
and
minimize
full
page
reloads
by
doing
html5
push
state
stuff
through
router.
C
So
we're
looking
at
like
one
of
the
primary
things
here
is
expressed
j/s
on
the
server
and
wanted
to
be
able
to
have
a
way
to
implement
one
of
the
features
that
express
j/s
has,
which
is
this
app
dot
programs
idea
into
router.
So
we
have
that
in
and
that's
really
to
help
people
who
are
trying
to
share
route
configurations
on
the
server
and
client
so
that
they
can
have
the
client
side
router
behave
and
act.
The
exact
same
way
that
their
that
it
does
on
the
server.
C
So
if
there's
no
mismatch
there
so
and
then
it's
just
in
general,
a
great
feature
to
have
in
router
for
for
various
little
formatting
or
validation
things
on
route
parameters,
so
that's
cool,
but
then
one
of
the
bigger
the
big
chunk
of
stuff
that
we
need
to
get
in
and
I'm
going
to
be.
Dedicating
time
to
this,
this
coming
sprint
sprint.
Ten,
I
guess
we're
calling
it
is
looking
at
what
happens
in
when
you're,
using
wideout
app
with
anything
more
than
a
trivial
application.
C
C
The
URL
changes
it
just
batches
through
the
routing
mechanism
and
you
swap
out
of
view
dynamically
and
you
can
use
transitions
and
all
the
stuff,
but
you're
really
only
limited
to
one
slot,
and
that
is
limiting
and
people
may
want
to
have
their
header
defined
as
a
view
that
also
gets
swapped
out
or
their
footer.
Or
what
more
likely
is
within
that
body?
It's
it.
C
The
application
is
more
complex
than
just
needing
or
just
wanting
to
be
represented
in
one
big
large
view,
that's
trying
to
do
all
the
things,
but
instead
having
nested
view,
so
each
little
part
of
the
that
page
can
can
be
concerned
about
its
own
section
of
the
user
interface.
And
so
this
nested
view
concept
is
something
that
the
wideout
app
has.
C
But
it
only
supports
you
know
one
child.
At
a
time-
and
you
can
choose
which
child
view
show
in
there,
so
what
we
want
to
do
is
that's
proving
really
useful
to
people
in
it
and
it
breaks
down
quickly
when
you
need
something
more
complex,
you
have
to
roll
your
own
parent
child
view,
management,
stuff
and,
since
app
already
has
a
lot
of
this.
What
we
want
to
do
is
extract
that
view
management
features
out
of
what
app
and
make
it
a
view.
C
If
you
look
at
the
implementation,
is
actually
a
big
mixing
of
a
lot
of
these
features
of
a
view
of
router
of
pJAK
space
and
and
some
of
its
own
stuff,
mainly
some
of
its
own
stuff.
Is
this
view
management
piece
being
able
to
pull
that
out
and
make
it
an
extension?
That's
usable
on
just
any
of
you
will
be,
will
be
really
powerful
for
for
people
who
are
have
anything
more
than
just
a
trivial
app
and
how.
B
C
Weird
other
way
around
what
would
be
the
other
way
around
where
the
the
child
would
render
and
then
cause
the
parent,
so
I
think
it
would
be
a
top-down
approach,
probably
how
I
would
want
to
have
it
set
up
where
the
a
parent
would
render
and
the
child
user
Brender.
But
instead
of
you,
people
having
to
still
manually
wire
that
stuff
up
or
you
know,
call
into
the
child.
Be
renderings.
C
B
C
For
like
a
flow
control,
these
you
mean
you
can
basically
think
of
this.
I
mean
it
really
does
fit
into
a
tree
like
structure,
and
you
could
think
of
it.
Just
like
the
Dom
look,
it's
it's
analogous
to
the
Dom
here.
It's
just
that
there
are
certain
sections
here
that
are
rich
and
represent
conceptual
chunks
of
the
UI,
but
they
would
be
chained
together
in
a
similar
way
that
event
bubbling
works
in
the
Dom
for
Dom
events.
C
A
C
I
mean
that
that's
something
that
I
explored
a
while
back
and
looked
at
and
really
what
I
think
people
want
to
do.
There
is
not
have
to
define
all
of
their
routes
and
route
handling
in
one
file
in
one
module,
but
instead
be
able
to
maybe
load
that
stuff
on
demand
is
needed
or
be
able
to
separate
it
in
a
sane
way,
and
so
I
think
that's
the
primary
use
case.
C
There
is
to
figure
out
how
how
people
can
easily
separate
out
the
finding
chunks
of
their
application
into
conceptual
modules
that
then
are
linked
together
somehow
but
yeah
the
the
idea,
the
other
idea
we
can
look
at
for
the
nested
apps
for
the
the
one
problem.
There
is
there's
only
one
URL
so
having
a
nested
app.
We
don't
necessarily
want
it.
Two
things
to
be
competing
for
what
the
URL
should
be.
C
C
I'm
not
like
I'd
want
us
to
look
at
use
cases
there
to
figure
out
if
it's
really
necessary
or
if
really
what
people
want
to
do
is
just
not
have
all
their
route
handlers
to
find
it
in
a
single
file
which
I'm
guessing
is
the
more
common
thing
here,
but
yeah
so
I
think
the
the
extract,
miss
v
management
stuff
and
making
it
available
to
any
view
and
then
expanding
it
from
one
to
any
number
of
regions
will
be
pretty
powerful
for
new
people.
So.
C
I
started
thinking
about
that.
It
feels
like
somewhat
of
a
natural
fit
I'm,
just
wondering
if
that
data
structure
really
is
just
a
behind-the-scenes
thing,
because
you
also
have
the
Dom
tree
and
like
do
you
have
these
views
are
sort
of
in
space
connected
in
several
ways:
they're
connected
to
particular
Dom
nodes
that
are
in
some
sort
of
hierarchy,
they're
also
connected
through
a
vent
bubbling,
which
is
another
hierarchy
and
just
thinking
like
do.
We
need
a
third
hierarchy
there,
which
is
like
a
tree
representation
of
them.
A
C
B
C
My
sense
is
that
applying
this
concept
of
multiple
regions
will
make
this
a
lot
hairier
than
just
what
it
is
now
and
why
that
app,
which
is
fairly
simple
for
the
single
region
most
of
the
code,
is,
is
in
the
thing
that
processes
the
declarative
configuration
for
views,
so
that
configuration
is
going
to
be
more
complex.
So
I
want
to
be
able
to
rethink
that
and
think
how
we
can
do
something
that
makes
sense
when
you
have
regions
and
which
things
are
available
to
go
into
those
regions
and
and
how
that's
defined.
C
But
hopefully
the
idea
is
that,
then
you
know,
especially
with
like
the
data
binding
stuff,
you
could
almost
imagine
looking
at
a
view
subclass
seeing
the
definition
of
its
regions
and
it's
possible
views
that
could
fit
into
those
regions.
It's
events
that
its
handling,
it's
Dom
events
and
then
also
like
its
its
binding
relationships
between
between
a
model
or
model
list,
or
something
that
it's
that
it's
trying
to
represent
yeah.
B
Like
to
release
what
I
have
for
data
binding
into
the
gallery
right
now,
by
the
same
time,
I
also
want
to
work
into
improving
things
within
core
to
start
preparing
for
either
a
better
way
of
doing
data
binding
or
doing
like
just
integrating,
like
smaller
parts
like
ripping
out
parts
from
the
data
mining
plugin
and
having
people
be
able
to
use
that,
for
example,
with
event
value
change,
for
instance,
which
is
being
used
in
autocomplete
right
now.
That
only
works
for
text
inputs
right
now.
B
As
far
as
I
know,
and
I
like
to
extend
that
to
basically
all
the
new
like
elements
that
we
have
right
now
or
any
like,
such
as
light
selects
and
options,
because
that's
something
that
we
really
useful
to
have
when
doing
data
binding.
So
whenever
you
have
a
change
in
vent
and
something
that
when
you
ever
something
changes
in
something
that
I
user
can
input,
that's
going
to
be
a
core
feature.
That
would
be
useful,
whether
or
not
you're
using
data
binding
or
not.
Yeah.
A
D
C
Yeah
so
I
think
what
my
my
plan
is
to
when
we
start
this
sprint
to
come
up
with
some
initial
I,
usually
work
best
if
I'm
like
trying
to
build
something,
also
write
the
code
in
sort
of
a
loose
fashion
to
like
sort
of
a
happy
fashion
to
really
feel
out
the
ideas,
and
then
I
think
I'll
be
at
something
where
I
can
propose
like
an
implementation
strategy
and
like
a
feature
set
strategy
that
I
want
to
go
with
and
the
way
to
maintain
backwards,
compatibility
and
go
through
like
why
you
I
can't
rib
for
a
lot
of
that
stuff.
C
A
More
question
if
he
were
done
yeah,
so
this
is
sort
of
philosophical
question
I
want
to
propose
to
both
parents
and
everyone
else
to
the
team.
I
feel,
like
you
know,
we're
talking
about
a
framework
in
general,
but
if
we
sort
of
think
step
back
to
the
YY
in
general,
what
are
the
sort
of
things
you
see?
Are
the
future
of?
Why?
A
D
C
So
I
think
the
the
thing-
the
thing
that's
interesting
is
that
there's
a
couple
major
shifts
coming,
where
which
I
think
will
be
major
shifts
and
how
people
are
developing
stuff-
and
you
know
at
the
time
Yui
3
was
written.
Stuff
didn't
exist
like
a
module
system
that
was
ubiquitous
or
a
or
that
worked
everywhere
or
they're.
Really
there
wasn't
no
Jas
there.
There
wasn't
this.
C
The
this
like
people,
doing
advanced
script,
loading
things
and
combo
handling
and
an
internationalization
and,
and
so
a
lot
of
this
this
stuff.
You
know
these
core
principles
that
are
that
are
Yui
has
been
built
around
especially
Yui
3
I.
Think,
what's
great
is
that
these
are
still
these
are
getting
validated
everyday.
C
By
seeing
these
new
standards
come
up
like
es6
modules
like
the
ACMA
script,
internationalization
specification
and
and
that
being
implemented
in
a
lot
and
some
of
the
browsers
on
the
edge
and
seeing
like
a
a
validation
here
of
like
that
yeah,
the
core
principles
that
Yui
is
built
around
are
are
are
still
like,
holding
strong,
but
how?
How
do
we
play
in
this
new
world
better?
C
And
you
know
looking
at
what's
coming
what
one
of
the
biggest
things
I
think
is
this
this
you
know:
sort
of
Holy,
Grail
or
universal
module
system
through
the
es6
modules
and
being
part
of
the
language
and
being
able
to
have
a
higher
like
making
it
way
easier
to
have
interoperability
and
the
new
module
system.
I
think
also
can
enable
some
sort
of
abstractions
such
that
we
can
still
continue
using
the
library's
we're
using
today,
through
Yui
or
through
AMD
or
through
node
jss
module
system.
C
But
in
this
this
new
es6
world
and
also
be
able
to
author
our
application
code
in
the
es6
module
syntax,
which
can
be
statically
verified
and
is
pleasant
in
heaps
metadata
alongside
the
actual
code
which
right
now
and
yui,
we
have
that
separated,
which
is
a
sort
of
a
pain.
So
I
think
that
these
these
things
are,
like
you
know,
are
coming
to
a
head
and
going
to
be
really
interesting
for
this
idea
of
being
able
to
write
application
code.
C
A
C
B
B
I
know
that
geo
and
Eric
are
already
doing
like
a
lot
of
stuff,
with
getting
a
pure
CSS,
for
instance,
to
work
with
power
and
I'd
like
to
do
the
same
thing
with
a
yeoman
right
now
and
by
that
like
making
yeoman
generators
so
that
you
can
scaffold
up
like
a
Wi-Fi
app
framework
application,
using
like
some
of
the
Express
modules
that
we're
building
out
right
now
or
even
if
you
want
to
integrate
together,
the
Wi-Fi
app
framework
and
the
mojito
framework.
For
instance.
C
Yeah
I
think
yeah,
and
you
could
even
imagine
like
in
even
you
know
now
and
today
and
like
there
may
already
exist
one,
but
a
yeoman
generator
for
just
getting
a
Yui
module
set
up
for
you
as
well,
so
yeah,
so
I
think
that
that
tooling
is
pretty
interesting
and-
and
yes,
so
you
mentioned
some
of
the
bower
stuff.
C
So
Bauer
is
this:
a
package
manager
for
front-end
assets
like
that's
its
focus,
and
it's
really
more
like
the
penalty
resolution
and
fetching
mechanism
that
really
works
more
as
like
a
plumbing
and
you,
you
can
usually
build
things
on
top
of
it
like
yeoman
uses
it
under
the
hood
I
believe
right.
C
We
can
start
pulling
in
pure
and
using
like
pure
base,
which
is
normalized
and
then
pure
grids
which
to
replace
Yui,
3
grids
and
but
then
be
able
to
contextualize
it
such
that
you
know
we
can
still
have
the
Yui
3
dash
prefix
on
the
CSS
class
names
and
like
this,
this
interoperability
will
well
like
are
using
these
tools,
will
just
help
like
integrate
these
pieces
a
little
better.
We
don't
have
to
build
the
tools
to
do
it
and.
B
We
also
want
to
make
it
easier
for
people
to
use
like
external
libraries.
I
know
this
was
a
big
thing
at
the
last
you
account,
for
instance,
you
want
to
come
all
the
way
for
people
that
say
like
if
you
want
to
use
like
this
micro
library,
for
instance,
with
a
Yui.
We
want
to
make
it
like
as
simple
as
possible
like
right
now,
I'm
thinking,
Ryan's
old,
talk
in
Ryan's
talk
last
year,
though,
he
talked
about
how
you
would
use
like
an
external
library
of
Yui
and
it's
a
little
funky.
It's
not
something.
B
That's
like
well
documented,
and
it
might
be
nice
having
like
some
sort
of
sugar
on
top
of
that.
That
would
be
something
that
would
make
it
easier
for
people
to
start
looking
past
Yui
if
they'd
like
something
that
red
basically
and
so
we
don't
need
to
like-
have
to
create
a
different
Yui
module
for
everything
else.
Right
like.
A
C
Exactly
that's
like
the
a
mind
shift
thing
they
can
have
to
is
we
we
may
not
even
have
to
wrap
things
in
Yui
modules
and
at
some
future
time,
but
then
not
only.
That
is,
if
we
don't
have
to
do
that,
and
it's
easier
to
use
these
other
things.
We're
going
to
be
more
inclined
to
not
try
to
like
write
our
own
implementation
of
those
ideas,
role.
C
Well,
so
I
think
that
the
bower
thing
in
the
gallery
is
an
interesting
combination,
especially
since
primarily
Yui
modules
are
focused
for
lettering.
The
gallery
are
focused
in
the
browser,
so
I
I
see
that
as
being
a
pretty
interesting
combination
there
to
help
people
pull
things
together
and
manage
the
dependents
like
resolve
dependencies
across
them
like
if
ass
gallery
module
depends
on
this
one.
B
To
handle
it
and
that's
why
I
think
we
meet
the
sugar
as
well
like
a
common,
like
pain,
point
that
people
often
talking
about
it's
at?
Why
isn't
as
easy
is
to
use
that's
just
like
jQuery
clinic
number,
my
script,
I'd
and
you're
ready
to
go,
but
now
that
we
have
power,
you
might
be
able
to
do
like
something
more
than
that.
A
B
A
Well,
it's
10
after
three
and
another,
some
people
have
some
time
constraints.
So
do
we
have
any
questions
or
items
willing
to
bring
you
up
before
we
close
down?
I
think
this
is
one
of
the
best
roundtables
we've
had
a
long
time.
I
want
to
thank
everyone
its
it
that's
come
to
this
today,
especially
Eric
and
Clarence,
because
you
guys
are
I
mean
having
great
content
is
awesome
because
it
helps
this.
This
video
ever
wanted
thing
will
continue
to
play.
A
You
know,
weeks
from
now,
and
people
who
aren't
able
to
be
in
this
time
zone
be
able
to
pick
up
on
this
and
be
able
to
comment
on
this
soap,
and
why
should
the
final
question
for
you
guys
is?
How
do
people
give
you
feedback
on
what
they
heard
today?
Did
it
go
to
the
contributor's?
They
sent
message
you
directly
or.
B
C
Yeah
definitely
they
can't
read
mailing
lists.
I
I've
been
in
a
state
where
I'm
like
horrible
at
checking
email,
but
since
all
the
content
in
the
contributor
mailing
list
is
always
really
good,
I
always
check
it.
I
just.
A
Want
to
add
one
final
plug
that
our
PHP
be
be
based.
Forums
are
going
away.
So,
if
you
are
involved
in
those
right
now,
I
encourage
you
to
switch
over
to
the
new
google
groups
based
forums
which
are
related
to
my
crib.
So
soon
they
will
be
going
away
so
feel
free
to
switch
over
again
thanks
everybody
for
coming
and
I'm
going
to
close
things
out,
yeah.
F
I
just
got
a
comment
at
a
nice
you've
heard
of
the
gucci
framework.
Yeah
they
have
a
script
loader
for
AMD
model
is
called
car
yeah.
I
just
heard
from
from
one
of
the
developers
that
you're
switching
focus
into
what
I
understand,
sir
I
near
61,
loader
polyfill.
So
that's
definitely
something
on
more
than
our
our
tender
yeah.
C
I
I
saw
that
I
have
they're
there
to
john
tweeted
out
who's
on
script
level,
on
twitter,
a
couple
posts
and
and
yeah.
I
want
to
sync
up
with
him.
He
actually
lives
in
the
boston
area.
So
I
see
him
at
a
lot
of
different
meetups
and
various
things
so
yeah
I
should
I
should.
I
want
to
read
that
and
sync
up
with
him,
because
I
think
that
you
know,
but
in
the
talks
at
him
and
I've
had
about
es6
module
stuff.