►
Description
Raph Levien shows off his latest Rust UI technology prototype. A refinement of the Xilem medium-grained reactive architecture has implementations of two different View traits for the same view tree, one that creates SVG DOM nodes for rendering in WASM in the browser, another for high performance native GPU rendering with the Vello rendering engine. The talk will touch on using advanced features of the Rust type system to make declarative vector graphics ergonomic. The Xilem family of projects welcomes open source collaboration on this work in progress.
Thanks to JFrog for hosting this edition of our meetup!
A
Foreign
well,
thank
you
so
much
jfrog
for
hosting
this
beat
up
I'm
very
happy
to
see
everybody
in
the
community
here
today,
and
so
what
I'm
going
to
be
talking
about
is
xylem,
vector,
graphics,
and
this
is
very
much
what
you're
seeing
is
very
much
unfinished
work
in
progress,
you're,
not
seeing
a
final
project,
a
final
product
but
I
think
it's
I,
think
it's
interesting
and
so
I
want
to
kind
of
take
you
along
for
the
ride.
So
so
here's
what
I'm
going
to
be
talking
about.
A
You
know
in
the
talk
that
I'm
going
to
start
by
really
talking
about
the
goals
and
scope,
because
that's
not
obvious
this
question
of
you
know:
if
you're,
if
you're
trying
to
build
a
UI,
do
you
use
Dom?
Do
you
build
it
on
Dom
technology?
Or
do
you
not
put
it
on
Dawn?
What
are
the
trade-offs
there
and
then
kind
of
a
picture
of
layered
UI
like
how
do
you
factor
a
UI
into
layers?
A
So
this
is
It's
a
science
project
and
there
are
hypotheses
that
I
want
to
test
and
then
I'll
I'll
close
up
with
next
steps
and
kind
of
a
call
to
action.
You
know
a
really
fellow
scientists,
you
know
come
along
so
so
this
is
an
exploration.
This
is
basically,
you
know
very
speculative
work.
I
am
not
sure
it's
been
a
result
in
a
usable
product
at
the
end,
but
I
want
to
learn.
I
want
to
find
out
what
the
parameters
are.
Is
this
going
to
work?
A
If
it's
not
going
to
work,
why
not
so
the
so?
The
goals
of
this
is
I
want
to
be
able
to
write
an
app
in
a
very
nice
clean,
declarative,
syntax
I'll,
be
showing
you
some
examples
of
the
actual
code,
I'm
running
and
then
the
other
thing.
That's
a
little
bit
new
to
the
work
that
I've
been
doing.
Is
that
I've
really
been
wrestling
with
this
question
of?
A
How
do
you
deploy
an
app
both
to
a
native
executable
and
in
wazam
to
run
in
the
browser
without
compromising
like
it's
very
easy
to
just
run
a
demo
of
something?
But
you
know
like
how
do
you
do
a
good
UI
to
both
of
those
platforms
and
in
particular,
how
do
you
preserve
the
performance
and
performance?
There's
a
lot
of
factors
to
Performance
and
in
order
to
make
this
science
experiment,
tractable
I
am
specifically
narrowing
the
scope
that
tonight
I
am
only
going
to
be
talking
about
vector,
graphics.
A
It's
a
much
reduced
surface
area
of
the
kind
of
problems
that
you
have
to
solve
and
the
hope
is
if
it
works
well
for
vector
graphics.
How
do
you
generalize
it,
but
I'm
not
going
to
be
going
too
deep
into
that
tonight?
We'll
be
talking
about
vector,
graphics,
so
this
constraint
of
trying
to
do
something
that
works
both
on
web
and
on
web
really
create
some
difficult
technology
choices,
some
difficult
trade-offs.
A
And
so,
if
you
choose
the
not
Dom
approach-
and
you
want
to
deploy
those
applications
on
the
web,
then
you
get
a
lot
of
problems.
So
one
of
the
problems
is
that
you
have
a
much
larger
lesson:
bundle
size,
because
if
you're
not
using
the
Dom,
then
all
of
the
things
that
the
Dom
does
all
of
the
drawing
and
text
rendering
which
itself
is
a
very
large,
complicated
problem.
A
Those
need
to
be
in
the
oasm
bundle
and
then
you'll
be
drawing
to
some
kind
of
canvas
or
some
kind
of
GPU
surface.
Depending
on
exactly
what
your
you
know.
What
your
app
is
trying
to
do
so,
even
with
the
west
and
bundle
size
like
doing
text
rendering
getting
the
text
to
look
right
is
hard,
especially
if
you're
drawing
to
like
a
GPU
surface,
if
you're
using
the
HTML5
canvas.
Well,
your
texture,
rendering
works,
but
now
how
do
you
interrupt
that
with
the
rest
of
the
app?
A
A
The
scrolling
is
all
always
a
little
bit
wrong.
There
are
there's
thinking,
there's
proposals
about
like.
Could
we
maybe
fix
the
web
platform
so
that
you
would
get
more
direct
lower
at
lower
level
access
and
be
able
to
solve
these
problems?
So
there's
a
proposal
really
interesting
thing
here
by
Ian
Hixson,
but
it's
not
the
reality
today.
A
Now
the
flip
side
is,
if
you
want
to
do
a
native
application,
then
one
of
your
choices
is
that
you
ship
a
fragment
of
a
bro.
You
either
ship
a
whole
web
browser
or
you
ship,
some
fragment
of
a
web
browser
and
that
solves
the
problems
on
the
web.
But
if
you're
trying
to
ship
something
native,
then
you
now
have
a
whole
other
set
of
problems.
So
one
of
them
is
that
the
web
Dom
API
is
slow
and
I
mean
that's
slow.
A
If
you're
doing
single
threaded,
you
know
it
may
be
that
there
are
things
that
their
configurations
in
which
the
the
Dom
is
not
slow,
but
basically
on
the
web.
Today
it
is
slow
and
all
of
the
other
stuff.
That's
Downstream
of
the
Dom
is
also
slow.
Css
resolution,
it's
very
expensive,
very
heavy
weight
layout
is
very
expensive,
very
heavy
weight,
and
so
you
just
don't
get
good
performance.
A
You
know
compared
with
what's
possible
on
Native
and
there's
another
problem
here,
which
is
that
the
web
Dom
API
itself
essentially
forces
single
threading.
It
was
really
built
in
a
single
threaded
World.
It
wasn't
designed
for
multi-threading
and,
like
one
specific
consequence
of
that
in
Rust.
Is
that
there's
this
type
for
the
Callback
which
you
use
to
wire
up
your
interactivity
and
that
type
is,
is
not
send.
So
if
you
put
it
in
an
arc,
you'll
get
a
compile
time
error
or
not.
A
You
can
put
it
in
an
arc,
but
if
you
try
and
actually
you
know,
move
it
across
a
channel
to
a
different
thread,
then
you'll
get
a
compile
time
error.
It
just
won't
work.
So
then
you
know,
then
you
have
this
problem
of
like
well.
What
browser
do
you
ship?
Do
you
bundle
CEF,
which
is
you
know,
the
that's
chromium
embedding
framework?
A
Also
electron
and
CEF
are
kind
of
two
two
aspects
of
the
same
thing:
large
bundle
size,
it's
popular,
a
lot
of
people,
do
it,
it
works,
it
solves
a
lot
of
problems
and
so
there's
other
possibilities
like
there's
tari,
which
is
more
popular
in
the
rust
world,
and
that
uses
the
platform
web
view.
But
then
there's
other
challenges
like
you,
don't
know
exactly
what
webview
you're
gonna
get
it
might.
It
belongs
to
the
operating
system.
It
might
not
be
up
to
date.
A
A
There
are
other
choices
that
are
out
there
like
there's
a
really
interesting
thing
in
the
C
plus
plus
world
called
Cider,
which
is
really
a
sort
of
a
mini
implementation
of
a
fragment
of
a
browser,
and
it
is
popular
in
some
domains,
but
it
is
missing
some
functionality
and
it's
not
plug
compatible.
You
don't
get
exactly
the
same
experience
with
cider
as
on
a
real
web
browser
and
then
in
the
rust
world,
there's
two
projects
that
are
worth
looking
at
I.
Think
when
serbo
was
happening.
A
You
know
in
the
early
days
of
rust,
a
lot
of
people
were
excited
about,
like
oh
there's,
all
this
UI
technology
and
it'll
do
all
of
the
fonts
and
text
layout
and
you
know,
draw
GPU,
drawing
GPU
accelerated,
drawing
and
stuff
like
that.
Let's,
let's
make
that
happen,
and
then
let's
bundle
that
or
have
that
as
a
layer
that
underlies
our
applications
and
the
progress
on
Servo
has
been
slow.
It's
it's
rebooting.
It
might.
A
Into
something
that
we
can
use
and
there's
a
new
thing
called
Blitz
and
I'm
going
to
be
talking
about
that,
and
that
is
an
interesting
possibility,
but
it
is
fundamentally
in
the
same
category
rate
of
implementing
a
fragment
of
a
browser,
so
the
API
is
Dom
HTML
nodes,
CSS
Etc,
so
I
want
to
give
you
this
kind
of
picture
of
layered
UI,
and
this
is
not
the
only
way
to
build
UI.
In
particular,
this
picture
is
not
accurate
to
immediate
mode.
Immediate
mode
kind
of
is
the
opposite
of
layered.
It's
it's
fusing
all
the
different.
A
You
know
reactivity
and
drawing
and
element-
and
you
know
all
the
way
down
to
the
infrastructure.
All
the
way
down
to
the
GPU
I
mean
you're,
basically
filling
in
vertex
buffers
with
the
with
the
logic
of
your
app
but
I.
Think
increasingly,
with
the
exception
of
immediate
mode,
that
the
rust
UI
ecosystem
is
moving
towards
this.
This
layered
model
and
there's
even
some
commonality,
that's
happening.
I
have
a
slide.
C
A
Couple
slides
where
I'll
go
into
that,
so
the
the
top
layer
is
your
reactivity
or
your
declarative.
How
do
you
express
a
UI
very
concisely,
very
declaratively,
and
that's
involving
you,
know
these
fairly
higher
level
ideas.
So
that's
where
State
Management
happens.
That's
where
your
incremental
updates
happen
that
you
know.
Usually
you
don't
want
to
when
you're
writing
a
UI
and
a
declarative
style.
You
don't
want
to
be
handling
like
the
dirty
bits
of
oh,
this
particular
label
change.
A
You
just
want
to
say
this
is
what
the
label
says
and
then
it's
up
to
the
reactive
layer
to
say:
did
it
change?
If
so,
I
need
to
propagate
those?
You
know
down
into
the
lower
levels
which
are
the
element
tree
and
then
ultimately
to
infrastructure,
and
the
other
thing
that
reactivity,
you
know
that
really
belongs
at
the
reactivity.
A
layer
of
this
stack
is
components.
How
do
you
factor
your
application
into
components
that
can
you
know,
operate
more
or
less
autonomously,
but
still
interact
with
each
other
Still
Still
share
data.
A
You
know,
have
data
flows
in
the
system,
but
have
these
components
that
are
fairly
nicely
abstracted
and
ideally
like.
If
this,
if
this
really
sort
of
in
the
vision
of
the
future
you'll
have
standard
components,
you'll
say
I
want,
you
know
a
font,
picker
and
you'll
just
go
get
a
font
picker
and
you
know,
and
that'll
interact
with
the
rest
of
your
application.
A
So
so
that's
the
top
layer.
The
next
layer
is
the
elementary,
and
you
know
this
is
where
the
kind
of
guts
of
the
UI
happen.
So
that's
where
the
widgets
are
defined
and
there's
a
lot
of
operations
that
a
UI
does
like
layout
and
styling,
and
text
editing
and
handling
the
the
the
mouse
input
and
the
you
know
the
touch
input
on
a
mobile
device
and
keyboard
and
all
that
stuff.
A
Through
the
UI
and
then
there's
a
layer
below
the
elementary
actually
before
I
go
down
there
I
want
to,
though
another
very
important
part
of
this
is
that
there's
that
there's
that
label
on
that
line
called
the
Elementary
API,
because
that
API
that
interface,
that
boundary,
that
can
either
be
something
that's
custom
and
bespoke
to
a
particular
UI
toolkit
or
it
can
be
something
more
General
and
standardized.
You
might
be
able
to
do,
mixing
and
matching.
You
might
be
able
to
say.
A
Oh
I
want
this
Elementary,
but
I
want
this
reactive
layer
on
top
of
it
and
I
think
increasingly
we're
moving
toward
that
and
that's
very
exciting
it.
The
other
distinction,
the
other
sort
of
boundary
in
the
system
that
I
want
to
call
attention
to.
Is
that
there's
a
lot
of
infrastructure
and
I've
done?
You
know,
like
you
know,
if
you
looked
at
my
blog
post,
you
know
advice
to
the
next
dozen
arrest
guise.
Most
of
that
was
really
talking
about
all
the
problems
that
still
need
to
get
solved
at
the
infrastructure
layer.
A
This
is
still
not
completely
settled,
but
there
there
is
a
lot
of
progress
at
that
layer,
so
so
this
is
kind
of
a
model
like
this.
This
describes
this
General
picture
describes
a
lot
of
individual
UI
systems,
and
so,
if
you're
on
the
web
it
takes,
you
know
it
takes
a
particular
shape
that
all
of
the
stuff
below
that
element
tree
API,
is
a
browser.
So
that's
all
implemented
inside
the
browser.
So
all
of
these
functions
are
still
in
there
and
you're
defining.
A
You
know:
you're,
defining
your
Elementary
as
HTML
and,
in
this
particular
case,
I'm
more
interested
in
the
SVG
notes
than
the
HTML
nodes,
and
then
you
know
CSS
for
styling
and
there's
there's
a
lot
more,
but
you
know
I'm
giving
kind
of
the
simplified
model
and
the
interface
for
that.
You
know
the
interface
above
that.
How
do
you
access
that
Elementary?
A
Is
this
highly
standardized
extremely
well
documented
thing
called
the
webdom
API
and
there's
a
ton
of
stuff
out
there
I
mean
there's
massive
amounts
of
stuff
out
there,
that
is,
that
is
designed
to
float
on
top
of
the
web.
Dom
API
and
I
mean.
Obviously,
you
have
a
lot
of
JavaScript
choices
and
then,
increasingly,
you
have
a
lot
of
rest
choices
as
well,
all
of
which
drive
this
webdom
API
and
then
you've
got
a
browser
under
that
or
or
a
browser
or
a
fragment
of
a
browser.
A
You
know
that
you
know
the
access
is,
is
definitely
one
of
the
choices
if
you're
trying
to
drive
web
and
dioxis
is
definitely
one
of
the
choices
if
you're
trying
to
drive
a
native,
but
if
you
don't
have
a
browser
now
we
have
the
responsibility
to
to
actually
do
all
of
these
other
layers
in
the
system.
So
at
the
element
tree
there's
a
little
bit
of
standardization.
A
So
a
lot
of
the
stuff
inside
these
boxes
are
like
suggestions
of
crates
that
you
might
be
able
to
use
to
solve
these
individual
sub
problems,
these
parts
of
the
larger
UI
problem.
So
if
you
want
to
do
layout,
there's
there's
this
new
crate
called
Taffy.
It's
used
primarily
in
Devi
the
Bevy
UI,
but
there's
a
couple
of
other
experimental
things
that
are
using
it
and
we're
looking
into
it
we're
considering
using
it
for
xylem
as
well.
A
For
how
do
does
your
reactive
layer
talk
to
the
element
tree?
That's
below
it,
and
so
one
of
those
is
Masonry,
which
is
a
kind
of
a
outgrowth
or
Fork
of
Druid
and
the
other
one
that
that
I
think
is
getting
a
little
bit
of
attention.
Is
the
dioxis
virtual
Dom,
and
so
this
is.
This
is
an
interface
that
could
be
driving
a
web
Dom
or
it
could
be
driving
a
native
element
tree.
A
It's
not
it's,
not
it's
web
compatible,
but
it
doesn't
tie
you
necessarily
to
the
same
kind
of
trade-offs
that
you
have
with
with
with
a
a
purely
compatible
with
Dom
and
then
on
the
infrastructure
layer.
I
mean
all
of
these
things
at
the
lower
lower
level
are
things
that
have
made
huge
amounts
of
progress
in
the
last
you
know
years
and
so
for
platform
integration.
You
have
a
choice
between
winit
and
Glacier.
Glacier
is
the
one
that
we're
using
in
xylem.
A
Again,
you
can
go
to
the
different
blogs
to
see
the
reasoning
of.
Why
are
we
not
just
doing
win
it
for
drawing
there's
Choice
again,
there's
choices
out
there
there's
femto
VG,
which
is
you
know,
among
other
things,
being
used
by
slint
and
then
there's
Velo,
which
is
the
2D
engine
that
I've
been
working
on
for
text
that
this
used
to
be
a
huge
problem.
There
is
like
how
do
I
do
text
there's
nothing
that
I
can
do
now.
A
There's
two
good
choices:
there's
Cosmic
text
and
there's
parlay
Cosmic
text
is
used,
I
think
increasingly
by
iced
and
parlia
is
the
one
that
we're
developing
for
the
for
the
xylem
stack
and
then
other.
You
know
other
problems
like
if
you
need
GPU
access.
You
know
we
have
standardized,
we
had
our
own
custom
bespoke
stuff
and
we
said
you
know
what
we're
gonna
be
better
off
if
we
join
forces
with
wgpu
and
that's
starting
to
pay
off
because
like,
among
other
things,
we're
able
to
integrate
with
Bevy.
A
A
This
is
future
work,
but
going
forward
we're
going
to
be
like
yeah,
just
just
write
it
in
wgpu
and
then
we'll
we'll
be
able
to
composite
that
in
and
then
another
thing,
that's
huge
progress
in
the
last
year
is
access
debt
accessibility.
You
need
uis
need
to
be
accessible.
We
can't
just
leave
these
people
behind
who
need
you
know,
screen
readers,
other
assistive
technology
and
access
kit
is
a
layer
that
is
really
starting
to
be
on.
You
know
developed,
so
it
has
these
accessibility
capabilities
and
it's
being
adopted.
A
Most
of
the
I
I
would
say
all
of
the
leading
UI
tool
kits
have
either
adopted
access
kit
or
are
in
the
process
of
doing
so
so
I
want
to
talk.
You
know
with
this
layered
architecture,
with
this
sort
of
like
reactivity
or
declarative,
UI
layer,
and
then
an
elementary
I
want
to
talk
a
little
bit
about
this
distinction
between
the
view
tree
and
Elementary,
because
when,
when
I
talk
with
people,
they're
always
like,
why
do
you
need
both?
Why
do
you
need
this
distinction?
A
Why
don't
you
just
do
everything
in
one
type,
one
trait
and
that's
the
way
that
Druid
used
to
work?
We
used
to
have
a
widget
trait
that
that
had
both
of
the
functionality
of
the
kind
of
declarative,
UI
on
the
the
reactivity
and
also
driving
the
elementary
handling,
all
the
functions
like
layout
and
so
on
and
so
forth,
and
so
that's
one
of
the
things
that's
changed
from
Druid
to
xylem
that
now
we
have
two
different
things.
A
We
have
a
view
tree
and
we
have
an
element
tree
and
the
difference
between
the
two
is
that
the
view
tree
is
specifically
charged
with
the
declarative
representation
of
the
UI,
and
so
it's
designed
to
be
ergonomic.
It's
designed
to
be
easy
to
deal
with
most
of
the
views
in
xylem
are
just
plain
old,
simple
value
types.
You
don't
have
a
lot
of
complicated
like
contexts
that
you
need
to
thread
through
or
access
to,
there's
no
complicated
stuff
like
how
do
you?
A
That's
all
in
the
elementary,
so
the
elementary
like
when
I
think
about
this
stuff,
the
elementary
is
the
messy
part.
The
elementary
like
every
element
has
to
deal
with
life
cycle
like
what
you
know.
What
happens
when
you
get
instantiated
and
get
yourself
connected
to
like
layout,
and
of
course
you
have
to
do
all
these
other
things
like
drawing
and
input
from
the
mouse
and
and
that's
also
where
the
accessibility
happens.
A
So
so
these
are
two
different
types
and
you
know
usually
your
view.
Your
view
tree
is
going
to
be
a
transient
thing
that
your
app
just
says.
Here's
the
view
tree.
This
is
what
I
want
to
look
like
right
now
and
then
you
know
it
updates
the
elementary
and
then
the
view
tree
gets
gets
dropped,
but
the
elementary
has
to
be
persistent.
The
elementary
you
know
that
has
like
your
cursor
Focus.
So
you
know
that
needs
that
has
a
lot
of
State
in
it.
A
That
needs
to
stay,
even
when
your
app
is
generating
all
these
all
these
views-
and
this
is
you
know,
I'm
talking
in
in
terms
of
xylem
and
the
the
distinction
in
xylem
between
View
and
element
and
by
the
way
these
names
there's
a.
There
is
not
really
super
consistent
terminology
that
there
are
a
lot
of
different
things
called
views.
A
A
Now
it
it's
relatively
new
I
mean
in
the
old
sort
of
object-oriented
days.
You
wouldn't
have
this
distinction,
so
you
know
I
spent
a
lot
of
time,
looking
at
other
systems
that
are
out
there
and
trying
to
learn
from
them
and
there's
a
lot
there's
a
lot
in
the
JavaScript
world
and
there's
a
lot
in
the
rust
world
and
when
I
kind
of
try
to
get
my
head
around
like.
A
A
This,
doesn't
you
know
again
to
emphasize
that
this
doesn't
tell
you
everything
about
the
entire
universe,
that
immediate
mode
is
not
in
here,
because
immediate
mode
doesn't
have
that
distinction
between
between
the
the
the
kind
of
declarative
layer
and
the
element
layer.
It's
all
one
thing,
but
in
any
case,
they're
they're.
These
four
tribes,
there's
solid.js,
which
is
also
known
as
fine-grained
reactivity.
A
There's
react,
there's
Elm,
which
is
also
known
as
model
view,
update
and
there's
Swift
UI,
and
each
one
of
these
tribes
has
multiple
representations
and
then
there's
two
things
that
I
want
to.
You
know
like,
if
you're
interested
in
the
sort
of
larger
world
of
like
how
how
is
reactive,
UI
or
declarative
UI
built
both
in
Reston
and
JavaScript.
A
Well,
both
of
these
videos,
both
of
these
blogs
resources
is
a
Blog
and
a
video
really
do
focus
on
Rust,
and
so
the
first
one
is
a
survey
of
about
20
different
systems.
Blog
posts
came
out
about
a
month
ago,
really
interesting,
I
learned
from
it,
and
the
second
one
is
a
video
that
goes
really
it's
a
deep
dive
into
the
performance
of
rust
driving
wasm.
So
when
you're
driving
a
web
browser
and
that's
by
Greg
Johnson
who's,
the
creator
of
leptos.
So
again,
really
good
information
strongly
recommended.
A
A
So
we'll
start
with
solid.js,
so
solid
JS
is
again
sort
of
least
like
xylem,
in
that
it
is
not
doing
this
transient
beauty
that
it's
throwing
away
it
actually,
like
kind
of
one
of
the
things
that
people
say
is
the
vdom
is
pure
overhead
I.
Think
that's
the
the
truth
is
much
more
nuanced
and
again,
you
know
go
to
that
talk
by
Greg
Johnson,
which
will
help
fill
in
a
lot
of
that
nuance.
But
solid.js
takes
a
position.
No,
we
don't
want
to
build
these
view,
trees
and
Biff
them.
A
Of
course
you
have
to
keep
building
it
more
of
it
if
you're
dynamically,
adding
new
content,
but
you
know
generally,
you
know
you
build
the
thing
once
and
it
stays
it's
persistent
and
in
order
to
get
the
updates
to
happen
because
you
need
to
update
you
know
you
need
your
your.
What
you're
showing
is
changing
in
this
tribe.
You
build
a
fine-grained
dependency
graph,
so
basically
every
piece
of
information.
That's
on
that
screen.
A
Every
property
has
is
a
node
in
a
dependency
graph,
and
then
your
app
state
is
also
nodes
in
a
dependency
graph,
and
you
know
when
you
build
your
UI,
it
is
dynamically
building
that
dependency
graph.
So
when
some
element,
when
some
field
in
your
app
State
changes,
that's
going
to
get
plumbed,
so
those
changes
are
going
to
propagate
through
the
dependency
graph
and
then
when
they
get
to
the
end
they're
going
to
cause
something
to
change.
A
You
know
in
the
elementary
so
in
on
a
Dom,
that's
going
to
be
like
a
set
attribute
or
something
like
that
on
a
Dom
node,
so
not
fine-grained
dependency
graph
and
that's
a
hard
thing
to
build.
This
is
this
is
the
tricky
part
and
so
there's
kind
of
two
flavors
two
sub
flavors
I
mean
everything,
has
infinite
amounts
of
variation,
but
one
of
them
is
that
you
do
all
this
building
of
this
dependency
graph
at
runtime,
and
that's
certainly
what
solid.js
does
and
sveld
has
the
kind
of
attitude
of
like
well
there's
a
compiler.
A
Why
not
do
a
ton
of
analysis
of
your
UI
so
that
you
you
kind
of
build
as
much
as
possible
like
there's,
maybe
some
that
you
still
have
to
do
at
runtime,
but,
like
you
can
analyze
it,
you
can
kind
of
figure
out
what
the
dependencies
are
at
compile
time,
but
that
requires
a
compiler.
That
requires
a
build
step
and
in
the
case
of
svelte
you
know
they
have
a
compiler.
That
does
that
right.
A
So
so,
then
that's
how
it
works,
that
you
know
when
the
input
changes
when
some
part
of
your
app
State
changes,
then
that
propagates
through
the
graph,
it
updates
your
element,
attributes
and
you
know-
makes
all
those
changes.
So
there's
there
are
three
really
interesting
rust
implementations
on
the
web,
that
drive
Dom,
that's
Sycamore
leptos
and
a
new
one
called
Silk
and
web
and
I
would
say
you
know,
Sycamore
and
leptos
are
actually
pretty
similar.
Leptos
is
a
little
newer.
A
One
of
the
things
that
about
these
tribes
is
that
most
of
them
have
both
web
and
Native
implementations
in
some
way
and
so
again
that
there
is
an
implementation
of
this
fine-grained
reactivity
model
on
Native
UI
in
in
in
the
form
of
vizia
visia
at
first
I
actually
had
it
in
the
wrong
category,
because
I
looked
at
it
and
I
saw
that
it
uses
Elm
style
messages
to
handle
sort
of
your
your
input.
I
was
like.
Oh
it's
in
the
elm
tribe,
but
got
set
straight.
A
So
the
next
are
the
big
tribes,
and
this
one
like
it's.
Actually
it's
not
surprising
that
this
tribe
exists
because
react
is
overwhelmingly
popular
in
the
JavaScript
world.
So
it's
surprising
that
there
aren't
that
many
rust
implementations
as
well,
but
there
are
some
and
the
one
you
know,
I
think
the
one
that
a
lot
of
people
are
really
excited
about
and
for
good
reason
is
dioxis.
A
So,
let's,
let's
get
into
it
a
little
bit
more.
So
this
one
is
a
transient
Beauty.
So,
basically,
you
run
your
app
and
your
app.
You
know
your
app
is
basically
a
function
from
the
App
State
to
this
view
tree,
which
is
this
transient
thing.
It's
also.
This
pattern
is
also
known
as
virtual
Dom
right,
because
you're
you're
building
a
tree
that
looks
a
lot
like
a
Dom
and
so
in
react
like
this
is
also
the
distinction
between
like
leptos,
which
is
fine,
green
reactivity.
They
didn't
react.
You
have
a
fairly
coarse
granularity.
A
It's
really
generally
component
scope
to
decide
when
a
rearender
is
needed.
You
know
that
you
you
build.
You
build
a
view
tree
for
an
entire
component
and
there's
a
couple
of
ways
that
you
trigger
this
right.
You
don't
always
build
all
of
the
world
on
every
update
cycle
that
you
either
have
a
notification
like
if
you
do
set
State
on
a
component
and
it
causes
a
component
to
rebuild
and
there's
also
a
memoization
function.
A
A
But
when
you
do
re-render,
you
get
a
new
view
tree,
and
then
you
take
that
utree
and
you
diff
it
against
the
old.
So
diff
is
basically
a
function
from
old
tree,
a
new
tree.
You
know
sitting
on
some
kind
of
mutable,
Elementary
and,
and
it
updates
the
elementary
it
creates
an
it
either
updates
it
directly
by
having
mutable
access
to
the
elementary
or
it
creates
some
kind
of
mutation
object,
which
is
the
way
that
dioxis
does
it,
and
you
know
like
one
of
the
reasons
why
I
prefer.
A
A
Another
thing
to
say
you
know:
people
are
very
concerned
like
react,
has
a
reputation,
a
fairly
well-deserved
reputation
for
not
having
great
performance,
and
you
know,
one
of
the
reasons
is
you're
You're
Building,
these
view
trees
with
fairly
coarse
granularity
and
you're
doing
a
lot
of
different
work,
even
if
nothing
has
changed,
or
only
a
very
small
amount
has
changed.
So
one
of
the
techniques
that
can
reduce
that
cost
of
diffing
is
that
you
use
templates
so
that
you're
you're
really
only
diffing
the
dynamic
parts
and
the
static
Parts.
A
You
know
get
done
once
and
access
the
recent
release
of
dioces
has
has
this
template
mechanism
and
it's
it's
one
of
the
reasons
why
their
performance
is
really
quite
excellent
and
then
there's
this
concept
of
you
state,
because
the
problem
you
know
one
of
the
challenges
here
is
that
these
view
trees
are
transient.
So
if
you
have
state
that
needs
to
be
persistent,
if
you
need
to
track
over
a
longer
period
of
Time,
how
do
you
do
that
and
the
way
you
react?
Does
it
in
JavaScript?
A
Is
that
there's
Hooks
and
those
live
in
some
kind
of
persistent
view?
State?
You
know
off
to
the
side
and
so
that
that
V,
that
view
state
tree
lives
and
persists
great
and
then,
when
you
oh
outside,
you
know
mostly
I'm
talking
about
rest
in
JavaScript,
because
in
JavaScript
there's
this
extremely
thorough
exploration
of
the
state,
but
I
will
also
mention
that
flutter
is
fundamentally,
it
belongs
to
the
react
tribe
and,
of
course,
it's
implemented
in
Dart,
so
the
third
tribe
is
Elm
and
Elm
has
a
great
long,
history
and
I
think.
A
The
reason
why
Elm
is
popular
is
that
that
it
that
the
impedance
mismatch
between
element
rust
is
less
than,
for
example,
between
JavaScript
and
rust.
The
JavaScript
you
know,
access
to
Shared
mutable
state
is
no
problem
right,
object-oriented,
inheritance,
no
problem,
those
patterns,
don't
adapt
well
to
rust,
but
the
elm
patterns.
Do
it's
pretty
similar
to
react?
It's
the
same
virtual
Dom
or
view
tree.
You
know
you
build
this
transient
Beauty
and
you
you
know
that
gets
dipped
to
actually
update
the
element.
Trees.
A
It's
a
little
bit
more
reliant
on
memoization
in
L.
Memosation
is
the
kind
of
primary
tool
that
you
use
to
decide
what
needs
to
get
re-rendered
but
I
think
the
main
difference
between
the
react
and
the
elm
tribe
is
that
in
react.
Everything
tends
to
be
very
dynamically.
Typed
comes
from
the
JavaScript
world
and
then
Elm
The
View
tree
has
a
type.
It
is
statically
typed.
A
And
that's
a
problem
like
how
do
you
represent
that,
like
you
know,
how
do
you
connect
that?
How
do
you
get
it
to
access
that
and
one
of
the
ways
that
that's
done
very
popularly
in
Rust
is
that
you
have
interior
immutability
that
you
have
shared
reference?
It
might
be
an
arc
mutex
or
a
RC,
ref
cell.
If
you
don't
care
about
running
in
a
multi-threaded
context,
and
so
the
the
Callback
itself
has
that
reference
and
it
reaches
into
the
interior.
A
Immutability
makes
the
change,
but
Elm
has
this
other
pattern
that
works
really
well
in
a
purely
functional
language.
That
says
no.
What
happens
is
when
you
click
the
button.
It
creates
a
message
and
then
that
message
gets
passed
to
an
update
function
and
the
update
function
reduces
you
know
it.
It
basically
creates
a
new
app
state
which
is
a
function
of
the
old
App
State
and
the
message
that
it's
given,
and
so
that
means
that
you,
you
don't
have
this
problem
like
you,
don't
have
to
do
interior
immutability.
A
So
this
you
know
all
these
problems
that
you
have
when
you
have
this
kind
of
soup
of
tons
of
shared
mutable
objects
that
have
references
to
each
other
and
are
constantly
trying
to
mutate
each
other.
You
really
avoid
that
it's
much
more
organized
and
disciplined
and
structured
than
than
then
these
object-oriented
types
of
patterns.
So
not
surprisingly,
we
have
a
number.
We
have
quite
a
number
of
rest
implementations
of
this
pattern,
so
on
the
web,
we
have
you
and
Sauron
and
then
in
the
native
world-
and
this
these
are
there's
more.
A
These
are
just
Representatives
that
iced
is
really
based
on
the
Elm
patterns,
and
you
also
have
this
realm,
which
is
I,
believe
a
layer
on
top
of
gtk
plus,
primarily
so.
The
last
of
the
four
tribes
is
Swift
UI,
and
this
is
less
known.
I
mean
one
of
the
reasons
why
it's
less
known
is
that
there
is
no
representation
of
this
at
all
in
the
JavaScript
world.
A
If
you
come
from
the
JavaScript
world,
then
Swift
UI
is
alien
and
the
main
reason
why
that's
the
case
is
that
Swift
UI
relies
extremely
heavily
on
the
statically
type
of
you
tree
like
it
goes
well,
I
mean
it's
similar
to
element
in
this
way,
but
this
is
really
characteristic.
If
you
try
to
do
Swift
UI
without
the
statically
typed
YouTube,
it
wouldn't
be
anywhere
near
the
same
thing.
So
there's
a
rich
type,
Swift
UI
Swift
has
a
very
rich
type
system.
A
There's
a
lot
of
commonality
between
a
swift
type
system
and
the
rest
type
system.
They
both
have
Associated
types
and
they
both
use.
Associated
types
well,
Swift
UI
uses
Associated
types
very
extensively,
so
that
that
view
State
like
when
we're
talking
about
react
and
having
the
hooks
there's
this
kind
of
array
and
there's
this
all
this
sort
of
ambient
Authority
where
it
goes
and
reaches
into
the
array
and
then
there's
the
rules
of
hooks.
That
say,
if
you
do
this
out
of
order,
then
you'll
get
the
state
completely
scrambled.
A
But
Swift
UI
is
again
much
more
organized
and
disciplined
about
this
that
you
know
that
it's
saying
well,
you
have
this
view
tree
and
then
there's
an
Associated
type,
which
is
the
view
state
tree
and
the
correspondence
for,
like
you
know.
How
do
you
access
that
state
when
you're
in
a
view
and
you're
trying
to
process
it?
It's
very
straightforward:
it's
it's
statically,
typed,
there's!
A
Actually,
a
lot
less
that
can
go
wrong
now,
if
you,
if
you
do,
want
more
chance
for
things
to
go
wrong,
you
have
that
option
as
well,
that
you
can
do
type
Erasure
any
View,
and
that
allows
you
that
that
gets
you
a
node
in
your
static
type
system.
That
says
you
know
this
is
any.
This
can
be
any
view
under
that.
A
A
Maybe
one
thing
to
mentioned,
though,
at
this
point
is
that,
because
those
view
trees
are
statically
tight,
there
is
a
lot
less
allocation
and
dynamic
dispatch,
and
so
on
and
so
forth
that
you
know,
if
you
have
like
numbers
and
stuff
like
that,
the
code
to
diff
can
just
be
comparing
those
numbers
and
and
going
on
you
don't
need
to
like
Chase
a
lot
of
pointers.
So
that's
one
of
the
reasons
I
think
why
it
works.
A
That
takes
that.
You
know
message
and
and
applies
it
to
this,
to
the
App
State
and
you
know
kind
of
a
react
thing
where
there's
a
callback
that
has
that
reference
and
goes
directly
that
in
xylem
there's
a
mechanism
where
the
Callback
is
given
access
to
the
to
the
App
State.
So
there's
an
and
mute
T
where
T
is
the
ABS
app
state
that
that's
part
of
the
xylem
type
and
then
rui
has
immediate
mode,
rendering
and
again
I
feel
like
immediate
mode.
Rendering
has
a
lot
of
limitations.
I.
A
A
A
There's
some
blog
posts,
there's
some
more
materials
are
out
there
and
we're
going
to
be
rolling
out
more
as
we
keep
developing
this
stuff,
but
I
I
want
to
give
it
at
least
a
very
quick
overview
of
what
this
alarm
architecture
looks
like
so
kind
of
similar.
Like
you
know,
it's
super
inspired
by
Swift,
UI
and
so
each
view.
So
you
have
this
view
trait,
which
is
really
the
center
of
the
xylem
architecture
and
the
view
trait
has
two
Associated
types,
and
one
of
them
is
the
view
state.
A
So
that
would
be
the
same
thing
that
you
would
use
your
hooks
or
in
react
and
the
other
is
the
element.
So
if
you
have
a
button
view,
then
you
have
a
button
element
and
the
button
element
is
the
widget
and
it's
gonna.
It's
gonna
meet
a
a
trait
bound.
You
know
for
a
widget
and
and
that's
the
actual
implementation
of
that
view,
and
then
there
are
three
methods.
A
Each
view
implements
three
methods
and
the
first
method
is
build,
and
so
that
creates
the
elementary
and
initializes
the
state
for
it
and
if
you're
not
going
to
see
any
changes
like
if
you're
building
something
that's
static,
then
that's
enough,
then
you're
done
you
have
you
you've
built
the
you've
built
the
element:
you've
initialized
the
state
and
you're
done.
But
if
you
do
have
changes,
if
you
need
to
update
that,
then
you
have
the
rebuild
method,
and
so
these,
by
the
way,
are
highly
simplified
signatures
of
these
methods.
A
There's
a
context
that
goes
in
and
the
nice
thing
is
that
that
context
it
has
the
context
it
can
use
it,
but
that's
hidden
when
you're
writing
your
app,
you
don't
need
the
context.
You
just
write
your
views
and
the
views
are
just
value,
data
types
and
the
context,
wiring
kind
of
happens
under
the
hood
for
you
so
yeah.
So
if
something
changes,
then
you
call
the
rebuild
method
and
the
rebuild
method
is
what's
doing
the
different.
So
the
signature
of
this
is
that
you've
got
self,
which
is
the
new
view.
A
You've
got
priv,
which
is
the
previous
state,
the
old
view,
so
you're
able
to
compare
those
diff
them
and
then
you've
got
mutable
access
to
the
state
and
you've
got
mutable
access
to
the
element
tree
and
again
in
xylem
like
this
is
actually
I.
Think
a
simplification
over
some
other
Alternatives,
that's
mutable
access
to
the
elementary.
So
when
you're
like,
how
do
you?
How
do
you
update
it?
How
do
you
mutate
it
in
some
of
these
designs,
including
dioxis?
You
actually
build
a
mutation
data
structure.
A
You
know
you're
trying
to
do
this
batched
mutation,
and
there
are
a
lot
of
advantages
to
doing
that.
I
had
that
prototype
in
an
earlier
prototype
of
this
thing,
that's
what
I
was
doing,
but
you
know
largely
largely
inspired
by
Olivier
I
can't
pronounce
his
last
name,
but
the
author
of
panoramics
and
and
masonry
really
said
you
can
simplify
this
you
can
you
can
get
direct
mutable
access
to
the
elementary
itself
and
then,
when
you
have
a
container,
then
you
know
when
the
container
traverses
down.
A
So
this
is
all
based
on
recursive
traversal
from
the
root,
and
so
when
you
have
a
container
and
the
container
has
mutable
access
to
some
parent
node,
then
when
it
traverses
into
the
children,
it
just
gives
the
children
mutable
access
to
it
to
their
individual
element
trees.
So
that's
a
pattern.
I
think
that
works
really
well
in
Rust
and
the
third
method
which
I
won't
be
talking
about
in
detail.
Tonight
is
the
message
method,
and
this
is
this-
is
the
sort
of
reverse
flow.
A
This
is
taking
your
mouse
clicks
and
your
UI
interactions
and
when
async
Futures
resolve,
basically
it
you.
You
know
this
is
a
real
graph
data
flow
incremental
computation
mechanism
that
anytime
something
needs
to
flow
in
that
direction.
That's
a
call
on
the
message
method
of
the
corresponding
View,
so
the
the
other
thing
you
know
like
I
I,
like
you
know,
I
focus
on
view,
but
a
lot
of
the
actual
work.
That's
been
done.
A
Sequence,
and
so
you
can
think
of
you
as
modeling-
maybe
a
parent-child
relationship
and
do
sequences
as
modeling
a
sibling
relationship,
so
view
sequence
is
zero
or
more
views
that
are,
you
know,
siblings
of
each
other
in
that
in
that
tree
structure,
and
one
of
the
things
that's
important
to
get
right
is
that
the
number
of
views
in
that
sequence
can
vary
dynamically,
like
that.
That's
a
little
hard,
the
the
mechanism
to
get
that
to
work,
but
I
think
what
we
have
now
works
really
well,
there's
this
Vex
glaze
it
has.
A
You
know
you
can
do,
insert
delete
mutate
and
Skip
operations
in
there
and
it's
reasonably
efficient.
You
don't
get
any
n-squared
Behavior.
The
details
of
the
performance
are
are
a
deep
and
nuanced
question,
but
I
think.
What's
there
is
good
and
then
one
of
the
other
things
that's
nice
is
you
know
a
lot
of
times
in
these
you,
as
you
have
conditional
rendering
like
display
this.
You
know
display
this
error
indicator.
A
A
So
the
idea
that
came
together
just
in
the
last
you
know
couple
of
months
is
you
know
if
you
are
trying
to
drive
both
native
and
web?
How
do
you
make
that
happen
and
the
idea
is
you
have
this
view
trait
and
one
of
the
beautiful
things
about
rust?
It's.
This
is
very
different
than
the
usual
object-oriented.
You
know.
Model
of
the
world
is
that
you
can
have
a
concrete
data
type
you
can
have
in
the
case
of
vector
graphics.
A
You
can
have
a
circle
and
you
can
say
I'm
going
to
have
two
different
traits
on
that,
and
one
of
them
is
going
to
be
an
SVG
View
and
the
other
is
going
to
be
a
xylem
view.
Then
I'm
going
to
render
you
know
with
Native
rendering,
and
so
when
you're
writing
your
app,
you
don't
have
to
care
which
backend
is
actually
driving
it.
A
You
can
say
I'm
going
to
generate
a
circle
here
or
all
of
the
other
things
that
are
vector,
graphics
types
groups,
and
you
know
you're
going
to
put
wrappers
around
them
to
control
their
styling
and
interactivity
and
stuff
like
that,
and
none
of
that.
None
of
that
actually
really
cares,
whether
it's
generating
Dom
nodes
that
will
be
interpreted
by
the
browser
or
whether
it's
generating
you
know
these
structures
that
will
be
implemented
natively.
A
So
the
thing
that
makes
this
work
and
again
this
is
something
that
really
only
landed
in
the
last
two
or
three
weeks
in
the
repo,
because
we
were
we
were
spending
time
to
get
it
right
is
the
generic
xylem
core.
So
this
is
a
crate,
that's
inside
the
xylem
repo
and
it
is
agile
over
the
type
of
the
elementary.
So
the
element
tree
can
be
Dom
nodes
in
a
browser
or
the
elementary
can
be
widgets.
You
know
that
you
define
or
the
elements
tree
can
be
something
else.
A
So
that's
that's
usually
modeled
as
a
trait
bound.
So
in
the
case
of
like
widgets
there's
a
widget
trait
and
it
says
any
any
any
node
in
the
elementary
that
you
generate
has
to
conform
to
the
widget
trade
and
then,
if
you're
a
container,
then
all
of
your
children
are
basically
like
impul.
You
know
imple,
widget
or
actually
box,
Stein
widget,
but
you
know
you,
actually
you
get
that
choice
if
you
really,
if
you
want
the
elementary
to
be
statically
typed,
you
can
do
that,
but
there
there's
some
downsides
to
that.
A
So
we
have
it
boxed,
and
so,
if
you
have
different
instances
of
this,
so
this
is
part
of
the
idea
that
we
do
want
different
instances.
We
want
one
instance
for
web
and
we
want
one
instance
for
native
and
then
we
actually
want
other
instances
for
other
things
that
are
not
widgets,
so
we
want
menus
to
be
their
own
view
as
well,
and
the
elementary
is
menu
items
and
not
widgets,
and
so
we,
after
considering
a
lot
of
different
possibilities
like
we
went
pretty
deeply
into
like.
A
Can
we
do
this
using
generics
in
the
type
system?
And
you
know
that
ended
up
I
mean
long
story
short.
It
ended
up
just
not
you,
you
could
force
it,
you
could
make
it
work,
but
it
just
wasn't
the
right
answer
and
you
know
you
can
read:
what's
on
there,
I'm
not
going
to
read
it,
so
we
ended
up
having
macros
so
that
you
just
say
you
know
basically
generate
all
these
traits
and
generate
all
these
helper
methods
like
type
Erasure
and
so
on
and
so
forth.
A
You
sequence,
you
know,
so
so
those
are
just
macros,
but
those
macros
are
not
exported
to
users.
You
don't
have
to
write
macros
in
application
code.
This
is
when
you're
implementing
something
when
you're
you
use
macros,
if
you're
applying
xylem
core
to
build
the
UI
framework.
So
it's
like
a
UI
framework
Construction.
A
So
the
Prototype
that
I've
been
using
to
kind
of
experiment
with
this
is
this
thing
called
xylem
SVG
and
it's
an
instantiation
of
xylem
core
that
generates
Dom
nodes
and
the
the
views
are
actually
just
plain
turbo.
Shades
kerbo
is
our
2D
geometry,
you
know
crate,
it's
got
circles
and
lines
and
rectangles
and
busiopaths
and
all
those
goodies
and
those
just
get
an
imple
view
on
it.
A
So
your
app
like,
if
your
app
just
returns
a
circle,
then
that's
something
that
will
generate
an
SVG,
Circle,
node
or
it'll,
draw
a
circle
using
Velo
and
so
then
there's
wrap
reviews.
So
those
are
the
clean
turbo
shapes,
are
kind
of
the
leaves
of
the
system
and
then
there's
wrappers
that
add
color
and
mouse
interactivity
and
xylem
SVG.
The
actual
xylem
SVG
crate
itself,
everything
that
it
does
compiles
to
wasm
and
it
runs
in
the
browser
and
it's
really
economical
it.
I'll
I'll
actually
show
it
to
you
now.
D
A
There
we
go
so
this
is
a
a
little
interactive.
Vector
diagram
I'll
show
you
the
code
for
it
too.
If
you
want
to
see
it
so
this
is.
This
is
going
to
be
something
in
a
future
blog
post
about
how
path
rendering
Works
internally
to
Velo,
and
so
it's
generating
it's
generating
these
views
and
it
is
those
are
becoming
wasm
and
if
you
look
at
the
bundle
size,
the
wasm
bundle
for
this
interactive
example
is
120
kilobytes
like
yeah.
This
is
pretty
good,
and
this
is
just
this
is
just
trunk.
A
A
And
then
this
is
I'll.
Show
you
like
this
is
you
can
see?
This
is
not
a
lot
of
code.
I
mean
this
is
calling
to
a
few
other
things
and
I'll
show
you
most
of
it.
So
this
is
the
this.
Is
the
wasm
bind
gen
start?
This
is
actually
entry
point
from
your.
You
know
into
the
app,
and
so
it
just
initializes
the
App
State,
and
then
this
is
your
app
logic,
which
is
the
function
from
App
State
to
a
view
tree.
So
this
is.
A
A
Render
tile
msaa,
there's
a
lot
of
complexity
there,
but
all
of
the
UI
stuff
is
really
in
this
part,
and
so
now
we
have
a
group
which
is
in
a
translate
actually
show
you
like
I
like
showing
I
like
talking
but
I
like
showing,
and
so
this
is
what
it
looks
like
right.
You
have
a
SVG,
no,
you
have
an
SVG,
you
know
element,
and
then
you
have
all
these.
A
You
know
nodes
that
are
under
that,
so
you've
got
G's
for
groups
and
then
you've
got
all
these
lines
and
circles,
and
so
on
and
so
forth
and
and
by
the
way
the
circles
have
classes
on
them.
You
might
be
able
to
show
you
this
then
yeah.
There
we
go
yeah,
you
see
them
change,
so
you
know
like
it's:
it's
updating
the
classes
in
order
to
cause
these
State
changes
to
I.
Don't
know
why
it's
being
bulky
did
it
crash.
I
might
have
crashed
it
anyway.
A
I'll
refresh
how's
that,
okay
great,
so
so
what's
so
so
you
saw
what
the
HTML
looks
like
you
saw
what
the
Dom
looks
like.
What
is
the
view
tree
that
generates
that
and
actually
it
is,
you
know
it's
the
same
structure
that
this
groove
turns
into
a
g
node
these
circles,
which
are
the
this
the
handles.
You
know
these
endpoints
here
that
it's
drawing
those
are
just
circles.
A
You
don't
want
to
have
one
big
giant
method,
that's
doing
everything.
So
you
want
to
have
helper
functions
and
those
are
also
like
really
really
straightforward,
that
this
is
just
going
through
your
app
State
and
you
know
just
iterating
through
well.
This
one
is
drawing
the
grid.
So
there's
no
there's
not
a
lot
of
data
dependency,
but
it's
just
pushing
it's
just
making
a
VEC
of
lines.
That's
all.
It
is
right
and
you're
just
Computing.
What
are
the
coordinates
of
those
lines?
And
then
this
is
the
one
that's
actually
working
from
the
App
State.
A
This
is
coloring
all
these
these
circles.
Again.
It's
just
iterating
over
this
thing
that
you
got
computed
and
it's
just
pushing
it's
just
it's
a
vect
of
circles
and
it's
just
pushing
a
ton
of
circles
and
and
it's
wrapping
them
in
a
class
where
the
class
is
you
know,
is
dependent
on
your
data.
So
that's
it
I
mean
you're,
looking
at
a
few
dozen
lines
of
code
to
drive
this
UI
great.
So
that's
the
demo!
There
question
yes,
Lynn
can
we
get
will
Mike?
Yes,
yes,.
E
B
A
A
F
A
A
Yes,
so
so
let
me,
let
me
explain
exactly
what's
going
on
here,
because
it
might
look
a
little
bit
mysterious.
So
so
so
the
circle
is
this
circle,
that's
just
that
that's
just
a
circle
and
then
we're
putting
a
class
on
it
and,
incidentally,
that
class.
Let
me
I
think
I
have
to
focus
the
window
to
show
that
that
do
you
see
the
way
that
it
like
gets
a
little
bit
bigger
when
you
hover?
That's
that's
CSS!
So
that's
just
a
hover.
A
Yeah
yeah,
so
so
that's
being
done
by
CSS
for
you.
So
then,
when
you
say
dot
pointer,
so
this
is
this
fluent
style
right
and
what
it's
actually
doing
is
that
it's
creating
a
wrapper.
So
the
type
of
this
thing
do
I
get
my
types
there's
a
lot
of
times
you
actually
get
well,
you
can
see
you
can
see
a
little
bit
that
it's
creating.
You
know
that
this
is
calling
a
function,
a
method,
that's
basically
taking
that
Circle.
Actually,
it's
a
circle
wrapped
in
class.
A
So
it's
a
three
level
sandwich
that
it's
a
pointer
view
that
has
a
Class
View
as
a
child
and
then
the
Class
View
has
the
circle
as
the
child,
so
that
point
of
view
is
saying
that
I
am
going
to
I
am
going
to
be
attaching
Mouse
interactivity
to
that
node.
In
the
view
tree
and
anytime,
you
get
pointer
events
into
that
node.
It
is
going
to
call
this
callback,
so
that
is
a
callback.
That's
a
closure
and
that
closure
is
given.
A
This
is
another
part
of
the
magic
of
xylon
that
it's
given
mutable
access
to
the
App
State
at
that
point
right.
So
that's
plumbed
by
the
framework.
The
framework
says
you
know
when
I'm,
when
I'm
dispatching
a
message
that
I'm
going
to
have
mutable
access
to
the
App
State
at
the
time
that
I'm
dispatching
it.
So
that's
given
to
the
closure,
and
then
this
closure
is
going
to
take
that
App
State,
which
is
s,
and
it's
going
to
call
this
function.
A
You
know
on
the
grab,
you
know
have
the
sort
of
helper
structure
which
is
called
grab
State
and
that
grad
state
is,
which
is
very
simple:
I
mean
you
can
look
at
it.
It's
just
tracking.
You
know
whether
you're
down
or
not
and
then,
which
pointer
is
being
touched
in
some
geometry.
So
that's
going
to
call
so
basically,
when
you
click
Mouse
down,
then
that's
going
to
end
up
calling
into
this
handle
method
on
this
grab.
A
A
Yes,
that's
correct,
so
so
great
question,
so
the
question
is
kind
of
what
happens
after
and
what
happens
after
is
that
you
know
you
call
that
call
back
and
it
causes
the
mutation
of
the
App,
State
and
then
the
framework,
so
the
framework
is
sort
of
in
charge
of
the
overall
sequencing
of
this
stuff.
The
framework
is
going
to
call
your
app
logic
function
and
your
app
logic
function
is
going
to
return
a
new
view
tree
and
the
new
view
tree
will
have
the
new
coordinates
like
if
you're
dragging
this
point
around.
A
So
the
callbacks
aren't
registered.
The
callbacks
are
just
there
right,
like
the
view.
So
this
is
this
is
subtle,
but,
like
the
view
tree
has
callbacks
in
it.
It
creates
a
view
tree
and
the
view
tree
is
all
of
these
nodes
in
it.
That
can
that
tell
you
how
to
actually
render
you
know
what
should
be
rendered,
but
it
has
these
callbacks
sitting
in
it
just
as
Fields
right.
So
when
you
have
a
you
know
like
I
I
can
actually
show
you.
This
I
can
show
you
all
the
code.
A
Well,
yeah
you
you,
when
you,
when
you
pass
in
a
closure,
then
you
know
you
get
a
new
value
of
that
closure
every
time,
but
that
doesn't
necessarily
involve
a
lot
of
allocation.
Most
of
the
time,
that's
just
a
function
pointer
that
doesn't
necessarily
involve
like
out
boxing
and
so
on
and
so
forth.
You're,
not
registering
it
you're
not
like
mounting
it
right
and
then,
when
you
get
a
message.
So
if
you
look,
for
example,
the
message
implementation
on
pointer
well
pointer
is
interesting
so
on
the
web
on
the
web.
What
happens?
A
Is
that
you're
doing
all
of
these
closures?
That
you're
that
you're
registering
at
build,
but
it
turns
out
that
you're
not
re-registering
those
closures
at
rebuild
time,
you're,
actually
creating
those
closures
once
right
and
then
when,
when
the
closure
is
invoked
when
the
Callback,
so
this
is
a
JavaScript
called
it.
This
is
actually
JavaScript
at
this
point
because
of
a
JavaScript
wasm
bridge,
and
so
when
those
when
those
closures
are
called
when
those
JavaScript
closures
are
called.
What
that's
going
to
do
is
that
it's
going
to
push
message
right.
A
So
that's
why
you
don't
need
to
keep
rebuilding
these
things
that
that
the
message
is
always
the
same.
But
then,
when
you
dispatch
the
message
right,
so
you
get
a
message
that
says:
hey
pointer
down
right.
This
is
the
coordinates
of
that
of
that
point,
and
when
you
dispatch
that
message,
that's
going
to
go
through
the
message
method
of
the
view,
trade
for
pointer,
which
is
going
to
go
into
this
code,
and
then
this
code
is
going
to
call
whichever
callback
is
present
of
the
view
that's
in
place.
A
D
A
And
then
in
terms
of
updating
the
Dom
like
this
is
all
very
simple
code.
So
this
is
this
is
line,
and
so
it's
just
saying,
let's
create
a
Dom
element
for
that
line
and
let's
set
the
attributes,
that's
build.
So
this
is
just
as
straightforward
as
you
could
possibly
imagine
like
create
the
dominance
that
the
attributes
and
then,
when
you
look
at
rebuild
this,
is
where
the
diffing
is
happening
and
seeing
if
any
of
these
values
are
different.
A
A
If
you
really,
if
you
want
a
lot
of
unanswered
questions,
if
you
want
to
find
out
more
than
the
Swift
UI
talk
on
that
actually
spends
a
half
hour,
answering
it
in
detail,
because
this
mechanism,
I
didn't
invent
this,
this
mechanism
is,
is,
is
adapted,
I,
don't
want
to
say,
stolen.
It's
adapted
great
artists,
adapt.
H
Yeah
I
have
a
question
about
the
immutable
state,
so
I
have
a
use
case
in
mind
and
I
want
to
make
sure
I
understand
how
the
pieces
would
come
together,
sure
use
cases
load
some
data
from
a
server
yep
and
then
patch
that
data
into
the
state
mechanism.
Here
now
from
the
code
I
saw
like
the
pointer
Handler,
the
mutable
state
passed
in
is
that
where
you
might
perform
that
Network
requests.
A
Yes,
so
when
you're
dealing
with
async,
so
there's
a
oh
there's,
a
blog
post
that
has
been
in
the
queue
for
a
year
and
I
need
to
just
finish.
Writing
it
and
publish
it,
because
that
will
talk
about
the
async
story
in
more
detail.
But
the
short
answer
is
yes.
It
looks
very
similar
that
there
is
a
view
node.
So
there's
a
node
in
the
view
tree,
which
is
responsible
for
sending
that
Network
request,
and
then
the
the
fancy
part
is
that
that
each
node
kind
of
has
its
own
its
own
executor
right.
A
So
when
that,
when
that
Network
request
comes
back
and
there's
a
wake
event
that
happens
through
the
you
know,
through
the
kind
of
rest,
async
stuff
that
notifies
the
The
View,
and
so
that
triggers
the
whole
re-rendering
cycle
and
it's
actually
tracking
like
how
many
of
the
requests
that
have
been
sent,
it's
counting
how
many
requests
have
been
sent
that
haven't
come
back
yet,
so
you
can
make
a
decision
about.
Do
I
want
to
do
it,
sort
of
synchronously
or
do
I
want
to
show
a
you
know.
H
C
A
It's
not
blocking
so
so.
If
there's
a
network
request,
then
that's
async
rust
right.
So
so
those
requests
go
and
you
can
have
as
many
of
them
in
Flight
as
possible.
Now,
when
those
land,
when
those
Futures
actually
resolve,
then
the
resolution
of
those
Futures
is
going
to
be
in
a
queue,
there's
actually
going
to
be
internally
a
queue
and
it's
going
to
apply
them
in
order
and
it's
going
to
give
mutable
access
to
those
in
order
as
those
resolve.
A
So
if
those
State
updates
were
super
expensive,
that
might
be
a
problem,
but
if
you're
blocking
on
the
network,
then
the
state
update,
hopefully
is
just
like
yeah
I
got
my
result.
Just
set
the
result
of
this
new
value,
but
the
you
know
the
network
request
and
you
can
it's
not
just
the
network.
You
can
do
expensive
work
like
I
want
to
do
things
like
image,
decompression
and
even
text
layout
and
stuff,
like
that
in
worker
threads
I
mean
this
is
part
of
the
goal.
I
do
not
want
my
UI
to
be
you.
B
H
A
E
A
A
But
this
is
a
high
performance,
2D
renderer
and
it
is
designed
to
be
the
next
generation
of
2D
renderers,
and
so
it
is
designed
to
have
a
rich
Imaging
model
that
encompasses
pretty
much
everything
that
you
want
to
do
in
a
a
UI.
So
it's
very
heavily
focused
on
paths.
Stroking
and
filling
it
does.
Glyph
runs
for
text
you
for
brushes.
You
have
solid
colors
gradients.
A
You
can
use
images
as
a
brush,
it
does
clipping
it
does
all
of
your
blend
modes,
your
exclusions
and
your
differences,
and
it
does
affine
transformations
and
it's
implemented.
The
implementation
is
very
interesting.
It's
a
pipeline
of
compute
shaders
and
we
did
have
our
own
bespoke
GPU
infrastructure
for
it,
but
as
I
mentioned,
that
we
decided
to
join
forces
with
web
GPU
and
on
Rust
wgpu,
and
so
all
of
these
stages
are
implemented
as
shaders
written
in
wigsaw
the
web
GPU
Shader
language.
A
So
that's
just
a
quick
introduction.
You
can
go
to
The
Velo
repo
and
there
will
be
I
promise
a
lot
more
information
coming
out
about
the
details
of
Velo
in
the
coming
months,
but
I
wanted
to
talk
about
how
do
you
do
Velo,
rendering
in
xylem
and
kind
of
like
how
do
these
two
pieces
fit
together
in
a
nice
way
and
the
thing
that
is
the
kind
of
the
magic
sauce?
The
thing
that's
really
interesting
is
that
in
this
xylem
framework,
when
you
have
an
element
node
that
contains
a
scene
fragment.
A
So
this
is
another
part
of
The
Velo
architecture
that
you
that
you
build
the
scene
like
in
a
classic
2D
rendering
thing
you
have
a
rendering
context,
and
you
have
all
these
mutable
methods
that
you
call
the
all
these
methods
that
basically
mutate
the
graphic
State
and
that
forces
a
single
threading.
It's
similar
to
the
same
questions
and
in
Velo
you,
you
generate
these
scene
fragments
and
one
of
the
explicit
goals
here
is
that
you
could
be
generating
different
fragments
of
the
scene
in
different
threads.
A
A
You
can
just
hold
on
to
that
to
that
in
pre-encoded
value,
so
the
the
overall
goal
I
mean
this
is
details,
but
the
overall
goal
is
you've
got
this
extraordinarily
powerful
GPU,
that's
sitting
there
able
to
do
astonishing
amounts
of
work
in
parallel,
and
so
anything
that
you
can
do
on
the
GPU.
You
do
on
the
GPU
and
you
try
and
make
the
amount
of
work
on
the
CPU
to
get
that
encoded
and
get
that
rendered
as
absolutely
minimal
possible.
A
D
A
A
That's
that's
in
flight,
but
you
know
I've
just
got
the
interactivity
wired
up
through
buttons
instead
of
mouse,
but
you
know
it's
very
simple,
but
it's
actually
drawing
Vector
shapes
and
let
me
show
you
the
code
because
I
think
that
makes
it
sort
of
more
interesting
that
again,
you
will
be
able
to
see
the
kind
of
clean
correspondence
between
the
and
there
we
go.
So
this
is
this
is
the
code
you
don't
need
to
sign
into
GitHub.
A
Let's
give
a
little
bit
more
screen
space
yeah.
So
this
is
the
entire
code
for
the
for
the
demo
that
you're
seeing-
and
so
you
know,
the
Launcher
app
launcher
is
just
a
couple
of
lines
of
code
and
then
you've
got
this
graphic
state
which
in
this
case
is
just
a
very
simple
thing,
just
a
vect
of
circles
and
a
an
index
of
what
is
the
current
Circle
and
then
the
rendering
of
that
is
again
about
the
simplest
code
that
you
can
imagine
that,
and
so
it's
got
both
buttons.
A
It's
got
both
user
interface
and
it's
got
this
VG
node,
so
you
basically
have.
This
is
also
an
application
of
xylem
core
being
generic
that
there
are
two
different
view:
node
types
in
the
system
there's
a
sort
of
a
UI
node,
which
is
things
like
v-stack
h-stack
button
and
also
VG,
and
then
inside
VG,
they're,
vector,
graphics,
nodes
and
so
there's
a
group
and
then
there's
these
circles,
and
so
the
as
I
say
this
is
still
very
much
work
in
progress.
A
I
just
pushed
pushed
this
Branch
I
think
around
5
PM
this
evening,
and
but
the
the
goal
is
so
what
you
have
currently
implemented.
There's
another
thing
that
you
might
notice
is
that
colors
are
concrete
instead
of
CSS
files,
so
this
is
all
sort
of
an
early
rough
version
of
what
you're
seeing
but
the
idea
of
a
circle
just
being
a
turbo
Circle.
This
is
common
between
the
two
and
as
this
progresses.
A
There
are
not
that
many
things
out
there
that
do
this,
and
so
one
example.
One
of
the
few
examples
that's
out
there
that
does
have
this
pattern
is
react
native
SVG
and
react.
The
react.
Ecosystem
is
innovating
a
lot
in
this
space,
and
so
they
are
taking
the
SBG
nodes
they're
taking
very
similar
code
that
you
would
write
in
JavaScript
react
that
you
would
deploy
in
a
browser
and
then
they
are
implementing
that
with
Native
vector,
graphics,
renderers.
So
I
would
count
that,
as
like
very
direct
inspiration
and
another
thing-
that's
happening
in
the
space.
A
That's
very
interesting
is
that
there's
this
Deoxys
project
and
they
have
as
their
kind
of
story
for
how
are
we
going
to
deploy
by
access
applications
on
Native?
They
have
a
blitz
render
which
is
under
the
dioxis
labs
GitHub
organization,
which
uses
the
dioxis
virtual
Dom
as
that
sort
of
interface
layer
between
the
elementary
and
the
the
reactive
layer
on
top.
But
again,
if
you
go
to
Blitz
you'll,
see
that
like
they
want
to
be
driven
by
leptos
as
well,
they
don't
want
to
it's,
not
specific.
A
It's
not
bespoke
to
to
to
dioxis,
so
I
think
that's
very
interesting
and
then
there's
also
another
project,
that's
similar
to
Blitz.
Although
it
it's
not
quite
in
the
same
category,
because
this
is
called
Freya
Freya
is
not
actually
trying
to
be
compatible
with
the
web,
you're
not
they're,
they
don't
have
the
explicit
goal
that
you
write
your
code
once
and
to
play
the
same
code
both
on
web
and
Native.
It's
more
like
it
share
some
of
the
same
infrastructure.
A
So
you
know
I,
said
early
in
the
talk
that
this
is
a
science
project
and
like
if
you're,
really
doing
science,
you
need
to
be
thinking
about,
like
what
hypothesis
are
we
testing
and
there's
two
I
think
that
are
key
to
this.
To
this
work,
and
the
first
is,
you
know,
like
I've,
talked
about
these
four
tribes
and
I've
kind
of
presented
them
as
roughly
equal.
You
know
of
all
being
very
viable
Alternatives
I
mean
there's
a
lot
of
shipping
UI
code
in
each
one
of
those
four,
but
none,
of
course.
A
Yet
in
xylon,
xylem
is
still
this
very
early
prototype
and
we
I
I
personally
am
consumed
with
curiosity.
It's
like
I
think
xylem
will
hold
up
very
nicely
compared
with
dioxis
and
lapdos,
but
is
that
true,
and
so
I
want
to
find
out
the
answer
to
that
and
like
when
I
say
good,
like
you
know,
there's
a
lot
of
evaluation
criteria
that
you
might
use.
There's
the
conciseness
of
the
code
and
I
hope
I've
showed
you
that
you
know
there's
that
code
does
not
have
a
lot
of
fat
on
it.
A
You
know,
there's
no
contexts
that
you're
threading
around
there's
no
macros,
where
you're
hiding
all
the
complexity
under
the
under
the
hood.
That
is
as
close
as
I,
can
imagine
to
the
Natural
Way
of
expressing
that
in
Rust,
so
I
think
on
conciseness.
We're
going
to
do
pretty
well
performance
is
another
really
good
question,
and
that
includes
multi-threading.
Are
we
really
going
to
be
able
to
do
useful
work
on
all
these
different
threads
expressiveness
like
these
are
like
so
far.
What
you've
seen
are
these
toy
examples.
A
Is
this
going
to
scale
to
like
real,
interesting
things
where
you've
got
non-trivial
interactions
between
the
components
right?
We
don't
know
yet,
and
you
know
overall
ergonomics
right-
are
people
going
to
be
cursing
and
pulling
their
hair
out,
or
are
they
going
to
be
saying
wow?
This
really
is
doing
what
I
hope
it
can
be
done
most
of
these
criteria.
We
can
test
in
a
web
context
right
and
that
that
reduces
the
variables
like
you're.
A
The
second
hypothesis
to
test
is
like
the
motivation
for
this
work
like.
If
you
didn't
care
about
performance,
you
would
just
use
electron
right,
so
how
much
performance
is
possible?
How
how
much
faster,
how
much
more
throughput,
how
much
less
latency
all
of
these
startup
time
is
another
there's
actually
like
performance,
is
not
just
one
thing,
there's
a
lot
that
you
care
about,
and
so
for
each
one
of
those
performance
criteria
that
you
care
about.
A
You
know
how
much
better
are
we
going
to
do
than
the
web
and
again
I'm
really
excited
like
this
is
more
straightforward,
like
some
of
those
criteria
in
the
previous
one,
some
of
them
are
a
little
fuzzy
like
ergonomics.
How
do
you
feel
about
it
right
and
the
problem
with
that
is
that
a
lot
of
it
boils
down
to
familiarity
if
you've
spent
two
years.
A
You
know
writing
react
and
then
you're,
given
another
model
which
is
more
based
on
Swift,
UI
and
you're,
not
familiar
with
it,
it's
going
to
feel
less
ergonomic,
but
this
performance
stuff
is
pretty
objective,
and
so
we,
basically
you
know,
want
to
find
out
like
when
I
say,
Dom
and
CSS
are
slow
like
how
much
faster
are
you
going
to
be
if
you're
just
accessing
that
directly,
instead
of
going
through
those
layers?
How
much
multi-threading
are
you
going
to
get
and
this
Velo
renderer
when
you're
doing
this
GPU
accelerated
2D,
rendering?
A
A
So
really,
this
is
the
call
to
action.
I
want
to
enlist
my
fellow
scientists
in
helping
on
this
science
experiment
and
getting
the
answers
to
these
hypotheses,
because
I
I
really
want
to
know
the
answers,
and
so
you
know
that's
really
what
I
think
some
of
the
next
steps
are
on
this
work
is
to
do
some
of
these
experiments
to
build
out
to
kind
of
take
the
seed
and
build
more
of
it
out.
I
am
personally
not
going
to
have
the
time
to
build
out
the
web
side
of
this
myself.
I
am
my
day.
A
A
Web,
and
so
so
this
is
these-
are
the
detailed
issues
of
kind
of
what
what
is
going
to
happen.
You
know
what
what
would
happen
next,
if
you
wanted
to
build
xylem
core
out
into
a
more
full-featured
thing
that
you
could
actually
use
to
maybe
build
real,
build
real
web
applications,
and
you
know
like
so,
for
example,
there's
a
whole
thing
in
there
about
the
async,
and
that
has
you
know,
links
to
other.
This
is
the
draft
blog
post
that
I
was
talking
about.
A
A
If
we
get
more
people
working
on
it
so
yeah
and
then
you
know
the
the
lowest
levels
of
the
stack,
the
2D,
rendering
is
something
that
you
know
that
I
think
that
this
has
been
making
great
progress
and
it's
got
great
velocity
I'm
not
going
to
make
a
promise
about
when
I
think
it's
going
to
be
ready
for
real
use,
but
I
will
say
that
it
is
a
priority.
It
is.
It
is
something
that
is
on
our
roadmap
for
sure
and
then,
if
you
do
want
to
get
involved.
A
Obviously
you
can
talk
to
me,
but
there's
a
lot
of
really
good
starting
points
here,
a
lot
of
resources.
We
just
started
this
linebender.org
webpage.
It
has
a
list
of
all
the
projects
and
you
know
pointers
to
other
resources
like
the
zulip
instance
and
so
on
and
so
forth.
I
will
link
I
don't
have
yet
I
will
link
the
slides
so
that
all
these
links
that
I'm
asking
people
to
click
are
also
going
to
get
linked
through
there,
and
then
we
have
a
zulup
instance.
There's
really
excellent
discussion.
A
That
happens
there
and
everybody
is
welcome,
and
then
we
also
have
we're.
Not
advertising
this
like
on
social
media
and
stuff
widely,
but
if
people
are
interested
then
they
are
welcome
to
show
up
at
our
weekly
office
hours
which
are
currently
8,
am
on
Thursday,
California
time
and
again,
there's
a
real,
really
tight-knit
Community,
that's
forming
and
really
good
discussions
that
happen
at
those
all
right.
G
Yeah,
here
I
am
so
you
you
showed
us
this
App
State
struct
and
how
you
can
store
the
state
of
your
application
in
there
can
I
still
break
down
my
application
in
components
and
do
things
where,
for
example,
I
have
a
button
which,
when
hovered,
has
a
slightly
different
background
color
but
I
don't
want
to
think
about
it.
When
building
my
application,
I
just
care
about
the
click.
A
Sure
that's
a
really
good
question.
So
yes,
the
answer
is
yes.
That
part
of
this
LM
architecture
is
that
the
App
State
type
can
be
different
for
different
parts
of
the
application
and
there's
a
view
node
called
adapt,
which
is
basically
something
that
you
know
the
node
has
one
type
and
the
child
has
a
different
type,
and
then
you
get
callbacks
that
are
able
to
like
kind
of
project.
A
It's
it's
actually
a
lot
like
a
lens,
if
you're,
if
you're
used
to
functional
programming,
but
it
kind
of
projects
that
App
State
into
a
single
field
and
can
also
apply
logic
as
necessary.
So
the
goal
is
that
it
absolutely
will
be
able
to
support
that
kind
of
component
architecture.
Thank
you,
I'm,
going
to
take
this
two
more
questions.
C
A
That
was
one
of
the
flaws
in
Druid
that
Druid
had
everything
kind
of
you
know
the
type
basically
forced
monomorphization
of
everything.
So
the
idea
is
the
view
tree
you
are
going
to
get
reconfired
is
is
going
to
get
monomorphized,
but
the
hope
is
that
the
logic
of
the
view
tree
is
so
much
simpler.
Is
so
much
less
of
it
not
doing
you
know
layout
and
text,
rendering
and
internationalization,
and
all
that
stuff,
so
I'm
hopeful
it
is.
It
is
a
problem
in
Swift
UI
though,
and
so
it
is
something
to
watch.
B
So
I'm
just
curious
if
what
the
story
is
for
fine-grained
reactivity,
something
like
solid.js
or
mobx,
if
there's
any
way
that
that
could
get
integrated
into
xylem
and
what
that
would
look
like,
What
mechanisms
are
needed.
If
you
would
need
like
a
change
to
the
language
itself,
like
a
new
view,
function,
keyword.
A
Yeah,
so
that's
a
that's
a
that's.
Also,
a
really
excellent,
spectacularly
good
question,
and
one
of
the
motivations
like
kind
of
the
original
motivation
of
xylem,
even
before
it
evolved
into
its
current
state,
was
to
be
a
kind
of
a
component
architecture
where
your
different
components
could
be
built
in
very
different
paradigms.
A
So,
like
one
of
the
original
goals
was
to
support
scripting
in
Python
right
and
so
the
when
you
actually
look
at
the
details
of
the
view
trades
right
so
so
part
of
it
is
like
you
know,
I
talk
about
diffing,
you
don't
have
to
diff.
Like
the
view
trade,
the
definition
of
the
xylem
architecture
is
whatever
implements
The
View
trade.
So
if
the
view
trade
wants
to
diff,
you
know
declarative
States,
then
it
can
do
that
and
that
is
great
and
it'll
be
ergonomic.
A
A
It's
like
take
this
cue
and
apply
that
to
this
mutable
Elementary
that
I
now
have
mutable
access
to
so
I
am
hopeful,
but
I
think
that
you
know
in
order
to
figure
out
how
well
this
works
really
is
going
to
take
a
lot
of
exploration,
and
you
know
it's
not
obvious,
but
it,
but
it
was
part
of
the
original
goals.
It
was
part
of
the
original
scope,
so
I
think
there's
reason
to
be
hopeful.