
WebAssembly is more than the web - steveklabnik
http://words.steveklabnik.com/webassembly-is-more-than-just-the-web
======
panic
I'm also excited about this aspect of WebAssembly, but interoperability will
hard without a well-defined ABI. There are only four types in wasm: int32,
int64, float32, and float64. Anything other than that needs to be encoded
somehow, either as multiple values or in memory.

For example, say you want to pass a 16-byte struct as an argument: how do you
do it? Do you store the struct in memory and pass an int32 pointer to its
start address? Or an int64 pointer? Maybe you encode it as two int64s? Once
you've made a choice, good luck calling functions generated by a compiler that
made a different one!

Another problem (in the web context) is blocking--Emscripten runs into this
one. You can't suspend WebAssembly execution in the middle of calling out to
an imported function. If a WebAssembly program wants to read keypresses
interactively, it can't use a blocking function like read(). You have to pass
the keypresses in at the outer level--or reimplement the call stack yourself
like Go did ([https://docs.google.com/document/d/131vjr4DH6JFnb-
blm_uRdaC0...](https://docs.google.com/document/d/131vjr4DH6JFnb-
blm_uRdaC0_Nv3OUwjEY5qVCxCup4/preview)).

In general, WebAssembly code today is very tied to the JavaScript code that
manages its interaction with the outside world. You can't just write a
WebAssembly program that uses OpenGL. You also need to write the JavaScript
that turns those calls into WebGL calls. I don't think this is a fundamental
problem--we just haven't seen standards develop yet. As platforms start to
define their API directly in terms of WebAssembly, without a JavaScript layer,
we may see more of a "standard ABI" develop. Until then, it's hard to know
what kind of APIs to target or support as an application or compiler writer.

~~~
klodolph
> For example, say you want to pass a 16-byte struct as an argument: how do
> you do it? Do you store the struct in memory and pass an int32 pointer to
> its start address? Or an int64 pointer? Maybe you encode it as two int64s?
> Once you've made a choice, good luck calling functions generated by a
> compiler that made a different one!

Sounds like every architecture ever? There’s an architecture specification and
then there’s an ABI. It’s common to only support some small number of sizes,
x86 is a bit the odd one out these days.

~~~
panic
Sure, but there's no standard ABI for WebAssembly yet. I'm basically just
saying we need an ABI before we can target it as a platform apart from the
web.

~~~
white-flame
It's not really a standalone platform, though. It's a sandbox utility to
contain high-speed or highly customized computation, that can be plugged into
any other platform. By design, it doesn't seem intended to be limited to a
single higher-level (well, higher than assembly language) ABI.

------
krylon
At the risk of sounding like an old grumpy guy[0], isn't this kind of what
Java[0] set out to achieve some 20 years ago?

I am in no position to compare the two by any metric other than age. But I
_am_ old enough to appreciate how such ideas tend return every couple of
decades.

Is this an IT thing, or is this phenomenon known in other areas, too?

[0] I am not even that old, and I do my best to not be grumpy.

[1] Yes, yes, Smalltalk, too. But Java - AFAIK - was the first language that
aimed for platform-independent bytecode + network delivery of code (Applets,
Webstart).

~~~
white-flame
Java's intent was "write _Java_ code once, run anywhere". The JVM exposes a
strict Java-centric view of what it can run, and it can be difficult to run
other language environments on top of the JVM reasonably.

Webasm is basically "write _any_ code once, run anywhere". It models a very
low-level CPU-like environment that the code fully controls at the byte level,
so even runtime language VMs can run in such a model without harsh slowdowns.
While this literally offers fewer features than the JVM, it doesn't restrict
which features the final runtime can implement.

This of course is all based on the assumption that you have a CPU-level
environment that already bootstraps what you need (like C-based garbage
collectors running underneath your dynamic language); or that you're running
low-level, assembly-style code for speed reasons.

~~~
Jasper_
Unfortunately, as a side effect of it supporting only one memory model, it
means that the host code only has a giant memory bag to work with, meaning it
needs to reconstruct objects from a giant heap. Currently, anything involving
more complex host interaction (say, handles to kernel objects like files) is
punted on to either the host-bindings proposal (which has a number of issues
and basically was agreed was not a way forward) or the GC proposal (which has
even more issues).

