►
From YouTube: Wasm in the Fall
Description
We're bringing WebAssembly to you this fall with another another virtual Meetup! Streaming is sponsored by solo.io, also one of this months presenters.
More details at https://www.meetup.com/wasmsf/events/273039707/.
A
B
C
D
B
B
If
you're
on
the
zoom
in
particular
pay
attention
to
what
you
say,
what
you
do,
we
don't
have
any
tolerance
for
for
inappropriate,
behavior
and
respect
for
everyone
is
always
a
good
thing.
This
meetup
is
our
fall
event.
We
have
two
awesome
talks
lined
up
for
you,
they'll
go
into
the
details,
but
it's
all
made
possible
by
the
the
help
of
our
friends
at
so
I
o
betty
who's,
the
co-host
and
yuval
and
his
team
will
be
speaking
later.
B
E
E
Yes,
all
right
so
welcome
everybody,
I'm
irval,
I'm
magic
chief
architect
at
solo
io
and
with
me,
shane
o'donnell,
he's
a
also
from
solo
leon,
naturally
social
engineer-
and
we
would
like
to
talk
to
you
today
about
a
developer
experience
that
is
docker-like
for
extending
android
and
other
cloud-native
products
using
web
assembly
and
webassembly
hub
as
the
first
step.
We'll
do
a
quick
introduction
to
envoy.
So
we
all
kind
of
have
a
baseline
and
we
are
we
all
talking
about
the
same
thing.
So
that
way,
you
don't
need
any
prior
knowledge.
E
It's
going
to
be
very
high
level
and
going
to
talk
a
little
bit
about
the
envoy,
the
the
control
plane,
the
data
plan
where
webassembly
fits
in
and
then
how
do
we
enhance
the
developer
experience
and
then
finally,
we'll
have
a
short
demo
where
we
show
live,
hopefully,
hopefully,
a
filter
that
was
written
in
wasim
and
used
by
envoy
so
and
in
the
end,
we'll
have
some
time
for
questions
all
right.
So,
let's
continue
first,
what
is
this
product
onward
that
we're
talking
about
so
in
the
cloud
native
ecosystem?
E
E
Other
products
are
service,
meshes
most
notable
hco
and
there's
a
lot
of
stuff
you
can
use
only
for
so
essentially,
it
can
be
used
as
front
proxy,
a
middle
proxy
or
a
side
by
side,
car,
proxy
and
part
of
the
appealing,
a
feature
set
it
makes
envoy
used
in
so
many
different
use.
Cases
is
the
ability
to
extend
it
now.
Today,
anger
is
written
in
c
plus,
plus
and
the
in
order
to
extend
it.
E
You
essentially
need
to
write
z,
plus
code
and
rebuild
android
with
your
filter
code
or
your
extension
code
compiled
into
android
and
that's
what
we
do
in
sol
io.
We
have
our
own
distribution
of
anyway
with
glue
and
that
we
use
to
provide
extra
value.
On
top
of
the
core
envoy
now
android
is
100
open
source,
there's
no,
a
company
that
sells
it.
E
E
That
envoy
has
provides
simpler,
use
cases
and
essentially
give
you
a
specialized
api
for
that
use
case.
So
glue
specifically,
is
a
an
api
gateway
and
the
way
it
works.
If
you
can
see
this
diagram
here
and
we
get
essentially
connects
to
glue
to
get
its
configuration,
but
all
the
data
goes
only
through
android
only
through
this
proxy
and
during
the
data
path.
There's
no
really
communication
for
glue,
as
per
configuration,
so
glue
asynchronously
delivers
the
routing
information.
You
know
this
request
should
go
here.
E
E
So
the
data
plan
is
that
the
path
user
data
requests
go
through
and
the
control
plane
is
the
out
of
band
configuration
plane
where
you
deliver
configuration
to
the
data
plane,
so
in
glucase,
a
user
configures,
what
we
call
a
virtual
service
that
has
a
route
that
in
this
case
says
everything
goes
to
service
one,
and
we
also
want
to
apply
an
open
policy
agent
policy
right
so
that
that's
this
is
that
configuration
on
the
bottom
right.
A
glue
translates
that
configuration
to
envoy
configuration
and
delivers
it
to
envoy
and
angular
synchronously
in
an
eventual.
E
E
The
request
goes
through
a
series
of
filters
that
can
manipulate
the
request
right.
So
in
this
example,
we
have
here
a
set
of
four
filters:
external
thread
limit,
a
jrpc
transcoder
and
a
router
filter,
and
the
request
goes
through
each
of
them
in
order
in
order
to
be
processed
by
android.
So
the
first
filter
external
auth
calls
out
to
an
external
authorization
server
and
asks
if
the
request
is
authorized
and
if
it
authorize
it
continues
to
the
next
builder
and
the
next
filter
checks.
If
we
need
to
apply
rate
limiting,
you
know,
return
429..
E
Extend
this
extensions
using
c
plus
plus
code
that
gets
compiled
into
envoy,
and
let's
talk
a
little
bit:
how
do
we
extend
the
data
plane
so
the
way
we
do
it
with
glue?
We
write
custom
filters
right,
so
we
android
build
system
is
engineered,
so
you
can
very
easily
bring
in
upstream
envoy
and
add
your
code.
On
top
of
it
right.
Add
some
extra
code
rebuild
the
binary
into
a
new
android
binary.
That
now
includes
your
extension
now.
E
E
You
need
to
understand
a
synchronous,
c
plus
plus,
and
that's
pretty
much
the
only
language
you
can
use.
There's
a
little
bit
talk
about
starting
to
introduce
rust
to
be
used
for
native
filters,
but
it's
not
there
yet
by
the
advantage.
It's
very
fast
and
the
code
is
strongly
tagged,
so
it's
safe
to
write.
F
F
So
if
we
go
to
the
next
slide,
you
know
webassembly
is
kind
of
a
little
bit
of
a
misnomer
because
it's
not
really
dedicated
to
the
web
or
necessarily
assembly.
So,
even
though
it
was
originally
built
with
the
web
in
mind,
it
was
actually
designed
in
such
a
way
that
it
could
be
embedded
in
other
environments.
F
So
you
know
google
came
along
and
saw
this
and
realized.
Does
it
actually
have
some
pretty
cool
synergies
with
envoy,
especially
when
it
comes
down
to
filters?
So
when
we
think
of
webassembly
and
all
the
benefits
it
can
give
us,
we
got
to
think
about
what
kind
of
features
and
characteristics
of
webassembly.
F
Would
we
like
to
see
that
we
could
maybe
take
advantage
of
in
envoy
so
on
the
next
slide?
The
first
one
is
that
it's
portable,
so
you
know
I
don't
have
to
target
any
specific
platform,
I'm
just
targeting
the
webassembly
output
format,
and
then
you
know
whatever
runtime,
on
whatever
environment,
we're
running
on
we'll
make
sure
that
it's
optimized
to
run
in
that
environment.
So
it's
one
more
thing.
I
just
don't
have
to
worry
about
next
up,
it's
secure,
considering
that
you
know
wasm
obviously
has
its
origins
in
the
web.
F
It's
kind
of
designed
to
be
run
in
a
browser,
and
you
know
browser
is
kind
of
implicitly
a
or
explicitly
a
hostile
environment.
You
need
your
wasm
applications
not
to
be
able
to
do
nefarious
things
and
attack
each
other.
So
you
know
by
design
it's
run
in
a
sandbox
and
in
order
to
break
out
of
that
sound
well
it
just
it
can't
break
out
of
that
sandbox.
So
it's
inherently
just
very
secure.
F
In
order
to
communicate
with
the
outside
world,
we
basically
have
to
use
a
specific
set
of
predefined
apis,
and
you
know
you
can
tweak
permissions
with
those
and
say
this
application
can't
talk
to
the
network
or
whatever
you
need
to
do
to
like.
Lock
it
down,
but
the
main
point
is
that
it's
pretty
secure,
which
is
something
we
really
value,
especially
if
you
think
about
something
that's
going
to
live
on
the
edge
of
your
like
kubernetes
cluster
as
a
proxy.
It's
that's
awesome.
F
I
want
to
run
a
bunch
of
webgl
or
I
want
to
run
some
really
complex
algorithms,
and
you
know
some
really
process
heavy
number
crunching
code
and
javascript
just
isn't
up
to
it
and
while
webassembly
is
going
to
be
faster
than
javascript
at
that,
what's
actually
surprising
to
a
lot
of
people
is
that
it's
almost
as
fast
as
native
c,
plus
plus.
So
if
you,
if
you
write
some
c
plus
plus
code
and
you
compile
it
to
you,
know
a
native
binary
and
then
you
write
some
c
plus
code
and
complain,
compile
it
to
webassembly.
F
Obviously
it's
a
little
bit
slower,
but
you
know
right
now.
We're
seeing
maybe
10
to
20
performance
degradation,
and
you
know
that
comes
along
with
you
know.
This
is
still
pretty
early
stages,
so
we're
pretty
optimistic.
It's
going
to
get
even
faster,
but
when
you
consider
all
of
the
advantages
that
we
get
from
running
web
assembly
over,
you
know,
like
you've,
all
said
being
a
native
c
plus
developer.
F
You
know
you,
don't
you
don't
need
to
know
as
many
things
in
order
to
be
productive
in
webassembly,
so
that
performance
game
really
isn't
that
big
of
an
issue
in
most
arenas?
So
you
know
that
brings
us
nicely
into
the
very
next
thing,
which
is
you
can
kind
of
write
this
in
any
language
right
now,
we're
kind
of
supporting
c,
plus
plus
rust,
assembly
script
and
tiny
go.
F
But
you
know
it's
just
something
that
brings
more
people
into
the
ecosystem
gets
more
eyeballs
on
webassembly
and
you
know
just
brings
the
whole
ecosystem
as
a
whole
up,
which
is
awesome.
So
you
know
that
checks
pretty
much
all
the
boxes
that
was
on
one
of
the
slides
we
looked
at
previously.
We
can
use
any
language,
it's
fast,
it's
safe.
You
don't
need
to
recompile
envoy,
which
you
know
we
really
can't
overstate.
F
That's
that's
a
big
deal,
because
unless
you
want
to
maintain
a
distribution
of
envoy
and
become
a
c
plus
plus
developer
or
even
more
than
that,
an
envoy
developer,
you
know
you
probably
don't
want
to
get
into
the
low-level
envoy
api.
If
you're
just
trying
to
write
a
couple
web
filters,
which
is
awesome-
and
you
know
it's
easy
to
use
it's
in
a
language
you're
familiar
with
and
there's
not
a
huge
surface
area
for
you
to
touch
which
brings
us
to
how
how
do
we,
you
know
harness
this
specifically
in
envoy.
F
What
they've
done
so
next
slide
that
they've
got
built
in
this
wasm
support
natively
and
what
they've
done
is
they've
embedded
the
v8,
runtime
and
they've
exposed
a
way
to
load
these
webassembly
modules
or
which
are
going
to
act
as
envoy
filters
via
the
control,
plane
and
envoy,
which
means
that
not
only
do
you
not
need
to
maintain
your
own
distro
and
fork
of
envoy
and
maintain
all
kinds
of
stuff
that
has
to
do
with
that.
You
don't
even
need
to
restart
envoy
in
order
to
deploy
these
they
can
be.
F
So
you
can
see
here
there's
an
example,
call
with
some
parameters,
and
you
can
kind
of
get
a
feel
for
this
is
going
to
be
pretty
powerful
and
you
can
use
it
to
create
any
any
filter
that
you
could
create
with
a
native
envoy,
almost
any
filter.
At
least
you
can
create
using
this
low-level
interface,
but
it's
still
kind
of
tricky
to
use.
So
for
that
reason,
people
have
actually
started
building
sdks.
F
Building
these
filters
for
envoy-
and
you
know
pretty
pretty
much
shipping
them
in
the
application.
You
can
go
forward
next
slide
and
next
slide
again
yeah.
So
we've
we've
pretty
much
harnessed
the
use,
any
language,
the
fast
and
the
safe
and
the
easy
or
sorry
the
need
to
compile.
But
we
haven't
really
touched
easy
yet
because
going
from
zero
to
I've
written
my
own
custom
filter
that
uses
this
sdk
that
uses
this
api
that
deploys
to
envoy
still
is
kind
of
hand
waving
away
a
couple
steps.
F
F
We
just
thought
this
was
you
know
really
something
that
we
believe
as
well,
that
this
guy's
saying
that
web
assembly
on
the
server
is
could
be
the
future
of
computing
and
that's
like
a
really
strong
statement,
but
you
know
we
don't
really
believe
that
that's
oversaving
it,
because
you
know
this
if
this
was
built
10
years
ago
this
this
could
have.
We
could
use
this
instead
of
docker,
which
is
which
is
pretty
powerful.
So
you
know
in
light
of
that,
and
given
that
this
is
the
future,
how
do
we
get
more
people
under
this?
F
How
do
we
get
the
future
here
closer
and
how
do
we
lower
the
barriers
to
entry
to
using
this?
So
what
we've
come
up
with
is
webassemblyhub,
which
is
kind
of
an
overall
idea
of
how
do
we
make
this
easier,
more
approachable,
and
how
do
we
address
the
primary
pain
points
for
developers?
So
we've
we've
identified
four
main
things,
and
these
are
them
here
that
are
kind
of
the
first
barriers
you
hit.
If
you
want
to
do
all
the
stuff
we've
been
talking
about.
First
of
all,
how
do
you
build
it?
F
How
do
you
go
from
an
empty
ide
to
having
a
fully
runnable
wasm
module
that
you
can
deploy
into
envoy?
So
in
order
to
do
that,
we've
taken
some
inspiration
from
some
tools
that
people
like
in
the
community
so
for
we
kind
of
have
something
that's
quite
like
if
you've
ever
used,
create
react,
app
or
ng
new,
if
you're
a
front-end
person.
Just
you
know
a
one-line
script,
that'll
fire
up
a
whole
ide
which
pretty
much
are
a
whole
folder
that
gives
you
a
dev
environment,
a
tool
chain.
F
You'll,
get
scaffolding
and
boilerplate
code,
pretty
much
like
a
hello
world
app
and
you're
just
ready
to
run
with
it
right
off
the
bat.
You
don't
have
to
worry
about
like
setting
up
things
like
bazel
or
you've
already
got
your
package.json
with
all
your
dependencies.
It's
all
set
for
you.
You
can
just
focus
on
writing
your
own
filter
code,
which
is
really
what
you
want
to
focus
on.
The
next
step
is
so
you've
used
our
build
tool.
You've
got
our
you
know.
F
F
We
you
can
see
that
we've
got
we've
pretty
much
checked
the
easy
box,
or
at
least
we
hope
we
did.
You
know
this
is
all
open
for
community
feed
pack.
We'd
love
to
hear
you
guys,
opinions
on
how
to
make
this
even
easier,
if
possible
or
some
things
that
you
guys
are
struggling
with,
and
then
after
that
I'll
pass
it
back
to
to
you
all.
E
Yes,
and
currently,
we
target
envoy,
but
this
can
also
be
applied
to
other
products.
For
example,
open
policy
agent
has
webassembly
a
support
work
as
a
work
in
progress.
This
key
wrestling
that
allows
you
to
run
was
some
binaries
and
kubernetes,
and
they
all
share
the
same.
Problems
of
you
need
to
build
deployed
distribution
discovery
so
hopefully,
in
time
our
tooling
will
extend
to
these
other
projects,
as
well
as
as
well
as
other
developer
use
cases
like
testing
unit
testing,
debugging
and
that
sort
of
things
and
without
further
ado.
E
I
hope
everybody
see
my
bs
code
now
just
do
a
brief
demo
with
how
wasm
looks
using
a
assembly,
script
and
envoy
and
the
envoy
webassembly
assembly
script.
Runtime
first
thing
I
just
one
sec.
Let
me
move
my
face
here.
All
right.
First
thing:
I
wanted
you
to
guys
notice
the
the
envoy
configuration-
and
this
is
a
very,
very
basic,
getting
started
demo
right.
So
when
we
use
wasmi,
we
also
abstract
some
of
that
and
we'll
get
to
that
later.
E
So
the
first
step
is
to
define
the
android
filters,
and
then
there
you
define
where
your
up
a
wasa
module
is,
in
our
case
it's
in
build
optimize,
dot,
wasam
and
various
stuff
like
configuration,
and
we
also
have
the
router
filter.
That's
the
same
router
filter
we
saw
in
the
slides,
so
you
essentially
define
a
web
assembly
filter
and
tell
it
to
load
a
web
file
looking
at
the
typescript
code,
or
rather
assembly
script
code
with
a
typescript
suffix.
E
So
we
get
code
highlighting
we
see
that
filter
code
itself
and
you
can
see
all
these
callbacks
that
were
previously
low
level
c.
Like
functions
are
now
typescript
functions
right,
so
this
function
gets
called
when
request
headers
arrive
so
for
every
request.
We
get
a
call
to
this
callback
and
we
can
decide
what
to
do.
E
In
this
example,
we
perform
an
http
call
out,
which
you
can
see
right
here
and
http
called,
and
the
result
of
this
call
is
returned
to
the
callback
right
here
that,
based
on
the
result,
decides
whether
or
not
to
allow
or
deny
the
request
right.
So
we
make
a
call
out
to
an
external
authorization
server
if
it
returns
200,
we
allow
the
request.
E
E
And
then
I
will
run
envoy
and
you
can
see
here
the
envoy
logs,
let's
clear,
the
terminal
and
on
the
other
terminal.
If
we
do
accrual,
we
get
the
forbidden,
but
if
we
do
a
curl
to
a
path
that
is
allowed
by
the
authorization
server,
you
see
that
we
get
an
authorized
response.
In
our
case
it's
postman
echo,
so
I
just
get
the
the
request
back
as
json.
E
I
also
want
to
note
a
web
assembly
hub
where
you
can
explore
and
discover
various
images.
Various
projects
download
them.
It's
a
very
docker-like
experience.
You
know
it
gives
you
the
the
command
you
need
to
use
in
our
case
was
me,
pull
it's
very
similar
to
docker
poll,
and
this
is
the
gita
page
for
wasmi.
If
you'll
go
to
the
releases,
you
can
download
was
me
itself
and
if
you
go
to
webassemblyhub,
docs
you'll
find
plenty
of
examples,
tutorials
all
the
good
stuff,
and
obviously
we
love
our
community.
E
So
if
you
have
any
questions,
you
can
file
an
issue
open
and
pull
request
even
better
and
be
engaged.
There's
a
awesome
channel
in
the
solo
slack.
If
you
have
any
questions
so
feel
free
to
hit
us
up
and-
and
that's
my
demo
for
today,
if
there's
any
questions,
we
left
intentionally
some
time
for
q,
a
so
till,
please
feel
free.
If
there's
any
questions.
B
D
E
Yeah
yeah,
so
our
goal
we
we
also
defined,
maybe
I'll,
share
the
screen
again
we're
trying
we're
in
the
process
of
defining
a
spec
and
getting
it
more
formally
recognized.
So
if
you
one
sec,
let
me
share
my
screen:
we're
trying
to
use
the
oci
artifact
specification
to
define
a
standard
way
to
push
a
wasm
images
to
standard
oci
registries.
E
You
know
like
a
gcr,
harbor,
azure
container
registry.
All
of
these
registries
can
contain
today
docker
images
but
they're
not
limited
to
docker.
They
can
contain
other
oci
images
and
we
started
with
envoy
because
we
know
envoy
very
well,
but
we
also
hope
to
extend
it
to
other
artifact
types.
For
example,
open
policy
agent
policies
can
also
be
compiled
to
webassembly
and
hopefully
in
the
future,
wasn't
programs
that
can
be
run
in
k,
rustlet.
You
know
and
essentially
bring
this
docker
experience
to
other
awesome
use
cases.
F
Yeah
so
an
example
of
some
of
the
metadata
that
we
were
already
using
for
the
envoy
filter
stuff
is
in
the
particularly
like
very
start
of
envoy.
The
abi
itself
was
for
at
least
for
the
filters
was
very
unstable,
so
it
would
change
pretty
frequently
so
we
use
the
metadata
to
keep
track
of
which
versions
were
going
to
be
supported.
So
if
you
go
to
wasn't
hook
today,
that's
also
like
baked
in
there
to
say
hey.
This
was
built
and
it'll
run
on
istio,
1.3
and
blue
1.5.
C
E
B
It's
worth
calling
out
in
the
context
of
wasm,
more
broadly
and
in
particular
with
wazi,
there's
a
lot
of
effort
to
define
you
know:
state
and
storage
as
a
first-class
citizen.
So
some
of
the
folks
here
work
on
on
wazi
and
there
is
discussions
around
how
to
expose
it
through
a
was
interface
and
maybe
outside
the
context
of
an
envoy
filter.
But
in
other
cloud
and
non-web
use
cases
for
sure.
E
Yeah
yeah,
that
makes
a
lot
of
sense
so
as
far
as
envoy
envoy
has
doesn't
support
a
lot
of
wazi
api,
specifically
because
android
needs
to
retain
control
of
io,
because
android
has
its
own
io
loop,
asynchronous.
It's
going
to
make
sure
all
the
I
o
goes
through
that
loop.
Otherwise,
a
single
io
function
can
block
the
whole
android
thread
so.
E
E
Are
you
referring
to
was
me
itself
so
sort
of
we'll
say
yes
and
no,
so
watson
itself
is
a
command
line
tool
very
similar
to
docker,
but
eventually
android
gets
its
configuration
from
the
control
plane
right.
In
our
example,
we
showed
the
glue
and
glue
can
be
configured
using
kubernetes
crds,
so
in
a
roundabout
way.
Yes,
because
when
eventually,
when
you
interact
with
android
you'll,
probably
do
it
through
a
control
plane
and
the
control
plane
will
probably
have
an.
H
B
H
And
I
typed
slowly
enough-
it's
maybe
better
doing
it
this
way.
I
just
wondering
about
overhead
crossing
the
I
I
mean
you
know
generic
wasn't
question,
but
the
overhead
of
crossing
the
boundary
into
was
a
machine
and
coming
back
out
again
sort
of
do
you
have
to
make
sure
when
you're
designing
the
packet
processing
abi
that
you
don't
get
too
fine-grained
or
is
there
a
point
where
you
say
you
know?
Maybe
I
ought
to
write
this
filtering
c
plus
after
all,
just
so
I'm
not
doing
that
or.
E
Yeah,
that's
that's
a
very
good
question,
so
the
api
is
optimized
to
give
you
the
minimum
amount
of
the
data
you
need
so,
for
example,
process.
The
callback
for
the
headers
doesn't
give
you
the
headers
right,
because
then
you'll
have
to
copy
all
the
memory
into
the
wasom
sandbox.
Instead,
it
gives
you
the
header
size
and
it
allows
you
to
call
a
different
function
to
get
the
headers.
E
So
yes,
wassum
is
sandbox.
Every
time
you
manipulate
memory,
it
has
to
be
copied
into
the
sandbox
and
if
you
want
the
modification
to
be
applied
to
the
request,
it
has
to
be
copied
out
of
the
sandbox,
but
the
api
was
designed
in
such
a
way
that
it
doesn't
happen
by
default,
and
rather
you
when
you
write
the
filter,
you
are
very
aware
on
the
time
you
pay
that
cost.
E
E
D
E
H
Thank
you
yeah,
I'm
I'm
just
going
on
intuition
and
we
know
how
unreliable
that
is.
I
I
I
would
have
guessed
you
might
be
more
concerned
about
trying
to
minimize
the
number
of
method,
calls
and,
and
and
and
and
and
the
data
copying
might
might
be
less
of
a
concern,
but
I'm
I'm
I'm
sure
you
guys
have
well
you've
actually
done
this,
I'm
just
guessing
about
it.
H
B
And
there's
actually
been
previous
talks
at
wasimassef,
which
is
which
is
on
our
youtube
channel
about
the
data
copying
overhead
in
particular,
for
webassembly
and
how
the
webassembly,
the
different
groups
within
webassembly,
both
at
the
overall
specification
level,
as
well
as
wazi,
are
focusing
on
reducing
that
overhead,
as
it
is
a
particular
area
of
concern.
So
I
can
refer
you
to
that
later.
C
E
F
The
top
of
my
head,
I
have
to
double
check
it,
but
you
know
it's
in
in
terms
of
like
support
from
the
the
waz
me
side.
It's
it's
got
the
exact
same
support
as
assembly
script
and
c
plus
plus.
If
you
do
like
a
was
me
in
it,
tiny
go
now
shows
up
as
an
option
and
it'll
show
you,
which
versions
of
all
the
various
android
envoy
distros
that
support
the
version.
F
The
tiny
ghost
targeting
and
the
the
tiny
go
support
that
was
contributed
to
was
me
itself
was
actually
contributed
by
one
of
the
creators
of
tinygo.
So
I
I
haven't
used
it
too
much
myself,
yet
it's
definitely
high
on
my
to-do
list,
but
you
know
given,
given
that
it's
coming
from
the
author
himself,
I'm
pretty
sure
this
part's,
probably
pretty
solid.
C
E
Well,
a
big
one
is
kubernetes
and
naturally
another
one
is
helm.
Helm
charts
for
kubernetes
can
be
stored
in
oci
and
if
you
look
at
the
lci
spec
there's
another
company
that
allows
you
to
release
their
their
artifacts
also
as
oci.
Essentially,
the
problem
oci
solves
is
the
distribution
right.
You
have
a
binary
blob
and
you
want
to
get
it
somewhere
right
so
from
the
developer
laptop
into
your
cluster
in
the
cloud.
E
So
that's
kind
of
a
standard
way
to
package
it
and
send
it
away
now,
wasm
itself,
it's
not
exactly
beneficial
to
oci
per
se,
but
rather,
when
you
use
wasm
in
the
context
of
cloud
application,
you
have
very
similar
problems
of
distribution
that
you
had
the
docker
sold
right
and
we
can
use
the
docker
solution,
oci
images
to
solve
the
same
problem
right.
So
if
we
have,
you
know
a
thousand
envoys
running
in
our
cluster
and
they
all
need
to
get
this
updated
copy
of
the
watson
filter.
E
E
C
G
G
D
G
B
I
think
that's
that's
good,
a
good
place
to
pause.
I
I'm
not
sure,
what's
gonna
happen
live
stream
once
we
go
to
the
breakout
room,
we'll
we'll
figure
it
out
all
together,
but
in
the
meantime,
if
you're
watching
a
live
stream,
there's
probably
a
little
bit
of
a
pause
before
we
get
to
the
next
speaker
and
yeah
for
everyone.
Who's
in
the
zoom
betty
has
helped
set
up
a
bunch
of
breakout
rooms.
You
want
to
explain
how
it
works.
C
C
B
H
B
Sounds
good
well.
Well,
I
think
we're
ready
for
our
next
talk
from
the
folks
at
rive.
I'm
not
going
to
spend
too
much
time
describing
it,
but
I've
been
following
their
progress
for
a
while
and
and
keep
on
seeing
webassembly
updates.
So
I'm
super
excited
to
hear
how
they
use
it.
I
think
you'll
enjoy
it.
So
with
that
I'll
just
I'll
just
hand
over
luigi,
are
you
gonna
kick
things
off
or
is
someone
else
in
your
team
gonna?
I.
I
I
I
A
I
I
As
you
can
see
here,
here's
the
animation,
it's
one
animation
state
called
idle
and
it's
running
and
we
can
introduce
other
animation
states
by
switching
on
the
wipers.
You
can
see
here
it's
a
subtle
effect,
but
these
are
two
entirely
different
animation
states
and
playing
and
being
mixed
together
and
it's
pretty
cool,
because
I
can
go
into
the
code
here
and
I
can
see
that
I
can
flick
through
and
I
have
my
idle
animation
state
and
I
have
windshields.
I
I
have
this.
One
called
windshield
wipers
and
I
can
go
in
and
I
can
update
this
to
another
one
which
I
know
is
in
here
called
bouncing,
and
then
I
will
let
this
update
and
then,
when
I
switch
it
on,
we
should
get
a
much
more
dramatic
effect
or
we
can
actually
see
these
two
things
mixing
much
more
nicely.
So
that's
what
bribe
is
about
is
being
able
to
create
animations
like
this,
which
are
interactive.
They
can
be
mixed
and
importantly,
can
run
across
a
wide
variety
of
platforms.
I
I
But
what
we
wanted
to
do
was
build
small,
tight
performance
runtimes
across
multiple
different
platforms,
and
at
the
moment
we
have
android.
We
have
ios,
we
have
flutter,
we
have
the
web
and
we
have
c
plus
plus
and
one
of
the
big
problems.
One
of
the
big
challenges
we
had
was:
how
do
you
take
four
engineers
and
build
all
these
things
and
manage
to
actually
get
anything
out
the
door,
and
so
what
we
came
to
was.
I
With
you
probably
all
know
more
about
wasm
than
we
do,
we've
taken
a
pragmatic
approach
to
build
it
to
get
it
running
and
we
chose
it
primarily
a
because
we
knew
we
could
compile
c
plus
plus
or
we
could
use
see
if
this
plus
is
the
core.
But
we
also
had
done
some
research
and
we
needed
that,
like
small
size
performance
and
we
wanted
web
compliance
and
wasm
seemed
to
give
us
all
this.
I
So
that's
why,
over
the
last
two
months,
we
took
this
approach
to
where
we
actually
have
our
web
runtime
running
today.
To
give
you
a
very
brief
idea
of,
we
can
actually
jump
into
code
and
luigi
will
take
you
through
how
we've
create
how
we've
locked
all
this
together.
But
our
overall
strategy
was
relatively
straightforward.
I
I
I
And
we
have
our
js
renderer
and
the
c-plus
engine
is
pumping.
Those
frames
of
animation
up
to
our
rendering
layer,
at
whatever
frame
rate
is
needed
and
javascript
in
return
is
communicating
back
down
to
the
c
plus
engine.
By
saying
there
has
been
this
interaction:
do
this
or
mix
these
two
different
frames
of
animations
at
these
different
time
points
together
and
in
fact,
the
js
rendering
loop
controls
the
frame
rate
of
which
it's
rendering
as
well.
I
So
it's
telling
the
c
plus
engine
the
time
points
at
which
you
should
be
building
the
next
frame.
So
we
have
this
dual
interplay,
or
this
like
loop,
where
c
plus
is
passing
data
to
the
javascript
renderer
and
the
javascript
render
is
passing
down
data
to
tell
the
c
plus
this
engine
wants
to
generate
next.
I
There
are
two
or
three
concepts
here
which
I'm
not
going
to
go
into
in
detail.
But
when
you
look
at
code,
it's
interesting
to
see
you're
going
to
see
how
we
built
our
render
in
javascript
and
you're,
going
to
see
a
couple
of
classes
called
render
path
and
render
paint-
and
these
are
sort
of
some
of
the
the
the
boundary
glue
that
we
use
to
handle
communication
back
and
forth
between
these
two
between
these
two
layers.
I
I
We,
it
was
a
quicker
route.
We
could
learn
more
quickly
about
how
we
could
create
these
bindings,
so
we
start
with
them
bind
and
that's
what
you
saw
running
in
the
browser
there.
It's
an
npm
module
that
we
serve
up
and
that
is
built
using
inscriptions
in
bind.
But
then
we
experimented
with
web
idl
and
we
did
a
quick
comparison
of
the
two
and
we're
still
doing
work
at
this,
and
we
haven't
quite
decided
exactly
which
we're
going
we're
going
to
go.
I
But
we
have
both
working
and
we're
going
to
talk
briefly
about
the
pros
and
the
cons
that
we
have
found
over
two
months
of
work,
and
this
should
be
interesting
not
only
from
perspective
how
we
put
it
together.
But
what
you're
going
to
see
here
is
folk
who
are
coming
to
things
like
webassembly
at
this
point
in
time
and
what
their
journey
is
like
to
actually
starting
to
build
with
these
things.
I
Now
kind
of
would
have
been
nice
to
be
able
to
play
with
rust,
because
having
looked
at
just
rust's
ecosystem
and
the
the
amount
of
information
out
there
about
creating
wasn't
from
rust.
But
rust
is
great.
But
we
have
these
natural
bindings
to
android
and
ios,
and
so
we
stuck
with
c
plus
plus
as
something
that
would
hold
us
in
good
stead
across
all
of
these
platforms,
including
things
like
unity
and
unreal
when
we
get
to
those
because
there's
good
application
for
for
animation
system
there
as
well.
I
So,
let's
jump
into
the
code
side
and
at
this
point
I
will
hand
you
over
to
luigi,
who
will
probably
fire
up
his
vs
code
and
we'll
start
to
walk
you
through
some
of
the
some
of
the
the
ways
that
we
have
built
the
bindings,
how
our
compile
chain
looks
like
and
how
we've
tied
it
into
our
front.
End
renderer.
A
A
I
I
So,
while
luigi
restarts
one
of
the
things
that
we
did
was-
and
all
of
this
is
open
source,
we'll
have
links
to
our
repos
at
the
end
and
you'll
see
that
we
have
arrived
close
plus
repo,
we
have
a
wide
ransom,
wasm
repo,
and
we
also
have
ios
and
drive
android
and
it's
interesting
to
see
how
we've
taken
this
single
c-plus
plus
core
and
how
we've
got
it
to
build
across
all
the
I
see
a
dinosaur.
Now,
that's
promising.
A
So
so
what
I
wanted
to
show
real
quick
was
just
from
all
those
concepts.
I
think
I'm.
I
want
to
show
you
the
code
that
matt's
talking
about,
but
I
also
wanted
to
show
you
just
really
quick,
just
a
couple
of
brief
concepts,
so
that
code
makes
a
little
more
sense.
What
these
abstract
things
are.
One
thing
is,
I
guess.
The
very
first
thing
is
what
a
file
is.
A
A
Actually,
this
one
only
has
one
animation,
but
the
other
one
is
like
the
soldier
and
you'll
see
that
this
has
a
few
different.
It
has
two
animations
on
it
and
anyway,
each
file
can
have
multiple
artboards.
Each
artboard
can
have
multiple
animations.
The
code
that
we
expose
to
wasm
gives
you
the
ability
to
kind
of
load
the
file
see
the
list
of
animations.
It
also
lets
you
query
for
things
that
are
in
here,
so
I
can
go
grab
things
like
this.
Is
I
glow
left
and
I
can
manipulate
it
at
runtime.
A
The
objects
that
are
in
those
artboards
and
then
the
various
animations
apply
them
and
render
them.
So
so,
just
an
example
this
this
soldier
that
you
see
here
in
the
editor,
if
I
go
over
to
our
beta
site,
this
is
what's
running.
That's
kind
of
our
our
hero
here
and
you
can
see
the
fidelity
is,
is
really
high.
It's
identical
to
that
animation.
A
You
just
saw
in
the
editor
itself,
but
this
one's
running
all
in
webassembly
and
it's
mixed
in
with
a
bunch
of
other
html5
layout
and
design
and
stuff,
and-
and
here
we
do
some
other
stuff
like
we
manipulate
things.
So
this
lets
it
follow
my
cursor,
you
can
detect
when
you
hover
and
trigger
different
animations.
A
A
So
I
guess,
if
we
start
looking
at
what
the
code
actually
looks
like,
I
think,
first
and
foremost
what
a
file
looks
like
from
the
sequels
plus
side,
the
very
basic
thing
that
the
first
thing
that
that's
bound
in
to
webassembly
is
the
ability
to
kind
of
interpret
those
bytes.
So
that's
our
load
operation,
which
is
here
we
do
read.
We
have
an
abstraction
for
a
binary
reader,
but
basically
the
way
we
glue
this.
If
we
look
at
bindings
is
we
have
a
simple
abstraction
to
load
the
file?
A
We
have
a
a
a
a
function
that
we
expose
and
then
we
just
get.
The
byte
array
took
us
a
while
to
figure
out
how
to
pass
kind
of,
from
the
last
talk
to
copying
memory
back
and
forth
from
we.
It
took
us
a
bit
to
figure
out
how
to
do
this
and
took
us.
It
was
even
harder,
I
think,
from
the
web
idl
perspective
just
because
it
wasn't
as
documented,
but
but
we
did
figure
it
out.
A
Basically
just
map
a
memory
view
we
instance
a
binary
reader
against
it,
get
the
file,
and
then
we
actually
return
the
raw
pointer
back
to
to
to
wasm,
and
the
nice
thing
that
we
found
that
combined
does
really
well
for
us
was
basically
do
all
the
boxing
and
the
unboxing
of
these
raw
pointers.
There's
nowhere
in
our
js
code
that
we
have
to
deal
with
pointers
we're
all
always
dealing
with
js
objects,
so
so
yeah.
A
Looking
back
at
the
the
notes
that
matt
had
up
there,
the
those
those
classes
that
we
really
care
about
is
once
we've
got
a
file.
We
have
to
have
the
ability
to
iterate
the
basically
the
artboards
in
that
file.
So
first
thing
we
expose
is
a
load
method
and
then,
when
we
get
the
actual
file
itself,
we
have
the
ability
to
get
the
let's
see
if
I
can
find
it
the
artboards
out
of
it.
A
Advanced
basically
says
this
amount
of
time
has
passed,
update
your
internal
state
to
match
to
match
that
and
reflect
that,
so
that
everything's
ready
to
draw,
and
then
you
call
draw-
and
this
is
where
things
get
interesting-
you
call
draw
from
the
js
side
on
this
artboard
object.
That's
exposed
passing
in
a
concrete
implementation
of
an
abstract,
c
plus
class
implemented
in
js,
and
this
is
where
we
think
the
stuff
that
the
scripting
crew
has
built
is
is
really
phenomenal.
A
The
ability
to
define
an
abstract
class
in
c
plus
plus
implemented
in
js
and
have
that
interop
work
seamlessly,
is
really
really
nice,
so
basically
our
abstraction
for
the
renderer
that
you
pass
into
this
draw
call
from
a
c
plus
plus
perspective.
It's
it's
pretty
similar.
It's
pretty
simple.
All
it
has
is
a
few
different
methods
exposed.
A
But
again
you
get
a
pointer
back
from
js
of
the
instance
object,
and
you
can
use
that
with
the
right
interface
in
cpus
plus
land
and
then,
when
you
pass
that
back
to
a
method,
that's
concretely
implemented
in
js
and
bind
automatically
gives
you
the
the
js
reference
to
it.
So
that
was
really
nice.
It
was
also
it
felt
a
little
bit
like
cheating,
because
we
didn't
really
understand
what
how
that
all
really
happened.
Web
idl
was
a
different
story.
We
had
to.
A
We
got
a
little
more
nitty
gritty
and
we
kind
of
got
to
see
how
a
lot
of
this
stuff
really
works
under
the
hood.
What
we
realized
there
is
that
so
so,
for
example,
if
I,
if
I
jump
over
to
the
bindings
for
for
the
idl,
if,
if
you're
not
familiar
with
this,
basically
it's
sort
of
really
similar
to
what
we
did
in
in
bindings
for
and
bind,
but
it's
just
a
kind
of
a
pseudo
cody
way
to
mark
up
the
code.
A
That's
going
to
be
exposed,
so
we
have
a
bunch
of
enums
that
we
expose,
and
then
we
have
a
bunch
of
interfaces
that
need
to
be
concretely
implemented
and
basically
we
generate.
We
run
some.
It's
a
python
script
that
basically
generates
this
glue
code
for
us,
and
then
we
do
kind
of
a
master
glue
file
that
includes
the
generated
one
and
kind
of
hooks.
A
And
similarly,
when
we
call
in
from
one
of
our
abstractions
like,
let's
see
something
where
we
call
like,
let's
see
draw
from
when
we
call
transform,
for
example,
with
a
matrix,
matrices
are
they're,
basically
all
on
the
stack,
and
we
have
to
sort
of
figure
out
how
to
get
the
pointer
from
it
and
cast
that
to
a
object
that
will
exist
in
js
land,
and
so
so.
What
you
get
here
is
actually
this.
A
This
value
that
gets
piped
through
is
actually
a
pointer
and
we
kind
of
emulated
some
of
the
get
cache
methodology
that
and
script
and
exposes
internally
to
cast
those
back
to
pointers.
So
you'll
see
in
like
our
our
implementation.
For
this,
which
this
is.
This
is
very
much
the
web
ideal
stuff
is
still
really
really
early.
So
we,
we
haven't
really
quite
polished,
this
stuff
for
publish
but
you'll,
see
that
there's
a
lot
of
funkiness
like
we
actually
have
to
look
up
the
pointers
for
a
lot
of
this
stuff.
A
So
when
we
get
transform,
we
get
a
pointer
object
and
then
we
have
to
box
that
and
find
the
actual
js
object
call
into
wasm
to
get
with
our
reference
with
the
with
the
js
object
such
that,
then
we
can
get
back
the
real
values
that
are
bound
in
from
our
from
our
glue
code.
So
it's
a
little
funky
it's
definitely.
The
nice
thing
about
inbind
for
us
is
that
it
really
does
abstract
all
this
away
and-
and
hopefully
one
of
you
know
how
to
make
this
cleaner
with
web
idl.
A
A
But
but
the
fundamental
thing
here
that
that
this
solves
for
us
what
wasm
does
really
nicely
on
the
bindings
that
we
get
with
both
with
web
idl
and
within
bind
really
work.
Well,
is
this
fact
of
being
able
to
have
our
c
plus
plus
code
be
handed
a
binary
blob
interpret
that
as
something
generate
a
whole
bunch
of
stuff?
A
And
I
there's
a
lot
of
things
that
we
ran
into
with
es6
classes.
We
found
a
really
nice
way
to
make
them
work
with
web
idl.
We
didn't
find
as
nice
away
with
them
bind,
but
there's
there's
definitely
so
much
potential
for
for
both
of
these
systems
and-
and
we
really
like
how
clean
the
final
implementation
ends
up
being
and
that
the
abstraction
layer
between
the
two
is
very
it's
very
well
defined
and
so
far
has
been
really
portable.
A
A
So
small
and
part
of
the
reason
why
we're
able
to
do
that
is
that
we
kind
of
have
a
preprocessor
that
generates
a
lot
of
our
class
information
for
us
for
a
lot
of
the
serialization
and
deserialization,
and
we
can
use
a
lot
of
the
data
that
we
inherently
have
from
that
to
do
kind
of
our
our
our
custom
rtti.
If
you
will,
and
that
ends
up
taking
way
way
less
space
in
the
in
the
final.
In
the
final
binary.
I
There
we
go
and
so
yeah
we
hit
a
bit
of
a
crossroads
and
we're
still
at
it.
We
we
find
both.
We've
got
both
unbind
and
web
idl
working
nicely
for
us,
the
unbind
code
is
smaller
and
the
combined
code
is
is
frankly,
at
the
moment,
more
legible
and
easier
to
maintain,
but
it
generates
currently
110
kilobytes
and,
as
we
expose
even
just
exposing
another
meth,
our
function,
call
from
our
c
plus
plus
to
javascript
makes
that
go
up
by
by
by
a
large
number
of
bytes.
I
So
we're
curious
to
see,
as
we
start
to
grow
the
surface
of
the
api,
how
that
makes
our
wasm
size
explode
on
the
web
idl
side.
As
we
said,
there's
sparser
docks,
the
abstractions
are
less
clear,
or
at
least
we're
not
grocking
them
quite
as
much
yet,
but
there's
a
20
size
difference.
So
it's
which
way
we
go.
We
we
we
still
kind
of
have
to
to
work
out,
but
the
the
nice
thing
is
is
that
our
c
plus
plus
core
without
modification,
is
compiling
down
to
wasm
by
either
of
these
roots.
A
A
I
I
I
There
is
also
a
blog
post
if
you're
interested
on
the
sort
of
pragmatic
or
not
pragmatic,
the
the
getting
right
to
run
inside
your
web
browser,
it's
less
about
how
it
uses
the
runtime
or
more
about
how
you
use
the
runtime
to
be
able
to
do
the
what
you
want
to
do
and
we're
more
than
happy
to
make
these
slides
available
publicly.
If,
if
people
want
to
grab
those
links
and
check
things
out
and
with
that,
we
just
want
to
say
thank
you
for
your
time.
I
We
are
still
fairly
fledgling
in
our
exploration
of
wasm.
We're
super
happy
with
what
we
have
so
far,
but
we
know
that
there
are
still
a
lot.
We
need
to
learn,
there's
a
lot
that
we
can
get
from
the
community
and
so
we're
always
happy
to
get
feedback
on
what
we're
up
to
for
those
of
you
who
are
interested
in
digging
in
to
see
how
we're
using
it
to
build
an
animation
on
time.
So.
A
A
A
Number
one
feature
request
from
scriptin:
I
think
right
now
more
documentation
around
the
web
idl
stuff.
I
think
it's
it's.
Maybe
it's
just
that
it
is
what
it
is
and
there
isn't
enough.
I
think
we
had
to
grock
a
lot
of
it
from
looking
at
examples
and
figuring
out,
like
one
of
the
things
that
we
ran
into,
for
example,
was
that
we
couldn't
at
first
it
didn't
seem
like
we
could
extend
the
the
classes
that
we
were
binding
out.
A
We
couldn't
inherit
from
those
in
with
an
es6
class
and
part
of
the
reason,
for
that
was
that
some
of
the
generated
code
was
doing
things
like
checking
if
the
methods
were
defined
directly
on
the
object
we
kind
of
just
stabbed
and
hacked
at
the
python
generator
and
removed
that
restriction
and
then
basically
just
defined
them
on
the
prototype,
and
that
made
it
all
of
a
sudden
work
with
the
s6
classes,
which
was
really
nice,
and
we
feel
like
we're
a
bit
stabbing
in
the
dark.
With
that.
A
A
And
we'd
love
to
figure
out
a
way
to
build
a
scripting
engine
into
the
editor
itself,
such
that
people
can
write
the
code
and
and
edit
with
it
and
and
visualize
in
the
editor.
What
will
happen
at
runtime
right
now?
It
depends
on
which
platform
you're
hosting
the
code,
so
basically
our
runtimes
are
effectively
driven
entirely
from
the
code
base,
that's
hosting
them.
So
in
this
case
on
the
web,
it'll
be
js
or
whatever
you
have
available
on
the
web,
that
you
can
transpile
down
to.
A
A
Although
assembly
script
looks
really
cool
and
if
we
could
figure
out
how
to
get
something
like
a
wasmer
layer
running
on
all
those
different
platforms
we
talked
about,
we
could
enable
a
solution
like
that:
a
plug-in
architecture,
an
expression
system
whatever,
but
yeah
right
now
on
ios,
it's
swift
and
and
on
android.
I
think
I
know
we
have
kotlin,
I'm
I'm
assuming
it'll
be
fine.
A
You've
worked
it
with
java
too,
but
I
know
our
examples
in
kotlin,
so
the
bindings
that
are
exposed
from
from
our
code
base
that
I
showed
you
like
the
ability
to
get
the
different
artboards
get
an
object
and
move
it
around
that's
available
on
all
those
different
platforms
and
in
js
it
looks
I
could.
I
could
show
some
code
if
you're
interested,
but
but
either
way
it's
basically
you.
B
A
Yeah,
so
so
right
now
we're
just
calling
directly
into
context2d,
so
we
chose
the
abstraction
such
that
it
would
work
fairly
well
across
the
platforms
that
we
know
have
kind
of.
We
took
a
look
at
what
the
renderers
were,
that
we
wanted
to
work
with,
and
we
kind
of
chose
our
common
denominator,
something
that
kind
of
would
work
across
all
of
them.
So
right
now
that
that's
binding
to
context
2d,
but
you
could
totally
do
that
with
webgl.
A
That
can
also
be
that
can
also
be
threaded,
potentially
driving
a
lot
of
that
from
the
c
plus
plus
side
and
kind
of
passing
off
some
the
lower
level
instructions
over
directly
to
webgl
the
big
thing
that,
because
so
much
of
this
could
be
done
on
the
gpu
we'd
really
like
to
kind
of
maybe
consider
just
going
for
web
gpu
directly.
But
I
think
it's
it's
still
something.
A
That's
it's
really
experimental
on
our
end
and
it's
something
that
we
really
want
to
do
because
it'll
enable
some
of
the
higher
performance
scenarios
that
we
want
for
things
like
game
engines
and
the
like.
But
it's
still
it's
something
we
haven't
quite
tackled.
Yet
it's
it's
really
on
the
forefront
of
our
minds,
though,
and
we
can't
wait
to
be
able
to
get
to
it.
It's
we're
really
passionate
about.
A
We
did
and
the
reason
it's
disabled
up
in
the
example
that
I
had
there
was
because
of
some
of
those
es6
things.
We've
got
some
code
like
some
destructuring
and
some
const
and
some
yes,
six
classes,
and
we
found
that
there
were
there.
There
was
there
were
a
few
issues
that
we
were
having
with
running
it
through
closure
and
the
built-in
minifier
that
inscription
had.
So
we
kind
of
did
this
really
hacky
thing
which
I'd
love
to
share
my
screen
and
show
you
just
how
hacky
it
is.
A
A
Then
we
arc
out
and
we
run
tercer
against
it,
and
that
was
purely
just
to
get
our
sort
of
the
minifying
working
with
with
with
es6
and
some
of
the
more
modern
javascript
features,
and
maybe
we're
missing
something
with
why
it
wasn't
working
with
closure.
But
I
think
it
was
when
we
had
it
without
the
s6
stuff.
A
It
was
definitely
smaller
with
closure,
but
it
wasn't
far
off
using
terser,
and
I
think
that
the
other
thing
that
we
realized
is
also
the
js
part
of
it
compiles
to
almost
nothing
when
we
g-zip
it.
So
it
didn't
seem
like
it
was
worth
spending
more
time
there.
It
seemed
where,
where
we
were
seeing
a
lot
of
the
bloat
go
in
was
when
we
exposed
more
functionality.
A
B
A
We
loved
it,
we
we,
you
know
we
came
to
flutter
totally
by
kind
of
accident
we'd
we
used
to
work
with
someone
who's
who's,
a
big
part
of
the
of
the
flutter
team,
and
we
reached
out
to
them
a
few
years
ago,
and
they
said
they
were
working
on
this
flutter
thing
and
we
kind
of
took
a
peek
at
it
and
we
we
really
liked
what
we
saw
and
as
an
application
building
framework.
It's
it's
phenomenal,
the
tooling
that
comes
with
it.
A
A
The
other
thing
that
it
has
that
we
really
like
is
kind
of
a
the
performance,
tooling,
the
the
language
itself.
We
really
like
dart.
We
love
that
it's
strongly
typed.
We
love
that.
There's
really
good
implementations
for
the
static
analysis
and
simple
in
in
vs
code.
It's
just
it's
just
all,
really
a
really
nice
ecosystem
to
work
in.
I
think
that
time
will
tell
what
the
future
for
our
editor
will
be.
If
you
know
our
bet
on
flutter
is
is
gonna.
A
You
know
last
forever
how
long,
but
we
you
know,
we've
obviously
looked
at
a
lot
of
different
options.
The
first
iteration
of
arrive
was
built
in
in
in
javascript.
It
was
es6
just
babel,
transpiling
modern
features,
modern
js
and
some
some
web
assembly,
but
mostly
we're
using
a
renderer
in
webassembly,
but
but
the
rest
of
it
was
all
all
js
code,
but
but
yeah
we,
we
really
are
huge
fans
of
flutter.
B
A
Not
yet,
and
the
reason
why
is
because
we
chose
renderers
that
were
kind
of
available
to
us
on
those
different
platforms,
kind
of
natively.
If
we
want
to
do
drop,
shadows
and
glows,
we
really
do
need
to
get
to
something
that
gives
us
a
lot
more
access
to
the
low-level
gpu
doing
that
in
something
like
context,
cd
would
be.
I
mean
there
are
ways
to
do
it.
It
wouldn't
be
really
performant.
A
There's
just
there's
so
much
more
that
we
can
do
if
we
have
access
to
a
low-level
system
to
do
that,
all
those
effects
performantly
and
we
have
ideas
for
how
to
do
that,
and
but
again
that
goes
kind
of
back
to
the
having
a
native
or
kind
of
our
own
renderer,
a
custom
renderer
for
this,
which
is
something
that
we
we
definitely
want
to
get
to.
But
we
also
want
to
make
sure
that
there
will
always
be
a
nice
really
super
thin
small
plugin
that
you
can
drop
in
to
any.
A
A
So
we're
we're
figuring
out
what
that's
going
to
mean,
whether
in
the
future
it'll
be
a
light
version
and
kind
of
a
more
heavy
full
feature,
full
version,
or
maybe
even
kind
of
deliver-
that
on
demand,
depending
on
the
contents
of
the
file,
we're
thinking
about
all
those
things,
and
we
definitely
want
those
features
in
rhyme.
One
has
a
lot
of
those
features
we
have
masking.
We
have
drop
shadows,
we
have
inner
glows
outer
glows
and
all
those
things
and
we
got.
A
We
were
able
to
do
that
because
we
had
a
custom
renderer,
but
we
didn't
have
the
ability
to
kind
of
provide
a
really
streamlined
super
lean
experience.
You
had
to
bring
in
a
four
megabyte
dependency
anytime.
You
wanted
to
host
a
10
kilobyte
file
and
that
made
no
sense.
I
mean
there
are
places
for
it
and
it
works
really
well
where
it
does
and
I'm
going
to
save
all
the
work
we
did
before
it
made
no
sense,
but
it
is
it
definitely.
A
It
definitely
was
a
weakness
and
we
think
that
being
able
to
answer
the
kind
of
lean
mean
story
first
and
then
kind
of
let
people
who
really
want
all
the
features
to
buy
into
the
the
bigger
run
times
and
adopt
more
even
more
of
our
code
base.
That's
great,
but
we
want
to
make
sure
we
have
an
answer
for
everyone
else.
First,.
B
All
right,
I
think
that
is
going
to
be
the
last
question
and
well.
Thank
you.
Matt
and
luigi
awesome
talk
and
yeah
we'll
we
would
love
to
get
my
link
to
put
in
the
description
for
youtube
later
and
I'll
get
that
from
you
after,
but
we
thought
we'd
use
the
rest
of
the
time
to
continue
networking
if
people
are
still
interested
in
hanging
around
we'll,
probably
end
the
live
stream,
because
it's
not
going
to
be
interesting
for
everyone
else,
but
yeah
betty,
we're
gonna,
take
us
away.