
Bringing the web up to speed with WebAssembly - yugoja
https://blog.acolyer.org/2017/09/18/bringing-the-web-up-to-speed-with-webassembly/
======
whoisthemachine
WASM has the potential to change the world... a thought: while WASM will
initially appear in compute-intense functions in web apps, it has the
potential to be a true "Common Language Runtime". It may become the future
platform that native, _dekstop_ apps run on.

This could be a good thing, if done correctly:

1\. Desktop apps have a common, safe runtime upon which they run, and the
packages can be easily distributed (and verified?) by browsers

2\. "Web apps" could potentially go away - leaving web browsers for what they
were intended, document sharing

~~~
lmkg
I have the suspicion that one possible future of HTML is to be a legacy
delivery wrapper for WASM code and a <canvas> element.

~~~
RubenSandwich
I hope not as HTML has accessibility built in while canvas doesn’t. No need to
take a step backwards on this. I’m okay with rendering to canvas but long as
accessibility is taken into account. (Hint: most of the time it is not.)

~~~
wlesieutre
I've said the same, but you just know somebody comes along and says "If we
render our entire site into a <canvas> it'll make ad blocking more difficult,"
and then _poof_ there goes the last 20 years of work on accessibility.

~~~
vbezhenar
We can port webkit to wasm, so our developers won't have to deal with browser
inconsistencies anymore :)

~~~
weinzierl
Yeah, and V8, so we could just write JavaScript again and wouldn't have to
deal with WASM. With a bit support from WASM and a few tweaks to V8 it could
run near native JavaScript speed. Let's call it JavaScript paravirtualization.

~~~
jfbastien
Interpreters can go a long way, but JIT code generation is required for really
fast dynamic language implementation. That's quite a bit off for WebAssembly:
[https://github.com/WebAssembly/design/blob/master/FutureFeat...](https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#platform-
independent-just-in-time-jit-compilation)

------
austincheney
WebAssembly is really going to bring some awesome fast processing for binary
heavy tasks, like video and gaming, to the web. Essentially, WebAssembly is
the new Flash, but it is an open standard, more secure, and language agnostic.

Despite this I really get the impression a lot of non-JavaScript developers
are really hoping this is some holy grail to allow them to write in their
favorite language for the web platform, which WebAssembly absolutely isn't.
Everything running from WASM is in an isolated sandbox. For obvious security
reasons this isn't likely to change.

~~~
hdhzy
> Essentially, WebAssembly is the new Flash, but it is an open standard, more
> secure, and language agnostic.

I disagree. Flash could draw things without interacting with DOM thorough JS.
Also Flash had sophisticated IDE. WebAssembly is just asm.js+ with a strong
aim to compile C/C++ for the web, so you don't need to rewrite anything.

~~~
drdrey
WebAssembly is a compilation target (like JVM Bytecode). You need an IDE for
the source language, not the target.

~~~
panopticon
That's his/her point; they were trying to point out why Flash and WebAssembly
aren't analogous.. Flash was a cohesive toolchain; not a build target.

------
TheAceOfHearts
I was a bit skeptical of WebAssembly when it started popping up, but reading
through this and the MDN docs has made me get a bit more excited.

In a few years WebAssembly might make for a great environment to learn about
lower level programming. I've always loved assembly, since it gives you the
bare minimum of concepts and tooling from which you can build everything.

What's the reasonable thing to do when a grow-memory instruction returns -1?

How are people using WebAssembly? Are there high-quality polyfills available
for older browsers?

How is forward-compatibility expected to be handled? Right now there's only
WebAssembly with the core feature-set. What happens as some vendors start to
add support for varying features such as GC, SIMD, threads, etc.?

~~~
avaer
> I've always loved assembly, since it gives you the bare minimum of concepts
> and tooling from which you can build everything.

Well... modern assembly is monstrously complex. Probably more so than your
favorite high level programming language. Modern assembly is generally not a
bare minimum, because it's designed to give compilers the interface to run
code fast, not to be easy to program by people.

And WebAssembly is a bit of a misnomer since it's not quite your processor's
assembly; it's designed to be assembled fast on the client side, while also
being memory-safe. Ironically that makes it simpler than actual assembly.

~~~
fasquoika
It sounds like you're assuming they were talking about x86 when they didn't
actually specify...

------
Animats
I suspect that the use cases for WebAssembly will be something like this:

\- < 10% user-beneficial compute in the browser

\- 60% ad and tracking obfuscation

\- 20% annoying scrolling and transitions

\- 10% hostile code

~~~
justinpombrio
That's about the breakdown for Javascript too, right?

~~~
Animats
Probably, but only the first use case needs more performance.

------
Asdfbla
Really interesting paper. When I first heard about what WebAssembly was trying
to achieve, I naively wondered why people didn't just slap some existing
interpreter for bytecode into browsers (JVM, .NET, maybe even adapt LLVM?) and
go with that. I knew people had been burned by Java applets, but I was still
curious why they invented something new again instead of possibly adapting
existing stuff.

Of course I accepted that they surely had some good reasons for doing it the
way they did, but the paper has some interesting specific points in favor of
the Webassembly and against existing stuff like the JVM (easier verification
of the bytecode etc.).

------
umamimc
My worry is, does this make it easier for the big companies to silo the
internet more completely? From a developer POV with regard to performance,
this seems great, but from the standpoint of open communication, it seems
problematic.

~~~
gsnedders
It doesn't make it any easier than minified, obfuscated JS.

