
Making WebAssembly better for Rust and for all languages - petercooper
https://hacks.mozilla.org/2018/03/making-webassembly-better-for-rust-for-all-languages/
======
harpocrates
One thing that continues to amaze me is that WebAssembly isn't being discussed
more outside of the context of the web. Think about it just as a format that
(a) is low-level enough to support performance tricks, (b) is fast to turn
into native code, and (c) easy to check.

Compilers could stop worrying about obscure/old architectures. Deploying an
application onto multiple platforms is no longer a problem. Sandboxing is much
simpler. Formal verification becomes possible (the WebAssembly spec actually
reads like a spec, unlike the C standard which reads more like a religious
text).

I'm so excited about WebAssembly, but really not because of the web.

~~~
fulafel
This has been tried many times in the history of computing (ANDF/TenDRA, JVM,
NaCL, P-code, TIMI, etc). What's different this time?

~~~
harpocrates
What other low-level format supports my points (a), (b), and (c)? And has an
actual spec?

EDIT: you've since added some examples. Here are my (very subjective)
opinions:

\- The JVM isn't really all that low-level - it eeks out a lot of performance
at runtime. Plus, you need to have GC, which tends to increase memory
requirements and complicate real-time constraints.

\- NaCL was interesting but its spec wasn't as good. IIRC Google didn't do too
much in the way of asking for public input. I think some folks had some
security concerns too. I really like WebAssembly's spec - I don't see any
typing judgements or small-step rules for NaCL.

\- Wasn't ANDF unix-bound?

~~~
e12e
I'm not very familiar with the various jvm profiles - but isn't javacard
pretty light? (the stuff that runs on similar cards and such)?

~~~
imtringued
Yes but you're still bound to java semantics. Java is very high level. Almost
everything except the blessed primtives long/int/short/byte is an object. This
is not a suitable target for lower level languages like C.

------
kiliancs
> we can use the ES module API. With this, working with WebAssembly modules
> should be as easy as importing them.

> import {myFunction} from "myModule.wasm"

> We’re working with TC39 and the WebAssembly community group to standardize
> this.

Note that this is already possible using Webpack 4.

~~~
steveklabnik
And Parcel, and hopefully others in the future!

~~~
k__
Does it work with Node.js?

~~~
steveklabnik
Yup! The most recent Node LTS includes wasm support without a flag, previous
versions required you to include a flag.

------
kodablah
Looking forward to ref types[0] and host bindings[1] so this stuff doesn't get
too JS-specific. The former has seen a good bit of activity recently.

