
Introduction to WebAssembly: why should we care? - ingve
https://tomassetti.me/introduction-to-webassembly/
======
rekado
I'm worried that this will make the JavaScript trap[1] even more of a problem.
The default operation of the web is to allow remote sites to push non-free
applications to your browser that it then proceeds to execute.

As people have been shifting towards running _everything_ in the browser (just
like people like me run everything in Emacs), this effectively results in a
revival of ubiquitous proprietary software.

I don't think this is desirable.

Granted, we already have this problem with plain minified JavaScript, but as
we shift more towards treating the web as a platform for which to compile
software, this problem is going to become worse.

I'd love for the web to be a set of stable application interfaces that in-
browser applications can talk to. Give me the sources and I'll use my package
manager to build the JavaScript applications I want my browser to execute for
particular online services. I want more control over the increasingly complex
software that we're expected to just execute blindly upon reception.

[1]: [https://www.gnu.org/philosophy/javascript-
trap.html](https://www.gnu.org/philosophy/javascript-trap.html)

~~~
munificent
I think the idea that "access to source code == freedom" is out of date.
Imagine someone gave you a thumbdrive with the complete source code for all of
Facebook's products, build system, infrastructure, _everything_ that's checked
into their repositories. They also gave you legal carte blanche to do as you
feel with it.

Would you be free of Facebook? Would you be able to do anything useful with at
all?

No. The problem is that Facebook still has all of the _data_ and that's where
the freedom and control live today. The code is just an interface for it.

Online multiplayer game developers figured this out decades ago. The primary
way to prevent people from cheating is not by preventing them from hacking or
cracking the client application code. It's keeping the game state — the data —
only on the server.

~~~
mikegerwitz
Yes that's a different problem different than software freedom:

[https://www.gnu.org/philosophy/who-does-that-server-
really-s...](https://www.gnu.org/philosophy/who-does-that-server-really-
serve.html)

------
osrec
I know a lot of people long for the days when the web was just text and a few
JPGs. I personally am waiting for the web to become a rich, ubiquitous,
standardised application delivery platform that works on any device. I think
web assembly adds to the richness while being fairly standardised, so I
welcome it!

~~~
_red
These things are cyclical:

* Early computers (1960-1980s): Dumb Terminal - Remote Server

* Early PCs (1980s-1995): Local Processing - Remote Storage

* WWW (1995-2010s): Dumb Terminal - Remote Server

* JS/ASM/Etc (2010s - near future): Local Processing - Remote Storage

Its fully possible that we will switch again to dumb terminal model. For
instance, once the hassle of local code execution takes it toll, someone will
have the bright idea of just putting the web browser itself in the cloud and
just having a remote control connection to that browser....and the cycle will
begin again.

~~~
hood_syntax
Yeah, if we want latency added to literally every action... I understand that
what you're saying is a possibility, but I sure hope it doesn't come to pass.

~~~
TheRealPomax
New technology starts with the above-well-off, using tech you currency
consider "absurdly unattaible to the masses" (like cars in the 20s, or
telephone in the 40s, or computers in the 60s, or 24/7 internet in the 90s):
for instance, when you just get a basically free gigabit connection straight
into the backbone (like in a new upscale Japanese apartment building) the very
idea that latency could even be a problem just... disappears.

In that context, just attaching an interactive window to a remote running
process (as long as it can stream faster than whatever is your minimum
acceptable framerate at your minimum acceptable resolution) is literally
indistinguishable from running locally. So I frankly do hope that comes to
pass (as long as I also get to keep being able to build a desktop computer for
working offline).

~~~
adrianN
Latency and bandwidth are different though. Your GBit connection won't help
you access servers on the other side of the Atlantic.

~~~
TheRealPomax
I have no idea why you would need to leave your country in a world where we're
back to thin clients and remote processing. Pretty sure the most obvious place
for that processing to take place is at what used to be ISPs and have in this
hypothetical future become Interactive Service Providers rather than
"internet" service providers, with low latency, high bandwidth hubs in or near
your city (and more likely, multiple hubs per city).

------
Endy
We shouldn't. All the nonsense we're trying to cram into the Web is making it
harder to justify connecting to it. I long for the days when simple images and
text were the norm. Nowadays, I need to have and devote constant system
resources to a tracking-blocker, cookie-blocker, an ad-blocker, a script-
blocker, a separate javascript-blocker, and a who-knows-what-else-blocker,
just to do the things I want to do; let alone the things I need to do.

~~~
dbbk
Okay, say every browser had a built-in tracking, cookie, ad, script blocker
etc. How would you propose websites then make any money?

~~~
mikestew
That’s not my problem to fix, no proposal is required of me.

~~~
dymk
Okay, then don't expect anybody to build one. Web browsers are incredibly
complex, and nobody is going to build one for free nowadays.

~~~
mikestew
Wait a minute, did I misunderstand? I thought we were talking about how
websites would make money, not build browsers. Are you saying that Apple, who
doesn’t depend on web advertising AFAICT, wouldn’t build this hypothetical
browser because other companies wouldn’t make money? A more macro economic
view, then?

------
pjmlp
I am betting when WebAssembly gets mature all Web sites will look like Flash,
just coded on the framework of choice, thus finally making the browser just
yet another VM.

~~~
MaxBarraclough
In the process, specialised web browsers such as browsers for the blind, will
be rendered useless.

~~~
pjmlp
Probably, or will make use of whatever features the "native" frameworks might
support.

Gtk+ and WPF have very good support for people with disabilities.

~~~
MaxBarraclough
Well sure, non-web platforms won't be affected by the self-destructive trend-
chasing of the web.

The harm to disabled users remains.

------
pdkl95
Remember that WebAssembly means no more ad blockers as soon as someone ports
freetype. The behavior of a program written in a Turing complete language
cannot be predicted without running the program[1]. Ad-blocking by regexp or
DOM element doesn't help when the entire contents of the page - including the
ads - is just a bunch of {canvas,WebGL} draw calls generated by a blob of
obfuscated code.

[1]
[https://en.wikipedia.org/wiki/Halting_problem](https://en.wikipedia.org/wiki/Halting_problem)

~~~
Figs
> when the entire contents of the page - including the ads - is just a bunch
> of {canvas,WebGL} draw calls generated by a blob of obfuscated code.

Your site would also be unreadable by Google, meaning that you'll be heavily
penalized in search ranking and no one will find your abomination of a website
designed this way.

~~~
dingo_bat
If it becomes the norm Google crawler will start running the pages and looking
at the content.

~~~
scanr
It already does

------
charlysl
"Its development is backed by people at Mozilla, Microsoft, Google and Apple."

It seems this is for real then?

JS has had a surprisingly long life actually given its original use cases, and
I understand the objections to wasm, but I guess that something like this was
inevitable given how big the browser is as a platform and how web apps have
been steadily fattening on the back of a suboptimal language, which, if this
goes ahead, can be confined to just UI again.

They are planning to add support for gc, threads, bigger mem, tail recursion,
etc [1], so will it be running everything efficiently? Even on mobile, given
its backers?

Wow

[1]
[https://github.com/WebAssembly/design/blob/master/FutureFeat...](https://github.com/WebAssembly/design/blob/master/FutureFeatures.md)

~~~
steveklabnik
It's probable you can already use it on mobile today. I have.
[https://caniuse.com/#feat=wasm](https://caniuse.com/#feat=wasm)

------
jokoon
The toolchain feels pretty clumsy and bloated, there are many intermediary
stages that should be done automatically.

I hope better alternatives will quickly become available, or at least some
package where you don't to install a thing inside the thing you already
downloaded and installed.

~~~
emj
Agreed since the toolchain is aimed at automatic conversion of C/C++
applications to WebAssembly, emulating filesystems, graphics etc, that makes
it feel sluggish for me. At this point I haven't seen many people using
WebAssembly directly to develop for the web. Mostly it's people who write to a
canvas.

This game logic in Rust was a good example of at least some communication with
javascript in a non bloated way:

[https://news.ycombinator.com/item?id=15843064](https://news.ycombinator.com/item?id=15843064)
[https://aochagavia.github.io/js/embedded-
rocket.js](https://aochagavia.github.io/js/embedded-rocket.js)

~~~
sjmulder
Agreed, back when I got the tooling up and running it generated a whole bunch
of things to emulate stdio and such. I couldn't figure out how to make a
freestanding wasm library.

I wish I could just do `wasmcc -ofoo.wasm foo.c` and get a `foo.wasm` that I
can include, without any implicit dependencies and such. Let me supply malloc
if I call it. I'm sure there'd be libc-lite libraries in no time (if they
aren't there already, I'm out of date).

------
Fifer82
I am still a bit baffled.

I am a TypeScript user and in the article he states:

For instance, instead of compiling TypeScript to JavaScript, its developers
could now compile to WebAssembly.

Alright, so I don't need to be a C/C++ dude to get some WebAssembly goodness
(maybe some day).

But now with this in my toolbelt. What occurs? What does it mean? If I have a
particle simulation in TypeScript on Canvas using Shaders... Now I compile to
WebAssembly, but now what? Can I still access Canvas or is Canvas like a 4th
dimension? IF I can't use Canvas, how do I render to screen?

~~~
TazeTSchnitzel
You're baffled because the author has no idea what they're talking about.
TypeScript is a superset of JS, it makes no sense to compile it to a platform
designed for AoT-compiled systems programming languages.

~~~
umilegenio
There is no need to be rude.

TypeScript was used as an example of a well-known language that currently is
transpiled to JavaScript. I am not saying that TypeScript will surely be
compiled to WebAssembly, just that it could.

TypeScript is designed for development of large applications. It is a superset
of JavaScript both because this facilitates learning, but also because there
was really not an alternative. In the end you had to compile to JavaScript. It
is not hard to imagine a language with the same objective of TypeScript that
is compiled to WebAssembly. Furthermore, if TypeScript was compiled to
WebAssembly you could use it wherever there was a platform for the WebAssembly
format. So if somebody created a project to consume WASM binary files and
execute them from within .NET assemblies[1], you could use TypeScript outside
the browser and node.

[1]
[https://www.hanselman.com/blog/NETAndWebAssemblyIsThisTheFut...](https://www.hanselman.com/blog/NETAndWebAssemblyIsThisTheFutureOfTheFrontend.aspx)

~~~
TazeTSchnitzel
> There is no need to be rude.

I apologise. I'm just… rather surprised at such an idea.

> It is not hard to imagine a language with the same objective of TypeScript
> that is compiled to WebAssembly.

It is not hard to an imagine a strongly-typed language targeting WebAssembly,
sure. But TypeScript is not that kind of language. TypeScript is just
JavaScript, and JavaScript, as a highly dynamic language, is a very poor
candidate for the kind of ahead-of-time compilation to a low-level target that
WebAssembly was made for. I mean… it _could_ , technically, be done, but why
would anyone do so? The result would be bigger and slower than normal JS.

~~~
umilegenio
Let's agree that is feasible, but unlikely.

------
Animats
Now, more obfuscated than ever! Better DRM! A few more layers of bloat! Buffer
overflows are back!

Search for WebAssembly demos. There's a crappy tank game.[1] WebGL is doing
all the real work; the game part is simple. There's ZenGarden.[2] 200MB
download. Again, WebGL is doing all the real work.

WebAssembly is going to be a way for sites to bypass ad blockers. That's the
real use case. Maybe the only use case. It's all about reducing user power and
giving total control to the big sites.

[1] [http://webassembly.org/demo/Tanks/](http://webassembly.org/demo/Tanks/)
[2] [https://s3.amazonaws.com/mozilla-
games/ZenGarden/EpicZenGard...](https://s3.amazonaws.com/mozilla-
games/ZenGarden/EpicZenGarden.html)

~~~
jcelerier
It's not always WebGL-y stuff. For instance Qt is working on a WASM
compilation target:

> [https://msorvig.github.io/qt-webassembly-
> examples/widgets_wi...](https://msorvig.github.io/qt-webassembly-
> examples/widgets_wiggly/widgets_wiggly.html)

cf.
[https://bugreports.qt.io/browse/QTBUG-63917](https://bugreports.qt.io/browse/QTBUG-63917)

The WASM binaries are around 10 megabytes for this. That's a lot, for sure,
but this includes a whole windowing system, a raster paint engine, and a C++
reflection mechanism.

~~~
Animats
_this includes a whole windowing system, a raster paint engine, and a C++
reflection mechanism_

All of which the browser already has.

~~~
baq
Yeah but it doesn't have qt built in.

------
roknovosel
I recently made a small project with WebAssembly:
[https://github.com/novoselrok/color-palette-
wasm](https://github.com/novoselrok/color-palette-wasm)

The toolchain (emscripten) is still pretty bloated and I hope they will
streamline the process somewhat.

------
mvindahl
Quoting from the article: "It will make developing for the web easier and more
efficient."

Um .. no. It will make code execute faster but it will be more work to write
and maintain.

For most of the daily bread-and-butter code that we produce, speed is not
awfully important but clarity is. In this equation, you gain a great advantage
from stuff like garbage collection, functional programming, and a well
equipped package manager, i.e. Javascript is a pretty good choice (and
Typescript an even better choice).

On the other hand, if you're writing very specialized algorithmic code which
will be executed a very large amount of times, then WASM and fine tuning is in
place. As cool a technology as WASM may be, a very small fraction of our code
is like that.

My prediction is that WASM will find its place, mainly within some of the more
popular libraries available on npm. If there is anything to gain from
rewriting, say, parts of ReactJS in WASM then it will eventually be done. But
it will be totally transparent to the user of said library.

Taking a view at the server side landscape is also instructive. There is a
plethora of languages which execute faster than JS, yet nodeJS thrives. So it
doesn't seem like people are eager to ditch JS. Hater's gonna hate, of course.

------
arnioxux
People should look at existing emscripten projects to see what the future will
be like since compiling to asm.js is already pretty mature (just a bit slow
and bloated as noted in the article). Any emscripten project can compile to
WASM trivially by adding a `-s WASM=1` compilation flag.

Example projects:

\- OCR (tesseract):
[http://tesseract.projectnaptha.com/](http://tesseract.projectnaptha.com/)

\- Computer vision (opencv):
[https://docs.opencv.org/master/d5/d10/tutorial_js_root.html](https://docs.opencv.org/master/d5/d10/tutorial_js_root.html)

\- Physics engines, retro games/emulators, entire operating systems, and many
many more: [https://github.com/kripken/emscripten/wiki/Porting-
Examples-...](https://github.com/kripken/emscripten/wiki/Porting-Examples-and-
Demos)

~~~
brian-armstrong
I'll plug my emscripten project here too :)

[https://quiet.github.io/quiet-js](https://quiet.github.io/quiet-js)

------
brunoc
> JavaScript has a bad reputation, but in reality is a good language for what
> is was designed for: quickly write small scripts.

That's a little condescending, considering the amount of non-trivial, critical
applications written in JavaScript. And it ignores the progress made on the
language and tooling of the last oh i don't know, 20 years.

~~~
sidlls
Non-trivial, sure. Critical? In what sense?

~~~
pecg
Node.js uses javascript as its default language interface, and considering it
is software intended for server-side, with a userbase ranging from Microsoft,
IBM, Netflix, Yahoo and Paypal (to name a few) in production environments, I
would assert without doubt that it is in fact critical.

------
pmlnr
> In practical terms, WebAssembly is implemented by browsers’ developers on
> the back of the existing JavaScript engine.

Isn't this contrary to the whole idea of wasm?

EDIT: this is a completely serious question, I honestly don't understand why
this is built into the existing JS engines instead of something separate.

~~~
Hasknewbie
WASM uses the current JS/VM environments to leverage its existing
infrastructure (i.e. low-level abstraction and security). In practice it is a
pre-optimized bytecode that only relies on JS primitives, so it does not need
dynamic typing features or GC, i.e. the slowest and least safe parts of JS.
Which means that anything compiled to WASM is "near-native" in terms of
performance, making the use of a separate VM unnecessary.

------
GrumpyNl
From the site: The kind of binary format being considered for WebAssembly can
be natively decoded much faster than JavaScript can be parsed (experiments
show more than 20× faster). On mobile, large compiled codes can easily take
20–40 seconds just to parse, so native decoding (especially when combined with
other techniques like streaming for better-than-gzip compression) is critical
to providing a good cold-load user experience. – from the FAQ of WebAssembly

If you build a website and have to parse something for 20-40 secs for a user,
they should fire you on the spot for bad design. Start working for adult
sites, if loads longer then 2 secs, redesign.

~~~
dingo_bat
Gmail takes around 5 seconds to load over a 100mbit connection. Seems to not
have posed any problem for them.

~~~
CaptSpify
Just because it works and makes money doesn't mean it isn't poorly designed.
It may be that some people care about their users, more than their company's
profit.

Weird, I know.

------
aaron-lebo
I can't tell immediately, but is there anything that compiles WASM to
something native? As in I'd like to write some WASM and then compile that to a
shared library that a C program could load in.

~~~
bschwindHN
Just write it in Rust and have the compiler emit wasm or a shared library.

------
MistahKoala
For non-dev idiots like me, what is it and why is it special? I got the
impression that it allows compiled scripts to run in the browser and is faster
than JavaScript.

~~~
alex_duf
It potentially allows any language (C, C++, Rust, .NET, heck in the future
maybe Java, Scala or anything you want) to be run inside a webbrowser, at near
native speed.

Because any language would be compiled to this intermediate form (wasm) it
would drastically simplify the distribution of complex applications.

Because any language can be compiled to that form, you can potentially reuse
your existing company's code to run it inside a webbrowser

Because it's already integrated in web browsers, it means the technology
deployment promise to be quick.

Because it's just an intermediary form, you can use a typesafe language
(Javascript isn't) and still use it at native speed rather than going through
a step of conversion to javascript.

It's still missing a few key things (garbage collection, interaction with the
DOM) but I see that as being the new standard for pretty much anything. I can
see that being used everywhere, from server side to client side, to mobile
devices, why not hardware support (Is that possible?)

~~~
cm2187
And it will pretty much allow to have a full app that bypasses the
Apple/google app stores and their pay tolls/random policies.

------
adriancooney
I feel like a really big point people gloss over when it comes to WebAssembly
is browser support. It’ll be years before we can drop JavaScript (not that I
want to) because we’ll be waiting for IE and friends to drop of the face of
the planet. WebAssembly could act like a catalyst to propel the web forward or
segment it even more. I’m leaning more towards the latter, at least for the
next 7-10 years or so.

~~~
dbbk
Many sites can already afford to drop IE entirely. Frameworks such as Ember
have dropped support for every version except 11. It is not going to take 7-10
years for you to be targeting evergreen browsers.

------
AngeloAnolin
The more I read about WebAssembly, the more I think it is the rebirth of
Flash, or Silverlight, or JavaFX without being tied to a proprietary entity
(Adobe, MS, Oracle).

Will it be really good for the web in general? I guess it will depend on the
motivation of those who would peruse the technology.

~~~
Skinney
Why? For almost everyone, it would be less work and give better results to
just have a WebASM app render HTML. Except for "legacy" apps written in C++
and some native UI framework, why would anyone bypass using what is already
there and works in a browser? It would be like writing an iOS or Android app
by using C++ and bypassing the native UI toolkit.

------
anonyCowardOz
what does WebAssembly mean For script-kiddies and malicious sites? I mean :
with great power.....

~~~
TomMarius
Nothing. It can't do more than asm.js-compiled Javascript is able to do today.

------
tardygrad
I doubt this will take off, because developers seem to prefer Javascript as a
language.

On the server where there is a choice of several languages both interpreted
and compiled, Nodejs is still very popular. If there were a war against
Javascript people would be moving away from Node.

My guess is that this is going to be another niche, underutilised technology
(like WebRTC or even SVG) that is efficient leads to highly optimised
products, and but lacks mainstream usage.

------
feelin_googley
There is no "war against Javascript" as the author suggests. It just happens
to be the chosen language of the now insidious ad-driven corporate-sponsored
web browser.

It is not Javascript _per se_ , but the so-called "modern" browser that
creates problems for so many users. The problem is not even that this program
exists. The problem is that users are coerced to use it and it is controlled
by a third party that needs to sell something, either to advertisers or to
users.

Again, there is nothing inherently threatening about Javascript. There are
many languages to choose from and anyone can choose not to use it. It is not
tied to the web browser anymore. Unfortunately it is from that association
that it gains a stigma like the one the author suggests with his "war on
Javascript" comment.

Today, there are a variety of standlone JS interpreters, of all sizes, and the
language is routinely used outside of the browser. Peer-to-peer projects use
it. Tiny interpreters for microcontrollers use it. Javascript can live on
without the corporate web browser.

The problem is the irrational assumption one must use a corporate sponsored
web browser to do anything interesting with a computer. This program
automatically runs code _from "anonymous", commercial third parties_, which
today happens to be JS, using the _user 's_ computer resources. The user today
does not get to choose the language, but _more importantly_ , given the level
of coercion and absence of alternatives, she does not get to choose _whether
or not to run the third party code_.

~~~
kbenson
> There is no "war against Javascript" as the author suggests.

Well, there's _my_ war on Javascript, that I wage in my head every time I have
to use it.

> Again, there is nothing inherently threatening about Javascript.

Well, it's not _inherent_ , but it exists. Javascript has ( _had_ , with
WebAssembly) an inherent advantage in that even though you could compile to
JavaScript, there was an inherent mismatch the farther your language semantics
were from it. CoffeeScript is straightforward. Others are less
straightforward. Rust requires a huge amount of runtime to be shipped even for
WebAssembly.

> It is not tied to the web browser anymore.

So, the beachhead is secure, time to advance into the countryside, eh? ;)

------
JSONwebtoken
I haven't been able to find many examples of working WASM projects or
experiments for a topic I have been hearing about for years, but here's one
that seemed pretty well made:

[https://d2jta7o2zej4pf.cloudfront.net/](https://d2jta7o2zej4pf.cloudfront.net/)

However it appears all the video editting effects render slower through WASM
than JS, what's the deal?

~~~
kabes
JS has been optimized to the extreme for years and years. Compilers that
compile to WASM are still new so I'm guessing there's still a lot of room for
optimization.

