
A cartoon intro to WebAssembly - happy-go-lucky
https://hacks.mozilla.org/2017/02/a-cartoon-intro-to-webassembly/
======
tantalor
The "cartoons" are buried in the navigation at the end of the post:

[https://hacks.mozilla.org/2017/02/a-crash-course-in-just-
in-...](https://hacks.mozilla.org/2017/02/a-crash-course-in-just-in-time-jit-
compilers/)

[https://hacks.mozilla.org/2017/02/a-crash-course-in-
assembly...](https://hacks.mozilla.org/2017/02/a-crash-course-in-assembly/)

[https://hacks.mozilla.org/2017/02/creating-and-working-
with-...](https://hacks.mozilla.org/2017/02/creating-and-working-with-
webassembly-modules/)

[https://hacks.mozilla.org/2017/02/what-makes-webassembly-
fas...](https://hacks.mozilla.org/2017/02/what-makes-webassembly-fast/)

[https://hacks.mozilla.org/2017/02/where-is-webassembly-
now-a...](https://hacks.mozilla.org/2017/02/where-is-webassembly-now-and-
whats-next/)

~~~
Heff
Heh, I was gonna say it seemed pretty low effort.

------
coltonv
I'm a bit lost on the appeal of webassembly. I can see why it's kinda cool to
be able to ship a different language to browser and retain performance and
bundle sizes, but the problem is I, and everyone else I know, has little to no
interest writing C/C++/Rust in the browser.

Most of the people I know want to write
Java/Python/Ruby/Elixir/Scala/C#/Clojure in the browser: high level
scripting/VM based langauges which require no memory management and have high
level features and data structures. As far as I can tell, these can't target
WebAssembly since they don't target LLVM (and you certainly will never be able
to compile a language like Ruby to LLVM)

I'd love to hear some of you guys talk about what uses you have for
Webassembly and what exciting things it will let you do.

~~~
tshannon
The first language I see making use of webasm is typescript. They can see a
lot of performance improvements over javascript by including type information
in the compiled assembly.

~~~
judah
FYI, the author noted that wasm-util[0] compiles TypeScript to WebAssembly.

Also, the author notes that future versions of WebAssembly may contain garbage
collection features, which would be relevant to TypeScript.

"Garbage collection: If you can define your types ahead of time, you should be
able to turn your code into WebAssembly. So code using something like
TypeScript should be compilable to WebAssembly. The only hitch currently,
though, is that WebAssembly doesn’t know how to interact with existing garbage
collectors, like the one built in to the JS engine. The idea of this future
feature is to give WebAssembly first-class access to the builtin GC with a set
of low-level GC primitive types and operations."

[0]: [https://github.com/rsms/wasm-util](https://github.com/rsms/wasm-util)

~~~
greenhouse_gas
Why can't Wasm compile the GC as simply another thread in the app?

Kind of like how it does on a regular compiler

~~~
abecedarius
Yes, when you're compiling a particular language to wasm, you could include a
GC in wasm code as part of that language's runtime system. But it wouldn't
interoperate with the Javascript GC, or GCs for other wasm modules compiled
from other toolchains.

------
nabla9
History keeps repeating itself. Alan Kay's idea was that objects are moved
around. You don't request a data structure like html, you request an object
and it runs in the new system.

1) Oberon had an idea of 'slim binaries' portable binaries that can be
compiled into object code in a single pass. Loading would be almost as fast
loading a file. Slim binaries were designed to be slim and fast.

2) Then came java, jvm and java applets People said that jvm is the plaform.
Java will be is just one language using that platform. Compiled java objects
were not so slim and fast to recompile :(

3) JavaScript became de facto portable platform but they are not binary.
Browser became the client virtual machine.

4) Now we have WebAssembly. Lets' hope that WebAssemply is actually slim and
fast representation like slim binaries.

------
jrvidal
Maybe the most interesting bit (in part 6/6): Browser Preview is over, they
can start shipping it!

[https://lists.w3.org/Archives/Public/public-
webassembly/2017...](https://lists.w3.org/Archives/Public/public-
webassembly/2017Feb/0002.html)

~~~
callahad
Firefox 52 will ship with WebAssembly support in exactly one week. The era of
a JavaScript monoculture on the Web is over.

~~~
batmansmk
WebAssembly has no access to any of the web API (DOM, ...) . WebAssembly
cannot start without javascript as of right now. Flash died because of one
platform not supporting it. The very same platform still doesn't support
WebAssembly. As much as I love the hyper around WASM, I don't want to overhype
it, otherwise, it will be a almost non-event as NPAPI.

~~~
callahad
I think that's an overly pessimistic view, which complements my overly
optimistic view. :)

> _WebAssembly has no access to any of the web API (DOM, ...)_

WebAssembly _can_ access those APIs via indirect, opaque shims today. Direct
access is on the roadmap.

> _WebAssembly cannot start without javascript as of right now._

We're still hammering out semantics on the HTML side, but WebAssembly modules
can define a `start` entrypoint that is automatically invoked when the module
is loaded. Combine that with ES6's `<script type="module">` and you've got
WASM that can load and begin executing without JS.

