
WebAssembly: Mozilla Won - nachtigall
http://robert.ocallahan.org/2017/06/webassembly-mozilla-won.html
======
jhpriestley
People seem way too optimistic about web assembly.

The elephant in the room is download size. A wasm photoshop, even if it works
and performs well, is still a multi-gigabyte "web page". The browser is in no
way set up to handle that.

Even simple things will be huge compared to javascript webpage. Let's say you
write your todo app in Python with Qt bindings. Sure, wasm lets you run it on
the web. You'll just have to ship Qt, the python interpreter, low-level
graphics rendering code, shims for system calls in the standard library ...
overall you'll end up way, way heavier than the javascript + DOM version.
Probably 100MB or something.

wasm as it's implemented is going to have a very narrow band of usefulness.
Basically, isolated computational modules (e.g. a physics simulation), and
games. The games won't be, like, "Call of Duty on the web", they'll be little
flash-type games with not too many assets. Creators will have to put a lot of
effort into asset loading and compression to get around browser limitations.

~~~
cbhl
> The elephant in the room is download size. A wasm photoshop, even if it
> works and performs well, is still a multi-gigabyte "web page". The browser
> is in no way set up to handle that.

So you split it into chunks and download the bits you need as you go.

Microsoft has already figured out how to do this -- you can run Office (the
real, full Windows version) basically streaming from the Internet already.

~~~
philsnow
> So you split it into chunks and download the bits you need as you go.

at last, the renaissance of the microcomputer programmers (like the COBOL
renaissance of the mainframe programmers)! that kind of technique was common
back in the 80s to get things done

[http://www.filfre.net/2017/04/the-640-k-barrier/](http://www.filfre.net/2017/04/the-640-k-barrier/)

------
fpoling
This article in few lines lists key differences between PNaCl and WebAssembly:

\--- WebAssembly defines no new platform APIs other than some APIs for loading
and linking WebAssembly code, relying on standards-based Web APIs for
everything else. WebAssembly differs from asm.js by defining a bytecode format
with some new operations JS doesn't have, so some spec work was required (and
has been done!). Like asm.js, WebAssembly application call-stacks are
maintained by the JS VM, outside the memory addressable by the application,
which reduces the exploitability of application bugs. (Though, again like
asm.js and unlike PNaCl, the compiler is trusted.) \---

~~~
dullgiulio
I don't really understand what "the compiler is trusted" means.

What could an evil compiler really do? Maybe add a spinning loop to waste CPU
cycles, but that can be done in JS too.

~~~
fpoling
Both PNaCl and WebAssembly need a compiler to a get the machine code run by
CPU, but the output of PNaCl is checked via NaCl verifier while nothing checks
that the output of WebAssembly is safe machine code.

As the verifier for NaCl is likely to be an order magnitude smaller than a
component in WebAssembly implementation that verifies and compiles the
bytecode to the native code, PNaCl attack surface is much smaller.

~~~
Nokinside
>nothing checks that the output of WebAssembly is safe machine code.

The JS/WASM VM does. If unsafe WASM code is allowed to execute, there is a bug
in VM. VM must prevent semantically incorrect WASM from executing Control flow
integrity and incorrect use of pointers are detected at load time. There are
traps for invalid indexes, exceeding stack limits, invalid indexes in the
index space.

~~~
fpoling
This is not about unsafe WASM which should be rejected by verifier. This is
about the raw machine output that the compiler generates from WASM. As with
JIT for JS currently nothing verifies WASM compiler output. So a bug in the
compiler may result in a WASM that passes the verifier to be translated into
unsafe machine code.

~~~
Nokinside
Same thing applies to NaCl verifier. Bugs in verifier can cause problems.
Verification or generation bugs are bug, not security weaknesses in the
architecture.

(I should not need to mention this but compiling is form of verification).

~~~
fpoling
NaCl verifier in practice is much simpler than WASM compiler leading to a
significantly reduced attack surface.

~~~
Nokinside
This is not true. NEXE has different security boundaries enforced differently
on each supported platform. You need to write disassembler for each supported
instruction set and verify them. This is more complex task than generating
correct code from wasm.

------
tete
I think this is a good thing. It probably prevented a new DirectX style dark
age of the web.

Probably! I don't pretend to be able predict what path companies would have
went in the next few years.