The current plan for the GC proposal is to allow skipping having memory heaps
at all and talk about things in terms of an object graph and types. See
comments here:
[https://github.com/WebAssembly/gc/issues/32](https://github.com/WebAssembly/gc/issues/32)

The important part of a runtime to me is the object model, and wasm basically
punted on one for now.

~~~
white-flame
Yes, that's what a CPU-level model with byte-level access means, and is how
all code running on your computer has its basis. Whatever high level
constructs you want are built on top of your asm-level runtime. This is as-
designed, as is the only reasonable way to allow different language paradigms
to run on top of it. It's also heavily implied by the name.

It does have a notion of function imports & exports, so in the same way it
allows you to do what you want, without specifying what you're going to do.
For untrusted code, like in a browser, the environment can choose only to
extend limited access. For trusted code, the environment can give access to
more OS-level functionality. By webasm not specifying _what_ functions to
bind, but giving the _ability_ to bind functions, it remains flexible and
appropriate for wildly varying deployments.

------
zackbloom
This is technically web, but not in the way you might think. We (Cloudflare)
are working on providing WASM support in our Workers [1] product that lets you
run code in our 155 data centers around the world.

WASM is great because we can run it in V8 isolates which are much lighter
weight than containers or full VMs.

[1] [https://cloudflareworkers.com](https://cloudflareworkers.com)

~~~
xxgreg
What are the security implications here?

i.e. the Chrome team, post-Spectre, are assuming that any value in a process'
memory is readable by any code executing within that process.

~~~
jeremyjh
V8's developer guide[1] recommends running un-trusted code in separate
processes. So each worker job would need to fork.

[1] [https://github.com/v8/v8/wiki/Untrusted-code-
mitigations#san...](https://github.com/v8/v8/wiki/Untrusted-code-
mitigations#sandbox-untrusted-execution-in-a-separate-process)

------
bluetech
I think it would be neat if WebAssembly were embedded in other languages, like
it is in JavaScript now. For example, suppose Python had a WebAssembly engine.
I bet that could replace a lot of C extensions, and it would be as
portable/universal as pure Python code, so no need for C compilers, OS-
specific binary packages, etc.

~~~
white-flame
While this would supplant "C for speed" libraries, it wouldn't supplant "C for
OS access" libraries. At some point, system code needs to call the OS.

~~~
pjmlp
Not all OS were or are written in C.

~~~
white-flame
Sure, replace "C" with whatever OS language is appropriate. The situation is
still the same: wasm doesn't talk directly to the host interfaces, regardless
of it being low-level. You'd still need another FFI layer somewhere to talk to
those.

------
w1nt3rmu4e
WebAssembly isn't _just_ a cross platform technology, it's also a way to
target platforms that are currently walled gardens. Being able to run software
on e.g., the iPad without paying Apple's 30% fee and being able to ship
features / bug fixes without added delays is a big deal.

"Write-once, run everywhere without paying someone for the privilege"

I think the term's overused, but this could actually be a "game changer".

~~~
nostalgeek
> WebAssembly isn't just a cross platform technology, it's also a way to
> target platforms that are currently walled gardens. Being able to run
> software on e.g., the iPad without paying Apple's 30% fee and being able to
> ship features / bug fixes without added delays is a big deal.

Apple still control what API you can use in their mobile browser, and it's not
like they are at the forefront when it comes to implementing Web API today,
especially when they also forbid any alternative browser on IOS. Ultimately
WebAssembly is limited by the API it has access to in the context of the
browser (and the resources that are granted by the browser). All the promises
of the "web as an app platform" have not been fulfilled yet.

IMHO WebAssembly will play a bigger role on the server, with nodejs for
instance as it will allow portable native code distribution.

~~~
w1nt3rmu4e
Sure, that's certainly a factor. But there's a large class of applications
that can get by with the API that is available.

I'm not suggesting it's a way to build mobile applications without paying
Apple. I'm suggesting it will be possible to deliver a product to (nearly) all
platforms using 1) a single codebase and 2) bypassing walled gardens.

Personally I won't build products for an App Store anymore. They're too
restrictive, expensive and time consuming to be worth it. But being able to,
say, deliver a desktop product (either via the web or packed in something like
Electron) and _also_ deliver nearly the same experience to an iPad Pro would
be huge.

~~~
pjmlp
If you can assure the same security quality, then by all means.

Meanwhile I will keep my sandboxes.

------
bovermyer
This is the first time someone explained the value proposition of WebAssembly
and I understood it. Now I'm actually intrigued.

~~~
steveklabnik
Thanks!

------
titzer
As one of the co-founders of WASM, I can say, yes, the layering was a
deliberate design decision for exactly the reasons laid out in the article.

Glad this is penetrating the wider consciousness.

Thanks for writing this, Steve!

~~~
steveklabnik
<3

------
jillesvangurp
Obligatory mention of this tongue in the cheek and visionary look presentation
"The Birth & Death of JavaScript":
[https://www.destroyallsoftware.com/talks/the-birth-and-
death...](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-
javascript)

This is basically what is happening with wasm and it's happening much faster
Gary Bernhardt was anticipating in that presentation.

IMHO wasm finally displaces javascript as the only practical language to run
stuff in a browser. Frontend stuff happens in javascript primarily because
browsers cannot run anything else now that plugins have been killed off. Wasm
changes that.

At the same time a lot of desktop apps are in fact javascript apps running on
top of electron/chrome. Anything like that can also run wasm.

Finally people have been porting vms to javascript for pretty much as long as
wasm and its predecessors have been around. So booting a vm that runs windows
95 or linux in a browser is not very practical but was shown to work years
ago. This is what probably inspired the presentation above.

I've actually been pondering doing some frontend stuff in kotlin in or rust.
I'm a backend guy and I just never had any patience for javascript. I find
working in it to be an exercise in frustration. But I actually did some UI
work in Java back in the day (swing and applets). Also there's a huge
potential for stuff like webgl, webvr, etc. to be driven using languages more
suitable to building performance critical software if they can target wasm. I
think wasm is going to be a key enabler for that.

Most of the stuff relevant for this has been rolling out in the last few
years. E.g. webgl is now supported in most browsers. Webvr is getting there as
well. Wasm support has been rolled out as well. Unity has been targeting html5
+ wasm for a while now. And one of the first things that Mozilla demoed years
ago with wasm was Unreal running in a browser.

I would not be surprised to see some of this stuff showing up in OSes like
fuchsia (if and when that ships) or chrome os.

~~~
steveklabnik
I was lucky enough to see that talk live, and it's stuck with me. It's
certainly where a big part of my enthusiasm for WebAssembly comes from.

------
dumb2223
If you have to compile a high level language L to wasm you could follow many
paths, for example L to C, C to wasm, or L to Lisp, Lisp to wasm. I should
suggest to create a graph in which vertices are languages and edges are
labeled with the efficiency of translation. This way one could use graph
theory to select the best path. This is only the ground idea. At a second step
one could study what features of languages are main ingredients of that
efficiency and design a middleware high level language M for the translation
to wasm: L -> M -> wasm. Or weight the translation using a vector of features
(concurrency, speed, bugs reports, etc) and select the path that gives the
best result. L -> M1 -> M2 -> ... wasm,where Mi are selected by the specific
features used for a concrete program in L. All computations of efficiency
should discount or take into account the use of specific libraries. For
instance, numpy with python makes the speed difference between c and python
smaller.

------
sehugg
One thing I am concerned about is startup performance. On my (slow)
Chromebook, some of my multi-megabyte WASM files take 10 seconds to compile.
Seems we need either faster CPU cores, faster code generation, or some kind of
staged JIT compile -- though I guess the latter could be accomplished today
with sufficiently clever tooling.

~~~
reitzensteinm
Chrome Canary contains Liftoff, which is about 8x faster on my machine for
initial compilation of wasm. I'm assuming it'll be in Chrome 69.

~~~
natorion
Indeed. X64 and ia32 support vor Liftoff will be in 69.

------
coldtea
> _So, WebAssembly itself, the core, is completely independent of the web. The
> web is a particular environment that Wasm is embedded in, but not actually
> required to use wasm. Other embedding APIs can be created, with their own
> interfaces, to do various things._

Does that mean one could e.g. create Node.js modules in Wasm, like we also
have the C++ modules? That could give a nice boost to certain kinds of code
like text processing and math (e.g. a big integer or matrix algebra library).

(Perhaps this is already a thing).

~~~
detaro
It's already a thing. In node you by default have a WebAssembly object giving
you access to the necessary features.

Here's an example (untested, just found it via Google)
[https://gist.github.com/kanaka/3c9caf38bc4da2ecec38f41ba24b7...](https://gist.github.com/kanaka/3c9caf38bc4da2ecec38f41ba24b77df)

------
jononor
I would like WebAssembly runtimes for embedded devices, both Linux and bare-
metal for microcontrollers. The WS program would be called with current inputs
(as data), and produce a datastructure describing output to set. This logic
can then easily and safely be tested before deploy and updated over the air.

------
billylindeman
The EOS blockchain uses webassembly and it's pretty cool. I've been working on
a side project and its interesting to be writing a "smart contract" in C++
that compiles down to wasm.

[https://developers.eos.io/](https://developers.eos.io/)

------
buchanae
> Eventually I’ll write a post about the wrong, but for now, the right: in
> some sense, WebAssembly is a different way of accomplishing what the JVM set
> out to do

I agree, it's exciting, but this is half (or less than) an article. These
hyped-up technologies make me grumpy neck beard.

~~~
steveklabnik
It is a bit light; I haven't blogged in a while because I'm trying to get back
into it, and writing long posts is hard. Some people prefer shorter posts; it
just depends.

------
ghettoimp
I, for one, want to rush out and grab a trademark on Node.wasm.

