►
Description
Bringing WebAssembly to the .NET Mainstream - Steve Sanderson, Microsoft
Many developers still consider WebAssembly to be a leading-edge, niche technology tied to low-level systems programming languages. However, C# and .NET (open-source, cross-platform technologies used by nearly one-third of all professional developers [1]) have run on WebAssembly since 2017. Blazor WebAssembly brought .NET into the browser on open standards, and is now one of the fastest-growing parts of .NET across enterprises, startups, and hobbyists. Next, with WASI we could let you run .NET in even more places, introducing cloud-native tools and techniques to a wider segment of the global developer community. This is a technical talk showing how we bring .NET to WebAssembly. Steve will demonstrate how it runs both interpreted and AOT-compiled, how an IDE debugger can attach, performance tradeoffs, and how a move from Emscripten to WASI SDK lets it run in Wasmtime/Wasmer or higher-level runtimes like wasmCloud. Secondly, you'll hear lessons learned from Blazor as an open-source project - challenges and misconceptions faced bringing WebAssembly beyond early adopters. [1] StackOverflow survey 2021
A
A
I've
been
working
with
this
and
focusing
on
it
professionally
for
about
five
years
now,
and
I
am
pretty
convinced
that
the
majority
of
the
potential
of
this
technology
still
lies
ahead
of
it,
and
the
people
in
this
room
are
probably
going
to
be
some
of
the
key
people
to
unlock
that
now.
Speaking
of
the
people
in
the
room
and
those
people
watching
the
live
stream,
I
know
that
many
of
you
are
technology
creators
or
influencers
innovators.
A
Perhaps
you
run
open
source
projects.
Maybe
you've
got
a
startup
in
this
space,
so
you
would
consider
doing
that
in
the
future,
and
you
probably
want
your
technology
to
reach
and
appeal
to
a
wide
audience
the
widest
audience
you
can.
You
probably
want
to
go
beyond
just
the
rust
community
and
the
assembly
script
developers.
You
probably
want
to
make
your
stuff
appeal
to
the
really
big
technology
communities.
So
I'm
talking
things
like
java
javascript.
A
And
that's
what
we'll
talk
about
I'll
show
you
a
bunch
of
examples
of
stuff
we
have
done
and
we'll
do,
but
just
before
we
get
to
that.
I
know
that
not
everyone
here
will
have
used.net.
So
I
do
need
to
just
spend
the
first
one
or
two
minutes
just
giving
you
a
quick
recap
of
what
dot
net
is.
Otherwise
this
might
not
make
sense
to
everyone.
So
net
is
a
general
software
platform
from
microsoft,
which
consists
of
a
bunch
of
different
pieces.
A
One
of
those
pieces
is
the
languages.
You
will
have
heard
of
c
sharp.
I'm
sure
you
might
have
heard
of
f
sharp,
there's
various
other
languages
that
all
compile
to
this
common
bytecode
format
for
net,
which
runs
inside
the.net
runtime,
and
that
brings
additional
services
like
garbage
collection,
just
in
time,
compilation
and
so
on,
and
if
you
are
a
java
developer,
this
might
look
like
a
very
familiar
arrangement,
because
it's
pretty
much
the
same
kind
of
managed
code
structure
and
then
there
are
various
frameworks
built
on
top
of
all
this.
A
Now
you
might
have
heard
of
something
called
net
core,
but
what
is
net
core?
And
how
does
that
fit
into
this?
Well
in
about
2014
2015?
We
completely
reinvented.
All
of
this
like
we
rewrote
it
almost
from
scratch.
That's
when
net
became
fully
cross-platform
and
open
source,
and
it
was
such
a
big
change
that
we
gave
it
a
new
name,
dot
net
core,
which
was
nice
and
then
after
a
few
years
we
thought
hang
on
a
minute.
What
were
we
thinking?
A
That's
a
terrible
name
like
dot
net
was
already
a
dubious
name
and
just
adding
a
random
word
to
it
turns
out
doesn't
actually
help.
So
we
thought
okay,
let's
just
scratch-
that
out,
pretend
it
didn't
happen,
we'll
go
back
to
calling
it.net
again.
So
you
know
we're
great.
At
naming
in
microsoft,
we've
gone
back
to
dot
net.
Now
it's
nice
and
simple,
except
if
you
use
asp.net
core,
because
that
is
keeping
the
word
core
for
reasons
that
nobody
knows
or
will
talk
about.
Okay,
so
that's
dubious
naming
but
good
technology
behind
that.
A
So
speaking
of
the
technology,
there's
still
some
prevalent
myths
about.net.
I
just
need
to
dispel
a
few
myths.
So,
yes,
modern.net
really
is
open
source,
it's
mit
licensed
it
has
been
for
years
and
it
really
is
cross-platform.
You
can
develop
on
windows,
mac
or
linux
and
deploy
to
any
platform
that
you
want
to,
and
quite
a
lot
of
people
do
so,
according
to
the
stack
overflow
survey
last
year,
around
three
and
ten
professional
developers
globally
are
using.net.
So
it's
a
lot
of
people
now
I
am
not
trying
to
sell.net
to
you
here.
A
I
don't
care
at
all
whether
you
like
it
or
not.
I'm
simply
trying
to
make
the
case
that
this
is
a
large
developer
community
and
that
microsoft
does
a
lot
of
work
to
make
the
performance,
reliability
and
simplicity
good,
because
we're
interested
in
technologies
that
will
appeal
to
wide
audience,
but
mainly
we
want
to
talk
about.net
and
webassembly.
A
So,
let's
think
about
that
for
a
minute,
and
you
can
kind
of
split
this
space
into
two
parts,
you
can
think
about
the
stuff
that
we've
already
done
up
until
now
and
then
the
stuff
that
we
might
do
in
the
future.
Now
the
main
thing
that
we've
done
up
until
now
is
this
thing
called
blazer
webassembly,
so
blazer
is
a
uiframeworkfor.net
and
it
was
originally
designed
to
run
in
the
browser
on
webassembly.
A
We
started
the
first
prototype
in
about
2017,
so
that's
just
when
webassembly
came
on
the
scene
and
it's
been
supported
in
production
since
2020,
and
it
allows
you
to
do
the
sort
of
thing
that
you
would
do
with
another
frame,
a
front-end
framework
like
vue
or
react
or
angular,
but
with
dotnet
inside
a
browser,
and
it's
going
very
well,
it's
a
popular
part
of
dot
net.
In
fact,
it's
one
of
the
fastest
growing
parts
of
net
and
has
been
for
some
years,
and
I'm
going
to
show
you
more
about
how
that
works.
A
A
It
happens
to
be
communicating
with
grpc
grpc
web
in
this
case
and
it's
getting
some
data
from
a
back-end
server
and
that's
the
sort
of
thing
that
people
want
to
do
and
if
I
go
over
onto
this
inventory
screen
you'll
see,
we've
got
a
nice
big
grid
which
makes
sense
because
you
know
most
business.
Applications
are
built
out
of
big
grids,
and
this
really
is
a
big
red.
We've
got
100
000
items
in
there
and
the
performance
is
really
nice.
A
I
can
just
scroll
to
any
point
in
that
entire
hundred
thousand
items-
and
it
just
comes
up
instantly,
and
that
is
possible
because
we've
got
all
the
data
inside
the
client
here.
So
we've
not
only
got
net
running
on
webassembly.
We've
also
got
sqlite
compiled
to
webassembly
running
inside
the
browser
too,
and
they
can
communicate
with
each
other
instantly,
which
means
that
we
get
very
fast
performance
so
like,
as
I
start
typing
you
see,
you
know,
queries
are
resolving
on
every
keystroke
filtering
is
us
sorting.
His
instant
filtering
is
like
super
fast.
A
We've
got
60
frames
per
second
of
filtering,
as
I
do
that,
and
that's
all
very
nice.
So
people
are
feeling
good
about
that,
they're
being
nice
and
productive.
Let
me
show
you
a
little
bit
of
some
code.
That's
going
on
behind
there,
so
I've
got
a
few
different
things.
I'm
certainly
not
going
to
go
through
every
line
of
this
because
you
know
there's
a
lot
in
there.
So
I've
got
this
central
server
project,
that's
asp.net
core.
A
On
the
back
end,
I
would
say
most
people
who
use
blazer
web
assembly
probably
are
using
net
on
the
server
as
well
as
on
the
client
you
don't
have
to,
but
it's
pr,
probably
the
most
productive
arrangement.
This
full
stack,
because
if
you've
got
the
same
technology
on
both
ends
of
the
wire,
then
well,
you've
only
got
to
think
about.
One
thing,
but
also
it
means
that
we
can
share
code.
We
can
share
our
domain
model
types
and
we
can
pass
data
between
server
and
client
without
any
friction.
So
people
generally
tend
to
do
that.
A
Then
I've
also
got
this
manufacturing
hub
project
here,
that's
the
actual
blazer
webassembly
application
and
there
are
two
main
types
of
files
in
this
project,
so
the
first
type
is
c
sharp,
and
you
know
this
is
my
program
cs.
This
is
where
my
application
starts
up
and
it
configures
all
the
services
and
stuff
in
there.
A
So
general
c-sharp
is
going
to
work,
but
also
the
other
main
type
of
file
in
these
projects
are
these
razer
files
and
razer
is
our
syntax
for
being
able
to
have
markup
as
well
as
c-sharp,
and
that's
how
we're
rendering
a
web
ui
now
the
actual
application
architecture
of
a
blazer
application
is
basically
the
same
as
all
other
front-end
frameworks.
So
you
know
things
like
vue
and
svelt
and
react
they've.
Basically,
all
ended
up
with
the
same
kind
of
component,
oriented
architecture
and
blazer
is
no
exception.
A
It's
pretty
much
the
same
kind
of
way
of
structuring
an
application
and
then,
in
terms
of
actually
running
this
in
a
browser,
you
might
think
that
we're
compiling
c-sharp
to
webassembly.
Well,
we
can
do
that,
but
that's
not
actually
what
we
do
by
default.
It's
not
what
what
we
do
in
development
in
development,
we're
using
an
interpreter
where
we
compile
the.net
to
regular.net
assemblies
and
then
run
them
on
a
runtime
that
itself
is
compiled
to
webassembly
and
to
show
you
that
I'll
go
into
my
browser
network
tag.
A
Tab
and
we'll
have
a
look
for
dlls
and
you'll
see
that
I've
got
a
bunch
of
dlls
in
there.
In
fact,
I've
got
an
enormous
number
of
dlls
loads
of
them,
and
that
is
because
this
is
a
development
build
where
we
optimize
for
compile,
speed,
developer
experience
is
key
here,
so
we're
not
doing
any
code
stripping
in
development.
A
We
just
dump
everything
in
there
and
these
are
normal
dlls
produced
by
the
c
compiler,
which
is
very
fast.
It
can
build
something
like
this
in
a
second
easily
and
then
to
actually
execute
them.
We've
got
the.net
runtime
compiled
to
webassembly
and
in
a
production
build
that
file
can
be
as
small
as
about
300
kilobytes.
A
We've
done
a
lot
of
work
to
optimize
that
now
there
is
another
execution
mode
for
blazer
web
assembly,
which
is
ahead
of
time,
compilation
where
we
do
compile
all
the
c-sharp
through
to
webassembly
bytecode,
and
that
allows
the
application
to
run
a
lot
faster,
but
at
the
cost
that
the
build
time
is
also
quite
a
bit
longer.
So
we
don't
want
to
do
that
while
people
are
actually
developing
okay.
So
what's
the
product
goals
for
this
sort
of
thing,
what
are
we
trying
to
achieve?
A
A
It's
about
bringing
the
full.net
experience,
and
that
includes
things
like
the
c-sharp
language,
but
it
also
involves
all
of
the
tooling
when
you're
working
with
a
mass
market
developer
audience,
they
know
what
tools
they
like
and
they
want
to
keep
using
them
and
they're
not
going
to
accept
some
new
tools
that
you
make
up.
So
we
need
to
make
all
the
existing.net
tooling
the
debugger
trimming
system,
hot
reload.
They
all
have
to
work,
but
also
critically
the
entire
package
ecosystem
people
expect
that
it
can
use
any
package
they
want
and
they
won't
be
happy.
A
If
you
tell
them
they
can't.
We
couldn't
call
this.net
if
you
couldn't
use
the
whole.net
package
ecosystem,
just
like
you
couldn't
call
something
go
or
python
if
it
didn't
support
the
corresponding
package
ecosystem.
For
that
and
the
net
result
is
that
people
get
to
build.
These
full
stack
applications
with
net
on
both
sides
of
the
wire,
and
I
think
that
the
same
approach
could
work
for
other
technologies
too.
You
could
easily
imagine
having
python
on
both
ends
of
the
wire
for
for
web
development,
and
that
would
be
productive.
A
Okay,
so
I've
been
really
focused
on
developer
experience.
So
far.
So,
let's,
let's
experience
that
ourselves.
Let's
have
our
own
little
developer
experience
right
now.
Shall
we,
let's
imagine
that
we
find
some
bug
in
this
application,
I'm
going
to
just
open
something
like
this
rocket
motor
here
and
you
can
see
that
at
the
bottom
there
it's
got
this
little
cost
calculator
and
as
I
change
it,
it
tells
me
the
price
for
different
numbers
of
units.
A
But
let's
say
someone
reports,
a
bug
and
they
say:
hey
did
you
know
you
can
have
a
negative
number
of
items
with
a
negative
price,
that's
kind
of
absurd!
Isn't
it
and
you
think,
all
right,
fine,
yeah,
I'm
going
to
fix
that
most
developers
at
this
point
are
going
to
start
reaching
for
a
debugger,
but
can
we
debug
c-sharp
when
it's
running
inside
a
browser
on
webassembly?
Yes,
we
can
that's
important.
A
It
wouldn't
be
much
of
a
developer
experience,
otherwise,
so
to
get
into
the
debugger,
I'm
going
to
press
a
magic
hotkey
shift,
alt
d,
and
when
I
do
that
a
browser
dev
tools
window
is
going
to
appear,
and
this
is
the
normal
chromium
dev
tools
which
you
all
seen
before
you
all
know
and
love
it.
It's
got
javascript
and
css
and
stuff,
but
because
this
is
blazer
webassembly,
it's
also
got
all
of
my.net
application
files.
For
example,
I've
got
my
c-sharp
sources
here
in
the
browser.
A
I've
also
got
all
of
these
different
razer
files,
and
I
happen
to
know
that
this
stock
label
pop-up
thing
here
is
rendered
by
this
part
details
raiser
file
and
I
also
look
through
it
and
I
see
okay.
This
is
where
we
get
the
cost
statement
the
formatted
cost.
So
I'm
going
to
drop
a
break
point
right
there
in
the
middle
of
my
razor
file.
A
And
then,
if
I
go
back
over
here
and
change
this
number,
we
will
hit
our
breakpoint
inside
the
browser
and
I
can
just
start
stepping
through
the
evaluation
of
my
ui
and
right
into
the
c.
Sharp
code
that
is
behind
there
and
we
can
see
okay,
so
here's
the
bug.
Oh,
it's
fairly
clear
that
there's
a
bug
here.
It
does
nothing
about
the
fact
that
there
might
be
a
negative
price.
So
should
we
fix
that,
then,
let's
go
into
our
code
editor,
let's
just
reorganize
the
screen
a
little
bit!
A
I'm
going
to
want
this
and
this
so
there
we
go
it's
kind
of
difficult
to
see
when
you've
got
such
a
small
font
or
such
a
big
font.
But
remember
we've
just
seen
that
there's
a
file
called
part
cs
which
contains
this
code
here
and
I
want
to
fix
it.
So
I'm
going
to
say
if
quantity
is
less
than
one
I'm
going
to
return,
not
applicable,
okay
and
then
I
hit
save
and
when
I
do
hit
save
what
we
should
see
in
the
browser.
Is
it
immediately
just
changes
to
say
not
applicable?
A
So
this
is
the
hot
reload
system,
it's
kind
of
standard
in
the
javascript
world,
but
it's
not
so
standard.
When
you
talk
about
running
stuff
in
webassembly,
we
had
to
do
quite
a
bit
of
work
to
enable
that,
but
now,
when
I've
got
a
negative
value,
it'll
say
not
applicable
and
for
positive
values.
It'll
give
us
the
right
numbers.
A
Now
you
might
think
that
net
on
webassembly
is
already
a
solved
problem,
because
you
know
I
just
was
doing
it
right
there
in
the
browser
it
was
working,
so
we
can
just
go
home
right,
but
no.
The
way
that
we
compile.net
to
or
run.net
on
webassembly
in
a
browser
is
not
suitable
for
yz
environments,
because
the
current
technology
is
built
on
scriptin,
which
is
designed
for
producing
browser
builds
of
stuff
and
importantly,
emscriptum
works
by
making
calls
into
javascript
all
of
the
system.
A
Apis
are
mapped
into
javascript
apis,
which
is
no
good
in
a
wazi
environment,
because
you
know
there's
no
javascript
in
a
wazi
environment,
so
we've
started.
Looking
at
a
new
experimental
way
of
building.net
to
running
webassembly
based
on
the
wazi
sdk,
and
when
you
build
something
with
that,
it's
much
simpler,
you
just
get
a
single
file
that
comes
out
of
it
and
it
does
not
rely
on
javascript.
A
So
let
me
show
you
our
new
experimental
sdk
and
I'm
going
to
go
over
to
a
console
here
and
I've
got
an
empty
directory
and
this
is
in
linux,
but
it
would
be
exactly
the
same
if
I
was
in
windows
or
mac.
So
you
don't
really
need
to
worry
about
the
operating
system
and
we'll
start
by
doing
the
simplest
thing
we
can
and
in.net.
A
The
simplest
thing
probably
is
a
console
application,
so
I've
created
one
of
those
and
in
case
you
don't
know
what
files
are
in
a.net
console
application,
I'll,
open
up
an
editor
and
when
we
get
in
there,
we
should
see
that
there
are
two
files
in
there.
We've
got
the
cs
proj,
which
configures
the
compilation.
We
don't
need
to
care
about
that
and
then
we've
got
program
cs,
which
is
just
going
to
print
hello
world.
A
So,
let's
run
that
dot
net
run
and
that
will
compile
the
application,
restore
its
dependencies
and
stuff
and
print
out
hello
world
very
good.
Let's
just
change
it
to
display
a
little
bit
more
info,
so
I'm
going
to
display
the
current
time
in
utc
and
the
current
os
architecture,
and
I
can
go
and
do
a
net
build
because
you
can
build
separately
from
run.
If
you
want
to
you,
don't
have
to
then,
when
I
do
a
net
run.
A
A
So
let's
just
copy
that
path,
and
then
I
can
run
it
on
any
wazi
runtime
environment.
So
I'm
going
to
start
with
wasm
time,
which
I'm
sure
many
of
you
know
about
or
even
work
on,
and
so,
if
I
run
that
file
now
it
will
work
exactly
like
you
expect.
We've
got
the
time
and
the
architecture
is
now
wasm
and
this
is
wazi
compliant.
A
I
can
run
it
on
a
different
wasm
runtime
if
I
want
to
such
as
wasma,
and
if
you
really
need
convincing
that
this
is
standard,
I
will
dump
all
of
the
imports
from
my
wasm
file
and
you'll
see.
There's
23
imports
it's
stuff
to
do
with
file
system
and
clock,
and
things
like
that.
You
don't
need
to
read
the
list,
but
every
single
one
of
those
is
part
of
the
wazi
snapshot
preview,
one
namespace,
so
it
should
run
anywhere.
A
Excuse
me,
okay,
so
that's
good!
It's
a
good
start,
but
so
far
it's
a
bit
boring
right
because
we
can
only
just
log
stuff
to
console.
Can
we
build
a
more
interesting
application,
something
that
we
would
deploy
to
the
cloud
something
network
enabled
so
here's
the
little
challenge
that
we're
going
to
set
for
ourselves?
One
of
my
lockdown
hobbies
has
been
growing
vegetables
in
a
greenhouse
which
is
great
yay,
and
when
you
get
into
doing
this
sort
of
thing,
you
tend
to
accumulate
a
bunch
of
sensors
little
iot
devices.
They
might
be
programmable.
A
They
collect
information
about
temperature,
humidity,
soil,
moisture
and
stuff
like
that,
and
it's
a
bit
tedious
to
go
around
looking
at
them
all
individually.
I'd
like
to
feed
all
that
data
into
a
central
monitoring
application,
which
can
then
present
a
ui
to
me
on
different
devices,
and
I
want
the
network
traffic
to
be
really
compact,
so
I'm
going
to
have
them,
send
grpc
messages
into
the
application,
and
I
want
my
ui
to
update
in
real
time.
A
So
I
want
it
to
push
updates
out
over
websockets
and
the
question
is:
can
we
do
all
this
stuff
with
just
standard
wazi?
Today
it
is
the
asp.net
compilation
model.
Is
it
going
to
work
on
web
assembly?
Is
all
the
networking
stuff
going
to
work?
Well,
the
answer
is
yes,
obviously,
otherwise,
I
wouldn't
have
brought
this
up.
It
would
have
been
a
silly
thing
to
do
so.
I'm
going
to
show
you
how
this
might
look
over
here.
A
I've
got
my
greenhouse
monitor
application,
which
is
a
standard
asp.net
core
application
which
references,
the
wazi
sdk
and
another
package
which
tells
asp.net
core
that,
instead
of
using
the
native
windows
or
linux,
networking
stack,
it
should
use
the
new
sock,
accept
api,
which
is
within
wazi,
and
that
should
mean
that
all
of
the
standard
asp.net
stuff,
such
as
grpc
and
signalr,
which
is
our
apis
on
top
of
webassembly,
they
should
all
just
work,
which
is
very
nice.
Okay,
I've
got
other
configuration
like
I've
got
this
json
endpoint
for
the
ui,
and
I've
got
here.
A
My
websocket
thing.
The
ui
in
this
case
is
actually
built
using
svelt,
and
you
might
wonder
why.
I
would
do
that
because
you
know
I've
just
been
bigging
up
blazer
if
blaze
are
so
good.
Why?
Wouldn't
I
build
the
ui
with
that?
Well,
I
could,
and
it
would
have
been
really
nice
and
convenient
for
me,
but
the
point
is
to
show
that
all
these
technology
pieces
are
independent
and
just
because
you
can
use
net
for
one
thing,
it
doesn't
mean
that
everything
has
to
be.net.
A
So
that's
why
I
did
it
with
svelt
also
felt
it's
quite
nice.
So
you
know
that's
okay,
let's
start
running
this,
shall
we
I'm
going
to
do
a
net
build
and
we
should
get
a
wasm
binary
out
of
that,
because
I've
got
the
wowzi
sdk
in
there.
So
when
that
builds,
we
shall
see
there.
We
go
greenhousemonitor.wasm
has
appeared
and
I
could
run
it
using
standard
dot,
net
tools
like
dot
net
run
or
just
by
pressing
f5.
A
If
I
was
using
visual
studio
but
to
show
you
that
there's
nothing
weird
going
on,
I'm
going
to
start
it
by
calling
wazomtime
directly
passing
it
a
reference
to
my
wasm
module
and
telling
it
that
it's
allowed
to
listen
on
port
5000
and
then
I'll
go
to
that
in
my
browser
and
we
get
our
ui
popping
up
and
it
looks
nice.
You
know
we
can
see
that
there's
disturbingly
high
temperatures
at
one
end
of
the
greenhouse,
but
it's
fine
everywhere
else
the
temperature's
been
fluctuating
and
the
automatic
irrigation
system
seems
to
be
working.
A
So
that's
all
good
all
right,
but
remember
that
we
want
to
push
stuff
into
this
over
grpc
and
get
the
ui
to
update
in
real
time
with
web
sockets.
So
I
need
some
sensors.
I
don't
actually
have
any
sensors
with
me
here,
but
I
do
have
this
little
simulator
that
I
wrote,
which
is
going
to
make
the
grpc
calls
into
the
application
and
we'll
see
what
happens.
A
So
when
I
do
that,
you'll
see
that
the
ui
does
start
updating
in
real
time,
because
the
sock
accept
api
in
wazi
means
that
all
the
stuff
we
build
on
top
of
that
is
just
going
to
start
working,
which
is
very
nice
okay.
But
what
if
something
goes
wrong?
How
could
we
diagnose
what's
going
on
inside
our
application?
Can
we
debug
stuff,
even
when
it's
running
inside
wasm
time?
A
Well,
wasn't
time
does
have
some
level
of
debugging
support,
but
it's
at
the
level
of
ldb
or
gdb,
and
it's
not
the
sort
of
thing
that
dot
net
developers
are
going
to
accept.
They
want
to
use
their
normal
debugging
tools,
but
the
good
news
is
that
the
net
runtime
has
its
own
debugger
support
inside
it.
So
if
we
can
attach
a
tcp
listener
to
that
debugger,
then
we
can
connect
a
normal
debugger.
A
A
So
I'm
going
to
press
the
attach
button
right
now
and
it's
kind
of
difficult
to
see
what's
going
on,
because
the
screen
is
so
small,
but
we
can
see
that
we've
accepted
a
connection
from
the
debugging
client
there
and
then
the
application
starts
up
so
now
back
over
here.
In
my
browser
I
can
reload
and
everything's
working
and
stuff,
and
then
I
can
go
and
put
a
breakpoint
somewhere.
A
A
So,
let's
see
if
we
can
hit
that
breakpoint,
I'm
going
to
go
and
start
sending
my
sensor
data
into
the
application
again
and
when
I
do
that,
you'll
see
that
we
do
in
fact
hit
the
breakpoint
and
we've
got
an
entirely
normal.net
debugger
working
in
the
normal
way
for
code.
That's
running
inside
wasmtime
and
we
can
do
all
the
normal
stuff
like
hover
to
see
variables,
see
the
call
stack
and
all
that
sort
of
stuff
and
that's
working
great.
It
even
works
with
remote
debugging.
A
A
The
first
time
that
we
tried
to
enable
debugging
for
net
inside
the
browser,
it
was
like
a
six
month
agonizing
effort,
but
when
tase
looked
at
doing
this
on
top
of
wazi,
she
was
able
to
make
it
work
in
under
about
two
days,
which
was
amazing
to
me,
and
I
think
that
goes
to
show
how
wazi
is
a
more
standard
environment
for
running
your
webassembly
code
than
the
browser
is.
We
can
do
a
lot
more
stuff
in
a
straightforward
way,
so
we
are
running
out
of
time
now
or
I've
run
out
of
time.
A
I
want
to
just
leave
you
with
a
few
final
thoughts
about
things
that
I
think
we
could
do
to
grow
the
wazi
ecosystem
from
where
it
is
to
reach
a
bigger
market
of
developers.
I've
made
this
point
a
number
of
times.
I
think
the
developer
experience
is
key.
You
need
to
have
compile
times
under
a
second.
You
need
to
be
able
to
use
standard
tools,
standard,
debuggers,
standard,
hot
reload
type
features.
People
are
not
going
to
use
any
weird
new
tools
that
you
ask
them
to
use.
A
I
think
there's
a
good
opportunity
when
it
comes
to
hosting
this
kind
of
thing,
so
I
just
built
my
greenhouse
app
as
a
single
wasm
file,
and
I
would
like
to
be
able
to
just
upload
that
file
on
its
own
to
something
that
would
host
it
in
the
cloud,
but
the
industry
doesn't
seem
to
have
got
a
feature
like
that
just
yet,
but
it's
kind
of
an
obvious
thing
to
do.
I'm
sure
many
of
you
would
be
working
on
something
like
that.
A
As
for
the
the
various
open
source
projects
that
are
going
on
in
the
yz
world,
some
of
them
have
got
great
samples,
but
a
few
of
them.
I've
noticed
don't
really
have
samples
at
all
or
they've,
just
got
kind
of
like
a
hello
world
sample
which
doesn't
really
sell
the
technology,
and
I
just
really
encourage
you
if
you've
got
any
project
in
this
space
to
make
sure
you've
got
some
samples
that
that
actually
sell
what's
unique
about
your
project.
A
Otherwise
people
might
not
make
sense
of
it
and
then
speaking
of
reaching
a
wide
audience,
you
don't
have
to
use
windows
yourself.
You
don't
have
to
like
it,
but
most
professional
developers
in
the
world
are
using
windows
and
if
you're,
not
shipping
windows
binaries
for
for
your
project,
then
you
are
leaving
a
lot
of
potential
users
on
the
table.
A
As
for
the
wazi
spec
itself,
I
think
we
all
know
that
there
are
some
gaps
in
networking.
It's
been
mentioned
in
the
keynote.
I
know
there's
a
session
about
this
later
in
the
afternoon.
So
it's
great
that
we've
got
the
sock,
accept
api.
That's
what
made
it
possible
to
just
make
asp.net
core
work
there,
but
there's
still
a
missing
piece
in
terms
of
outbound
networking
to
be
filled
in
there.
A
We
can't
get
every
possible
thing
inside
the
wazi
spec.
So
you
know
the
new
component
model
interface
types
are
going
to
be
key
to
making
a
wider
range
of
things
work
on
wazi,
and
it
would
be
great
if
we
as
a
community
could
get
together
and
agree
on
what
the
high
level
representations
for
stuff
like
http
web
sockets
calls.
Database
calls
and
stuff
should
look
like,
so
that
is
all
I've
had
got
time
for,
and
I
know
that
you'll
be
ready
to
go
and
get
some
coffee
just
now.