
Why WebAssembly Is Faster Than Asm.js - dwaxe
https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-than-asm-js/
======
erikpukinskis
WASM has it's uses, for games and such. But on the web, the more weird stuff
you do, the more friction you tend to introduce to your users. You can boot a
JavaScript app, but the startup time will push people away. You can take
months to replicate iOS animations, but the lack of bookmarkability will
hamper your virality. Now you can compile C++ and run it in the browser, but
you can't use any of the existing web frameworks, and browser support is hit
or miss.

The real questions are: what are you _really_ doing that actually couldn't be
done with Craigslist-level technology? Does your application need to look and
feel the way it does because you want show off what you are capable of, or
because your customers would actually like you less if you did less?

What people keep missing is that the Web isn't a platform, it's an idea: It's
the idea that the lowest common denominator, or whatever crappy text-based
document format is supported in every single device ever made, is actually
good enough for almost everything. And you can add fanciness, and you can add
features, but the weight of the web pulls all content towards that lowest
common denominator.

This drives iOS developers crazy, because they want to be special snowflakes
who make animations that run at 100hz and might make Dieter Rams notice them
in the lunchroom. Platform after platform keeps challenging the web, and the
web keeps chugging along. Because the web is not a tool, it's the idea that we
should communicate with as many people as we can, and to do that we should use
the simplest technology that will do the job.

------
nitemice
So let me get this straight: WASM is basically asm.js, but without having to
go through javascript?

The future has changed! [https://www.destroyallsoftware.com/talks/the-birth-
and-death...](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-
javascript)

~~~
adamnemecek
I know it's easy to dismiss it but wasm will be th e biggest deal in the
world.

~~~
Zikes
There are already talks about compiling Go to wasm:
[https://github.com/golang/go/issues/18892](https://github.com/golang/go/issues/18892)

~~~
stymaar
I'm not sure I see any interest in that tbh: what's the point of porting a
memory-safe (with GC and runtime) on a VM especially dedicated to remove the
costly memory safety part of JavaScript.

Plus, the concurrent model of Go doesn't really shine if you run it in a
single threaded configuration (which is most likely to be the case in wasm).

I might be missing something but to me it sounds like pure hype to put go and
wasm together.

~~~
bradfitz
You're confusing concurrency and parallelism.

Even with GOMAXPROCS=1 (1 CPU running Go code), it's very liberating to be
able to write blocking Go code and not worry about callbacks or async/await
and let Go's runtime deal with it all while you write concurrent code.

~~~
stymaar
> You're confusing concurrency and parallelism.

I'm not, it's just that the most appealing feature of Go is it's ability to
use parallelism for concurrency with a decent overhead, which makes it
straightforward to scale vertically.

> Even with GOMAXPROCS=1 (1 CPU running Go code), it's very liberating to be
> able to write blocking Go code and not worry about callbacks or async/await
> and let Go's runtime deal with it all while you write concurrent code.

IMO, Async/await is a much cooler pattern than Goroutine + channels do do
concurrent stuff on one thread. I find it way easier to use, and less error
prone. The drawback is that you need a different paradigm when you want to
take advantage of parallelism.

Of course it's a matter of personal preferences, but the prevalence of
async/await in different programming languages indicates that at least I'm not
the only one thinking this way :).