> _Flash died because of one platform not supporting it. The very same
> platform still doesn 't support WebAssembly._

Apple is a party to WebAssembly's development and a co-signatory on the linked
announcement that the WebAssembly binary format and Web APIs are complete.
This doesn't mean they'll necessarily ship in a timely manner, or at all, but
it's a damn good sign.

> _I don 't want to overhype it_

That's fair. The world won't change overnight, but it's clear that the world
_is_ changing in fundamental ways. The initial changes may be insignificant,
but they'll compound over time and as WebAssembly matures.

JavaScript isn't dead, and WebAssembly won't kill it, but it _will_
dramatically change the landscape. In a similar vein, C will never kill
Python, but I'd be shocked if most moderately complex Python applications
_didn 't_ depend on a module implemented in C somewhere in their stack.

------
EdSharkey
This web assembly scheme saddens me a bit. I wish the scripting line would not
be crossed and we could stick to JIT-compiled JS or even dialects that can
execute closer to the metal (like asm.js). It's just so nice to be able to
have all the codes - I've found that even the most aggressively minified uber-
scripts can be pretty printed and studied.

All the arguments in favor about saving bytes and offline compiling would seem
like only short term gains since network, cpu's, and memory sizes are going to
continue to improve.

And, it's certainly not Flash or Java Applets all over again since there are
multiple competent vendors in the mix. Yet, I fear a new wave of
unconstrained, impenetrable code schlock will flow from content creators once
this thing hits the mainstream.

~~~
pager86
Just because its binary doesn't mean it can't be studied. Even with something
like compiled native machine code its still relatively easy to disassemble and
look at how it works with the right tools. With WebAssembly, dissassembly
should be even easier and be more clear than native x86 or something. Still
not as easy as well written javascript, but I expect it will approach the
difficulty of minified js.

In my eyes, the size and offline compilation aren't even the biggest benefits.
Having a low level assembly language for web computation lets people write in
any language and compile it for the web. There's already an LLVM backend for
it - although still experimental. But this may even mean we can simply port
existing codebases to WebAssembly with little performance loss.

You've been able to compile stuff for web for a while, by transpiling to
javascript, but the result has been too slow for many applications, so it
never really picked up.

~~~
azakai
> I expect it will approach the difficulty of minified js.

WebAssembly has less structure than minified JS (instructions are a linear
list - a stack machine - for example) and it is less hackable (it isn't
intended to be written or modified by hand).

WebAssembly will be somewhere in between native x86 and minified JS in terms
of how open it is to being studied.

------
danellis
> With this improved performance, JavaScript started being used for things no
> one ever expected it to be used for, like server-side programming

Oh, how quickly we forget.

~~~
bhaak
Please elaborate, I don't get what you are suggesting.

JavaScript was hacked together in short time for the browser. You can't get
any less server-side than that?

~~~
evilpie
Might be a reference to Netscape Enterprise Server[1], which had server-side
JS in 1995?

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

------
paxcoder
>Some applications of WebAssembly may be held up until [direct access to DOM]
is resolved."

I don't know what number crunching web applications the vendors are thinking
of. I want wasm for client-side web programming without JS.

~~~
thristian
> _I don 't know what number crunching web applications they're thinking
> of..._

Games, and WebGL games in particular.

~~~
paxcoder
Surely they're not chasing native just for games

~~~
__jal
Search for 'mobile app revenue by category'. I'll wait.

------
flaviuspopan
Awesome intro, that was pretty easy to follow :)

Just a few small typos to point out:

[https://hacks.mozilla.org/2017/02/what-makes-webassembly-
fas...](https://hacks.mozilla.org/2017/02/what-makes-webassembly-fast/)

"Executing" section - "...know how to write code so that they compiler can
type specialize it" \- the compiler instead of they compiler

"Conclusion" section - "etching WebAssembly takes less time because it is more
compact than JavaScript, even when compressed" \- missing the f in fetching

~~~
callahad
Thanks! Looks like these have been fixed.

------
vvanders
Article misses one of the big marks as to why WebASM could be faster. Manual
memory management allows for much better cache utilization which is usually
where managed languages spend most of their time vs native languages.

------
teabee89
I am so afraid that WebAssembly will make too many assumptions that will
prevent Go from targeting it as a platform.

~~~
abstractbeliefs
A well designed assembly language should be targetable by any well designed
IR. When the Go team decided to work on their own compilers instead of writing
frontends for existing compilers, they chose to take on that effort.

What assumptions is wasm making that will prevent Go from targeting it, and
why are those assumptions fundamentally harder for Go to target than LLVM IR?

~~~
porjo
Not sure about assumptions made by wasm, but current limitations preventing Go
from targeting it are:

 _> there is no efficient way to implement setjmp/longjmp functionality
currently, therefore it's not a viable target of a gc port. We need to wait
until it gets real stack unwinding and exception handling support._

[https://github.com/golang/go/issues/18892](https://github.com/golang/go/issues/18892)

~~~
abstractbeliefs
Well, thankfully TFA includes a short paragraph talking about the
standardisation of exception handling, so here's hoping to have that resolved
soon.