It's really good to see that there is a will to agree and that there is more
than one player. Could always be more, also for keeping standards sane.
(WebSQL officially failed because there isn't more variety)

~~~
rubber_duck
>It probably prevented a new DirectX style dark age of the web.

DirectX was hardly a dark age, DX8 and onwards was a step ahead of GL.

~~~
rocky1138
But tied only to one OS. I believe this is what the OP meant and something I
agree with.

------
Touche
WebAssembly is nice and all, but I don't understand why Mozilla is so obsessed
with this feature that will be useable by 0.01% of applications. Meanwhile
they are falling far behind in a variety of features that are useful to a much
bigger % of the web. Safari and Edge have leapfrogged Firefox in providing the
important things to web developers.

~~~
flavio81
As pointed out, this will be HUGE.

For starters, this will enable client (browser) software development in a
language other than Javascript/ES6. With, probably, a plethora of compilers to
choose from, some of them giving better optiimizations than others.

I think this will make an explosion of more browser-hosted applications, with
much more power than before. And will make many more programmers go into
serious frontend app development.

Also, as a personal wish of mine, this enables the possibility of being able
to program on the language of your choice, both in the browser side and on
your server side. For example Haskell/Haskell, Common Lisp/Common Lisp,
Clojure/Clojure, Racket/Racket Python/Python, etc. And i mean using in the
browser the FULLY FEATURED version of the language, not a subset or a limited
version like ClojureScript, PyJS, Transcrypt, etc, but a full version of the
language supporting the full libraries available for it.

This also gives us a little step forward in liberating ourselves from being
tied to the mainstream operating systems: Windows, Apple X, Linux, BSD,
because more and more apps will target the browser environment, not the
operating system directly.

Roll your own operating system and still keep compatibility with most apps!!

~~~
ccozan
>full version of the language supporting the full libraries available for it.

Does this mean, simply said, that I can take any arbitrary windows desktop app
written in C++, for example, and run it in browser on every other OS?

~~~
ebiester
[http://www.quakejs.com/](http://www.quakejs.com/)

It required 3 days of porting from what I remember hearing.

------
TekMol
What are the main benefits of WebAssembly over asm.js?

I understand that asm.js was a subset of JavaScript that allowed the compiler
to create faster code. For example because it could be sure that variable
types do not change during runtime.

But what do we gain with WebAssembly? Faster download+compilation times? How
much faster?

~~~
flohofwoe
Here's a good overview from the emscripten author:
[https://hacks.mozilla.org/2017/03/why-webassembly-is-
faster-...](https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-than-
asm-js/)

TL;DR: much faster parsing over asm.js (10x to 20x faster), parsing should
also use much less memory, 10%..20% smaller downloads (when comparing the
compressed sizes, uncompressed WASM is several times smaller then asm.js),
64-bit integers (these have to be emulated on asm.js),

~~~
TekMol

        much faster parsing
    

Isn't parsing super fast already? From my experiments, jquery seems to compile
in a staggering 0.1ms.

~~~
kibwen
The partial intent of WASM is to write things orders of magnitude larger than
jQuery. Whether or not it will ever be practical to ship e.g. a complete
Photoshop clone in a browser remains to be seen, but if that's your goal then
you do have to start worrying about things like parse time.

~~~
TekMol
Why would the whole Photoshop be downloaded and compiled? I would expect a web
app to only download the parts the I use. If I want to blur an image, I don't
need the other gazillion filters for example.

And hey, even if photoshop is 1000 times bigger then jquery - that would still
compile in one tenth of a second.

~~~
vanderZwan
Developers like you are why apps are slow when they don't need to be.

EDIT: Also, if you think 10%-20% smaller downloads aren't worth it, you're
clearly not working at a CDN.

------
ericfrederich
It seems there is this effort to get C/C++ code performing fast inside of a
browser... then at the same time there seems to be an effort to get people to
stop coding in C/C++ altogether and switch to something more memory safe.

Go or Rust for example. Also, I watched a talk from DConf and saw that D is
adding memory safety as well. You need to mark any part of code doing pointer
arithmetic as "system code" or something like that.

I think it's a shame one couldn't have happened before the other. I wish
something like D or Go or Nim or something else would have won. Then there
would be this effort to get that language fast on the browser.

Is anything I'm saying making sense? I don't know enough about WebAsm, is it
really tied tightly to C or could Go or Rust or some future version of
statically typed Python become a first-class citizen?

~~~
rwj
It is not about running C/C++, it is about running native code (or something
approximating it). With the right backend, most languages should be able to
target WebAssembly. The other complication with supporting Go or Rust is that,
even if the language is memory safe, the code still needs to be sandboxed.

~~~
empath75
Gc'd languages will take a while.

~~~
fasquoika
What does Go's GC need that WebAssembly doesn't have? I understand it might be
hard for a language like Java that expects a GC in the VM

------
scriptproof
Asm.js was a brillant idea, but wasm is more like a bytecode. This is where is
the part from NaCl the author missed. Wasm is derived from asm.js but also an
improvement on LLVM to make a portable bytecode, that LLVM is not. One more
step in the LLVM toolchain to get portability...

~~~
ZenoArrow
WASM isn't based on LLVM. WASM is a compiler target, but compilers other than
LLVM can target WASM.

~~~
sitkack
And WASM is now the defacto portable Bitcode. Just as JS took over the world,
so will WASM. In six months, WASM will have had more program launches than the
totality of .Net and the JVM.

We have yet to fathom how far reaching WASM will be. Did I say WASM enough
times? I end with only this. WASM.

~~~
ZenoArrow
> "In six months, WASM will have had more program launches than the totality
> of .Net and the JVM."

I don't think so. The only languages that can currently target WASM are
languages that don't need GC. It'll take a while before the tooling and
functionality is mature enough to support the most commonly used languages
(aside from C/C++).

------
johnhattan
One of the best things about Flash was that you could pack up all your
bytecode and bitmaps and vectors and sounds and fonts into a single compressed
SWF file that contained your entire application/game/demo. That made it really
easy to do stuff like double-click-able client demos and deliverables for
websites. Ditto for Java and JAR files.

Looks like the "compressed bytecode that runs really fast" part is now a
reality. I'm hoping they'll work on making deliverable packages that are
convenient for programmers and users.

Anyone know if there is there anything like this in the works?

~~~
chrisweekly
Related tangent: sounds like Zeit.co's `pkg` for Node:
[https://twitter.com/zeithq/status/858393067241357312](https://twitter.com/zeithq/status/858393067241357312)

------
Andrex
This is just my personal viewpoint with nothing to back it up, but I doubt
Google ever seriously wanted other browsers to implement PNaCl. As this post
says, it was never specced and Google's big push for it was in Chrome apps on
the Chrome Web Store.

Also, wasn't asm.js just a subset of JS? This line confuses me:

> asm.js and PNaCl represented quite different visions for how C/C++ code
> should be supported on the Web

Yes you could compile C to asm.js, but it would still be compiling it to JS at
the end of the day. WebAssembly is completely different in that regard.

~~~
AgentME
>Yes you could compile C to asm.js, but it would still be compiling it to JS
at the end of the day. WebAssembly is completely different in that regard.

WebAssembly (at least to start with) is mostly intended as a more compact
binary encoding of asm.js. It still mostly executes the same way and offers
the same APIs as asm.js.

------
therealmarv
Is there anywhere a "hello world" or simple DOM modification program which I
can implement with WebAssembly?

~~~
remcob
I made this factorial compile-and-run example in NodeJS:

[https://gist.github.com/Recmo/e0b6911992897c5f51c38fda822537...](https://gist.github.com/Recmo/e0b6911992897c5f51c38fda822537c2)

To run it you need at least Node 8.0.0 and the `--expose-wasm` flag.

Sorry for using modern JS, you will need to use babel-node to run it. Or you
can port it to old fashioned JS.

~~~
Houshalter
I didn't know you could run wasm from node, awesome.

------
k__
Is WASM platform independent?

~~~
TazeTSchnitzel
To the extent that asm.js and JavaScript are, yes. Everything is well-defined,
so in theory any Turing machine should be able to run it, but it's certainly
going to be easier to implement efficiently on a typical modern 32-bit or
64-bit CPU in a computer or phone than on something more unusual.

~~~
k__
So I could write an application in, lets say Rust, compile it to WASM and run
it on Linux, macOS and Windows browsers without anything extra?

~~~
TazeTSchnitzel
Yep! It's a completely portable target and fulfils the promise of “compile
once, run anywhere”, although how well it runs depends on the particular
browser.

(It is pretty amazing you can compile C code to something that actually runs
on multiple machines, it's very nice.)

~~~
k__
Yes, this sounds awesome.

Can this be used as alternative to native modules in Node.js?

~~~
bobbytherobot
That is a good question. I imagine it depends on why it is a native module. If
they are native module because it utilizing features at the OS or machine
level, then I doubt they could.

~~~
TazeTSchnitzel
Well, whatever syscalls you want to make could be made by node.js for you,
though that quickly veers into absurdist territory.

------
z3t4
Seems like a lot of complexity for very little gain in performance. Optimizing
JavaScript often gain 100x performance, and after that rewriting it to Web-
assembly would only gain up to 4x performance.

~~~
roca
4x performance is worth having for many applications.

The other thing is it's not just about performance, but also about running
existing and future C/C++/Rust etc code on the Web.

~~~
z3t4
those C/C++/Rust apps will perform worse on the web and a lot of glue code
will be needed.

------
markdog12
Keep in mind nacl/pnacl, as a more mature technology, is ahead of WebAssembly
wrt features, such as threads, simd, etc.

I know these are coming to WebAssembly, but who knows how long it'll take.

~~~
xemoka
More mature, and soon only available in chrome extensions and apps:
[https://blog.chromium.org/2017/05/goodbye-pnacl-hello-
webass...](https://blog.chromium.org/2017/05/goodbye-pnacl-hello-
webassembly.html)

Chromium is refocusing on WebAssembly

~~~
markdog12
Yep, I'm aware, my point is it's still behind.

------
DamonHD
Interesting perspective. I've largely kept out of that fight for many reasons,
but it is interesting to see a counter-argument to the Mozilla/Firefox just
apes Chrome story.

~~~
nachtigall
> but it is interesting to see a counter-argument to the Mozilla/Firefox just
> apes Chrome story

I think looking at Quantum
([https://wiki.mozilla.org/Quantum](https://wiki.mozilla.org/Quantum)) and
Phonton ([https://www.ghacks.net/2017/03/31/firefox-photon-new-
design-...](https://www.ghacks.net/2017/03/31/firefox-photon-new-design-
mockups-show-interface-and-more/)) this becomes even more clear.

~~~
mrec
I agree that Quantum is exciting, but if there's anything interesting about
Photon the article you linked really didn't bring it out. What aspects were
you thinking of?

~~~
H4CK3RM4N
I think it's just used here as an example of Moz://a not aping Chrome, by
moving their UI even further away.

------
diafygi
Will there ever be a way to have constant-time functions in WebAssembly?
Relying on WebCrypto primitives is fairly limiting.

------
moonfern
In 2016 the global games market had $99.6Bn revenue and a 8.5% YoY. PC had a
27% +4.2% market share, TV 29% +4.5% , mobile 27% +23.7% tablets 10% +4.5% and
casual webgames 5% -7.5%. (source:Newzoo) Google with it's presence in mobile,
tablets and web seems to be the winner, edge will support webassembly in the
future and mozilla which is much smaller than opera on mobile reminds me of
Xerox.

------
alex_duf
I wonder if we can do scala native -> llvm -> webassembly. Anyone tried?

------
Vinnl
I don't really like the headline. I don't want Mozilla to "win", and I don't
think Mozilla wants to either; I want the open web to flourish.

That said, the article is very informative, and well-balanced. It was really
good of Google and the other browsers to join the wasm bandwagon. And yes,
although as the author himself points out, "proclaiming a "winner" is
unimportant or even counterproductive", Mozilla does deserve a lot of credit
here.

~~~
nthcolumn
It is joke - we had 'Chrome won' the other day. There is a hidden point being
made which you would probably agree with.

~~~
chii
i hate how HN now has titles that require knowing previous posts to
understand.

That's the domain of reddit.

~~~
xiaoma
I've seen this on HN, going back to at least 2007 or 2008.

~~~
_delirium
I especially remember that in the first few years of HN there was an
expectation that everyone had read Paul Graham's essays and would recognize
references to them.

------
SimonPStevens
It's worth pointing out that Mozilla can only continue to put pressure on
Google and fight for the open web if people continue to use Firefox and
support them. Consider switching to Firefox even if you prefer Chrome. Report
websites that don't support FF. We are all better off for the existence of
Mozilla, and strong viable competition to Chrome and IE.

~~~
jeswin
Even if thousands of developers from HN switch, that would hardly move the
needle. Ordinary users just won't care about any of this.

Servo, which I think is the most important software project in the world, is
where it will start to change. That's when those of us who may not be directly
contributing code into Servo need to come out and do our thing. I still fondly
remember the NYT ad and the crop circle. We should do it all over again.

~~~
kuschku
I doubt that would help.

As the lead dev of VLC in a recent interview said, they’ve been offered huge
amounts of money to include Google Chrome in their installer, and saying no
was the hardest decision he’s ever made.

As long as Google has fraudulent ads for Chrome "your browser is outdated,
update now to Google Chrome" on their websites, as long as Google
intentionally makes the experience worse for Firefox (see the youtube
redesign), as long as Google pays developers to ship Chrome as malware with
every single installer, as long as Google forces OEMs to install Chrome with
Android, Chrome will rule the market.

The only solution now is the EU.

~~~
tambourine_man
Agreed with everything but your first sentence.

MS was a much bigger impenetrable monopoly and the Web was won back. It can be
done again. Having a great product and grassroots evangelism certainly help.

(Not that I think Chrome is THE ENEMY. It's constantly evolving, multiplatform
and open source. IE was none of that. But I agree Google's practices you
described are despicable. Huge kudos to VLC for doing the right thing)

~~~
valarauca1
Whoa.

Internet Exploder was constantly evolving and multi-platform.

Did you forget IE ran on PPC Macs, X86 Macs, Windows, and CP/M?

IE updated... just slower than Netscape.

~~~
jchw
IE ran on... _CP /M_? What CP/M are you talking about?

~~~
echeese
They probably meant Windows CE or Pocket PC (P/PC)

------
frik
I can't wait to see ad networks abuse WebAssembly. /s

------
__name__
Mozilla wins a battle but loses the war

------
desireco42
Which I believe was Brendan Eich initiative. Mozilla without him is just not
the same project.

------
ericfrederich
WebAssembly and PNaCL always seemed like a hack. A very elegant thought-out
hack, but still a hack. It required a 64 bit OS but could only ever operate in
32 bit space.

Should have been dead on arrival because of that fact alone. For something
that was trying to bring C/C++ and video games into a browser setting a 4GB
max on memory should have been a non-starter.

~~~
Vinnl
I'm afraid pretty much every part in the pipeline of getting websites to your
computer and shown on screen is a big giant hack of which it's a wonder that
it even works at all, most of the time.

~~~
kibwen
s/getting websites to //

------
midnitewarrior
Congrats for winning!

This does not change Firefox being on its final death throes though.

Chrome won where it counts.

~~~
tommica
And that is a sad thing :( I really hope Firefox comes back with a new push
towards better web, and keeps pushing it!

~~~
ZenoArrow
In terms of usability it's already on a par, it's just a question of waiting
for average users to have a strong enough reason to switch. Potential speed
improvements from Project Quantum seem like the best hope in the short term.

------
hacker_9
WebAssembly will finally put an end to the constant battle between browser
vendors as to who has the fastest Javascript Engine. The endless benchmarks
about how V8 is faster, or Chakra is faster, or SpiderMonkey is faster, and so
on and so on. Hundreds of thousands of millions of man hours have been poured
into building the fastest JS parsers imaginable, and now WebAssembly is going
to come along and side step the whole thing in one go by moving the parsing
stage off of the client.

Javascript parsing technology will go down in history as ultimately the
biggest waste of time that mankind ever indulged in, all because no one stood
up and questioned if this language was even a good fit in the first place. In
a few years the WebAssembly creators may even win the Noble Peace Prize for
finally ending the biggest battle in the never ending "browser war".

~~~
stdbrouw
> Javascript parsing technology will go down in history as ultimately the
> biggest waste of time that mankind ever indulged in

If there is absolutely nothing else in this world that you can think of that
might be a bigger waste of time than performance optimizations that have
benefited billions of users for many years, you're not trying very hard.

