
An Abridged Cartoon Introduction To WebAssembly - pk2200
https://www.smashingmagazine.com/2017/05/abridged-cartoon-introduction-webassembly/#
======
IvanK_net
They often forget to mention, that WebAssembly is just a low-level programming
language (much lower than C), it has extremely simple syntax (it has just four
data types, no system calls, the specification takes 5 pages instead of 500
pages of C spec). You may call it a "bytecode", but typical bytecodes also
have around-500-page specifications.

Also, its relation to javascript is not any bigger than the relation to any
other programming language (i.e. there is no relation). A WebAssembly VM could
be made as an extension of any environment.

I recommend reading the official paper
[https://github.com/WebAssembly/spec/blob/master/papers/pldi2...](https://github.com/WebAssembly/spec/blob/master/papers/pldi2017.pdf)
(I learned more than about 50 "essays" that I read about WASM in the past).

~~~
paulddraper
Also: WASM is best as a target for languages that usually committee to machine
code.

E.g. it's great for C, but not really for Python.

~~~
moron4hire
Many languages--like Python--are implemented in C, so it's a pretty natural
chain-of-events to get from there to WASM.

------
gavinpc
I'm of two minds about WASM.

There's the Alan Kay attitude that we can build entire systems on top of
minimal VM's, rather than sacrificing power to bake in more facilities. But
even he says that too much time has been wasted by teams reinventing the wheel
(or flat tire) who didn't really have the chops to do it.

The other side of that, then, is the great potential for interop that
Javascript offers. We now have a worldwide platform with a built-in
presentation layer and a highly-optimized interpreter with useful, reflectable
data structures out of the box. ( _edit_ i.e. it's a viable platform for
metaprogramming... the endgame of which is JS-in-JS (see "prepack")).

I would love to see a future in which the browser (and "personal" computer
generally) remained a locus of significant computation. In practice, I suspect
that highly-intensive tasks (mostly AI stuff) will continue to be done on
servers, not because we lack the processing power, but because end users will
have signed away the custody of all data worth processing. If that is the
case, then WASM's role will be to fill a fairly marginal gap, between what JS
can do, and what has to be farmed out anyway.

So ultimately I hope that WASM offers a lifeline to the computing power that
individuals still have. But given the state of JS (after huge investments), it
feels like starting over again.

~~~
throwasehasdwi
Realistically, as soon as WASM is a good alternative to JS a good part of
websites won't use a single line of JS.

Regardless of arguments for and against whether this is a good idea, market
pressure to open floodgates to other languages will be far too high to ignore.

My prediction is that WASM will quickly evolve into a new way to containerize
applications, very close to a full-fledged VM/OS. The market constantly
demands more features and faster execution. The only logical conclusion is
that the web browser will become an operating system.

~~~
thaumasiotes
Something I ask in basically every WASM thread is: what is the conceptual
difference between WASM ("good") and Java applets ("bad")? How does the system
you describe differ from having the browser implement a JVM?

~~~
amyjess
Conceptually? It's not that different, and the only problems with Java were
its implementation.

* Java was plagued with security problems. One area where Java really shot itself in the foot was that unsigned applets were sandboxed, but signed applets had unfettered access to everything, so you had to choose between signing and sandboxing. And then once security concerns became a big thing, Sun responded by killing support for unsigned applets saying it'll increase trust, but what they really did was make the problem worse by killing the sandbox.

* Java was proprietary until long after its star had fallen.

* Java was introduced when computers weren't that powerful. The JVM took forever to start up and would slow down your whole computer while running. Most of us kept Java disabled unless we had to use an applet for something just because of the massive performance hit.

You can make similar arguments about Flash, too: it too had security holes,
proprietary software, and performance issues.

There is one thing I really liked about Java and Flash, though: you could turn
it off. If you don't want a site loading some heavy Flash monstrosity and
eating all your RAM (I had so many issues with Flash killing the RAM on my old
laptop with only 512 MB of RAM), you could just turn plugins off or install an
extension to force you to click to load Flash content. You can't do that with
JavaScript, so maybe WASM will bring that part of the old days back too.

~~~
Canada
> you could just turn plugins off or install an extension to force you to
> click to load Flash content. You can't do that with JavaScript, so maybe
> WASM will bring that part of the old days back too.

NoScript?

------
kowdermeister
I'll find it really amusing when devs outside the frontend world will storm
in, devs who currently hate working with the browser because of JavaScript.
The problem they will face is that a nice UI will still be needed. Since they
will probably hate the DOM even more than than JS now they can just omit it. A
canvas is canvas, right? :)

