►
From YouTube: Magento PWA Demo, 19 November 2018 (Sprint 29)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Here's
the
lineup
for
today,
so
we've
got
a
couple
things
from
Jimmy.
We've
got
a
couple
things
from
the
James's
and
then
I'll
be
covering
for
or
salvia
on,
some
work
around
us.
A
So
again,
you
know
lots
and
lots
of
work
accomplished,
certainly
certainly
behind
the
scenes
on
the
cloud
enablement,
the
documentation,
you
know
merging
a
lot
of
the
great
work
from
bar
green
and
many
of
the
other
community
members
as
well,
and
so
so
this
one's
gonna
be
a
little
bit
different
in
that
respect,
that
a
lot
of
good
progress
on
those
enabling
pieces
and
kind
of
in
timing
for
our
general
availability
and
so
I'm
going
to
kick
things
off
and
and
start
with
mr.
Kalka
Ben
who's
going
to
walk
us
through
some
improvements
to
documentation.
B
Yes,
you
must
be
sure,
can
the
first
thing
you
wanted
to
present
documentation
or
routing
on
this
area.
Basically,
it
is
a
conceptual
topic
that
talks
about
how
routing
is
done
in
Peter
base
yeah.
There
was
a
lot
of
questions,
but
how
our
approach
to
routing
so
this
breaks
it
down
to
how
it
works
and
all
the
components
involved
do
that
next,
one
next
test
I
did
this
print
was
duplicating
some
dots
in
the
project
directories.
B
B
B
Another
update
we've
moved
their
opinion
sample
data
into
its
own
topics
in
the
set
up
there
since
vineya.
No
longer
requires
you
to
set
up
your
own
Magento
instance.
We
removed
that
into
its
own
topic
here
that
just
focus
on
installing
them
later,
so
that
dream
line
to
set
up
installation.
So
you
can
just
follow
this
without
having
Magento
installed
anywhere
and
we've
run
through
this
ourselves.
B
C
A
Got
a
couple
updates
from
from
from
Jimmy
and
James
here,
and
so
one
give
you
guys
an
update
to
share.
Maybe
some
of
the
work
on
merging
you
know,
James
I
know
we
also
landed
webpack
four
as
well,
and
so
some
of
the
things
may
not
be
as
visual
as
others,
but
that
you
guys
want
to
share
any
updates
on
that
one
with
their
with
the
community.
D
D
Come
on
here,
so
this
is
a
list
of
all
of
our
open
poll
requests
which
we
have
great
velocity.
Now
the
PRS
are
coming
in
faster
than
we
can
actually
close
them,
but,
like
like
Eric
said
we
got
two.
We
landed
two
major
ones
at
the
beginning
of
the
sprint
which
were
related
to
web
pack,
four
and
and
then
related
to
routing,
and
so
that's
doing
enablement
of
community.
A
A
C
C
C
We
can
okay,
so
yeah.
This
is
venía
right
now
in
in
its
stable
release,
which
is
deployed
right
out
of
the
released
2.0
branches,
they're
America's,
it
was
briefly
broken
because
web
pack
work
is
a
very
new,
build
architect
and
bundling
architecture,
and
so
there's
still
some
kinks
to
work
out,
but
I'm
gonna
go
ahead
and
figure
out
all
the
storage
for
it.
Although
I
think
it's
worth
observing
with
the
storage
vendor
and
megabyte
here,
the
site
data
and
then
just
to
be
on
the
safe
side,
you
close
the
tab
as
well.
C
Observe
that
the
JavaScript
is
coming
down
sort
of
an
odd
collection,
the
vendor
bundle
comes
down
firsts,
pretty
small
37
kilobytes.
The
client
bundle
is
a
little
larger,
it's
106
kilobytes
and
that's
what
contains
most
of
the
underlying
libraries
that
everything
uses
like
the
acting
Apollo
etc.
But
we
have
a
hard
limit
of
about
a
hundred
and
six
kilobytes,
something
like
that
in
the
intelligent
configuration
of
the
split
chunks,
plugin.
So
right
about
that
size.
C
Web
pack
decides
that
the
client
is
going
to
be
broken
up
into
another
asynchronous
chunk,
so
even
the
core
functionality
that
is
statically
imported
is
still
being
progressively
loaded.
This
is
something
that
when
pack
does
for
us
automatically,
you
might
also
notice
that
there
is
a
named
chunk
for
the
CMS
kg
component.
There
used
to
be
a
plugin,
that's
detached
the
root
components
and
their
dependencies
as
separate
chunks
by
kind
of
hacking,
the
internals
of
web
pack
and
we're
doing
that
a
little
differently
now.
C
You
know
why
don't
you
do
that
because
I
think
it's
potentially.
This
is
a
very,
very
cool
demo
that
just
broke
and
I
bet.
The
fix
is
quick,
so
I'll
go
ahead
and
unshare.
If
you
want
to
see
what's
down
these
stuff
and
it'll
come
back
to
me
yeah.
If
anything,
this
is
nowhere
near
what
happened
to
Surma,
but
in
chrome,
developer
summit,
so
I'm
still
feeling
good
stopping
sharing
and
feel
free
to
talk
about
Sammis
update,
yeah.
A
Absolutely
so
it's
only
had
a
couple
updates,
she's
actually
out
on
vacation
well-deserved
in
South
Africa
this
week,
but
they're
working
a
couple,
things
relative
to
kind
of
theirs,
last
and
kind
of
final
finishing
touches
that
we
want
to
have
for
for
venía,
namely
the
the
splash
experience
to
looking
at
what
that
animation
looks
like,
but
also
in
the
future.
Potentially
what
that
page
learning
experience
might
look
like
similar
to
the
bars
that
you
might
see
you
go
across
the
page
and
so
I
think.
Well,
we
what
we
decided!
A
You
know
that
somebody
had
worked
with
several
of
you
here,
including
Jimmy,
and
also
some
of
our
green
folks.
On
that
it,
it's
really
just
a
simple,
simple,
splash
kind
of
loading
experience
that
you'll
see
again
part
of
its
because
it's
a
core
requirement
of
Google
Lighthouse.
You
need
that
as
that
initial
experience,
but
then
also
it's
just
good
good
practice
and
it's
going
to
replace
those
fetching
and
loading
blocks
of
text
that
you'll
see
which
are
always
in
you
know
intended
to
be
placeholder
from
the
beginning.
A
So
don't
you'll
see
you're
just
a
basic
basic
animation
that
we'll
share.
So
give
me
a
second,
then
I'll
pull
that
up
here.
So
it
doesn't
look.
You
know,
you
know
it's,
it's
not
going
to
take
more
than
a
minute
or
so
to
show,
but
that's
really
the
Intendant
and
now
there's
a
story
related
to
that,
and
this
also
feeds
into
some
of
the
some
of
the
related
work
on
JavaScript
out
available
and
things
like
that.
A
A
Right,
but
that's
really
it,
and
so
so
again,
very,
very
subtle,
I.
You
know
he
went
back
and
forth
base
and
what's
possible,
but
what
is
the
better
experience
that
look
at
this
in
an
upcoming
PR
relative
to
again
just
simply
replacing
some
of
the
debug
work?
We
had
touching
and
fetching
and
loading
there,
but
something
is
a
little
bit
more
elegant,
as
you
would
expect.
No,
that
was
it.
A
C
C
This
is
where
we
were
at
you
guys
can
see
right
that
the
total
amount
of
just
JavaScript
that
is
downloaded
is
only
149
kilobytes
of
the
one
and
a
half
megabytes
that
have
been
transferred
right,
yeah,
okay,
so
same
functionality
with
a
little
bit
less
over
here,
because
at
this
tag
stage
we
didn't
have
a
lot
of
pull
requests
merged
and
we
didn't
have
the
accessory
thumbnails.
But
this
is
the
web
pack
free
version
notice
that
the
vendor
bundle
is
542
kilobytes
and
the
total
JavaScript
payload
is
860
kilobytes.
C
C
C
C
Area
so
observe
that
the
loading
time,
the
scripting
time,
the
rendering
time
I
guess,
they're,
pretty
ok,
I,
think
I,
managed
I.
Think
I
did
not
manage
to
disable
cache
properly,
but
that
all
of
that
area
here
is
JavaScript
which,
when
evaluating,
is
going
to
block
the
main
thread
in
and
it
evaluates
in.
C
It
evaluates
in
a
way
that
stops
the
scrolling
and
the
user
response
and
delays
metric
from
the
real
world
that
we
like
to
call.
First
input
delay
that
the
web
pack
3
version
of
the
load
and
it's
leveled
off
pretty
fast,
because
this
is
sort
of
a
version
of
the
shop
that
doesn't
have
a
lot
of
the
functionality.
C
One
so
observe
that
those
giant
yellow
chunks
are
spread
further
out
over
time.
So
that
means
that
there
is
a
lot
more
space
in
between
for
the
UI
to
be
responsive.
This
is
just
the
beginning
of
the
application,
there's
wonderful
spike
during
the
initial
render
of
the
clients,
and
it
takes
place
between
2600,
milliseconds
and
3,000
milliseconds.
Compare
over
here
when
there
is
a
lot
of
JavaScript
being
evaluated
for
almost
half
a
second
here.
C
The
deepest
JavaScript
point
occurs
in
less
than
a
quarter
of
a
second
and
that's
the
difference
between
something
feeling
good
and
not
webpack,
for
swapping
it
in
resulted
in
no
code
changes
to
the
actual
venía
components
beyond
some
build
stuff
in
the
way
that
route
components
operate.
It
was
essentially
an
invisible
change
to
the
folks
making
the
pretty
eyes,
and
we
are
super
super
happy
with
it.
It
has
made
the
the
folks
doing
initial
implementations
in
the
UK
and
in
Brazil
and
in
Spain
and
in
Argentina,
really
really
excited.
C
C
C
The
way
that
optimization
works
in
webpack
4
is
a
little
different.
Instead
of
adding
a
commons
chunk
plug-in
there's
no
such
thing
as
a
commons
chunk
plug-in
whose
whole
logic
was
just,
let's
find
the
common
stuff
and
then
pile
it
into
a
vendor
bundle.
That's
500,
kilobytes
in
size,
there's
now
a
concept
of
splitting
chunks,
so
web
packs
default
behavior
is
to
have
a
maximum
size
that
a
given
javascript
file
should
be
and
to
split
them
and
spread
them
out
so
that
they
progressively
load
in
the
application
for
vessel
enhances.
C
A
C
C
You
all
right,
I
am
outstanding
at
demo,
so
the
web
pack
config
used
to
have
something
called
a
commons
chunk
plug-in
in
it,
which
is
just
a
specification
that
says
everything.
That's
shared
between
the
entry
points,
dump
them
in
a
commons
chunk
the
vendor
files,
everything
that
more
than
one
chunk
uses,
so
the
CMS
page
and
the
category
page,
if
they
both
use,
feather
icons,
feather
icons
goes
in
the
vendor
chunk
web
pack,
four
comes
in
a
from
the
opposite
side.
There's
a
concept
of
splitting
chunks
that
is
right
out
of
the
box.
C
Something
webpack
tries
to
do
it.
It
makes
small
bits
of
JavaScript
that
progressively
load
the
only
way
that
we've
configured
it
here
is
by
creating
a
vendor
chunk,
consisting
of
a
few
core
libraries
by
matching
against
a
path
in
our
node
modules,
calling
it
vendor
and
those
libraries
happen
to
be
here,
so
you
can
actually
fine-tune
in
the
same
way
that
you
could
the
Commons
trunk
plug-in,
but
somewhat
in
the
opposite
direction.
What
results
in
this
configuration
is,
let's
see,
I'm,
probably
gonna,
have
to.
C
Generate
a
full
built
in
order
for
that
to
take
place,
but
I
will
I'll
move
around
here
in
venía,
so
you
can
see
that
the
route
components
of
category
comes
in
and
it's
just
another
couple
of
kilobytes
and
then
the
route
component
for
product
comes
in
just
another
couple
of
kilobytes.
We
get
a
little
bit
of
extra
functionality
with
cart.
C
C
Heyy,
alright
and
now
the
the
shopping
part
in
the
category
and
the
the
checkout
systems
are
right
now,
as
you
can
see,
not
loading
extra
JavaScript,
so
there
is
more
opportunity
for
before
enhancements
in
for
efficiency.
Here
right
now
we
just
divided
up
route
components
with
our
plugin,
but
the
more
dynamic
imports
we
use
the
more
automatically
these
things
get
separated
into
chunks.
So
in
the
code,
when
you
are
sitting
in.
C
Mini
cart.
This
import
causes
web
pack
to
split
up
a
chunk
and
our
configuration
is
not
doing
it
properly.
So
we're
going
to
continue
to
fine-tuning
so
already.
You
can
see
that
this
156
kilobytes
with
a
bunch
of
load
up
front
can
shrink
more
and
more
and
more
as
you
continue
to
so.
There
is
a
whole
lot
of
runway
for
us
to
gain
speed.
C
A
Great,
thank
you,
sir
yeah
I
can't
underscore
the
importance
of
the
performance
benefits
here
for,
for
even
the
small
upgrades,
so
preciate
your
help
on
that
one
so
good
stuff
towards
good.
So
you
know
again
what
was
originally
intended
to
be
a
fairly
light
demo,
based
on
all
the
other
great
work
that
we're
pulling
together.
A
All
right,
well
very
good.
Well,
thank
you
again
for
everybody
as
I
help.
I
will
continue
with
sprint
sprint
32a
to
close
things
out,
but
but,
as
always,
we
have
any
questions,
comments
or
considerations.
You
know
where
to
find
it
so
have
a
great
time
rest
of
your
day
and
rest
every
week.
We'll
talk
to
him.
Thank.