0 - [https://github.com/WebAssembly/reference-
types](https://github.com/WebAssembly/reference-types) 1 -
[https://github.com/WebAssembly/host-
bindings](https://github.com/WebAssembly/host-bindings)

------
netcraft
A friend was recently trying to use webassembly from rust and ran into an
issue where he couldnt use anything that depended on rust's random - because
it depended on a nano scale clock from the system. With problems like
meldown/spectre, how could this even be resolved in the future? Would anything
that depended on that need to use a random function from js instead?

~~~
wyldfire
Maybe eventually if retpoline robustly resolves the issue of speculative
execution, the high precision clock access could be restored?

~~~
imtringued
Alternatively the problem could be fixed directly in the hardware.

------
fnord77
> This is because JS is a good choice for most things.

It really isn't, though. Maybe less bad with ES6. I feel like this was thrown
in to mollify the scores of people who <strike>wasted their lives
with</strike> invested a lot into javascript.

I know the unfortunate story of how javascript came to be the "web language".
It's a shame even a tiny bit more thought didn't go into it.

------
vvanders
wasm-bindgen looks Awesome. Definitely the most painful part of using
wasm/emscripten and looks like a very clean solution.

------
e12e
> One of the hardest parts of working with WebAssembly is getting different
> kinds of values into and out of functions. That’s because WebAssembly
> currently only has two types: integers and floating point numbers.

So... The only overlap between Javascript and webassembly is floating point
numbers? Are they the same type of floating point?

And is the conversion unicode-string > js float > ws int - or something else?

Or does js have integers now?

~~~
echeese
JS doesn't have integer, but its Number is really just a double, which has a
52 bit mantissa, meaning it can hold any 8, 16 or 32 bit integer. Only 64 bit
integers are unable to be stored in a double, which is why the WASM->JS
interface doesn't allow them.

------
prewett
The article talks about being able to integrate into the JavaScript
"ecosystem," but for me the excitement of WebAssembly is that I can avoid
JavaScript and an object system that is fundamentally unsuitable for anything
other than static word-processor-like documents. (Which, to be fair, is what
HTML was designed to be.)

We know how to write a UI library, I think the basic components are pretty
well-defined. Qt and NextStep (surviving to some extent in Cocoa) are well-
regarded. Java Swing is okay. So if we could get a real UI library for use in
the browser, instead a JavaScript framework poorly re-inventing it, that would
be wonderful. And, best of all, it doesn't have to be in JavaScript!

~~~
ZenPsycho
Why does nobody think of accessibility when they indulge in these weird
1980's-style-ui-library-in-a-browser fantasies?

~~~
swsieber
With web assembly you don't have to write a lick of javascript to write a
guide in some other language that uses a completely accessible dom tree under
the hood, provided your library provides the glue (like the rust library Yew).

There's no reason one couldn't wrote a UI frame work like the ones mentioned
by the parent that use the dom under the covers.

------
themihai
>> One big 2018 goal for the Rust community is to become a web language.

Without DOM access I fail to see how that would happen. So until WASM gets DOM
access no other language(except JS) can become a(first class) web language.

What is JavaScript without DOM access?

~~~
steveklabnik
You can access the DOM, but you have to call into JS, which adds some
overhead. When people say “DOM access,” they mean native, not through JS.
Check out the stdweb crate.

Even then, there's tons of logic you want to execute in the browser that
aren't related to UI. For example, any sort of number crunching. That stuff is
now feasible, which opens up all kinds of applications.

~~~
TomasSedovic
To add a specific example here, I've recently compiled a roguelike I'm working
on to WASM, not knowing what to expect when I started.

This required only a handful of changes across the codebase (mostly handling
external resources such as the filesystem and the random generator) and then
implementing a bit of JavaScript that took the drawcalls from the WASM core
and rendered them on the canvas. And vice-versa, a bit of JS that passed the
browser input into the WASM game.

Since the original game had no concept of a DOM, it didn't matter to it. I
think WASM can be huge for browser games.

But like Steve said, you can call any JavaScript function and manipulate the
DOM that way. At least for Rust, there's also a library that does this for
you. So you can have Rust code that uses a DOM API and the WASM <-> JS bridge
is handled for you:

[https://github.com/koute/stdweb](https://github.com/koute/stdweb)

~~~
tyingq
The bridge is currently VERY slow though. Like 10x slower than doing it in JS,
sometimes worse.

~~~
zaarn
Then applications in WASM will have to reduce the number of these calls until
it gets native.

This can be easily achieved by buffering calls to the DOM and merging batches
of actions together (you could probably even divide DOM actions into priority
queues to improve reaction time at expense of throughput in less important UI
elements)

~~~
imtringued
I'm wondering if it would make sense to have a virtual DOM inspired by react.
This would be faster than direct DOM access via a bridge.

~~~
zaarn
A vastly simplified DOM if anything. I imagine each language will use native
objects, like how .NET did it for a while.

But I don't think languages will interact with the DOM extensively once it has
been properly abstracted.

One major difficulty would be to have it available quickly so a page refresh
doesn't take until the WASM binary has sorted out it's internal state.

------
Dude2023
_> This is because JS is a good choice for most things._

That's why it's one of few languages: 1) with mainstream transpilation; 2)
more than one transpiler.

~~~
amelius
Isn't that simply because, until recently, JS had a "monopoly" on languages
you could use inside a browser?

~~~
burner5692
Yes, that's the only reason anyone has voluntarily used JavaScript.

~~~
kiriakasis
This, is false. for many (some, if you prefer) use cases javascript is
perfect.

