►
Description
Open Round Tables feature weekly hangouts on, javascript, YUI, and other front end technologies.
Links referenced in the video:
https://gist.github.com/ericf/6133744
https://github.com/imalberto/photonews
https://github.com/joyent/node/issues/6371#issuecomment-41347745
A
Hey
everybody
welcome
to
the
next
yy
open
round
table
for
thursday
may
1st
we
have
with
us
eric
ferrellio
and
kari
patino
are
going
to
talk
about
updates
and
new
features
and
new
things
about
the
mo
down
project
kerry.
I
want
to
ask
you
is
so
I
guess
tomorrow's.
My
second
are
you
gonna
celebrate
cinco
de
mayo.
A
we've
got
a
lot
of
updates
for
loader,
and
we've
got
some
new
things
coming
on
from
tilo
we're
looking
at
potentially
adding
a
hammer
js
as
in
place
substitution
for
some
of
the
event
stuff,
the
touch
events,
it's
not
backwards
compatible
so
for
a
while
there'll
be
it'll
they'll,
be
both
both
modes
hammer.js
and
the
old
mode.
Until
we
get
the
deprecation
process
going
outside
of
that,
I
think
we're
ready
to
go
ahead
and
start
talking
carried
if
you're
ready
to
go.
B
B
What
it
really
is
is
a
collection
of
components
and
packages
to
help
to
really
help
people
build
and-
and
we
mainly
focus
on
the
server
side
of
things,
but
to
really
help
people
build
out
the
server
side
of
their
their
their
web
projects
and
their
their
front
ends.
And
it's
like
the
server
side
of
the
front
end,
and
so
it's
really
focused
on
node.js
being
the
low-level
platform
and
then
building
some
components
on
top
of
node.js.
B
Trying
to
build
and
not
not
re-implementing
a
lot
of
these
common
things
that
every
web
application
ends
up
needing
to
do
so
so
one
of
the
the
major
the
major
focuses
we
did
was
build.
We
built
a
lot
of
these
components
in
a
very
modular
way:
they're
all
open
source
they're
all
on
npm
on
github,
but
we
we
looked
at
what
what
like
application
frameworks?
A
lot
of
teams
are
using,
and
the
teams
inside
of
yahoo
and
and
express.js
was.
It
was
definitely
by
far
the
most
popular.
B
So
a
lot
of
the
things
we
did
were
to
try
to
cater
around
making
making
that
better
for
people
and
and
providing
building
blocks
that
that
extend
what
express
does
and
well
so
we
don't
actually
have
a
a
website
or
product
or
whatever
modon's
like
the
code
name.
But
if
you
go
on
npm
and
you
search
for
mowdown
as
a
keyword,
you
will
find
a
lot
of
the
libraries
I
think
I'm
trying
to
do
it
right
now.
Keyword
colon
modem.
No,
let's
see
that
I
think.
B
Yeah
I
was
trying
to
get
it.
Where
is
the
keyword
here?
We
go
yeah,
so
so
the
types
of
things
we
have.
If
you
look
look
in
there,
there's
a
lot
that
are
around
express,
and
so
one
of
the
the
core
motown
components
that
we
have,
that
I
can
definitely
talk
to
is
is
one
called
express
state
and
the
idea
behind
express
state
is
to
be
able
to
share
the
server
side
state
data.
B
That's
either
configuration
or
data
that
the
server
may
have
gotten
from
some
backend
api
and
that
it
used
to
render
the
initial
page
and
be
able
to
use
this
data
and
and
pass
it
along
to
the
client
side
of
an
application.
So
a
lot
of
everybody's
really
moving
towards
this
idea
of
having
rich
client-side
javascript
applications
using
html5,
push
state
and
routing
on
the
client
and
all
this,
but
to
provide
the
initial
page
load
a
lot
of
times.
B
B
Do
things
like
put
yui
in
debug
mode
when
you're
in
development
and
put
it
in
production
mode
off
the
cdn,
when
you're,
when
you're
working
in
production
and
be
able
to
add
your
custom
modules
and
all
that
configuration
and
just
make
sure
that
that
it's
all
passed
to
the
client
and
that
you
will
load
yui
on
your
page
efficiently
as
asynchronous
as
possible
to
not
block
rendering
of
the
other
content
on
the
page
and
just
really
help
bootstrap
yui?
So
they
work
really
well
together.
In
that
way,.
B
Yeah,
so
the
data
the
data
sent
on
twice,
I
should
have
elaborated
on
that,
so
the
idea
with
express
data
is
to
make
that
data
very
accessible
to
javascript.
So
what
it
wants
to
do
is
it
puts
a
json
blob
inside
of
a
script,
a
script
element
on
in
the
html,
and
that
makes
it
very
easy
to
to
access
that
data
in
a
namespace
fashion.
So
you
do
like
window.app
or
whatever
you
want.
The
top
level
object
to
be
dot.
B
You
know
models
and
or
like
dot
photos
or
something
like
that
and
say
that's
an
array
of
like
data
that
represents
photo
models
or
something
that
you
can
use.
So
it's
this
idea
of
serializing
the
data
across
the
wire,
and
so
that
does
have
duplication,
especially
if
you're,
rendering
that
same
data
in
the
html.
But
luckily,
when
you
gzip
things
it
more
or
less
covers
that
that
overlap.
For
the
most
part,
it
adds
about
a
25
overhead,
even
though
you're
doubling
the
data
in
theory.
A
B
B
But
this
idea
of
creating
these
building
blocks
is
really
like
what
we've
tried
to
model
mojito
around.
It's
like
okay,
there's,
this
common
problem.
We
needed
to
send
this
data,
this
data
around
configuration
and
state
data
and
then
there's
another
big
common
problem
that
we
saw,
which
was
like.
We
need
to
make
it
much
easier
to
configure
yui,
especially
when
you
have
your
own
custom
modules
and
really
integrate
that
in
with
your
application,
and
that
also
needed
to
pass
along
this
configuration
data
about
yui's
configuration
to
the
client.
B
So
this
is
where
we
start
adding
up
these
building
blocks
and
we
really
start
getting
a
pretty
long
way
in
helping
people
work
on
their
applications
and
then
some
other
some
other
ones.
We
have
are
like
combo
handler
to
be
able
to
have
a
middleware
to
serve
multiple
files
in
one
http
request:
it's
very
common
for
yui
people
to
care
about,
and
then
and
then
we
also
we
we
have
some
stuff
around
routes,
so
so
really.
B
So
you
can
say
I
want
the
path
to
my
index
page
and
or
you
know,
or
path
to
photo
with
this
id
and
and
so
we
realize
that,
like
kind
of
managing
this
metadata
around
routes
and
giving
them
logical,
names
was
another
area
that
that
was
pretty
common,
so
so
something
we.
We
also
wanted
to
to
add
some
components
around,
but
curie
do
you?
Are
you
able
to.
C
C
All
right,
let
me
see,
let
me
know
when
you
see
it
yeah,
it's
there
all
right,
so
really
quick.
We
talked
about
some
of
these
things
during
yy
comp
last
year.
Today
we
just
wanted
to
give
you
an
update
of
some
of
the
components,
some
of
the
new
components
that
are
coming,
some
of
the
things
that
we're
working
on
today
and
we'll
be
working
on
the
next
few
weeks,
but
essentially
just
a
quick,
quick
history
around
this.
Remember
what
we
mentioned
in
your
time.
C
You
were
there
or
not,
but
essentially
we
have
three
major
competing
frameworks
within
the
company.
Mojito
was
one
of
the
open
source,
our
framework
that
we
released
around
two
years
ago,
monolithic
opinionated
framework,
and
then
we
have
two
more
frameworks
that
were
trying
to
attack
different
different
areas
in
the
company,
specifically
use
cases
for
media
for
flickr
and
so
on.
C
So
we
decided
to
go
one
level
under
and
start
providing
the
building
blocks.
So
this
different
frameworks
could
work
on
top
of
those
building
blocks
and
we
ended
up
having
a
very
compelling
set
of
components
and
we
we
plan
to
continue
growing
those
those
components
and
adding
more
and
more
trying
to
solve
these
very
hard
problems
that
we
identify
across
these
three
different
major
frameworks.
This
helped
us
a
lot
because
we
can
identify
things
that
are
common
between
different
use
cases.
C
So
in
you
I
come
we
I
think
we
announced
like
six
components
at
that
point.
Today
we
have
a
few
more
components.
We
have
been
maturing
some
events,
so
I
haven't
sliced
here.
I
don't
have
fancy
slides,
but
I
do
have
to
know
knowledge
stack
to
try
to
to
show
you
how
these
things
stack
together,
because
we
have
seen
that
people
really
get
sidetracked
by
the
fact
that
these
small
things
work
independently
and
then,
when
you
have
to
put
them
together,
you
really
don't
know
how
to
do
it.
C
C
So
essentially,
we
are
moving
in
between
these
three
layers.
All
these
modern
components,
some
of
them,
are
targeting
the
browser.
Some
of
them
are
targeting
the
browser
and
the
server
some
of
them
the
server
only
and
some
of
them
even
expand
a
little
bit
to
provide
functionalities
that
we
need
to
do
the
build
process
for
for
your
application.
So
that's
why
you
see
these
three
layers
in
the
middle
here
and
then
on
top
of
that,
we
we
want
to
stack
them.
C
We
have
the
ecmascript
or
the
javascript
runtime
that
is
common
through
these
three
different
layers,
and
then,
on
top
of
that
we
have.
You
know
the
browser
engines
and
all
the
different
browsers,
major
browsers,
while
the
server
layer
and
the
build
layer
are
mostly
about
node.js,
you
might
have
built
build,
build
scripts
that
are
shell
script
or
something
like
that.
C
As
you
see,
the
server
side
at
the
moment
is
the
biggest
one.
We
have
a
lot
of
components
targeting
express
specifically
targeting
express
extinctions,
trying
to
create
things
that
will
extend
the
express
capabilities,
so
you
can
use
them
in
your
application
to
easily
add
a
new
feature
to
your
application,
and
this
is
something
that
I
think
we
mentioned
during
yui
account,
but
eric
wrote.
Let
me
try
to
find
it
here.
C
Eric
wrote
a
proposal
for
extending
express
application
and
we
have
been
using
this
for
all
the
components
that
we
have
created
for
express
and
it's
basically
a
very
simple
way
to
extend
an
express
application
and
a
reliable
way
to
do
it,
branding
the
extension.
So
you
know
what
are
the
extensions
that
are
applied.
You
avoid
applying
extension
twice.
C
It's
very
small.
You
will
learn
how
we're
doing
things
with
express
and
potentially
you
you
will
be
creating
some
of
this
express
engine
that
could
potentially
just
like
expand
the
capabilities
of
express
or
potentially
mixing
with
some
of
the
components
that
we
are
creating,
which
is
the
ultimate
goal
here
to
be
able
to
give
you
building
blocks
that
you
will
go
ahead
and
wrap
around
with
your
own
things
and
create
your
own
infrastructure
based
on
that.
So
look
at
it
we'll
share
this
just
but.
C
C
It
has
the
serialization
engine,
which
is
basically
a
function
that
you
can
pass
in
an
array
and
it
will
give
you
a
javascript
block.
That
represents,
I
mean
an
object
and
you
just
serialize
that,
but
it
maintains
functions.
Serialized
function,
serialize,
regular
expressions,
serialize
many
other
different
things,
and
it
does
it
in
such
a
way
that
it
is
secure.
C
It
will
not
introduce
script
tags
or
it
will
pretty
much
clean
that
up,
and
those
are
things
that
you
potentially
want
to
use
as
in
a
stand-alone
function,
just
to
include
that
thing
in
your
application
and
use
it
directly.
So
it's
really
yeah
it's
trying
to
maintain
that
kind
of
pattern
across
all
these
things
go
ahead
so.
B
Like
in
that
example
of
express
state,
it's
written
in
such
a
way
that
there's
there's
really
one
main
index.js
module,
which
is
the
express
module
that
that's
just
and
then
there's
two
helper
modules,
an
exposed
class
and
then
the
serialization
function
and
those
two
things.
If
we
ever,
if
there's
ever
a
need
to
like
pull
them
out,
we
could
easily
publish
those
as
their
own
package
and
right
now,
the
express
wrapper
is
actually
the
smallest
bit
of
code
in
the
whole
thing.
B
So
we
wrote
it
with
modular
in
mind,
but
we
just
didn't
take
the
time
to
like
go
through
the
ceremony
of
creating
many
packages,
because
this
was
the
one
use
case
where
we
had
it
and
when
more
uses
come
up.
This
would
be
very
simple
to
pop
this.
This
this
thing
out
into
its
own
package
or
the
other
support
module
in
here
so
but
look
on.
A
C
Well,
we'll
get
to
that
we'll
get
to
that
so
yeah.
This
is
the
one
express
state,
the
serialization
function,
which
is
just
part
of
the
lift.
So
you
can
do
something
like
require
express
state,
slash,
lift,
slash,
sterilize,
and
you
will
get
access
to
this
thing,
that
just
serialize
structures,
maintaining
functions
and
regular
expression
and
escaping
all
those
things
to
be
able
to
put
it
into
a
blog
javascript
blob
in
your
html
when
you
render,
on
the
server
side,
all
right
so
back
to
this.
C
For
example,
the
pure
website,
pure
people
side,
is
using
some
of
these
components
and
and
so
on,
and
in
the
last
three
months
last
quarter
we
really
focus
on
the
intel
stuff.
You
see
this
is
at
the
top.
Here
we
have
been
expanding
to
the
client,
since
all
the
intel
stuff
are
affecting
the
server
side
and
the
clients.
I
run
time,
especially
at
this
point
where
we
have
node.js
that
doesn't
support
intel
out
of
the
box
and.
C
So
I
will
not
go
into
details,
but
basically,
what
we're
doing
is
again
stacking
things
on
top
of
each
other,
so,
for
example,
for
intel
you
need
to
have
the
intel
polyfields
if
you
need
it
depending
on
the
runtime
firefox
already
implemented.
Is
the
latest
version
chrome
as
well,
so
the
polyfill
is
not
needed
there,
but
internet
explorer.
11
also
has
that
but
safari
doesn't
and
and
so
and
so
on.
So
you
have
to
bring
the
polar
film
when
you
need
it.
A
C
Well,
we
are
not
doing
the
polyfill,
although
this
one
is
an
open
source
project
from
someone
andy.
Actually,
we
have
an
open
hour
with
andy
that
we
did
a
few
weeks
ago.
This
one,
the
white
promise
implementation
is
from
juan.
So
that's
from
our
team.
Actually
it
should
be
a
purple
here,
yes,
module
loader
is
another
proposal
that
we
that
we
have
been
using
for
for
a
few
months
already
investigating
and
trying
to
get
it
sanitized
and
use
it.
This
one
is
also
open
source.
C
The
ones
that
we
implement
are
not
polyfills
our
libraries
and
we
want
to
to
pretty
much
make
sure
that
whenever
you
want
to
use
those
libraries,
you
are
using
the
correct
polyfill
if
needed.
So
there
is
really
no
much
here,
it's
just
a
matter
of
normalizing
the
runtime,
so
you
can
use
the
components
that
we
are
creating.
C
Basically,
what
we're
saying
is
you
want
to
use
the
intel
message,
format
which
gives
you
the
capabilities
to
do:
plural,
translation,
plural
and,
and
and
and
even
formatting
numbers
and
dates
in
different
ways
and
for
custom,
formatters
and
so
on.
You
need
to
have
the
intel
available
as
a
global
variable
in
your
system,
and
for
that
you
could
use
a
the
polyfill
if
you
want,
but
but
that's
in
your
hand
we
are
not
in
the
business
of
trying
to
accommodate
all
the
pieces,
but
you
we
are
not
creating
a
framework.
C
We
are
creating
building
blocks
and
it's
your
responsibility
to
put
them
in
such
a
way
that
they
work
together
and
that's
why
I
try
to
put
it
in
a
stack
here,
so
you
can
see
how
they
stack
and
what
are
the
things
that
you
need
in
order
to
use
other
things
like,
for
example,
here
in
order
to
use.
Actually
this
one
is
backward
because
in
order
to
use
now
this
one
is
good.
C
B
Excuse
me
intel
and
promise
now
are
shipping
in
some
like
in.
Let's
see
firefox,
I
believe,
but
definitely
in
chrome,
chrome
has
promise
now,
and
so
these
are
shipping
in
the
browser,
so
they're
in
those
ecmascript
runtimes
at
the
very
bottom.
So
the
idea
is
that
if
we,
if
we
look
towards
leveraging
these
future
features
and
using
polyfills
to
do
it,
that
that
layer
of
code
there
just
eventually
goes
away,
which
is
nice,
nobody
has
to
maintain
it.
B
We
know
that
those
features
will
be
coming
if
they're,
not
already
in
the
browsers
and
especially
on
mobile
devices,
where,
where
the
browser
uptick
is
much
more
rapid
than
what
we
saw
in
the
past,
with
desktop
browsers
and
old,
ies
sticking
around
forever.
So
it's
more
viable
now
to
to
know
that
the
polyfills
will
actually
be
coming
in
the
short
term
and
not
just
like
some
future
thing.
That's
like
way
out
there
that
that'll,
the
polyfill,
will
finally
not
be
needed.
It's
actually
much
shorter
time
period
now
so.
B
C
C
They
are
in
the
making,
but
basically
this
express
prep
client
will
be
released
soon
and
what
it
allows
you
is
to
extending
express.
So
you
can
define
what
what
are
the
capabilities
that
you
need
in
your
runtime
and
the
client
run
that
by
saying
okay,
my
my
client
will
support
intel
because
I
need
it
and
it
will
make
sure
that
intel
is
there
for
you
and
patch
the
browser
when
needed.
So
you
can
rely
on
a
reliable.
C
You
have
a
runtime
that
is,
that
is
already
complete
at
the
moment
that
you
code,
your
application
code
start
running.
We'll
have
more
information
about
this,
but
basically
what
it
allows
you
is
to
define
rules
that
prepare
the
client
for
executing
your
application
code,
and
it's
the
same.
You
need
promise,
you
might
check.
Okay
promise
is
there
if
it
is
not
there
then
go
ahead
and
load.
This
thing
that
will
patch
the
browser
so
promise
is
going
to
be
available
there
in
a
form
of
a
polyfill.
C
This.
This
is
a
very
low
level
package
as
well.
So
you
have
to
define
your
your
own
rules
for
your
application,
but
eventually
you
might
want
to
provide
a
package-
that's
stacked
on
top
of
this
one,
with
a
pre-defined
set
of
rules
that
you
can
enable
or
disable
at
some
point
for
your
application,
depending
on
the
requirements
that
you
have
in
your
application.
C
Again,
we
want
to
have
the
very
low
level,
and
then
we
can
stack
things
on
top
of
it
to
have
a
more
medium
level
api,
although
we
don't
want
to
get
to
the
point
where
this
becomes
a
framework.
It's
just
a
library,
that's
stacked
on
top
of
another
library,
to
give
you
some
sugar
on
top
of
it,
and
we
want
to
do
that,
for
example,
for
the
set
of
polyfills
that
we
use
within
yahoo.
Those
are
already
sanitized.
C
Those
are
already
tested
that
we
are
confident
that
they
are
good
enough
and
and
potentially
providing
providing
them
directly
from
java
cdn
and
so
on.
We'll
get
to
that.
Eventually,
but
this
is
something
that
we
have
in
the
making.
Actually
I
I
put
it
here
as
one
of
the
components
that
is
still
private,
so
you
see
it's
still
private,
it's
almost
ready,
but
but
we
need
to
continue
working
on
it,
so
we
can,
we
can
get
it
ready.
C
So
that's
this
sort
of
thing
that
we're
trying
to
look
at
at
the
moment
so
going
back
to
the
top
of
the
graph
here
we
have
obviously
the
intel
message:
format,
which
is
the
low
level
library
and
then,
on
top
of
that,
the
things
that
we
already
discussed
in
open
hours
like
we
have
the
implementation
for
dust.
We
have
the
implementation
for
handlebars,
because
those
two
we
use
it
within
yahoo
and
and
react
intel
is
on
the
making
because
we
probably
will
use
it
within
yahoo
as
well.
C
But
we
want
people
to
go
ahead
and
create
similar
packages
that
will
be
in
the
same
layer
here
that
might
implement
the
intel
features
for
different
engines
and
so
on.
So
ideally,
we
will
start
seeing
more
and
more
of
these
things,
but
you
can
go
ahead
and
just
use
intel
message
directly.
It's
it's
already
in
npm,
I
think,
is
not
yet
in
power,
but
it
will
be
in
bowerson
and
then.
B
Well,
I
was
just
going
to
say
just
just
around
the
internationalization
stuff
we're
also
working
on
an
effort,
because,
as
security
described,
it's
it's
somewhat
complex
like
you
have
to
conditionally
load
the
polyfill
you
have
to
to
know
about,
then
the
the
built-in
apis
that
are
provided
under
the
intel
name
space
then
also.
This
message
format
thing
which
we're
adding
as
a
library
that's
based
on
some
of
the
proposals
that
will
eventually,
hopefully
make
it
intact
the
script
properly.
A
B
There
would
be
multiple
entry
points,
so
that's
why
I
think,
like
the
the
intel
stuff
is,
is
something
similar
to
like
how
we
have
pure
like
this
is
something
we
can
promote
on
its
own,
because
it's
useful
to
a
large
number
of
people
like
it.
It
doesn't
really
assume
much
besides,
hey
are
you
using
javascript
and
then,
if
you
are
like
okay,
you
can
use
intel
and
intel
message
format
and
then
it's
like.
B
So,
like
there's
aspects
of
this,
where
you
may
have
it
have
a
node.js
app,
it
doesn't
even
matter
if
you're
using
express
or
not.
You
still
may
want
to
use
these
packages
on
the
server,
because
node.js
doesn't
actually
support
the
built-in
intel
apis
by
default.
You
actually
have
to
compile
and
build
your
own
version
of
node.js
with
a
particular
flag
turned
on
to
be
able
to
get
this.
B
This
is
something
we're
working
with
tj
fontaine,
the
node.js
maintainer
and
some
other
people
at
yahoo
who
really
deal
with
the
infrastructure
level
of
node.js
are
working
to
try
to
get
this
to
be,
hopefully
the
default,
so
that
node.js
maintains
a
true,
proper
ecmascript
runtime.
The
intel
features
are
added,
as
in
addition
to
ecmascript
5
under
5.1,
and
we
really
want
to
make
sure
that
node.js
maintains
being
an
actual
ecmascript
runtime
right.
A
B
Yeah
and
while
that
doesn't
really
matter
as
much
on
the
note
side,
because
it's
just
coming
off
of
the
local
file
system,
it's
still
something
where
the
polyfill
hasn't.
Actually,
it's
more
focused
on
the
browser
and
hasn't
actually
implemented,
particular
a
particular
feature
collation,
and
that's
where
we're
really
hoping
that
the
intel
system
we
provided
had
the
built-in
in
full
intel
features
at
the
node.js
level
so
that
you
could
communicate
if
you
had
to
do
like
sorting
of
things.
This
is
where
you
need
the
collation
feature.
B
If
you
needed
to
do
that,
that's
something
that
you
could
then
like,
communicate
with
the
server.
Have
it
do
the
sorting
work
and
then
send
you
back
the
results
and
that
that's
really
something
where,
where
in
those
old
browsers,
you
could
fall
back
to
an
xhr
style
communication
for
those
sorts
of
features.
But
you
need
the
server
side
to
actually
have
those
features
and
that's
something
that
is
currently
lacking
at
node.js
level.
By
default.
This.
C
B
C
We
can
get
so
so,
but
on
top
of
that
we
have
been
focused
on
the
browser,
layer
and
server
layer.
So
far
we
haven't
talked
much
about
the
build
layer.
So
we'll
give
you
an
example
what's
going
on
here,
so
I
will
pick
up.
One
of
the
upcoming
components
react
intel.
I
have
it
open
somewhere
here,
so
I
can
share
with
you
some
of
these
examples.
C
C
All
right,
okay,
so
here
here,
is
an
example
where,
where
you
want
to
put
translation
a
translation
to
your
application,
you
will
go
ahead
and
create
potentially
json
file,
for
example-
and
this
is
a
very
common
case
where
you
have
a
json
file
that
has
different
translations.
This
is
what
translators
will
do
potentially
or
your
developers
will
end
up
doing
manually.
But
but
in
any
case,
this
is
an
english
translation.
You
have
something
like
this,
where
you
have
token
replacement.
So
this
is
easy.
C
C
Where
you
have
in
french,
you
need
the
gender
to
be
considered
if
there
is
one
travel
or
more
travels
and
if
there
are
female
or
male,
so
you
get
into
all
these
things
that
are
way
more
complex
than
what
you're
normally
used
to-
and
this
is
this
is
all
string.
You
see
this
is
in
a
string
that
need
to
be
parsed
and
they
need
to
be
processed
and.
B
This
is
a
this:
is
a
standardized
syntax
yeah
correct
yeah.
So
this
is
something
that
that,
if
you're,
if,
if
you're,
working
with
professional
translators,
they
understand
how
to
write
these
messages
in
this
format
and
this
format
is
it
works
in
in
java
and
php,
and
you
know
in
in
the
library
that
we
created
in
javascript
as
well
yeah.
C
And
then
you
see,
you
have
all
these
streams
and
you
want
to
use
these
strings
on
the
server
side.
You
wanted
to
use
it
on
the
client
side.
You
need
to
have
a
way
to
load
them,
but
then,
at
the
same
time
you
see
well,
this
thing
has
to
be
parsed.
Are
we
going
to
parse
this
for
every
user
for
every
execution,
so
things
get
a
little
bit
more
complex
and
you
want
to
have
optimization
around
this.
C
You
want
to
have
a
parser
that
goes
and
parse
this
thing
and
produce
a
bundle
that
you
can
use.
If
you
use
yui,
you
might
want
to
get
a
yui
bundle
that
you
can
load
using
the
loader.
So
when
you
need
it,
you
go
and
load
the
thing,
the
module
that
you
need
and
the
associated
bundle
with
for
that
for
that
module.
C
Maybe
you
use
command.js
depends
on
what
you
need,
so
we
ended
up
in
a
situation
where
we
need
to
find
ways
to
to
be
able
to
process
this
raw
data
coming
from
translations
into
something
that
potentially
also
have
to
be
transpiled
into
a
module
system.
So
all
these
steps
are
complicated
steps
that
you
need
to
to
have
in
your
application
and
you're,
really
serious
about
translations
and
performance.
B
And
so
the
reason
for
for
doing
this
is
to
essentially
say
in
your
application
code.
I
depend
on
the
settings,
messages
for
the
settings
screen
and
it's
a
module
that
has
all
of
these
these
strings
in
it
or
or
potentially,
even
pre-parsed,
but
just
you
know
like
so
you
can
have
this
common
dependency
system
that
you
would
be
used
to
where
you
would
say
that
you
depend
on
the
strings
and
you
and
you
just
treat
them
as
a
as
just
a
yet
another
module.
C
And-
and
as
you
see
here,
I
have
this
this
area
here
like
blur,
so
I
will
get
into
the
next
slide,
which
has
this
thing
really
highlighted.
I
put
it
in
blue,
because
this
is
an
area
that
we
that
was
the
first
area
that
we
work
on
for
the
motown
pieces.
Now
we
are,
we
are
going
to
focus
on
refactoring.
This
is
then
ongoing
at
work
to
try
to
change
that,
so
I
will
not
focus
much
of
on
what
it
is
today
and
how
it
works
today,
but
potentially
what
we
want
to
have
tomorrow.
C
This
is
all
today
is
all
our
proprietary
thing.
It
has
on
apis
and
no
way
to
create
plugins
extensions,
get
ready
pieces
that
you
need
for
the
build
process
of
your
application,
so
we
want
to
walk
away
from
that
into
using
more
ground,
broccoli,
potentially
gold
and
other
executors
and
potentially
broccoli.
That
will
give
us
a
little
bit
more
extra
control
over
the
flow
because,
as
I
mentioned,
we
do
have
in
most
cases
different
steps
that
we
need
to
execute.
We
need
to
get
the
json.
C
We
need
to
trans
to
to
parse
each
of
these
strings,
generating
some
sort
of
object
in
this
case
arrays
that
are
that
have
the
tokens
and
inherit
a
inheritance
between
the
different
elements
of
that
translation
and
all
that,
if
it
is
singular,
if
it
is
plural
and
then
all
the
ramification
of
that.
So
it's
a
complex
structure.
So
we
need
to
generate
something
that
is
a
javascript
object
that
we
can
easily
use
for
javascript
without
having
to
do
any
parsing
of
any
time
at
the
runtime.
C
So
we
improve
performance
by
not
having
to
go
and
parse
the
whole
thing
for
every
user
and
every
request
that
we
need
to
use
that
string.
So
for
that
we
want
to
have
a
process
that
allows
to
transfer
that
into
foundation
to
these
objects
that
are
compatible
with
our
internal
system,
but
also
being
able
to
transpile
that
into
a
module
system.
That
will
will
allow
you
to
a
specific,
monitor
format
that
allow
you
to
use
it
with
a
module
system
and.
B
The
same,
I
think
I
was
just
going
to
say
like
I.
I
think
that
the
way
to
think
about
this,
too,
is
if
you're
familiar
with
handlebars
is
that
each
of
these
messages
is
like
a
template
and
what
karate
is
talking
about
is
we
can
get
more
efficient
so
like
in
handlebars?
You
can
render
a
string
template
every
time
and
it
will
redo
it
or
you
can.
B
C
And-
and
I
was
about
to
get
into
templates,
so
it's
exactly
the
same
thing.
As
you
said,
it's
the
same
thing.
We
have
the
handlebars.
We
need
to
transfer
that
into
a
function,
so
we
can.
We
use
a
compiler,
we
get
a
function,
then
that's
function.
We
need
to
load
it
somehow
from
the
different
runtimes
we
needed
a
server.
We
needed
a
decline.
How
you
do
that?
Well,
you
might
need
to
transpile
that
into
module
format
that
you
can
use
with
one
of
the
module
systems.
Specifically
you
use
y1.
C
C
We
are
running
out
of
time,
but
essentially
what
going
back
to
this
is
that
we
want
to
stack
all
these
things
that
are
needed
for
the
server
and
client,
but
also
we
want
to
take
care
of
providing
the
pieces
that
are
potentially
optional
to
use
then
to
optimize
the
build
process
for
your
application.
So
you
can
gain
extra
in
performance,
so
we
are
keeping
all
these
things
in
mem
in
in
in
our
minds,
and
we
are
trying
to
solve
each
of
these
different
problems
so
jumping
into
this
one.
C
This
is
the
intel
technology
stack,
so
there's
more
depth
into
how
we
we
see
this
for
people
to
use
like
in
this
case
again
we
have
the
runtimes
here
which
include
the
browser,
the
node.js
any
any
browser
that
implements
already
in
internationalization,
which
is
ema
for
tube,
or
you
potentially
use
node.js
with
the
flag,
which
is
not
just
0.12,
will
have
the
flag
there.
If
not,
you
can
just
fill
it
up
with
the
polyfill.
C
So
you,
you
normalize
that
so
your
application
and
the
libraries
that
you
use
can
be
sure
that
intel
is
there
whether
it
is
a
polyfill
or
is
already
implemented
by
the
runtime.
We
really
don't
care.
We
just
need
to
have
that
thing
there
and
it's
your
responsibility
to
go
and
do
it
and
then,
on
top
of
that,
you
stack
the
different
react
components
that
we
provide.
So
you
stack
the
intel
message.
You
start
whatever
you
need
from
this.
Probably
you!
You
don't
need
three
of
them.
C
C
Yeah
yeah,
so
this
is
this
is
more
in
details
about
what
intel
is
about,
but
I
want
to
get
to
the
to
the
other
one
before
we
wrap
up,
which
is
the
loader.
So
this
has
been
also
the
focus
for
the
last
three
months
and
will
remain
a
focus
for
for
a
few
more
months,
we
have
been
engaging
with
different
people
about
the
lawyer
in
the
in
the
tc39
meetings,
alcohol
trying
to
push
for
the
lawyer
to
be
ready
and
respect,
but
basically
the
same
principle.
You
look
at
it.
C
It
looks
a
lot
like
the
intel
stuff.
You
have
the
different
browser
engine.
You
have
node.js
the
uncommon
version
on
objects
that
potentially
implement
the
es
modules
browsers
that
will
potentially
implement
the
yes
module
really
soon.
Then
we
have
the
browsers
of
today-
and
you
know
js
today,
which
do
not
implement
this
thing.
So
for
that
you
need
to
use
a
powerful.
C
We
want
to
have
conditions
we
want
to
have
prefetching,
so
we
can
do
parallel
loading
to
get
all
the
stuff
that
you
need
ready
right
away.
We
want
to
be
able
to
support
aliases,
so
you
can
create
robots
and
and
define
some
specific
definitions
for
for
how
to
load
your
modules
we
want
to
provide
combined,
so
we
can
use
a
combo
handler
that
we
that
we
are
very
used
to
and
so
on.
C
So
all
these
things
are
coming
as
part
of
the
new
package
that
will
be
released,
which
is
the
loader
extension,
so
juan
has
been
working
on
this
for
a
while.
We
we
plan
to
get
it
ready
soon.
Even
it
includes
most
of
these
extensions
and
a
few
more.
It
actually
also
includes
extension
for
being
able
to
use
the
yui
format
with
the
with
the
new
loader.
C
I
will
not
get
into
details
about
that,
because
this
is
more
complex,
the
same
for
amd
and
and
some
other
extensions
that
you
will
see
coming
up
along,
but
but
basically
what
we're
saying
is
we
want
to
provide
extensions,
so
you
can
create
a
loader
instance
plug
those
extensions
very
similar
to
what
happened
in
express
it's
actually
very
similar
in
in
code
as
well.
We
want
to
do
the
branding
the
same
branding
that
we
do
in
express,
but
we
will
want
to
follow
the
same
principle.
They
look
a
lot.
C
C
You
will
be
able
to
go
ahead
and
plot
some
of
these
extensions
and
get
this
system
to
function,
just
like
the
yui
loader
work
today
using
combine
for
combo
using
prefetching
or
using
conditions,
and
so
on.
We
also
plan
to
provide
potentially
a
a
prescript
prescribed
sort
of
loader.
That
already
has
the
extension
that
we
want
configured
in
such
a
way
that
you
can
go
ahead
and
load
things
directly
without
having
to
know
more
too
much
about
internal
configuration.
We
are
still
looking
into
this
again.
This
is
a.
C
C
But
again
you
can
use
this
directly
with
javascript,
so
you
want
to
use
the
extensions
manually
when
you
get
the
system
ready
or
the
loader
ready
in
the
browser.
You
can
still
use
that
use
the
extensions
to
provide
these
extra
features
that
are
not
coming
with
the
default
loader.
That
browsers
will
implement
so
that
that's
the
kind
of
things
that
we're
looking
at
right
now.
Also,
if
I
don't
know,
if
we
have
more
time,
do
we
have
more
time
yeah,
yeah,
okay.
C
C
So
we
also
want
to
make
sure
that
this
new
loader
work
well
with
speedy,
but
also
for
all
browsers.
When
you
use
the
polyfill,
you
will
be
able
to
use
the
combine
for
that,
and
the
same
will
happen
for
yui.
So
what
I'm
saying
here
is
that
some
of
the
work
that
we
are
doing
in
morale
also
retrofit
back
into
yui
in
some
cases
that
you
have
seen
some
updates
in
the
loader.
C
In
the
last
two
or
three
releases,
we
have
been
working
on
the
loader
to
align
well
with
the
things
that
we
have
been
doing
to
to
support
loading
other
module
formats
to
support
loading,
transpile
es6
modules
into
yui,
and
that
kind
of
things
the
same
will
happen
for
for
the
speedy
http
2.
We
want
to
have
the
ability
to
to
figure
out
when
to
use
the
combine
when
not
to
use
it
loading,
those
things
from
the
cdn
that
supports
pd.
C
B
No,
I
mean-
I,
I
think
you
covered
it
and
and
that's
where,
like
there's
a
lot
of
other,
build
related
things
too,
around
modules,
especially
es6
modules,
and-
and
so
that's
also,
another
area
we're
looking
at
and
actually
the
main
the
main
transpiler
to
to
compile.
Es6
modules
already
has
yui
is
one
of
the
targets,
and
so
we
did
a
lot
of
work
on
in
the
yui
side
to
be
able
to
to
deal
with
this
because
of
the
just
really
the
differences
between
hanging.
B
B
Those
things
in
sync
is
something
that
we've
been
doing
in
yui,
because
the
the
last
like
like
an
important
thing
for
us,
is
that
we
we
want
to
make
sure
that,
if
you're,
if
you're,
if
you're
trying
to
push
people
towards
writing
this
new
code
as
as
es6
modules
that
will
still
work
in
their
current
applications
and
and
that's
important
to
us
and
something
that
we
made
sure
to
do.
And
then
similarly,
if
you're
using
the
new
loader.
B
But
you
have
all
this
old
code
and
existing
code,
that's
already
as
yui
modules.
You
can
still
load
that
into
your
system,
using
the
new
loader
and,
and
those
are
the
things
that
we
wanted
to
make
sure
were
there
and,
and
it
really
helps
to
like
open
up
yui,
to
be
more
open
to
dealing
with
code
from
other
places
and
then
also
as
you're
authoring
code
you're,
not
having
to
lock
yourself
into
whether
or
not
you're
writing
a
yui
module
for
a
yui
system
or
you're
writing
something
for
everything
else.
B
What
we
really
want
is
you
to
be
able
to
write
one
module
that
you
can
use
in
multiple
places
by
compiling
to
to
a
yui
module,
for
instance,
or
and
compiling
to
a
common
js
module
which
then
can
be
used
on
the
server.
So
for
things,
especially
like
utilities,
then
we
a
lot
of
times
you
run
into
this
problem
and
we're
we're
hoping
this
this
way
we
can
avoid
it,
and,
and
all
these
these
same
things
we
talked
about
with
internationalization
and
and
having
things
to
help.
B
C
Yeah,
so
to
answer
the
other
question
from
andrew
alberto
wrote
like
two
months
ago,
he
wrote
this
application,
so
many
people
from
the
team
were
working
on
this
that
showcase
how
to
use
mora.
In
fact
it
does
it
in
such
a
way
that
it
even
use
yes
modules.
So
you
you
really
see
where
we
are
heading
here,
so
you
see
offering
the
internal
pieces
of
the
application
in
es6
and
then
be
able
to
transpile
that
into
yui
monitors
and
be
able
to
use
it
with
the
current
yui
loader.
C
B
All
the
the
so
we
wrote
a
new
getting
started
thing
which
will
be
promoting
to
production
soon
and,
and
that
is
a
is
a
javascript
client-side
application.
And
what
we
did
is
we
wanted
to
make
all
that
javascript
code
for
for
this
getting
started
feature
to
actually
be
written
as
esx
modules,
but
also
used
within
yui,
so
so,
you're
you're
writing,
es6
modules,
but
you're
leveraging
yui
modules,
existing
iui
modules
and
yui
core
and
then
the
yui
loader
as
well
to
to
bootstrap
and
load
everything.
C
So
at
this
point
we
have,
as
I
mentioned,
the
three
major
frameworks
that
we
have,
which
is
more
down.
I
mean
mojito,
which
is
used
by
search
mostly
and
other
properties
is
using
a
subset
of
these
moral
components,
not
as
many
as
we
like,
but
we
will
continue
that
effort
to
continue
changing
the
guts
of
mojito
to
use
more
and
more
and
more
down,
because
mora
is
implementing
some
of
the
features
that
we
implement
initially
in
mojito,
and
it
seems
that
the
moran
components
are
more
solid
in
that
sense.
C
C
C
B
C
C
But
it's
also
difficult
because
we
don't
want
to
be
opinionated
about
it.
We
don't
want
to
tell
you
how
to
use
those
components.
We
want
you
to
mix
them
in
in
such
a
way
that
it
makes
sense
for
you
and
for
the
things
that
you're
building.
So
it
is
a
kind
of
a
chicken
and
egg
problem
here,
but
we
will
continue
working
on
that
and
also
essentially,
this
is
the
main
focus
of
most
of
the
people
in
our
team.
So
you
will
see
more
and
more
things
coming
up
from
the
project.
A
B
B
So
if
you're
using
express
and
any
of
these
problem
spaces
that
we've
tried
to
talk
about
really
seem
to
to
be
like
something
that
you're
experiencing
like
yeah,
you
can
definitely
use
these
components
and
try
them
out
and
let
us
know
like
I
had
I
had
somebody
asked
me
about
express
state
and
they
were
trying
to
use
it
on
express
4.x
and
issued
a
pull
request
to
to
update
a
couple
things
to
make
it
work.
And
you
know
we
were
able
to
merge
it
in
and
get
that
going.
A
People
so
yeah.
These
things
are
interesting
to
you
guys
if
you're
watching
this
or
even
via
the
archive,
just
contact
us
on
irc
or
email
me
directly.
You
can
find
me
all
over
the
net.
You
can,
even
just
even
as
simple
as
replying
to
a
blog,
post
or
messaging,
the
yy
library
on
twitter.
Anything
like
that.
Can
you
get
help
with
this.