►
From YouTube: Workerized JavaScript Made Easy - Ben Morss, Google
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
Hello,
welcome
to
work
arise,
JavaScript
made
easy,
so
my
name
is
Ben
Morse
I'm,
a
developer
advocate
at
Google
my
job.
There
has
helped
the
web
be
more
beautiful
and
faster
and
easier
for
both
developers
and
for
users
really
easier
for
developers
to
make
good
experiences
for
users
and
I
used
to
be
a
musician
which
makes
me
especially
a
sad
that
I
can't
be
here
in
Austin.
A
Today,
I
was
looking
forward
very
much
to
being
in
Austin
it's
a
great
city,
I
used
to
go
opera
house
by
Southwest,
has
great
music,
barbeque
and
so
on
and
so
forth.
Here
I
am
instead
in
New
Jersey,
but
hey,
let's
travel.
My
dog
is
over
here,
it's
comfortable,
so
there's
always
that
anyway,
if
you
heard
this
conference
you're,
probably
a
big
fan
of
JavaScript,
and
why
shouldn't
you
be
I
mean
javascript
is
awesome.
A
It
does
what
kinds
of
incredible
things.
It's
blossomed
in
the
last
year's
from
this
little
thing,
to
make
small
button
changes
and
little
things
on
webpages,
the
full-featured
programming,
language,
ecosystem
environments,
with
lots
of
wonderful
libraries
and
frameworks
and
features
that
are
great.
The
thing
is,
though,
it's
possible
to
have
too
much
of
a
good
thing.
This
actually
is
a
screenshot
from
chrome,
dev
tools
of
a
site
owned
by
Google.
If
you
have
a
lot
of
JavaScript,
your
wonderful
site
may
load
slowly
for
many
people
and
also
may
execute
slowly.
A
So
things
on
your
page
may
not
work,
sometimes
because
you've
got
lots
of
JavaScript
running
and
things
can
happen
in
the
browser.
If
you've
got
a
nice
device
and
you're
on
a
nice
connection,
then
it
may
not
be
quite
as
important,
but
for
a
lot
of
people
in
the
world.
This
matters
a
lot
I
mean
for
me,
for
example,
if
I'm
on
a
train
somewhere
trying
to
go
somewhere
some
sites
that
you
try
to
load
up,
don't
work
at
all.
A
Other
kinds
of
things
can
be
problems,
but
we're
going
to
discuss
JavaScript
today.
That's
why
certain
people
around
the
world
are
trying
to
look
at
your
site
and
instead
they're
getting
frustrated.
So
this
is
not
good.
Let's
focus
on
the
JavaScript
side
of
things.
What
can
we
do
as
JavaScript
developers
to
make
these
sites
load
faster
and
be
functional
more
quickly?
One
thing,
of
course,
is
ship
less
JavaScript,
okay
great.
How
do
we
do
that?
A
Well,
you
can
minify
in
gzip
our
code,
of
course,
you're
probably
already
doing
both
these
things,
but
people
don't
always
minify,
don't
always
gzip.
It
send
less
code
over
the
wire,
at
least
it
will
load
up
more
quickly,
also,
of
course,
code
that
isn't
being
used
shouldn't
be
on
your
page.
It
happens
a
lot
because
you
have
code
for
all
over
your
site.
What
you
put
on
all
your
pages
on
your
site,
but
in
fact
that
makes
things
just
slower
for
the
user.
A
You
can
also
go
through
the
code
coverage,
tool
of
chrome
and
realizing
now
I'm
missing
an
S
and
I'm
necessary
yeah,
so
that
was
necessary,
but
it's
not
there
anyway,
that
wasn't
necessary.
It
should
have
been
included,
but
don't
let
the
deter
you
if
you
have
extra
code,
don't
include
on
your
pages
also,
if
you're
using
frameworks
or
are
using
various
kinds
of
ways
to
move
code
which
merges
together,
reduce
your
bundle
sizes
make
those
more
efficient.
If
there
are
dependencies
that
shouldn't
be
there
get
rid
of
those
things
that
all
helps.
A
It's
also
possible
to
load
code
when
it's
needed
so
right
before
an
interaction
is
going
to
occur,
load
the
JavaScript,
then
like
lazy
load,
it
don't
litter
all
at
once
and
block
rendering
and
tell
everything
loads
or,
of
course
you
can
use
amp,
which
you
know,
I
talked
about
amp
quite
a
bit.
Amp
is
a
way
to
use
less
JavaScript
and
make
pages
load
faster
in
general.
So
there's
all
those
things.
A
None
of
those
really
deal
with
the
problem,
though,
of
making
things
making
interactions
happen
more
efficiently,
like
JavaScript
can
be
running
and
it
can
be
blocking
that
would
browser
from
doing
things.
Long
tasks
can
make
things
not
able
to
happen.
There's
a
way
to
get
around
this,
which
is
webworkers
because
the
web
is
single-threaded.
The
web
brokers
run
in
another
thread,
so
you
can
offload
code
that
is
gonna
take
a
while
to
run
into
a
different
thread
via
web
worker
kind
of
neat
right
that
way.
A
Your
code
is
running
over
here
in
a
different
thread
and
your
other
code
keep
on
handling
events.
The
browser
can
keep
on
doing
things.
But
what
is
this
about?
The
thread
thing?
Why
is
the
web
single
threaded?
I
mean
every
modern
OS
is
multi-threaded
and
multitasks?
Why
can't
the
web
do
this
well
part
of
it.
Is
that
it's
just
how
browsers
and
JavaScript
we're
created
how
they've
always
been
now,
of
course,
modern,
browsers
multitask,
you
can
run
various
tabs,
they
can
be
loading
files
while
doing
the
various
other
kinds
of
things
depending
the
screen.
A
But
the
thing
is
that
each
browser
tab
has
a
single
thread
for
the
UI,
which
means
only
one
process
can
make
changes
to
the
screen
at
a
time.
So
JavaScript
can
block
the
browser
from
doing
things
and
vice
versa.
Imagine
it
wasn't
that
way.
Much
of
users
allow
JavaScript
tasks
to
run
simultaneously.
They
call
a
modified
Dom
at
the
same
time,
and
while
the
browser
is
laying
out
and
paying
the
screen,
this
task
is
modifying
the
Dom.
This
task
is
modifying
the
Dom
you'd
have
race
conditions
and
general
chaos.
A
It
would
not
work
it's
confusing,
but
because,
as
we
know,
javascript
is
asynchronous.
Javascript
depends
on
events
getting
fired
as
a
sync.
So
doesn't
it
isn't
the
kind
of
thing
where,
as
soon
as
an
event,
fires
code
executes
immediately?
Well,
it's
not
actually
how
it
really
works.
Remember
that
all
the
code
on
a
single
web
page
runs
in
a
single
thread.
This
thing
called
the
event
loop.
Let's
look
at
this
diagram
here,
rather
or
not
diagram
animation.
If
I
take
archibald
I've
borrowed
for
this
case
over
here,
this
shows
the
simplified,
simplified
version
of
JavaScript.
A
You
event
loop,
so
the
browser
fires
an
event
right
if
there's
event
handler
for
that
thing,
that
could
runs
until
it's
done
as
other
events
fire.
They
get
added
to
a
queue
so
we're
gonna
see
over
here.
These
tasks
move
into
the
loop
they're
the
arc
gets
handled.
Another
task
is
being
queued
up
and
event
loop
handles
that
one
next,
all
well
and
good.
So
really,
if
this
works
out
nicely,
the
browser
was
able
to
get
the
tasks
pretty
quickly
and
there
delays.
A
However,
if
a
long
task
happens,
it
has
to
wait
for
the
task
to
finish.
Nothing
else
can
happen
until
that
task
completes,
so
the
next
bit
of
code
will
be
delayed.
It
also
means
the
browser
may
be
blocked
from
doing
things
in
the
UI.
You
may
be
blocking
the
browser
from
entering
things
into
a
form
you
can't
be
blocking
scrolling
from
happening.
A
Animations
make
a
janky
and,
of
course,
if
the
person
taps
on
something
else,
while
your
code
is
still
running
that
event
can't
get
handled
until
your
code
finishes
running
because
it's
all
one
event
loop,
it's
all
one
thread,
so
that
can
be
a
problem.
You
can
get
this
case
where
there's
traffic
holding
up
the
entire
thing
happening
in
the
Dom.
We
want
to
avoid
this
happening.
Not
only
you
do
have
JavaScript
causing
pages
to
load
slowly
sometimes,
but
it
makes
this
unresponsive
screen
where
you
can't
swipe.
A
You
can't
do
things
users,
don't
like
that
sort
of
thing.
So
one
solution
for
this
is
to
use
web
workers.
Web
workers
are
special
because
javascript
and
web
worker
runs
in
its
own
thread,
which
is
nice.
Web
Brook
has
been
around
for
quite
a
long
time
actually
about
10
years.
So
why
don't
they
use
more
I
think
because
their
limits
make
them
harder
to
use
the
thing:
is
workers
can't
cause
those
race
conditions
in
the
DOM
and
can't
get
in
the
way
of
other?
You
know
kinds
of
things
because
they
lack
access
to
the
Dom.
A
They
also
like
access
to
the
global
scope.
They
can't
modify
variables
that
are
in
the
global
scope,
so
they're
limited
you
can
kind
of
pass
them
things
and
they
can
then
send
messages
back,
that's
how
they
work.
They
work
by
passing
messages
back
into
force,
so
web
workers
can
pass
messages
to
the
native
thread,
but
you
can
pass
messages
back
to
the
web
workers.
That's
about
it.
Now
that's
kind
of
complicated.
A
There
are
libraries
that
make
this
easier,
like
comlink
by
Surma
and
worker
eyes
by
Jason
Miller,
but
even
with
those
libraries
workers
can't
access
the
Dom
they're
stuck
in
this
little
Dom
area
over
here,
where
they
can't
get
near
the
Dom.
That's
a
big
obstacle.
Fortunately,
there's
a
new
library
called
wicker
Dom.
This
was
released
by
the
amp
project
a
couple
years
ago.
Wicker
Dom
works
in
the
following
way:
it
the
copy
of
the
dom
the
worker
can
use,
and
the
worker
dom
also
recreates
in
its
own
javascript,
a
subset
of
the
standard
Dom
API.
A
So
the
worker
can
manipulate
the
Dom
and
make
changes
on
the
page
using
standard,
Dom
methods
and
properties.
It
looks
sort
of
like
this.
There
is
a
copy
of
the
Dom.
If
you
will,
a
virtual
Dom,
which
is
worker,
Dom,
creates
and
there's
a
real
Dom,
and
the
worker
Dom
creates
the
two
Dom's
a
lot
of
Dom
zero.
Sorry
worker
Dom
keeps
the
real
DOM
and
the
virtual
Dom
in
sync.
A
So
when
a
change
is
made
in
the
real
Dom
worker
Dom
detects
that
it
dips
it
and
detects
it
and
sends
a
message
over
to
the
worker
telling
it
to
go
ahead,
make
the
same
change
in
the
copy.
If
your
workers
code
changes
its
copy
worker
Dom
recognizes
that
mutation
and
sends
a
message
over
to
the
real
Dom
making
the
same
change
over
there.
It's
a
little
bit
of
overhead,
but
it's
actually
pretty
fast.
A
Here's
how
it
kind
of
looks
weird
on
panels
mutations
in
this
way
it
does
a
dipping
of
the
virtual
Dom
in
the
actual
Dom,
which
sounds
kind
of
like
other
frameworks
have
used
before
and
efficient
different
mechanism
figures
out
what
changes
and
then
in
a
codes
it
encodes
those
changes
into
an
array
buffer,
a
very
compact
way
of
sending
a
message
over
to
the
other
thread
that
has
to
make
the
change
and
then
passes
it
over.
Here's
an
example
of
that.
A
So,
for
example,
this
kind
of
standard-looking
thing
here,
document.createelement
'div,
gets
represented
in
the
following
way
as
this
very
compact
looking
series
of
numbers,
the
first
number
that
represents
the
reference
to
the
node,
which
this
div
here
will
be
always
indexed
number
3.
The
second
number
tells
the
main
thread.
What
kind
of
Dom
boat
is
being
created?
Element
boat
happens
to
be
number
1,
then
the
node
name
of
div
corresponds
the
six
and
so
on
and
so
forth.
So
any
kind
of
mutation
gets
encoded
into
a
small
bit
of
numbers.
A
That's
why
this
message
passing
actually
isn't
that's
slow,
I
think
the
Cermak
chily
has
a
whole
blog
post
about
this,
where
he
discusses
how
it
can
be
pretty
fast.
He
does
some
measurements
about
this,
so
worker
Dom
does
this
for
you,
but
it's
still
a
little
complicated.
You
might
be
telling
yourself.
Ok,
so
I
can
try
this
thing
out.
This
worker
is
but
how
do
I
use
it
have
to
build
this
myself?
A
I,
don't
use
this
whole
worker
Dom
thing
well,
the
good
thing
is:
there's
an
easy
way
from
the
framework
that
wants
to
make
things
easy
for
developers
and
advanced
web
features
accessible
to
all,
which
of
course,
is
our
friend
amp
amp,
as
you
probably
already
know,
was
created
by
Google
as
an
open
source
project.
The
goal
being
to
make
the
web
faster
and
easier
to
use
and
just
better
in
general
amp,
is
now
part
of
the
open,
Jazz
family.
It's
why
I'm
here
today,
amp
is
now
an
open,
JSP
earth
project.
A
Tu
amp
may
just
be
a
way
to
get
into
Google's
top
stories
carousel,
which
has
a
special
place,
and
if
you
do
that,
you
may
also
know
that
Google
is
just
announced
recently
that
in
the
near
future,
any
page
that
meets
new
standards
for
speed
and
for
a
stable
layout,
which
are
called
Web
vitals.
Any
page
that
meets
these
standards
will
now
be
eligible
to
be
at
the
top
stories.
Carousel,
not
just
amp
pages,
in
fact,
and
pages
that
are
slow
or
unstable,
won't
get
in
there
anymore.
A
This
is
not
true
now,
but
this
will
be
happening
in
the
fairly
near
future,
so
you
may
have
thought
of
amp
in
various
kinds
of
ways,
but
probably
not
as
a
way
to
make
developers
lives
easier.
That,
in
fact,
is
why
I'm
interested
in
amp,
because
it
makes
things
easier
for
developers
for
common
and
basic
tasks.
What
is
amp?
It's
basically
a
web
components,
library,
so
HTML
was
created
about
30
years
ago,
and
it
was
a
document
description
language.
So
there's
things
like
hey.
A
This
is
boldface,
and
this
is
a
paragraph
there
weren't
things
like
hey:
this
is
the
interactive
menu
hey.
This
is
image
carousel
because
those
things
didn't
exist
yet,
as
those
things
became
part
of
the
web
javascript
grew
to
the
task.
To
make
these
things
happen.
To
make
interactions
happen.
Html
couldn't
do
those
things
which
means
if
people
end
up
like
adding
a
lot
of
code
to
their
site,
which
isn't
always
necessary.
A
So
amp
aims
make
this
better
by
using
web
components
to
add
new
tags
to
HTML
that
do
those
kinds
of
things
the
HTML
didn't
do
before.
You
see
some
examples
over
here
in
this
large
list
of
colorful
looking
names,
things
like
a
flying
carpet
effect,
Facebook
common
components,
the
amp
carousel
component,
all
kinds
of
things,
I
think
I
see
Hulu
player
over
there.
All
these
tags
here
worked
because
the
web
components
that
are
run
by
small
bits
of
JavaScript
that
amp
uses
on
the
contrast.
A
Amp
discourages
you
from
writing
your
own
JavaScript,
because
that
can
make
things
slow.
That
was
the
idea
of
amp.
It's
now
allowing
more
JavaScript
to
be
written
as
well
soon
see
before
we
see
that,
though
here's
our
amp
looks
in
practice.
This
is
simply
how
you
know:
YouTube
embed
an
amp.
Instead
of
embedding
youtubes
on
JavaScript
use,
a
component
called
amp
YouTube,
specify
a
layout
type
and
has
various
layouts,
including
responsive,
which
is
its
way
of
automatically
making
the
YouTube
video
or
any
component
shrink
of
its
container
shrinks
or
expanded.
A
The
container
expands
and
the
width
and
height
are
specified
in
advance.
That's
because
amp
wants
to
prevent
things
from
shifting
around
on
the
screen
and
wants
to
prevent
content
layout
shift.
So
it
creates
a
space
for
everything
in
advance
and
then,
as
things
load
up
develop
into
their
space
things
that
move
around
the
browser
wasn't
repainting
the
screen
recalculating
the
layout.
Things
are
just
faster
and
more
stable.
A
And
finally,
here
we
have
data-video-id
simply
the
ID
of
the
video
of
the
YouTube
video,
and
then
you
just
do
this
and
there's
your
YouTube
video
all
done
so.
I
was
saying
before
a
worker
DOM
and
makes
this
possible
to
use
through
a
component
called
amp
script.
An
scrip
is
kind
of
a
wrapper
around
worker
Dom,
which
brings
it
into
amped,
makes
it
pretty
easy
to
use.
How
does
this
look?
Let's
try
a
simple
hello
world
example
over
here
so
hello
world.
A
A
Then
we
have
the
script
over
here,
which
simply
grabs
h1
tag
and
appends
a
comma,
a
space
in
the
word
world
and
there
you
are
notice
that
we
have
typed
equals
text
plane
instead
of
text
JavaScript.
This
is
so
the
browser
doesn't
see
this
as
a
script
executes
it.
Instead,
it's
just
plain
text:
am
script
can
grab
it
and
give
it
to
worker
Dom
to
use,
there's
that
and
let's
see
if
we
can
get
this
thing
to
actually
work.
I
think
that's
the
next
thing
over
here.
A
All
right,
I'm
gonna
make
a
new
tab
over
here
and
I'm
going
to
enter
over
here
the
URL
of
my
little
demo.
That's
actually
not
what
it
is.
It's
actually
supposed
to
be
this
script
getting
closer
now,
thank
you
all
to
completion
for
almost
being
there.
This
is
that
hello,
world,
okay,
hey
I'm,
coming
for
myself,
because
no
one
else
is
here,
but
me
and
my
dog
hello
world.
So
what
does
it
actually
do?
He
see
that?
Actually
it
worked.
You
can't
tell
what
it
actually
did.
A
Let's
look
here
over
here
at
the
console,
rather
at
the
sources
we
can
see
here
at
the
bottom
of
the
sources
and
dev
tools.
This
little
extra
thing
this
thing
over
here
and
there
is
this
little
bit
of
JavaScript
and
the
top
over
here
and
let's
make
this
a
little
bigger
I
said:
give
it
a
little
bigger.
Thank
you
very
much.
The
top
over
here
is
worker.
Dom
stuff
in
the
bottom
is
our
JavaScript,
so
there
it
is.
We
actually
managed
to
inside
a
worker.
Add
this
little
world
thing
over
here.
A
There
you
go
that
worked.
It
wasn't
that
exciting.
So,
by
the
way,
this
is
a
little
more
of
the
page
that
can
go
in.
So
this
is
more
of
the
app
page.
This
would
be
part
of
notice
that
the
first
thing
we
do
over
here
is
we
load
up
amps
own
runtime,
which
makes
impossible
I
also
load
up
the
bit
of
JavaScript
that
encapsulates
worker
Dom.
That
makes
an
EM
script
work,
so
you
can
also
put
this
JavaScript
into
different
files
of
putting
it
in
line.
A
In
this
case,
we've
just
stuck
the
JavaScript
into
a
different
file
called
hello
world
is
and
pointed
the
source
attribute
of
am
script
to
that
file.
There
we
are
a
more
glamorous
example.
Here
is
an
event
handler,
so
we've
added
a
button
to
HTML
over
here
this
button
that
says
hello
who
and
added
some
more
JavaScript
that
adds
an
event
listener
to
the
button
where,
if
it's
clicked,
it
adds
the
famous
comma
and
world.
Let's
try
this
out
over
here.
I
think
this
is
called
hello
button,
which
I
named
very
very
cleverly
and
I.
A
Think
this
little
whoops.
That's
not
what
dude
there
we
go.
Okay,
like
that,
a
little
smaller
and
hello
who
look
at
this
hello
world
and
more
worlds
and
more
worlds.
Now
the
document
we
use
over
there
document
object
is
not
the
same
as
the
one.
Usually
we
see-
let's
add
a
breakpoint
over
here
and
run
this
thing
again,
but
again,
okay,
let's
go
to
the
button
notice.
The
document
over
here
is
not
the
usual
document.
It
contains
the
things
you
wouldn't
usually
see.
A
Look
at
this
seven
and
eight
and
nine
some
arrays
at
E
some
more
things
over
here.
This
is
because
this
document
object,
not
the
one
that
Dom
provides.
The
browser
provides
it's
created
by
worker
Dom
and
worker
Dom
gives
you
all
these
things
to
simulate
a
Dom
kind
of
interesting
kind
of
neat.
That's
how
it
works.
A
So
there's
that
there
is
that
JavaScript
over
there,
okay
and
you
can
be
more
in
a
worker
workers,
actually
natively
support
fetch
XML,
HTTP
requests,
WebSockets
canvas
all
kinds
of
features
like
that:
here's
a
fetch
version.
Let's
try
that
one!
So
again,
we
just
have
a
fetch.
Instead
of
having
the
thing
just
stuck
in
there,
you
click
on
the
button,
and
then
you
fetch
it.
Let's
go
over
here
and
see
how
that
works.
A
So
here's
hello,
fetch,
okay,
let's
go
over
here
to
the
network
tab
and
see
if
we
can
watch
this
being
added
so
there's
what's
additive
there
we're
gonna
click,
hello,
who
and
notice
hello
texts
was
grabbed
over
there
and
it
contains
the
incredible
payload
of
comma
world
there.
It
is
all
these
things
are
not
so
complicated
and
a
way
to
get
JavaScript
into
a
worker
which
is
kind
of
neat.
Remember,
though,
this
is
actually
not
again.
The
real
document
API
remember
that
rooker
Dom
has
and
recreated
these
things
with
its
own
JavaScript.
A
A
Sorry
about
this
cut
here
in
the
video
my
dog
got
bored
and
went
downstairs
and
was
stuck
inside
the
downstairs
area.
I
couldn't
get
out
and
there
was
some
general
chaos
for
a
little
while,
but
now
we're
back
so
I
think
I
was
talking
about
where
we
were
here.
I
think
we
were
somewhere
over
here
in
the
previous
slide
there
we
are
that
worker
Dom
recreates,
the
api's,
with
its
own
JavaScript,
doesn't
recreate
the
own
the
whole
dumb
API,
because
it
just
couldn't
do
that.
A
So
there
is
this
handy
web
compatibility
table
over
here,
which
you
can
find
at
go.
Dev,
slash,
amp
script.
Api
is
this,
provides
a
list
of
API
is
that
are
and
are
not
supported,
so
you
can
go
through
your
JavaScript
and
if
things
aren't
supported,
replace
them
with
the
Quillen
API
is
that
are
supported
there.
Also
a
couple
of
limits
that
AM
script
places
in
there.
So
you
don't
violate
web
vitals
principles
and
have
things
loading
slowly
then
I've
layout,
shifting
around
on
the
screen,
one
of
those
things
is
M.
A
Script
doesn't
allow
more
than
150
K
total
JavaScript
per
page.
If
there
are
use
cases
that
required
more
than
that,
the
team
would
consider
raising
the
limit,
but
so
far
no
one's
really
complained
about
it,
because
it's
usually
used
for
the
tasks.
Amp
doesn't
really
do
out
of
the
box.
You
just
want
to
change
something
here
and
there
to
add
some
kind
of
functionality.
The
other
thing
is
that
it
wants
to
restrict
intrusive
mutations.
A
So
if
your
M
script
tries
to
make
changes
before
a
user
action
that
will
make
the
screen
move
around
too
much,
it
will
try
to
block
you
from
doing
those
things,
so
you
can
get
around,
or
rather
you
can
make
your
M
scripts
more
capable
by
taking
some
simple
precautions.
M
script
knows
that
if
your
layout
is
a
fixed
type,
then
that
can't
move
around
too
much
like
if
the
children
of
your
M
scripts
area
change
size,
the
whole
container
won't
change
size.
A
If
the
height
and
width
are
fixed
in
HTML,
it
knows
the
hole,
M
script
area
can't
change.
So
if
those
things
are
true,
if
the
app
script
area
really
is
fixed
to
a
certain
part
of
the
screen,
it
says
go
ahead
and
make
changes
over
here
if
it
isn't
fixed
to
a
certain
part
of
the
screen.
It
says
you
know
what
you
can't
change
things
all
over
the
place.
Tell
users
take
an
action
to
request
to
change,
because
it
would
revolve
a
lot
of
things
that
would
surprise
the
user
in
terms
of
layout
shift.
A
It's
kind
of
more
elaborate
topic
so
to
hear
more
about
it,
go
to
MF
and
meet
about
the
actual
ways
that
it
keeps
this
safe
for
you.
So
again,
I
was
saying
before
that
worker
Dom
has
certain
api's.
You
want
to
not
worry
about
this
too
much
and
just
go
ahead
and
write
your
code.
Have
it
work
out
of
the
box,
you
may
want
to
try
one
of
your
favorite
frameworks.
A
The
team
that
works
on
worker
Dom
also
works
on
various
frameworks
and
uses
them
frequently
and
they've
tried
using
M
script
with
things
like
view,
react
angular
that
HTML
aurélia.
The
thing
is
that
these
frameworks
use
a
certain
specific
subset
of
the
Dom
API
to
do
their
own
changes.
They
do
a
diff
between
the
virtual
Dom
and
the
actual
Dom,
and
then
they
use
certain
api's
consistently
to
make
changes.
So
worker
Dom
supports
all
of
those
things.
A
Well,
however,
you
may
find
yourself
with
larger
bundle
sizes
with
certain
frameworks,
so
to
make
your
bundle
sizes
small
and
to
really
follow
the
principles
of
amp
that
yourselves
less
JavaScript
no
more
than
you
need
and
keep
things
fast
for
the
user.
I
recommend
that
you
use
pre
act
and
pre
act.
Actually,
one
of
the
people
that
works
on
the
worker
Dom
team
as
part
of
the
pre
act
core
team.
He
was
very
careful
to
make
sure
that
the
API
is
a
pre
act.
Users
are
well
supported
within
worker
Dom.
A
It's
a
pre
act
actually
is
like
react
very
similar.
It's
compatible
in
most
ways.
You
can
always
transform
react
and
pre-act,
but
it's
only
3k
minified
in
gzipped,
so
out-of-the-box,
not
much
extra
JavaScript
being
added
to
your
project
and
actually
amp
itself
is
being
rewritten
with
pre
act.
Amp
is
being
recreated.
So
that
all
the
components
will
work
reliably
by
themselves
not
be
using
the
up
runtime
at
all,
this
is
possible,
usually
now
but
not
guaranteed,
but
to
make
amp
more
part
of
the
web.
A
Those
efforts
being
undertaken
as
I've
begun
to
take
an
amazing
pre
act,
so
the
app
team
is
very
invested
in
pre
act.
So
in
the
spirit
of
that
I
take
my
hello
world
example,
and
we
did
it
with
pre-act.
It's
not
that
much
more
complicated.
It's
just
a
component
and
usual
kind
of
JSX
things.
Let's
now
drag
this
terminal
here
into
our
visible
window
there.
It
is,
let's
build
this
suspense
suspense
suspense:
let's
serve
this
now,
let's
drag
this
out
of
the
visible
area,
and
let's
try
this
over
here.
A
A
Soap,
react
works
so
that's
my
discussion
here
about
work
arise.
Java,
Script
made
easier
by
amp.
If
you
want
to
learn
more
and
try
this
yourself,
we
just
updated
this
tutorial
here.
It's
quite
nice
now
go
to
go
dot,
amp
dev,
slash,
learn
script
and
you
can
make
your
own
custom
UI
widget.
That
does
some
form
validation.
It
guides
you
along
and
teaches
you
about
the
various
things
damn
script.
Then
we're
dumb
do
on
the
way.
A
So
look
at
worker
Dom's
code
to
get
involved
in
the
project
just
go
to
github.com,
slash
ant
project,
slash
worker
down
and
yeah.
Try
it
out.
We
think
that
workers
are
a
way
to
make
javascript
more
friendly
for
the
user
and
get
me
users
way
less
often
there
was
various
ways
to
use
workers
and
the
way
that
amp
provides
makes
it
simple
to
get
started.
Try
it
out.
If
you
like,
it,
then
go
from
there
thanks
a
lot
and
have
a
great
day.