But then the next obvious problem will kick in. What should we use to
implement a UI. GTK? WxPython? Swing? Tkinter? QT? JavaFX? Great candidates :)
It will just be great. I mean not, but it will happen, because JS and "browser
tech" is considered sub par (not by me, but I keep reading this).

WebAssembly will bring in lots of innovation, opportunities and also create
the next level chaos. We will look back to the tooling hell as the good old
days of frontend development :)

------
moron4hire
In 20 years of software development and trying different platforms, JavaScript
has been the most frustrating and the most rewarding of all of them.

I find a lot of value in using JavaScript as a cross-platform shell. I
personally do a lot of work on all of the major operating systems. I primarily
(a light primary, like maybe 67%, not 90%) work on Windows, but most of my
users are working on macOS. And we're all writing software that eventually has
to run on Android. There is almost never a problem I can't solve using a JS
project of some kind. That's the rewarding part. I feel like my software goes
a lot further on the JS platform than it could have ever gone on any other.

But it's frustratingly slow. A lot of that is the poor quality of a lot of the
libraries that are available. I'm not really keen on writing my own HTML
templating system, but I'm afraid I might have to just to get the performance
targets I want (I static-gen almost everything).

And I often feel like the language is not doing enough to help me. I love
writing metaprogrammable systems, but the lack of easily accessible,
standardized, advanced type information in JS is a big impediment to that.
Sure, I can enumerate all of the methods an object has available to it, but
there is no good way to enumerate the parameters those methods take, their
return type, or even that they _are_ methods, if I ever happen to get a
reference to one of them sans the object from which it came

And yes, I still do object oriented programming. But the functional story in
JavaScript is not any better. With map, filter, and reduce being methods on
Array, coupled with JS's goofy OO semantics where methods can become detached
from their objects if they aren't explicitly bound to them, things become
frustratingly verbose to get basic functional patterns to feel good.

So a WASM that let me build better dev tools, in better languages, without
losing that cross-platform capability, would be a godsend. Having it run in
the browser also is just icing on the cake at this point.

~~~
jbreckmckye
It sounds like you want to program in TypeScript.

~~~
moron4hire
TypeScript and I have had many bouts in the past. It is not the solution to my
particular problems.

------
vivin
> For now, WebAssembly does not support garbage collection at all. Memory is
> managed manually (as it is in languages like C and C++). While this can make
> programming more difficult for the developer, it does also make performance
> more consistent.

Does this worry anyone else? Or I am getting worked up over nothing?

~~~
thaumasiotes
It seems like the normal thing to do would be to develop for a runtime that
does feature GC?

Of all the things you've ever encountered called "assembly language", how many
supported GC?

~~~
tyingq
It is on the wasm roadmap, along with other things that sound more like a
virtual machine, and less like ASM. I assume to allow for dynamically typed
languages without a download of the entire runtime.

------
tamat
after reading many tutorials about WASM I still figured out one of the most
important questions for me:

Would I be able to call JS functions from WASM? or pass callbacks to WASM.
Because WASM sounds like it goes agains the async nature of JS and I have the
feeling that is going to be very annoying to merge both worlds.

Also if I cannot call any JS func from WASM it means I cannot call WebGL or
Audio so I dont know what would I need the performance if I cannot access the
most performance demanding APIs.