~~~
emn13
async/await is possibly simpler to implement. At least: in go effectively
every method is async (at least the api doesn't show what is and is not), and
that means you can't afford the inefficiencies that typical async/await
implementations have because you'd be paying them all over the place.

------
genjipress
What seems most important about WebAssembly is that it is essentially a
universal language runtime. It's not that what it brings to the web is
unimportant, just that it seems like we're also getting a way to do truly
cross-platform language deployment as a bonus. Am I wrong about this?

~~~
randiantech
Well, Java bytecode already does that. The cool thing about WebAssembly is
that runs (or will run) on any browser.

~~~
throwawaysbdi
Is it just me or do Java applets seem like they were way the hell ahead of
their time?

If the sandbox didn't have so many holes in it Java applets were arguably
better for webapps than the unholy mess we've cobbled together over the last
ten years to replace them.

It's sad to me that Java fell out of the browser and was replaced with a slow
non standardized single threaded shit language for almost ten years just
because Java didn't have DOM access.

JavaScript is just nearing Java feature parity and still not anywhere close
for performance.

And I'll tell you what Java didn't have. A unfathomable clusterfuck of module
systems, transpilers, shit build tools and IDE support, crazy syntax gotchas,
unholy and inconsistent exception handling systems. God dammit what have we
done.

 _Shakes cane at neighborhood kids_

~~~
tdeck
I remember Java applets, and reading this thread it's hard to square the
revisionist nostalgia with those experiences. The Java applets I remember
absolutely sucked as a user. They took forever to load, had weird clunky UIs
that were out of place in the host OS and the browser, constantly broke due to
compatibility issues, and had no concept of graceful degradation. There's a
reason Java applets lie in the dustbin of history - good riddance to them,
it's where they belong!

~~~
bjbXXX
Java could have worked fine in the browser. All feature phones (which are/were
almost universally less powerful than a desktop PC) were able to run Java ME
applications just fine.

My memory from the mid/late nineties is that Microsoft wanted to balkanise
Java with J++ (or was it J# ?) and got into a big argument with Sun, and
because of this and the fact they eventually came to own the browser market
there was no way they'd embed a JVM in the browser.

~~~
tannhaeuser
Ironically, MS browsers remain the only ones to support Applets today.

~~~
kbutler
firefox extended support release has NPAPI support for another year:
[https://www.mozilla.org/en-
US/firefox/52.0esr/releasenotes/](https://www.mozilla.org/en-
US/firefox/52.0esr/releasenotes/)

------
hackcasual
Using Emscripten (with embind) 1.37.3 it takes slightly over 1 second to
initialize a 2.7mb wasm file. The JS version shows slightly under 300ms for
parse time, obviously not the same as the full WASM pass, but it does
significantly delay initial page load.

The positive side is what took 250ms to run with cold JS (nothing JIT
compiled) and 35ms after a few runs takes just 5ms the first time in WASM.
This is on Chrome Canary on Windows.

Is there anything I'm missing to speed this up?

~~~
jsheard
Have you tried compiling your project with the -Os flag instead of -O2 or -O3,
so the optimizer prefers to generate smaller code?

Performance will be slightly worse but a smaller wasm binary means less for
the browser to deal with on initialization.

~~~
hackcasual
Yes, it's compiled in Oz.

------
gcr
Why aren't we standardizing on something like Java bytecode or LLVM IR or CLR?

What problems with those existing technologies could wasm solve better?

~~~
darpa_escapee
My friend, where have you been for the last 5 years?

Web developers have been reinventing the wheel every 3-6 months and calling it
innovation.

~~~
pizza
smaller ideas faster, zestierly

~~~
scrame
oooh, it's like agile, but lightweight.

~~~
throwawaysbdi
"micro" if you will

------
Mindless2112
> indexes are LEB128s

This article is promoting how fast WebAssembly is to parse (and no doubt it is
faster than JS), and yet LEB128 is a slower-to-parse representation than
"prefix varint" with the same cost in bits [1][2]. It seems the designers
didn't actually care what was faster. [3]

[1]
[https://news.ycombinator.com/item?id=11263378](https://news.ycombinator.com/item?id=11263378)
[2] [https://github.com/stoklund/varint](https://github.com/stoklund/varint)
[3]
[https://github.com/WebAssembly/design/issues/601](https://github.com/WebAssembly/design/issues/601)

~~~
Ajedi32
> Implementors have discussed and concluded that while alternative encodings
> might offer improved size, the intention to support layer 1 (allowing outer
> wrapping format specific compression), and the degree to which LEBs are well
> known, outweighs this advantage for MVP.

Interesting. Any idea what's meant by "layer 1" here?

------
msoad
Without a GC WASM is very hard to use for regular web development tasks. When
GC infrastructure lands lots of mind-blowing stuff will happen. Things like
JVM and .NET running in WASM.

A lot of web people don't realize magnitude of impact WASM will have on the
web.

~~~
dualogy
> _Without a GC WASM is very hard to use for regular web development tasks_

Well yeah.. it's an _assembly_ language, the sort you inline in your C (or
some other) programs to squeeze critical code paths.

Doing your virtualdom or form validation in assembly probably wasn't a core
design goal, no matter all the scripters that get so easily hyped about wasm.
But consider usecases such as real-time interactively adjustable filters on
currently-playing page-embedded media objects, 3d editors that let the user
run (non-shader) algos on the current model such as geometry simplification..
all kinds of use-cases come to mind where wasm can really drive richer,
faster, more powerful browserbased apps than were possible without it.

~~~
Ajedi32
> Doing your virtualdom or form validation in assembly probably wasn't a core
> design goal

It wasn't part of the MVP, but it most definitely is a design goal for future
iterations. See:
[https://github.com/WebAssembly/design/blob/master/GC.md](https://github.com/WebAssembly/design/blob/master/GC.md)

------
ChicagoDave
A colleague, Thilo Planz, is working on an Interactive Fiction VM based on the
Glulx specification (1) called glulx-wasm (2). If completed, this will be
integrated with fyrevm-web, a web platform for glulx+channel IO stories.

(1) [http://www.eblong.com/zarf/glulx/](http://www.eblong.com/zarf/glulx/) (2)
[https://github.com/thiloplanz/glulx-
wasm/](https://github.com/thiloplanz/glulx-wasm/)

------
cm2187
Do we know if we are likely to see support for WebAssembly for all platforms?
It looks like a way to bypass the app store. I am surprised apple or google
(on android) would be happy to do so.

~~~
tannhaeuser
Exactly. Apple won't support WebAss, and I'm WITH them on this one. Why does a
browser have to run native apps with a laughable/non-existant, designed-by-
comitee API? That's what the operating system is for IMO.

WebAss is a technical solution to an economic problem: lackluster SW sales and
adblocking

~~~
cm2187
I don't agree with you. The only language that allows truly cross platform
development right now is javascript. It's a language I do not like and I
believe I am not the only one. In fact the popularity of extensions like
typescript is an evidence of the challenges of using what was meant to be a
simple scripting language as a full blown programming language.

WASM, if it allows to run high level languages like c#/vb/python/java, will
enable a huge developer base to start writing truly cross platform, productive
apps with a single code base. So it would be a solution to a fundamental
technical problem: the fragmentation and incompatibility of proprietary
platforms.

As a side, it would have another benefit (which would make it even less
palatable to Apple but should motivate Microsoft to develop a CLR for WASM):
as the apps would be cross platform, it would lower the barrier to entry for
alternative mobile platforms. If the same app compiled to WASM runs on every
platform, a Windows mobile OS (or any other challenger) would immediately have
access to the same apps that are available for iOS or Android.

~~~
invalidname
If you prefer Java check out Codename One:
[https://www.codenameone.com/](https://www.codenameone.com/)

It's an open source project that compiles Java to all OS's including iOS,
Windows (UWP), Android (obviously) as well as JavaScript (with threads etc.)

~~~
oceanswave
Is it language agnostic?

------
6nf
What languages do you all recommend for compiling to Wasm? I know Rust is an
option and something like Nim would probably work well. What is the future of
Wasm?

~~~
overgard
Honestly I'd only use C and C++ with this. It's not going to be a good target
for anything that currently requires a VM (most garbage collected languages)

~~~
icefox
Rust doesn't require a garbage collector

~~~
kibwen
Or a VM, or (in the extreme) even a memory allocator (which is how it gets by
on microcontrollers).

------
infogulch
What if the javascript interpreter / jitter was built in WASM and the jit
target was WASM?

The browser could reduce its' surface area to just network, html/css layout,
compositing, and wasm. Js just becomes a special case with an automatically
loaded wasm plugin.

------
Ericson2314
I predicted this before, but somebody will do a cloud with webassembly. With
all the extensions, this becomes quite an interesting middle ground between
VMs and containers.

------
tambourine_man
I though SIMD had already landed on WebAssembly.

 _That_ will make asm.js look a lot slower and should get it closer to C/C++
where it's still lagging.

~~~
markdog12
Not yet: [http://webassembly.org/docs/future-
features/](http://webassembly.org/docs/future-features/)

------
kevin2r
By the time wasm supports GC languages like python or ruby, javascript may get
a lot better. Will people still want to write client side apps in python?,
even if it means that it will run slower and also you have to download the
language runtime on a webpage load.

~~~
cm2187
JS is not to everyone's taste. And certainly not to mine. In the line of
business world, there would be a huge value added being able to use the
browser as a distribution mechanism for what are effectively desktop apps,
developped in a high level but statically typed language like VB, C# or Java.

I don't think downloading the app everytime is a big deal on an intranet/local
wifi. Also with things like the core CLR, the assemblies should be smaller.

------
inDigiNeous
Is it possible to compile javascript to WebAssembly or asm.js?

~~~
orthecreedence
Believe it or not, most browsers already run javascript ;)

~~~
inDigiNeous
Thanks for pointing out the obvious. That's not what I asked, I asked whether
can you compile javascript to WebAssembly, without having to parse javascript
source files on the fly and expose source code to the javascript engine, but
instead provide just the WebAssembly output directly.

------
frik
Who else thinks that Asm.js was okay, but WebAssembly is evil and might
destroy the current web landscape. It's like a trojan horse. Guess which
companies are involved.

~~~
eridius
What makes you say this?

~~~
tannhaeuser
WASM will be used to ship browser-in-browser runtimes (WebKit+FreeType already
compiles to WASM) to make ad and tracking blockers impossible.

~~~
eridius
Why would that make ad and tracking blockers impossible? Those blockers
usually operate by blocking resource loads, and a browser-in-browser runtime
can't sidestep that, because any network access still has to go through the
browser and therefore can be blocked.

~~~
tannhaeuser
Fair point. But a browser-in-browser can hide so many things from you. It can
easily piggyback tracking data on regular content requests, use proxies, block
basic page navigation; the possibilities are endless.

------
wtbob
> indexes are LEB128s

It's just a personal nit and beside the point of the (rather short) article,
but I've long felt it sad that the more correct 'indices' is so rare and the
correct-but-inelegant 'indexes' is so very common.

------
ballenf
The most popular language that you can't compile into wasm is Javascript?

This issue was closed 12 hours ago:
[https://github.com/WebAssembly/design/issues/219](https://github.com/WebAssembly/design/issues/219)

I know it's cliche and been written about ad nauseum, but this really does
feel like the trojan horse threat to MS, Apple and Android.

~~~
dualogy
What exactly is the "threat" to those players here, wasm?

It baffles me when people are asking for "a mechanism (aka hidden behind-the-
scenes magic) for objects and GC" _in an assembly language_ =)

~~~
Rusky
It makes complete sense to ask for GC support. Even if it's never used to
implement GC-d languages targeting WebAssembly, it's still important for
integration with the Javascript GC.

(I imagine the threat here is that the more things can be deployed as web
apps, the less they depend on any particular desktop OS.)

~~~
runeks
Why not write the GC in WebAssembly?

~~~
readittwice
How would you implement determining the root set? So how would you detect
which local variables reference an object? The Gc needs to keep these objects
alive.

AFAIK even conservative root-scanning is not possible right now. Please
correct me if I am wrong: With the current bytecodes it is only possible to
access the heap but not the stack. To make things worse, object references
could also be in registers.

