
WebAssembly’s post-MVP future - steveklabnik
https://hacks.mozilla.org/2018/10/webassemblys-post-mvp-future/
======
justinclift
On a semi-related point, TinyGo (a subset of Go for embedded devices) recently
added a WebAssembly output target:

[https://github.com/aykevl/tinygo](https://github.com/aykevl/tinygo))

Unlike the current mainline Go's WebAssembly output (min ~2MB file size), the
Wasm generated from TinyGo is practical in size. eg ~1kb for the toy examples

This is all leading edge dev stuff too, so updates and improvements are
happening pretty frequently. :)

~~~
sametmax
Your comment just made me realized that, while using cPython => webassembly
for something else than electron would be overkill, this would be kinda neat
for microPython.

~~~
fulafel
There seems to be some work on it: (1)
[https://github.com/micropython/micropython/pull/3575#issueco...](https://github.com/micropython/micropython/pull/3575#issuecomment-425346070)
(2)
[https://github.com/matthewelse/micropython/tree/emscripten/e...](https://github.com/matthewelse/micropython/tree/emscripten/emscripten)

------
kodablah
Here's a newly created proposals repo to keep track:
[https://github.com/WebAssembly/proposals](https://github.com/WebAssembly/proposals).

> Skill: 64-bit addressing

As a WASM backend implementer in an environment w/ only 32-bit addresses, I
hope people don't move to 64-bit addresses too soon. Are we really reaching
the limits here already?

> Skill: Portability [...] A POSIX for WebAssembly if you will. A PWSIX? A
> portable WebAssembly system interface.

Yes please, but dev'd outside of WebAssembly. This is needed for
interoperability between languages. Even just strings would be nice. A stdlib
interface to rule them all, so to speak. If kept modular and avoided a lot of
bikeshedding and had a full test suite, it could have a great benefit even
outside of WASM.

~~~
PowerfulWizard
Agreed on the stdlib concept. I'm sure people are working on it, the benefit
would be massive. Just the amount of mobile data transfer that could be saved
by 1MB of software pre-distributed to all browsers would be huge.

I wonder if anyone is trying to do it based on the javascript integrity
hashes. In theory, if you took the top 100 javascript libraries and
established a blessed build pipeline that would produce reference builds that
would be bundled to the browser, and if anyone loaded a resource with an
integrity hash matching the browser's pre-installed versions, it could just
load from disk instead. That would give people who can tolerate less frequent
library releases the ability to use all that functionality without networking
related page load costs, and would provide a fallback since CDN's could host
the file anyway if the browser doesn't have it.

~~~
iainmerrick
_Just the amount of mobile data transfer that could be saved by 1MB of
software pre-distributed to all browsers would be huge._

That would be great. I’m normally a fan of multiple competing implementations,
but this might be an area where a single common library implementation,
developed in partnership by all browser vendors, would be beneficial. All the
code would be in wasm so it would be portable by definition. And with
everybody using exactly the same implementation there shouldn’t be any sneaky
incompatibilities. With a single master repo it could be versioned and updated
cleanly.

Just as long as it’s kept small (1MB sounds like a good goal) and there isn’t
too much churn -- those are the real challenges.

~~~
PowerfulWizard
Yeah agreed, it is extra complicated since it requires coordination between
browsers and also enough websites to make it worth it. If it were released
today it could take years to register in i.e. global internet statistics. I
guess in theory shared CDN's and caching should be almost as good as well if
major website could agree on dependency sharing.

------
zimbatm
I'm a bit concerned by the addition of Garbage Collection to WASM. Is there a
way to implement those without favouring some type of language?

It seems to me that GC tuning and memory models are very language-specific. A
purely-functional language like Haskell or Closure can make different
assumptions about the memory regions but also generate a lot more young
generation items compared to OOP languages.

~~~
amelius
Why not implement the GCs themselves using low-level WASM code? That would
enable a language-agnostic approach (though it would prohibit collecting
garbage over multiple cooperating languages at the same time, which is a less
urgent problem imho).

~~~
rkangel
You've already got 2 co-operating languages - JS and whatever is compiler to
WASM.

~~~
amelius
True, but once you're using WASM, you probably don't need to hold references
to JS objects that point back to the objects created in WASM.

We've been interfacing C with e.g. Python without needing a garbage collector
that crosses language boundaries. So why would we need one now?

~~~
TomMarius
Because that's not safe. It's only as safe as the Python binding is, which is
not good enough.

~~~
amelius
Define "safe". Are you talking about security or correctness, or both, and
please elaborate.

~~~
TomMarius
The point of WASM is the ability to safely run _any untrusted code_ in a
performant way, that includes seamless interfacing with other modules.

[https://webassembly.org/docs/security/](https://webassembly.org/docs/security/)

~~~
amelius
I'm sure that if you can make WASM secure without the GC part, then you can
create a safe interface. Yes, it may leak memory (remember, so can a GCed
program that forgets to unreference objects), but that's just something you
have to deal with when programming at a low level; and languages built on top
of WASM can make that a non-issue, actually.

Let's keep WASM simple. It's probably the best thing one could do in view of
security.

~~~
TomMarius
Can you elaborate on how two WASM modules each with its own GC could safely
interface without unnecessary overhead? Why would we want to have this
overhead in the first place? It may not be that bad with 2 modules, but you
might easily have 20 or (way) more.

~~~
de_watcher
I've got multiple specialized GCs within one module, and they're doing fine.

Trying to shoehorn everything into one model isn't something that should have
'asm' in its name.

~~~
TomMarius
OK, but could you share the specifics? I'd like to understand. Emphasis on
combination of safety (primary) and performance (secondary) - remember that
any number of completely unrelated, untrusted, maybe buggy and potentially
even malicious modules might be combined. They're being very careful about not
forcing languages into one model, BTW.

------
skybrian
I'm reminded a bit of Java's early days when Sun was able to create the
illusion that it would take over the world. WebAssembly has had a lot of early
success and its limits are hazy, but it seems like they must be out there
somewhere? To speculate:

On the server side, it seems like docker format has already won. Maybe cpu
architecture portability doesn't matter there and x86 is good enough? Although
serverless and edge computing often use JavaScript.

On mobile this seems to depend on Apple and/or Google deciding to support
WebAssembly for native apps, which seems unlikely.

Developers need laptops to run their development environment in. I'm wondering
if this might just be Linux tools running in a container on your laptop.
Chromebooks seem to be moving in that direction.

The revival of something like Sandstorm might be interesting, but that's
pretty speculative.

~~~
kllrnohj
WebASM really only makes sense in the context of embedding untrusted code,
which outside of the browser is a concern that largely doesn't exist.

Otherwise you are severely crippling yourself for no real gain. You're going
to lag the hardware features by years if not decades, you're not going to get
arch-specific optimizations as readily, and you're going to have huge startup
costs. You're also stuck with sandbox restrictions that you've self-imposed,
making it harder to do things that would have otherwise been trivial or needs
to be re-invented.

You could maybe squint and claim you need a portable IR, but given there's
only really 2 ISAs in widespread use (x86 & ARM) does that _really_ matter?
Similarly you could claim cross-OS support, but again as there's only _really_
2 OS's for each target (Windows/Linux for server, Android/iOS for mobile) does
that _really_ matter? Critically does it matter to such a degree that you'd
rather severely cripple your own app to get it instead of just compiling it 2,
3, or 4 times?

~~~
cm2187
In what language can you just “compile 4 times” to target android, iOS,
windows, linux, macos and any future platform?

~~~
kllrnohj
Literally all of them? Since you scope creaped to add macos to the list even
though it doesn't exist in the server or mobile space you'll need to increase
that to 5 compiles instead of 4, though.

But C, C++, Rust, Go, D, etc... all support compilation to those platforms.
This is a really common thing to do.

------
jholman
Okay, I've only done the over-breakfast skim of this, and I hate to be that
guy who comments without having fully read TFA, but here I go anyway...

I don't see any explicit mention of what I understand to be the killer
feature: the ability to directly access the browser's WebAPIs, from
Accelerometer to Document to MimeType to XPathExpression. Start with modifying
the DOM, and go from there. Of course fast WASM/JS interop lowers the cost of
the obvious workaround. And yes, there's discussion in the article of getting
WASM to play nice with JS GC, which I understand is a prerequisite. But there
should be explicit discussion of what the predicted path is for making WebAPIs
available in WASM, what the sub-goals are, and how to measure progress.

And the first paragraph of the article is a joke, claiming that people thought
the 2017 version was the final version. No, we're waiting for a _relevant_
version (this sentence is an exaggeration, but it's more true than what TFA
said).

~~~
kodablah
What is the meaningful difference between WASM/JS interop and WASM/Web-API
interop? Implicit importing of them all? There are host bindings coming [0].
If Web APIs are expressed in terms of JS and you want interop with them, you
use what they are expressed in. Or are you saying Web APIs should be available
in WASM terms (which is harder due to lack of structural, array, string, null,
etc types)?

0 - [https://github.com/WebAssembly/host-
bindings/blob/master/pro...](https://github.com/WebAssembly/host-
bindings/blob/master/proposals/host-bindings/Overview.md)

~~~
marcosdumay
The difference is being able to serve some WASM script that interacts with
your page without having to send and entire glibc equivalent.

In practice, that means having an standard library on browsers that you can
call in a standard idiom.

~~~
fulafel
Dead code elimination in your compiler should be taking care of this, no?

------
Vinnl
Wow. Never did I expect it to generate this much (potential) innovation back
when asm.js was announed. Pretty excited to be following on, even though I
personally probably won't be writing anything for WASM any time soon - though
this excellent series on Mozilla Hacks probably also played a role.

------
matthberg
The parallels with the Destroy All Software talk "The Birth and Death of
Javascript" [0] are crazy. Seeing the section where they address the
possibility of Node modules and system access from WASM is like seeing a
flying car advertisement in real life.

[0]:[https://www.destroyallsoftware.com/talks/the-birth-and-
death...](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-
javascript)

~~~
tabtab
Re: _like seeing a flying car advertisement_

Ditto the feeling. I don't "get" WASM from a typical in-house CRUD
development. Game makers, maps, movie editors; sure they need the speed. But
some say it's gonna revolutionize most browser-based application dev, but I
can't get specific examples that are relevant to us. And even for those
domains listed, relying on inconsistent and buggy DOM as found in browser
variations is a problem it probably won't solve. DOM will still suck as a
general purpose UI engine.

 _WASM just makes DOM bugs run faster._

~~~
pcwalton
The DOM isn't particularly "buggy", relative to, say, Win32 or Cocoa. It may
or may not be a bad API, but implementations are pretty solid.

(I have to confess I've never understood the objections to the DOM. I have
literally never had an instance in which I had to use the raw Win32 API that
didn't turn into a miserable experience.)

~~~
tabtab
With Win32 and Cocoa you pretty much have _one_ vendor with roughly 3 or so
major releases. But with browsers you have roughly 8 vendors above 1% market-
share with 3 or so (notable) major releases each. Therefore, you have to
target roughly 8x more variations of the UI engine.

Look how hard Wine's job is to be sufficiently compatible.

I believe we need to either simplify the front-end standards (pushing as much
as possible to the server), or fork browsers into specialities: games, media,
CRUD, documents, etc. What we have now sucks bigly. Try _something_ different,
please!

~~~
pcwalton
Interoperability, and the standards process, is how we get specs that are
sensible. Whenever I have to program using Win32, Cocoa, etc. I inevitably
spend a ton of time reverse engineering how the proprietary APIs work. For DOM
APIs, things generally work how they are supposed to work, because they were
actually _designed_ in the first place (well, the more recent APIs were).

Wine isn't comparable, because the Web APIs are designed by an open vendor-
neutral standards committee and have multiple interoperable open-source
implementations.

Your proposals break Web compatibility and so are non-starters. Coming up with
fixes for problems in the DOM and CSS is the easy part. Figuring out how to
deploy them is what's difficult.

~~~
tabtab
Re: "the standards process, is how we get specs that are sensible." \- They
are not sensible: different vendors interpret the grey areas differently. A
sufficiently thorough written standard would be longer and harder-to-read than
the code itself to implement such.

Re: "Your proposals break Web compatibility" \-- Web compatibility is whatever
we make it. A one-size-fits-all UI/render standard has proven a mess. What's
the harm in at least trying domain-specific standards? We all have theories,
but only the real world can really test such theories.

------
tehsauce
What is the state of expanding GPU programming APIs in the browser? Seems that
one of the biggest factors holding back the development of media applications
for photo/video editing, games is a lack of a modern graphics api and first
class GPGPU support. A while ago there was momentum towards webGPU and
webVulcan but these projects seemed to have quieted down. We did get Webgl 2.0
but there is still tons of room for improvement and much to be gained!

~~~
ArtWomb
Chrome team has also announced intent to implement WebGPU on most platforms

[https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...](https://groups.google.com/a/chromium.org/forum/#!msg/blink-
dev/dxqWTSvyhDg/1UDaFD17AQAJ)

In addition to rich applications for 3D modelling, photo editing, etc.
Adoption of WebXR as a distribution platform for VR/AR content could drive
development. MagicLeap's Asset Builder Web Tool for example is built on top of
NextJS and ThreeJS

------
francasso
The threading description is highly misleading, the current proposal being
implemented is based on WebWorkers, they are not just native OS threads with a
small overhead

~~~
luke_wagner
That's true for the "threading MVP", but there is also discussion about adding
"pure wasm threads" as a follow-up which avoids worker overhead/limitations.

------
fabian2k
Is there already a performance advantage with the current WASM implementations
for number crunching code compared to writing plain Javascript?

My experience is that modern JS engines are already pretty good at optimizing
that kind of code, so I'm wondering if there are still significant speedups to
be had by using WASM, given that it's still pretty new and didn't have much
time to get optimized further yet.

~~~
username223
> Is there already a performance advantage with the current WASM
> implementations for number crunching code compared to writing plain
> Javascript?

I may be out of date here, but IME neither JavaScript nor WASM is any good for
actual "number crunching" (i.e. statistical or scientific code). For that, you
want at least a compiler/language that uses the latest SIMD instructions and
lets you choose 32- or 64-bit floats. Better still, you want one that
automatically parallelizes loops (you may need to align your data), gives you
cheap GPU access, and above all is simple enough that you can figure out why
the compiler isn't performing the optimizations you expect.

Modern JS engines are pretty good at speeding up the weirdness that is JS, so
maybe WASM will only have small benefits, but using either for numerical work
would be making your life unnecessarily hard.

~~~
AgentME
WASM does let you choose between 32 and 64 bit floats. SIMD and threading are
mentioned in the article as things that are being worked on now.

GPU access is about browser APIs rather than being something tied to WASM. We
have webgl now and it seems like there's more coming hopefully
([https://github.com/gpuweb/gpuweb](https://github.com/gpuweb/gpuweb)).

>and above all is simple enough that you can figure out why the compiler isn't
performing the optimizations you expect.

Reading WASM seems easier to me than reading real assembly, so double-checking
a WASM compiler's output seems much easier than double-checking a native
compiler's output. Of course it's on the compilers to support WASM well, but
hopefully that simplicity aids them too.

------
kristianp
"The tail calls proposal is also underway", but the repo hasn't had a commit
in 5 months.

[https://github.com/WebAssembly/tail-
call/blob/master/proposa...](https://github.com/WebAssembly/tail-
call/blob/master/proposals/tail-call/Overview.md)

------
zackbloom
You can deploy WebAssembly to 154 data centers as a part of Cloudflare Workers
if you'd like to play with it: [https://blog.cloudflare.com/webassembly-on-
cloudflare-worker...](https://blog.cloudflare.com/webassembly-on-cloudflare-
workers/)

------
dbielik
The visualizations in this article are excellent!

~~~
Crespyl
I believe Lin Clark is the artist, she has a whole series called "Code
Cartoons" where she explains various (usually web related) technical systems
like WebRender in similarly excellent style.

[0] [https://code-cartoons.com/](https://code-cartoons.com/)

------
upofadown
>People have a misconception about WebAssembly. They think that the
WebAssembly that landed in browsers back in 2017—which we called the minimum
viable product (or MVP) of WebAssembly—is the final version of WebAssembly.

They do? When people point out that WASM can't do stuff they are simply
pointing out that WASM would need to be extended. That is a pretty simple
concept and a very important observation because historically that is the
phase where everything falls apart.

Creating an intermediate language that all the higher level languages can
compile to is not a new idea. It has been done over and over again with little
practical result. Some current scepticism is in order.

------
user111233
From what I have seen it looks like Mozilla and Firefox are really leading in
WASM. All these detailed posts explaining it in easy to understand terms are
amazing as well.

------
__s
WASM's gc story will be tough to outline, it's going through its own MVP cycle
in omitting finalizers & weak references

------
hencq
I wonder if eventually with some of the stuff like GC in place, you could
write a javascript JIT on top of wasm. I'm only half kidding. It would be
pretty neat if wasm became a kind of universal IR that different (AOT and JIT)
compilers could target.

~~~
jhpriestley
JIT is pretty hard to do with wasm. There's a strict separation between code
and data in wasm, for security reasons. You can't jump into the heap. So the
best you could do is to generate your new JITted code as a separate wasm
module.

~~~
s-macke
That's exactly what I was thinking when I tried a more theoretical approach to
my web emulator. I wrote a little about my approach in the Wiki [1].
Definitely one of my worst hacks :-) . Unfortunately the demo doesn't work
anymore. I need to find out why.

[1] [https://github.com/s-macke/jor1k/wiki/Breaking-
the-1-billion...](https://github.com/s-macke/jor1k/wiki/Breaking-
the-1-billion-instructions-per-second-barrier-via-Dynamic-Recompilation-and-
WebAssembly)

------
msoad
I used to think without DOM web assembly is uselsess then I saw how Figma made
their UI super fast rendering to a canvas and was convinced that hopefully WS
will be the reason DOM apis go out of fashion

~~~
sk1pper
How does this not end up as Flash reincarnated though?

~~~
roblabla
What part of flash was bad?

\- the (bad) sandboxing? WASM uses the same sandboxing model as JS, and thus
provides the same security guarantees?

\- the requirement of an external plugin? WASM comes preinstalled in all
browsers.

\- the proprietary aspect? Wasm is an open standard.

\- the obfuscated nature? WASM can be decompiled very easily. Besides, js
served by modern websotes are already minimized and obfuscated beyond
recognition.

What am I missing here? I consider Flash to be a truly great piece of
technology. It allowed easy creation of multimedia contents Its flaws were in
its implementation, not in what it allowed. I __want __wasm to succeed as a
reincarnated, better flash.

~~~
nchie
Having to reimplement things such as text selection, clipboard, and making it
more or less impossible to write plugins which affect the pages being shown
(adblock, reddit enhancement suit, etc) are a few huge reasons. I'd prefer to
keep the web consistent for sites which don't actually need to be rendered on
a canvas.

~~~
roblabla
Adblock works on the network layer, for the most part, so this would continue
to work. Furthermore, most content isn't going to migrate to canvas-based
rendering, as that's much more complicated to setup.

The GP I was answering too was talking about figma, a sort of content creation
app in the browser. Being able to write those tools and deploy them via the
web is a net positive for the web. Just like all the good ol' flash based
games were an awesome thing for the web.

When flash was a thing, most web content didn't move to flash. Not only did
Flash behave in a foreign way, breaking the user's habit, it was significantly
harder to create flash content than web content. Similarly, it's delusional to
think most web content will move to wasm. The barrier of entry is enough to
prevent that.

------
arduinomancer
Maybe a stupid question but why does the browser itself need to do
compilation?

Why can’t WebAssembly developers compile ahead of time and just serve the
binary?

~~~
AndrewDucker
Because they don't know what they're compiling to. The browser could be
running in a wide variety of hardware.

~~~
arduinomancer
Right, seems obvious now, thanks

------
bayesian_horse
I'm looking into building a state-management system for React with Pyodide.
Yes, it might add 3mb to the downloads, but that should be acceptable. It will
probably use some kind of asyncio work-alike which will use Web-Apis to
perform what asyncio normally does.

------
ConanRus
This is all right and all, but I have one question: why the hell it needs to
be inside of a browser? To do what exactly? I don't care about browsers, I
care about applications. I don't want freaking Photoshop in my browser,
because I want a browser to die. This should be a part of the OS, not a
freaking browser. Give me a built-in runtime with sandboxing, a delivery
method, and an AppStore. Give me next generation Java/Flash. I tired of a
browser as an OS replacement. It is not and it shouldn't be.

~~~
msla
Because it effectively solves the distribution problem in a way which includes
non-technical people.

If you think your solution does that, meditate on what "non-technical" means.

~~~
user111233
Having the URL system also makes them so much better for sharing. Imagine
being able to share a link that someone could click and it would open up your
shared image inside of photoshop.

~~~
pjmlp
Android, iOS and UWP do that with deep links.

------
candiodari
I don't get this. What would you write in this language ?

~~~
ToFab123
I dont think you will write in that language. You will compile to that
language from whatever language you prefer to write in.

------
fulafel
It would be a shame if these improvements were restricted to WebAssembly only.
For most modern high level languages, JS remains a much better compile target
than WebAssembly for the foreseeable future.