~~~
Rusky
Yes, JS and wasm can call each other. In the long run wasm should also be able
to call web APIs directly.

~~~
infogulch
Is wasm also restricted to running on one thread like js?

~~~
Rusky
No, though neither is Javascript. (I am not sure how far along non-WebWorker-
based wasm threads are, but here's the proposal:
[https://github.com/WebAssembly/threads](https://github.com/WebAssembly/threads))

~~~
moosingin3space
Shared-memory threads are something I hope lands in WASM, since they're part
of the reason you'd want to drop down to WASM in an application in the first
place.

------
Slackwise
Oh cool, the text format[1] appears to be s-expressions!

Sounds like an easy dump from AST to text to wasm. Aside from what the Google
Closure Compiler provides, I wonder what benefit, if any, this may give to
ClojureScript. I'm guessing CLJS will just keep Google Closure for its
optimizations, while Google Closure will output either wat files or wasm
files. Unless optimizations can just be done during wat to wasm, which would
be ideal for other language authors who can just translate to their intentions
and not have to worry so much about fancy optimizations. (I'm rambling at this
point. Sorry.)

[1]: [https://developer.mozilla.org/en-
US/docs/WebAssembly/Underst...](https://developer.mozilla.org/en-
US/docs/WebAssembly/Understanding_the_text_format)

------
jorblumesea
Question...

The issue is that JIT js is hard to improve performance on because it's a
dynamically typed language. Even with Web Assembly, something will still need
to compile down into the bytecode to run. So perf is going to depend on that
step in whatever language you write in and how easily that converts and
optimizes into web assembly standards.

Does this mean that strongly typed languages have a performance advantage,
given that they will be able to easily compile down into optimized typed
bytecode?

------
amelius
Since JS is already quite fast nowadays, how much faster will WASM typically
be?

(Yes, I know, it depends. I'm just looking for a rough estimate.)

~~~
throwasehasdwi
The generalish difference between JS and native code languages like C is about
10X. This varies from around 2X to 50X depending highly on what you're doing.

WASM should run at native speeds minus some special CPU instructions like
vector stuff. So about as fast as highly optimized bytecode languages like
Java, maybe 20% slower than optimized C.

~~~
sp332
And vector stuff (SIMD) is being planned.
[https://hacks.mozilla.org/2017/02/where-is-webassembly-
now-a...](https://hacks.mozilla.org/2017/02/where-is-webassembly-now-and-
whats-next/)

Edit: an even longer list of proposed features.
[http://webassembly.org/docs/future-
features/](http://webassembly.org/docs/future-features/)

------
ericfrederich
Currently browsers only support JS. If you want another language you have to
transpile to JS or implement your language in JS, etc.

If the browser vendors were going to add another language I would have hoped
it would be something so generic like LLVM instead of this WebASM which is too
tied to JS.

~~~
bzbarsky
LLVM bitcode doesn't make a great interchange format, because it's not really
hardware agnostic, last I checked. Obviously you _can_ run it on hardware it's
not created for, e.g. in an emulator or via some extra transpiling. But now
you're introducing some serious inefficiency into the pipeline.

------
backtoyoujim
Is javascript being used as an ORB and this _possibly_ binary byte code is a
bit of machine readable IDL ?

------
acomjean
Looks really interesting, but How does one debug the web assembly code?

~~~
hmottestad
Same way you would C code. Tell the compiler you want to compile for
debugging, and then connect your debugger to the running program. Marks in the
code will tell your debugger what things are called and which line in the
source code you are on.

JS today is often transpiled anyway, so you have to use some mapping to the
source code to do debugging (eg. source maps).

~~~
acomjean
Thanks

I figured the built in browser debuggers wouldn't work so well for this.

~~~
khedoros1
The debuggers would need to be modified to support it, but I don't think
there's a reason that you _couldn 't_ debug wasm inside a browser, if they
were built to understand the debug annotations in the wasm code.