~~~
jerf
Out of curiosity, is there anybody in the last couple of years who would say
that reading the source of websites was a significant component of their
learning the web? (By "significant", I don't mean "primary" but I do mean more
than "I once popped open a bit of source and found a method I didn't know
existed".) Even in 1997, I was using free documentation, not reading websites,
which even before minification and such were still often quite ugly to read.

------
flavio81
I love Webassembly, because It will eventually remove Javascript's dominance
from the web for good.

~~~
golemotron
Eich's support is poetic.

------
grondilu
This is probably hand-waving but : instead of implementing threads directly
into the WebAssembly language, would it make sense to compile a known micro-
kernel to WebAssembly and then compile the C standard library (which, IIRC,
implements threads)?

~~~
Rusky
This wouldn't help at all. Kernels (micro or no) can only implement preemption
with the help of hardware timers (and, if you want parallelism, hardware
cores), which Webassembly cannot access. (The C library does not implement
threads; it merely wraps the kernel's implementation of them.)

So at some level WebAssembly itself must provide some sort of primitive for
threading, or else at best you'll get cooperative coroutines/an event loop.

------
sulizilxia
I wonder how this will affect Java in the long term. In the comments about the
JDK9 release, there was discussion about the JVM becoming a sort of language-
agnostic platform where Java is a small part. It seems WebAssembly is
occupying a lot of the same space, but from a sort of opposite direction (in
the sense of providing the compilation target first).

Java and the JVM obviously aren't going anywhere soon, but the history of
javascript, node.js, etc. leads me to suspect WebAssembly could displace the
JVM in the long term.

~~~
austincheney
Java is a language. It comes with a standard VM, compile mechanism, and
bytecode. Fortunately, the Java platform is well segmented so that the
language is a separate technology from those other pieces. Scala, for example,
is a language different from Java, but still targets the compile mechanism and
JVM.

WebAssembly, by contrast, is not a language. It is only a bytecode and
conforming container. Java could compile to WebAssembly instead of its
standard bytecode and the biggest difference is execution environment. In
order for WebAssembly to displace the JVM it would have to run where the JVM
can run with appropriate levels of support.

~~~
sulizilxia
I was a little unclear about this, but I meant Java in the broad sense of the
Java ecosystem, including the JVM and the language. I was mostly wondering if
languages will move toward WebAssembly as a target instead of the JVM, and
what consequences that will have.

On the other hand, maybe I had Java the language in mind unconsciously at some
level. You're right that you could have Java targeting WebAssembly instead of
its standard bytecode, which I hadn't thought about.

At least now, it seems like the JVM offers some stuff that WebAssembly
doesn't, but I have a hunch it won't stay that way in the long run.

There's been a lot of good discussion here about WebAssembly versus the JVM;
it seems like lots of people have similar thoughts about this topic.

------
haberman
> nothing in its design depends on the Web or a JavaScript environment. It is
> an open standard specifically designed for embedding in multiple contexts,
> and we expect that stand-alone implementations will become available in the
> future.

I did not realize that the design was this ambitious! I wonder how lightweight
a standalone implementation could be, while still getting competitive
performance.

------
pedrocr
We spent a long time wishing for a VM for the web that could be targetted by
any language and being told that wasn't possible. WebAssembly will finally
deliver that and it seems to be done by the same people/organizations. What
changed?

~~~
fasquoika
>We spent a long time wishing for a VM for the web that could be targetted by
any language and being told that wasn't possible.

Technologically speaking, this has been _possible_ since the days of p-code.
The browser vendors have only just decided that it's something that's actually
beneficial

~~~
always_good
It's also been possible since Javascript.

------
batmansmk
Yet, almost one year after its release, nobody makes money directly or
indirectly with wasm... despite the beauty of its engineering, I'm starting to
worry. Who will continue funding it if nobody uses it?

~~~
tannhaeuser
Exactly. WASM stories always bring up wild fantasies of platform world
domination, when in reality there aren't APIs for even the most basic things,
let alone practical apps.

In a heretical way, I've got to ask why not just use JVM byte codes, an
incomparably more established platform at this point with several mature VMs
and sophisticated API ecosystem, albeit not necessarily in the graphics space?
Why did we want to rid browsers of Java in the first place just to start all
over with it?

~~~
Rusky
Java doesn't provide a sufficient security model for running arbitrary
C/C++-like code, which is the entire purpose of WebAssembly. Drop that and all
the new use cases will just go back to asm.js instead.

~~~
pjmlp
Sure it does,

[https://github.com/graalvm/sulong](https://github.com/graalvm/sulong)

[http://dl.acm.org/citation.cfm?id=3132204](http://dl.acm.org/citation.cfm?id=3132204)

~~~
Rusky
That's... not Java or the JVM providing the security model. It's impressive
but it's not a comparable solution to WebAssembly.

------
dangjc
Webassembly is incredibly hard to debug in the browser. Source maps give you a
decent stack trace, but you can't evaluate variables. I'm hoping this
situation improves.

------
bnolsen
AKA how to bring more advertising and tracking crap to your browser...I really
do hope it's not that.

------
dang
Url changed from [https://blog.acolyer.org/2017/09/18/bringing-the-web-up-
to-s...](https://blog.acolyer.org/2017/09/18/bringing-the-web-up-to-speed-
with-webassembly/), which points to this.

acolyer.org's glosses on papers are excellent and I like reading them myself,
but sometimes it's a bit of a struggle knowing where to situate them on HN
given the original source rule
([https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)).

Edit: changed my mind. Like I said, a bit of a struggle.

~~~
krallja
I think you made a good choice: acolyer.org posts provide enough additional
analysis, comparisons to previous posts, and meta-commentary to stand on their
own.

------
primeblue
JavaScript is so 2015, long live C++

