►
Description
RustConf 2019 - Towards an Open Ecosystem of Empowered UI Development by Adam Perry
Rustaceans want to write GUI apps in their "native language" and to do it with declarative syntax, type safety, great tooling, and minimal runtime overhead. Moxie is a platform-agnostic component library to provide just that, currently targeting the DOM, win32, and WebRender, with more targets to come. We're on a path to building Rust apps that instantly reflect user intent, correctly handle inputs, and save battery and CPU cycles. We discuss what makes UI hard, how others handled that in the past, and what we can do today in Rust to clear those hurdles and unlock new powers.
A
A
Thank
you
by
the
way
for
being
here
sharing
your
lovely
presence
with
me
here
and
thank
you
to
the
staff
and
organizers
as
well.
It's
I
mean
having
been
on
the
other
side
of
some
events.
It's
monumental
and
I
am
not
jealous
of
the
job.
They
do
and
I'm
extremely
grateful
for
it.
If
you
see
me
organizer
around
to
thank
them,
so
Who
am
I.
I
have
an
origin
story
much
longer
than
any
of
our
births.
Of
course
you
all
do
too.
A
If
you
aren't
thinking
about
that
a
lot
these
days,
you
might
want
to
like
it's
a
fun
story,
a
fun
line
to
draw
into
the
past,
but
I've
been
using
Russ
for
about
four
years
now,
I
learned
it
right
around
the
time.
I
got
my
first
full-time
programming
job
as
like
a
professional
software
person,
so
my
enthusiasm
for
rust
has
had
me
involved
in
this
community.
For
that
whole
time,
and
it's
been
a
pretty
central
element
of
my
like
personal
and
professional
growth,
lots
of
friends
I,
see
in
the
audience
here.
A
You've
all
been
a
part
of
that
and
people
that
I
would
like
to
meet
afterwards.
Hopefully,
you
can
be
a
part
of
that
in
the
future,
and
so
aside
from
the
rusted
story
before
my
current,
my
current
work
I
was
at
the
startup
building
like
react,
native
developer
tools
and
I
got
pretty
nerd
sniped
by
you,
know
the
challenges
of
GUI
application
frameworks
and
being
able
to
iterate
on
them
over
time
trying
to
ship
products
on
multiple.
A
You
know,
multiple
platforms,
don't
even
begin
to
think
about
like
desktop
and
mobile,
and
so
you
know
I
kind
of
been
thinking
about
it,
a
lot
and
we
were
working
on
this
project
for
a
while
and
then,
of
course,
the
the
requisite
disclaimer
I
do
work
at
a
tech
company
who
has
a
very
effective
and
professional
PR
and
marketing
department.
I
am
NOT
here
as
a
representative
and
further
disclaimer
I'm,
actually
not
working
on
this.
A
With
my
day
job
at
all,
I
do
you
know
I'm
very
privileged
to
write
rust
for
a
pay,
but
this
isn't
what
I'm
doing
and
then
another
point
to
keep
in
mind.
I'm,
like
almost
definitely
wrong
about
really
important
things.
I
started
this
project
in
part,
because
I
wanted
to
build
apps
and
I
was
too
picky,
so
I'm,
not
really
a
person
who
builds
apps
I
see
a
lot
of
interesting
technical
problems
here,
but
I
want
to
learn
more
from
people
who
do
I
want
people
to
have
things
to
use
and
I.
A
You
know,
I
think
that
that
feedback
process-
and
even
you
know,
experimentation
outside
of
my
work-
is
absolutely
necessary
for
us
as
a
community
to
do
this
thing,
which
kind
of
brings
us
to
this
thing.
I
want
to
write,
apps
and
rust,
as
I
mentioned,
I
want
to
give
back
technology
that
I
build
doing
that
to
this
community.
That's
been,
you
know,
real
support
for
me
and
I
have
some
specific
technical
desires
of
like
how
that
should
work.
Those
should
be
structured.
A
You
know
rust
is
not
constrained
to
a
single
environment,
so
if
we
are
sitting
here
asking
ourselves,
what
do
you
want
from
us?
Gui
I
think
almost
every
person
I've
spoken
to
has
had
implicitly
in
their
mind.
It's
gonna
be
awesome
and
it's
gonna
be
cross-platform
and
I'm.
Just
gonna
like
I'm
gonna,
go
rust
all
day
and
then
I'm
gonna,
like
click
deploy
on
github
and
it's
gonna,
be
on
like
eight
targets.
Oh
right,
I
mean
that's
what
I
want
right,
but
I
want
to
reuse.
A
My
knowledge
I
want
to
reuse
my
tools
when
I'm
in
different
environments.
This
is
a
brief
aside.
Just
I
found
that
a
o-l
image
this
is
like
our
world
is
beautiful.
Isn't
it
let's
just
let
this
soak
for
a
second,
this
says:
discover
ideas
about
blockchain
technology,
email
marketing.
Today's
email
inbox
looks
significantly
different
from
the
AOL
inbox
of
your
make
sure
your
email
marketing
has
grown
with
the
times
tagged
with
blockchain
technology,
business,
innovation
and
Thought
Catalog.
A
So
that's
totally
relevant.
My
point
about
the
cross-platform
thing,
though,
is
it's
like
these
engineering
efforts
to
build
something
that
you
can
actually
use
to
do
that
I
click
a
button
and
I
hit
eight
targets
with
my
deploy:
they're
massive
engineering,
artifacts
coordinated
over
huge
groups
of
people
like
the
program
expertise
experienced
in
this
room.
If
it
was
all
UI
developers,
I
like
we
could
spend
a
year
or
two,
it
might
crank
since
I'm
really
good
at
right.
Like
it,
you
have.
A
Law
scaling
with
the
organization
like
people
are
more
effort
to
coordinate
and
there's
just
there's
a
lot
of
technology
that
you
have
to
cover
to
talk
about
applications
that
are
visually
interactive
right.
So
this
is
an
architecture
diagram.
If
I
can't
see
any
of
the
details,
that's
fine.
This
is
Coco.
Mac
OS
is
application.
Framework
they've
got
2d
animations
in
3d,
transforms,
they've,
got
opengl
and
their
own
windowing
and
drawing
tools.
They've
got
data,
persistence,
they've,
got
text
layout,
rendering
glyph
transformations,
they've,
got
image,
processing,
rendering
etc
got
notifications.
A
You
know,
network
access
via
asynchronous
I/o,
etc.
Here's
some
bit
from
a
newer
Android,
jetpack
framework
listing
they've,
got
data,
binding
lifecycle,
navigation,
pagination,
etc,
etc,
etc,
etc,
and
a
lot
of
these
things
actually
nothing
to
do
with
what's
on
screen
right,
there's
another
interesting
example,
and
obviously
in
this
orbit.
So
it's
like
it's
on
my
mind,
but
flutter
is
a
really
cool
set
of
technologies
built
for
you
know.
Basically,
the
like
I
want
to
write
a
GUI
that
hits
a
targets
at
once
kind
of.
A
One
of
the
ways
they
do
that,
of
course,
is
by
like
hiding
many
details
from
the
platform
from
you
and
I.
Don't
think
that's
very
rustic,
but
it's
a
really
cool
project,
and
it's
this
is
a
good
nice
thing
to
look
at
to
just
say,
like
yeah,
you
really
do
need
all
of
those
things.
If
you
think
about
each
of
those
lines,
that's
like
three
crates
per
box,
at
least
so
you
know
you
might
want
to
to
temper
expectations
if
you
think
that
we're
gonna
have
like
these.
A
Covering
everything
ferment
in
the
future,
there
is
one
caveat
to
this,
of
course,
which
is
like
human
civilization.
Has
this
really
big
project
for
making
UI,
and
it
has
really
cool
properties
like
it-
exposes
stable
public
API?
This
lower
level
than
most
applications
want
to
speak?
It's
been
a
place
for
experimenting
with.
You
know
different
paradigms,
but
it
has.
You
know,
limitations
and
I.
Think
those
limitations
are
fine
right.
It's
the
web
is
good,
but
it's
not
going
to
provide
like
a
rich.
You
know
local
data
oriented
consumer
thing
for
managing
your
life.
A
For
someone
on
a
future
phone,
you
know
on
a
cheap
device
and
the
world
is
made
up
of
a
lot
of
these
people
in
the
web
has
a
difficult
time
addressing
their
needs
right
now
and
I
think
the
other
unfortunate
thing
about
that
is
because
you
can
actually
like
really
cool
rust.
Web
stuff
and
I've
been
prototyping
initially
on
the
web
is
I'm
actually
I'm,
pretty
sure
that
having
our
own
equivalent
is
pretty
far
off
to
the
point
where
I'm
satisfied
with
the
personality,
at
least
I
think
I
should
I.
A
Should
you
know
call
out
some
really
cool
efforts
that
I've
been
happening?
I,
think
druid
and
orb,
DK
and
Azul
are
really
interesting.
Exciting
I
was
a
little
sad
to
see
as
well
wasn't
getting
as
much
maintenance
effort,
but
I
think
these
experiments
and
like
efforts
and
projects
have
to
continue
but
I
like
when
I
think
what
do
I
want
to
build
tomorrow.
When
can
I
start
doing
that,
you
know
they're
they're
pretty
far
off
and
I
think
that
there's
a
different
way,
but
you
know
so.
A
It
is
aspirational
right,
it's
a
long
road,
but
I.
Don't
think
we
need
to
have
our
own
big
projects,
necessarily
I
think
we
can
eventually,
but
I,
think
that
we
can
start
by
focusing
on
how
do
we
make
like
a
rust
native
UI,
but
using
someone
else's
tool?
Kit
right,
you
know
like?
Can
we
make
this
feel
idiomatic
in
the
language?
Can
we
make
it
so
that
we
can
collaborate
on
this
together
and
I?
A
So
you
know,
if
you
look
at
like
the
you
know:
libraries
not
frameworks
methodology,
I,
think
many
of
the
important
ingredients
for
being
able
to
pull
that
kind
of
trick
off
are
here
in
Rus
right
now.
So
my
proposal
is
that
you
know
starting
well
whenever
you
know
yesterday
or
something
that
we
tried
to
build
an
authentic,
you
know
actually
rustic
UI
ecosystem
and
that
we
begin
iterating
on.
A
You
know
that
that
notion
without
having
to
build
our
own
rendering
stacks
and
input
stack
sentiment
stacks,
and
we
also
are
in
really
cool
position
with
futures
and
a
bunch
of
other
language
features.
Allow
us
to
kind
of
natively
Express
UI
concepts
that
other
frameworks
have
to
bring
their
own
special
implementation
for
right.
So
I
think,
there's
there's
a
lot
of
a
lot
of
room
here,
I!
Think.
If
that's
going
to
work,
if
we
can
pull
this
off,
we
have
to
have
code.
A
Reuse
right,
like
that's
like
the
basic
trick,
is
crates
that
IO
lets
us
reuse
code.
We
have
nice
API
as
we
iterate
on
them
separately,
and
you
know,
groups
of
people
can
build
technology
without
like
central
coordination.
Right
UI
is
hard
because
you
have
so
many
domain-specific
and
when
I
see
de
Mannion
really
like
platform
specific
paradigms
to
navigate
and
also
just
like.
Historically,
we've
not
tried
to
do
it.
This
way,
we
don't
have
like
UI
protocols,
as
I
mean
there
have
been
attempts,
but
they
tend
to
get
hidden
underneath
frameworks
anyways.
A
A
Of
people
working
on
compose
I'm
happy
to
say
that
you
know
we're
not
just
copying
impose,
but
I
was
really
surprised
actually
to
find
out
after
I've
been
working
on
this
for
months
when
I
talked
to
him
and
I.
So
you
know
once
I
joined
to
Google
and
I
got
to
talk
to
him
about
it
after
they'd,
open
source
to
etcetera,
I
was
really
impressed
to
find
out
like
oh
actually,
if
you
want
to
describe
UI
in
this
declarative
style,
there's
you
know,
there's
a
lot
of
commonality
in
the
problem
set
for
the
language
anyways.
A
That's
all!
That's
neither
here
nor
there,
on
top
of
Moxie
I'm
working
on
this
library
right
now
called
Moxie.
Dom
I
have
a
couple
of
other
like
binding
bindings
in
progress
that
I'm
tinkering
with,
but
this
is
the
most
mature
it's
what
I
can
demonstrate.
So,
let's
look
at
an
example
of
a
counter
implemented
for
the
web
in
Moxie
Dom
right,
we
have
a
struct.
A
Structs
fields
are
like
their
arguments
right,
so
the
campus
doesn't
ache
any
arguments
and
we
have
some
content.
So
we're
going
to
show-
and
the
first
interesting
thing
here
is
that
this
is
going
to
this-
describes
our
UI
right
now
right.
The
function
needs
to
be
able
to
run
at
anytime
and
fully
fully
explain
to
the
underlying
system.
What
should
be
on
the
screen?
So
first
is.
A
We
need
some
persistent
state
to
stick
around
in
between
these
iterations
of
our
render
loop
right,
we're
gonna
initialize
that
with
a
default
0
and
the
type
that's
returned
here
is
actually
like
a
handle
to
that
state
variable
and
you
can
update
it.
You
can
read
from
it.
The
updates
are
mediated
by
the
runtime,
though,
to
make
sure
that
we
have
the
scheduling
properties
we
need,
and
then
you
know
we
have
some
child
components
that
we
show.
A
So
first
we
create
a
text
node
with
the
counts
of
the
current
state
variable
and
that
state
variable
by
the
way
you
know
in
future,
iterations
that
have
occupied
that'll,
have
the
new
value
and,
and
then
we
make
a
HTML
element
type
this.
You
know
you
if
you
had
JSX
this
would
be
much
nicer.
We
don't
have
that
yet,
and
then
we
have
an
event
handler
right.
B
A
A
The
first
half
of
the
buzzword
soup
is
worth
talking
about
right.
So,
like
rust
is
platform
agnostic,
we
aren't
adding
platform
into
the
core.
Runtime
take
minimal
dependencies
and
I.
Think
the
focus
on
latency
is
the
other
thing
here
and
because
rust
is,
you
know
like
we're
fast
right,
but
we
can
can
in
our
software
aggressively
optimize
for
the
user
experience
and
have
more
empathy
for
people
interacting
with
the
software.
A
Let's
just
talk
about
you
at
runtime
right,
so
a
UI
runtime
does
some.
You
know
basic
stuff.
It
presents
a
tree.
A
visual
items.
Input
is
accepted
from
some
actor
user.
Whatever
the
items
are
updated.
This
is
done
frame
by
frame
as
like
a
unit
of
discrete
scheduling
and
done
in
a
loop,
so
you've
got
kind
of
an
implicit
while
true
loop
outside
wrap
right.
Some
some
frameworks
obviously
make
you
write
that
yourself.
A
So
if
you
have
like
a
traditional
UI
system
that
has
like
Model
View
model
new
controller
architecture,
you
know
you
might
find
that
you
have
this
tree,
that
you
create,
and
then
you
write
some
code
so
that
when
events
occur,
you
manually
poke
at
that
tree
right
and
the
the
tree
carries
over.
Of
course,
you
know
this
crowd.
I
think
is
probably
well
versed
in
the
evils
of
persistent
shared
mutable
state.
A
This
tends
the
mutability
tends
not
to
be
too
shared,
although
you
can
have
fun
things
when
it
is,
but
still
it's
cumbersome
and
it
doesn't
let
you
do
what
we
really
want,
which
is
to
describe
UI
right
now,
this
moment,
I'm.
What
does
user
see
and
I
think
this
is
a
really
interesting
framing,
because
it's
human
focused
as
opposed
technology,
focused
right.
A
You
actually
have
to
do
a
very
sophisticated
dance
to
show
the
program
like
this,
but
one
of
the
nice
things
about
it
is
that
it,
you
know
each
item
on
the
screen
corresponds
to
something
that
you're
looking
at
in
your
code
right.
So
one
of
the
first
attempts
to
do
the
like
describe
UI
right
now
in
completion
was
the
like
the
in
GUI
type
of
library
right.
So
these
fully
describe
the
scene
on
every
frame
they
run
60
times
a
second.
They
take
your
input.
A
You
know
you
write
very
nice
concise
code,
especially
if
you're
coming
from
like
C++
model-view-controller
land
render
some
stuff.
They
can
only
work
if
you
have
a
target
that
takes
a
GPU
vertex
buffer.
Basically,
right
like
you
have
to
actually
draw
every
triangle
yourself,
and
so
some
really
really
smart
people
came
along
and
we're
like.
We
want
to
do
that.
I,
don't
know
if
this
is
actually
the
history,
but
like
we're
gonna
pretend
this
is
like
I
had
like
a
galleon
dialectic
these.
These
people
came
along
and
we're
like.
A
If
things
you
know
miss
the
frames
etc,
and
so
they
said
I
want
to
describe
this
UI
like
this,
but
backed
by
stateful
elements
right
these
persistent
things
and
that's
where
react
comes
in
so
there's
tilde
here,
because
react
is
actually
very,
very
interesting
in
many
of
its
own
ways,
and
this
is
a
horrible
abusive,
like
architecture
and
terminology.
But
basically
you
have
a
state
store.
You
accept
some
event.
A
You
get
state,
prime,
because
some
event,
you
know
some
transition
is
caused
by
that
event
that
gets
committed
the
renderer
there,
the
runtime
schedules,
a
new
render
call
and
that
generates
a
tree
of
virtual
Dom
objects.
If
you're
familiar
with
this.
Basically,
it's
like
lightweight
descriptions.
It's
it's
a
hash
map
of
hash
maps,
of
hashmat
hash
maps
of
the
strings,
to
write
to
the
Dom.
Basically
right,
that's
all
allocated
by
the
way.
A
If
you
want
to
think
about
the
the
GC
performance
on
that
and
and
then
what
it
does
is
extremely
cleverly
goes
and
figures
out
the
difference
between
your
your
description
and,
what's
actually
out
there
right,
this
persistent
state
that
it's
storing
for
you,
and
so
it's
kind
of
it
owns
the
state.
It
owns
the
backing
dom
tree
and
your
kind
of
your
code
is
running
in
between
them
and
the
runtime
keeps
them
updated
right.
So.
B
A
Kind
of
like
a
declarative,
UI
runtime
is
it's
managing
these
updates.
It
lets
you
do
fun
things
like
you
can
see
here.
We
have.
You
know:
chrome,
dev,
tools
like
these
are
divs
they're,
just
they're
from
the
browser's
perspective
they're,
like
any
other,
but
you
know
you're
writing
codes.
It's
like
it's
fake
XML
in
JavaScript
and
I'm
flying
a
million
miles
a
minute
and
I
mean
if
you
haven't
written
JSX,
it
actually
is
like
it's
surprisingly.
A
Productive
I
was
going
outside,
and
so
if
this
is
kind
of
the
the
status
quo
like
this
is
the
bleeding
edge
of
here's.
How
you
program
UI
effectively
we
can.
We
can
identify
our
own
goals
on
top
of
this
right,
so
rust
is
harder
to
write
in
JavaScript
or
C,
sharp
or
other
languages
right,
maybe
not
for
me
now
with
you
know,
haven't
been
it
for
a
while
and
I
think
like
over
time.
A
We
will
continue
to
iterate
on
this
on
the
rust
tax
so
to
speak,
but
right
now
we
need
to
find
ways
to
invest
that
right
like
if
we
want
to
write
UI
today.
We
can't
wait
for
next
year's
language
changes
and
I
think
that
we
have
a
few
areas
of
strength
for
rust
and
for
that
one
were
incredibly
latency.
Sensitive.
All
of
our
resource
allocation
and
destruction
happens
in
bandwidth
logic,
it
executes
unless
we
explicitly
shove
it
out
of
band.
A
We,
you
know,
have
extreme
control
over
the
amount
of
interaction
we
we
implant
and
you
know
we're
pretty
portable.
So
this
is
where
kind
of
this
the
direction
takes
us
right.
We
want
to
work
directly
with
these
dom
nodes
right,
we
can
have,
we
can
roll
broad
pointers
were
rust
and
we
want
to,
you
know,
allocate
only
the
data
that
needs
to
be.
You
know
inserted
into
them
and
we
want
to
do
this
using
some
kind
of
uniform
storage.
A
So
there's
not
like
a
you
know,
a
uncanny
valley
or
no
cognitive
cliff
between
you
know,
user,
controlled
state
and
then
the
runtime
controlled
state
of
the
host
tree,
and
so
ideally
you
know
we
can
just
have
this
happen
in
a
loop
right,
and
these
memorized
updates
are
minimal
and
perfect,
etc.
How
do
we
do
that?
Well,
we
need
to
describe
trees.
A
Functions
if
you
squint
execute
over
time
as
a
tree,
maybe
maybe
I
mean
you
know,
you
know
where
I'm
going
so
we're
gonna
I'll,
show
you
what
we
do.
We
have
these
functions
and
we're
gonna
pretend
that
when
you
push
the
stack
frame
for
that
function
onto
the
stack
that
allocates
a
node
in
the
tree,
weird
I
know,
and
then
the
other
thing
we're
going
to
pretend
is
that
indent
finds
our
depth
in
this
tree
and
indents
the
print
line.
A
Accordingly,
pretty
simple
assumptions:
I
think
anyone
confused
awesome-
and
here
we
go
so
we
enter
route.
We
created
a
root,
node
stack
frame
where
we
create
a
node
for
the
root
stack
frame,
and
then
we
go
to
the
first
line
and
we
have
a
side-effect
function.
This
all
looks
like
normal
programming
right
and
then
a
you
know:
it's
called
by
root,
so
it
becomes
a
child
root
and
we
enter
its
stack
frame
and
then
we
call
side-effect,
because
this
is
now
a
child
of
root.
A
It
has
a
depth
of
one
in
the
tree,
so
it's
been
invented
by
a
couple
of
spaces
and
we
pop
back
out
to
root
right.
This
is
this,
is
this
is
control
flow
101,
do
the
same
for
be
great
stack
frame?
Has
a
node
of
corresponding
has
a
side
effect
to
a
function
inside
and
then
we
enter
loop.
The
first
one
is
a
child
here.
A
Same
thing,
second
call
becomes
a
child
of
the
same
type,
but
you
know
specialized
for
that
that
index
in
that
loop-
and
you
know,
then
the
same
thing
right.
So
what
we
end
up
with
is
you
know
we
call
a
few
functions
and
if
we
had
some
magical
system
for
observing
the
creation
of
the
stack
frames
and
recording
that
data
at
runtime,
we
correlate
them
together
to
actually
construct
this
tree
and
that's
what
the
topo
crate
does
so
the
toe
pose,
like
the
you
know,
scary
low-level
dependency
for
moxie.
A
It
assigns
you
know,
runtime
identifiers,
to
kind
of
logical
scopes
or
stack
frames
of
topologically
bound
functions.
That's
it.
Let's,
you
do
what
I
just
showed
you
and
these
IDs
are
unique.
So
if
you're
like
in
a
conditional
or
you're
in
a
for
loop,
you
know
we're
tracking
the
runtime
state,
so
you
can
kind
of
just
put
the
calls
to
these
functions
wherever
and
you
know
the.
A
If
you
want
to
get
a
little
more
technical,
you
know
we
trace
the
path
through
the
the
the
function
topology
to
the
current
point
and
do
some
hashing
along
the
way,
and
that
gives
us
this
unique
ID
and
because
it's
derived
from
this
structural
path
right
on
each
iteration
of
this
loop.
That
idea
is
stable
right.
A
So,
if
I
were
to
query
the
ID
for
C
sub
one
on
revision
0,
it
would
be
the
same
as
revision,
1,
etc,
etc,
etc,
because
C
sub
1
only
like
I
can
only
talk
about
it
from
within
that
function.
While
it's
executing-
and
it
has
this
stable
identifier
right,
so
you
can
do
fun.
Things
like
have
a
hash
map
of
toko
ID
to
blah,
and
then
that's
call
site,
specific
storage
right
and
then
this
tree
has
to
get
managed
right
like
we
have
to
do
this
in
a
loop
repeatedly.
A
So
there's
this
moxy
runtime
struct.
It
takes
a
root
function
that
it
calls
on
each
iteration
and
it
can
be
woken
up
by
state
changes.
That's
basically
it
it
provides
a
memoization
store
for
the
for
this,
like
you
know,
incremental
updates
of
the
Dom
stuff,
and
you
know
really
what
happens
is
everything
is
in
there
all
the
stuff
you
care
about,
and
frankly,
you
in
this
context
is
not
like
an
end
user.
The
runtime
shouldn't
really
be
exposed
by
bindings
like
moxie.
A
B
A
Not
on
a
simple
thread:
I
mean
not
literally
react
so
anyways.
We
we
create
this
environment.
That's
scoped
to
this.
This
topology
we
run
functions
within
it
that
have
side
effects.
Some
of
those
side
effects
might
register
event
handlers
that
can
update
our
state.
That
will
call
when
that's
updated.
It
will
get
scheduled
again.
A
There's
an
analogy
here,
that's
worth
thinking
about
if
you're
familiar
with
react.
This
is
basically
like
what,
if
you
made,
react
and
rust,
but
only
use
context
and
hooks
as
the
primitives
I
think
I,
it's
fun,
I
think,
but
also
this
means
that
you
know
you
can
I
haven't
done
this
yet,
but
you
can
like
react
hooks.
Imagine
an
ecosystem
of
you
know
kind
of
drop-in
functions
that
will
navigate
this
state,
updating
with
your
runtime
for
you
without
needing
to
explicitly
past
those
now
one
trick
here
is
as
I've
described
it.
A
A
We
already
have
you
know
this
like
call
site,
sensitive
tracking
of
where
and
the
component
tree
we
are,
that
gives
us
IDs.
We
can
have
global
scope,
storage
that
can
be
read
from
anywhere,
but
where
you
can
only
look
at
things
that
are
corresponding
to
our
area,
so
you
can
do
things
like
run
a
function
as
long
as
the
inputs
haven't
changed
and
that
will
be
kept
around
for
the
next
iteration
of
loop.
A
So
you
kind
of
rendezvous
with
yourself
with
your
own
code,
the
next
time
and-
and
you
can
combine
these
of
course-
Rex-
it's
just
less
code,
so
you
can
have
a
memo,
call
that
captures
some
variable
and
will
rerun
the
provided
closure.
Whenever
that
variable
changes,
you
can
say,
as
long
as
this
component
is
mounted
I
want
this
content
to
be
identical
right
like
never
rerun
this,
and
the
fun
corollary
here
is
that
if
you
implement
drop
on
these
types,
when
there's
no
longer
referenced,
we
G
see
them
from
the
memoization
store.
A
So
you
have
like
a
frame
resource
collection
process
that
happens
after
each
root,
and
this
means
you
can
have
essentially
avoid
like
a
whole
class
of
I,
implement
a
custom,
will
unmount
method
or
did
unmount
or
whatever
right
lots
of
lots
of
lifecycle
methods
on
traits.
Can
just
evaporate
the
state
that
I
pointed
out
in
that
really
counter.
A
Okay,
that's
herd
immunity,
I'm
going
it's
a
clone.
It's
a
it's
an
app,
that's
very,
very
simple:
that
people
clone
a
lot
in
order
to
demonstrate
their
framework.
So
of
course,
if
you're
making
a
new,
weird
UI
runtime,
it
would
be
a
straightforward
thing
to
copy
and
it
has
CSS
available.
That's
like
one
of
the
big
things.
So
here
we
have
a
top-level
struct.
This
is
our
root
component,
that
to-do
app
and
like
the
few
app
has
too
many
jobs
right.
A
It
has
a
list
of
to-do
items
and
it
has
a
filter
that
applies
to
those
to
render
them.
So
we
allocate
this
at
the
top
and
then
we
enter
a
topological
call.
You
can
have
like
this
is
like
a
topological
closure,
maybe
sort
of
we
can
show
an
element
and
CSS
class
and
run
child
component.
That's
a
custom
struct
same
with
the
main
section.
This
is
code
I
copy
from
github,
and
then
we
exit
and
crucially,
we
pass
to
this
topological
closure,
a
scoped
environment.
A
So
it
can
look
up
these
types
in
its
environment
when
it's
called
right,
and
so
we
pass
this
key
to
the
to
do's.
Like
hey,
everybody
in
this
subtree
is
going
to
care
about
the
state
of
dues
in
this
application.
So
now
it's
provided
to
all
of
them
and
the
same
with
the
visibility,
filter
and
Google
slides
gonna
make
me
click
like
twelve
more
times,
but
so
this
is
basically.
This
is
the
top-level
entry
point
of
the
app
it's
like.
A
A
In
smart
at
a
time,
so
let's
look
at
it
to
do
list
example.
Here
we
get
our
two
dues
get
our
visibility.
We
create
an
unordered
list,
we
filter
which
to
do
is
we
want
to
show
and
we
loop
over
them.
So
if
you've,
if
you've
written
collections
and
other
like
declarative
systems,
it
can
be
quite
baroque,
I
think
it's
pretty
cool.
Also
a
filter
list
is
usually
something
big
to
build
in
any
in
any
system,
and
we
can
do
you
know
quick
demo
of
how
this
works
in
this
gonna
play
for
us.
A
A
A
If
you
want
to
be
a
part
of
this
and
you
want
to
use
it
then
send
PRS
so
like
right
now
the
domnode
memoization
is
working
progress.
It's
like
I
can
keep
the
whole
tree
static,
but
I
lose
that
one
thing
and
I
don't
know
why,
and
so
there's
a
little
bit
work
there
and
once
that's
in
place
it'll
be
easier
to
extend
that
to
other
backing
UI
systems
right
cuz,
this
minimization
is
very
generic,
doesn't
know
anything
but
the
phone
I'm
not
measuring
performance
in
any
meaningful
way.
I
do
know
on
my
old
system.
A
A
Wink-Wink
nudge-nudge
get
really
really
fast,
dachshund
testing
very
much
working
progress,
there's
no
JSX
or
equivalent
if
Bodil
wants
to
make
type
HTML
at
this
I'd,
be
super
happy,
there's
no
cross-platform
elements
and
I'm
not
going
to
attempt
them
anytime
soon,
because
I
think
that
if
you
have
a
rest
system
that
can
describe
native
UI
components
with
the
same
runtime
life
cycle,
you
can
abstract
over
those
to
get
cross-platform
components,
as
opposed
to
like
existing
cross-platform
systems.
That
tend
to
you
know,
manage
the
things
directly
and,
of
course,
there's
nothing.
A
A
Build
your
wine
run
like
you
want
to
build
apps.
We
want
to
do
together
and
not
be
fragmented
into
a
million
different
little
projects.
This
is
what
happens
happen.
So
the
repo
I
have
a
website
that
I'm
working
on
publishing
will
be
up
soon.
Qr
code
takes
you
to
the
discord.
If
you
want
to
come
chat
with
me,
I
get
pinged
on
every
message
right
now:
yeah
I.