
What makes WebAssembly fast? - nfriedly
https://hacks.mozilla.org/2017/02/what-makes-webassembly-fast/
======
aphextron
My excitement for WASM has nothing to do with speed or efficiency of the
runtime. It's all about finally having a universal compile target for the web.
We're finally going to be able to develop web apps in a proper language of our
own choosing, without needing hacks like TypeScript.

Hopefully, this will lead to real dedicated IDE tooling and standardized
libraries for the web along the lines of what's available in iOS and Android
native development.

~~~
charlieflowers
True. I agree with it all.

However, by then, TypeScript might be so darn good that people choose to keep
going with it!

It really does have a better type system than C# in a lot of ways.

~~~
throwaway010317
Could you please elaborate on how TypeScript's type system is better than C#?

~~~
nothrabannosir
I disagree with OP, but two interesting corollaries of TS type semantics are
its strong type inference and structural typing:

Const x = [{x: 3, y: "hi"}, {x: 9, y: "bye"}];

Automatically gets you x: "Array of {x : number, y: string }". And if you
declare the same type somewhere else, as long as they're "structurally
equivalent" (i.e. same x and y types) you can actually use them
interchangeably. You can't do that e.g. with c#, where one class will never be
exchangeable with an unrelated class , no matter how similar the definitions.

This lets you do some funny stuff like"subset type detection ":
[https://gist.github.com/hraban/66c1778cdd31868034b12db93fcce...](https://gist.github.com/hraban/66c1778cdd31868034b12db93fcce41c)

All in all, it's more of an oddity than an actual strength, if you ask me.
It's necessary to emulate JS semantics, but I wouldn't consider it an
advantage in a new language.

~~~
aphextron
> You can't do that e.g. with c#, where one class will never be exchangeable
> with an unrelated class , no matter how similar the definitions.

Agreed. Duck typing is a killer feature. I can't say how many time's I've
rolled a new class for no reason other than data structuring, which would have
been far preferable as something just defined inline.

------
Svenskunganka
> In the last article, I explained that programming with WebAssembly or
> JavaScript is not an either/or choice. We don’t expect that too many
> developers will be writing full WebAssembly code bases.

I see this statement all the time, but it doesn't make sense. If you're
looking at any programming language out there, they all have a growing members
of their community asking and showing interest in targeting WebAssembly for
their language of choice. It's not just C/C++. Go, Rust, Ruby, Python,
Crystal, Nim, D, and many more. Now you might get the reaction that "meh, why
would anyone write web apps with Rust?", but that's an irrelevant question.
Companies are going to see this as an opportunity to save resources and become
more efficient, especially since wasm has so much better perf than JITed JS
and the possibility of going isomorphic is a reality (back-end & front-end
written in Ruby for example, deriving from the exact same codebase and shares
code).

Now I'm not saying "WebAssembly will take over JS!", what I'm saying is that
it perhaps, possibly, maybe will. It will depend on these languages and how
they add support for it, what abstractions and integrations they provide with
their current ecosystems. And of course, how WebAssembly will improve over the
coming years.

~~~
ncantelmo
I agree completely, but I would take it a step further:

If wasm doesn't overtake JS, something else that offers native bindings to
other languages will eventually. There are huge benefits to be had for teams
that want to be able to code their full stack in a language that isn't JS.

We never asked for JavaScript (well the vast majority of us), but we've been
stuck with it for the past two decades for all things web. Now that a doorway
to replacing it with a general-purpose solution has been cracked, I expect the
industry to kick it wide open as soon as possible. Not because JS is bad per
se (it has certainly gotten _much_ better), but because a lot of developers
would simply prefer to use something else.

~~~
shadowmint
> something else that offers native bindings to other languages will
> eventually...

No it won't.

This is our one chance to kill javascript; if we don't do it now, it'll be
entrenched forever, and best we'll ever get is 'compiles-to-js' languages like
clojurescript and typescript.

Let's be realistic; who has the man power, community good will and business
savvy to push an entirely new language across all platforms, mobile and
desktop?

Microsoft? Come on. Apple? Google? Google tried with dart and failed.

Who else, seriously, is going to step up?

We can day dream about the magical 'no js' world, but it's _never going to
happen_ if web assembly doesn't work.

Currently we're seeing the reverse, js stretched off the browser, onto the
server, into mobiles, onto iot devices.

You've got to layout some pretty damn fine arguments about why that trend is
going to suddenly reverse.

Web assembly is pretty much our last best chance to flip javascript off and
have something better...but it might already be too late for that to work. :/

~~~
wybiral
> This is our one chance to kill javascript; if we don't do it now, it'll be
> entrenched forever, and best we'll ever get is 'compiles-to-js' languages
> like clojurescript and typescript.

Do people really hate JavaScript that much? I've grown fond of it in recent
years, especially after ES6.

~~~
bluejekyll
Yes. People really hate JavaScript that much. ES6 brought some sanity to the
language, but I continue to be firmly in the camp of continuing to hate and
despise its existence.

~~~
wybiral
Weird. I remember hating it ages ago. So much so that I was developing a
Python->JavaScript transpiler (before all the cool kids were writing
transpilers!) and blogging about how bad it was [1].

Granted, that was back in 2008 and most of my complaints have been addressed
now almost a decade later (except for destructors, it still doesn't have
those, but I also don't need them anymore).

These days I move between JavaScript, Python, Go, and C seamlessly and I can
honestly say that I don't hate any of them as much as clients, managers, and
3rd party code.

[1] [http://davywybiral.blogspot.com/2008/01/javascript-
bad.html](http://davywybiral.blogspot.com/2008/01/javascript-bad.html)

~~~
bluejekyll
People have definitely had and continue to have successful careers in, and
many actually enjoy, JS.

I would never debate that. I think language choice for many people is a
personal decision. There are some that I will hold my nose and use; not even
complain too much. There are others that the minute there is an alternative
to, I would use that instead. JS is in the latter camp for me.

If it helps, my current favorite language is Rust... they may be syntactically
similar, but I just can't stand the semantics, or lack there of, of JS.

------
rocky1138
On one hand, I'm excited about performance improvements. On the other, I
lament the fact that this will kill one of the best parts of the web: the fact
that the source is sent to the end user instead of a binary. It now makes the
code and how it works opaque, thus killing the spirit of innovation and
learning.

~~~
wybiral
Agreed. But I've felt that way about minified JS for a long time too. I'm not
sure there's a way around it.

------
TazeTSchnitzel
The edge over asm.js is a subset of this. Obviously, asm.js neither has JIT
reoptimisation overhead, nor garbage collection to worry about.

However, a weird, highly-annotated strict subset of JS is not the ideal
representation of what is basically portable assembly language. WebAssembly's
big strength over asm.js is it has smaller executables and they can be rapidly
decoded and verified in binary IR form, rather than having to shove megabytes
of ungzipped bracket-fest through a JS parser.

~~~
chrisseaton
> Obviously, asm.js neither has JIT reoptimisation overhead

Why does it never need to re-optimise the JITed code? I know WebAssembly and
asm.js are more static than JS, but even very static languages like C benefit
from speculative optimisations which may need to be reversed. For example
asm.js and WebAssembly have branches don't they? Does the JIT always compile
both branches even if one has never been taken in practice?

And what is the reoptimisation overhead anyway? If deoptimisation is caused by
a bad speculation on the same thread, it's zero overhead on the fast path
until it's used isn't it?

~~~
acqq
> For example asm.js and WebAssembly have branches don't they? Does the JIT
> always compile both branches even if one has never been taken in practice?

WebAssembly is treated just like other "real binaries" produced for the "real"
OS. Whatever survived the static optimizations while producing the binaries is
converted, at the end, to the pure machine code, you don't "trace" it in run-
time by the user.

> even very static languages like C benefit from speculative optimisations
> which may need to be reversed.

I'm not aware of "speculative optimisations which may need to be reversed" in
C, and I'd be very interested to read what you mean when you write that,
possibly with some links and references. Do you mean run-time, by the user, or
something else?

~~~
Someone
I think that is left open to the implementation. _If_ an implementer thinks
there is a benefit in doing so, he's free to do so.

In fact, that's similar to how a CPU runs "real binaries". Modern CPUs use
_some_ runtime information to make code run faster. Examples include branch
predictors and the recognition of stride lengths to move data into the cache
before the instructions being executed need it.

That's only small bits, but it _is_ runtime information. I do not rule out
that WebAssembly developers, similarly, will find hat there are ways to use
runtime information that speed up WebAssembly code.

~~~
acqq
I think you confuse the tracing during the interpretation of JavaScript with
asm.js&WebAsm. Namely asm.js&WebAsm are designed to avoid as much as possible
anything deciding in the run-time, except for verifying and generating the
machine code, exactly because these "let's see what the code is doing in the
run-time" were already implemented and were used for "plain" JavaScript, but
had too much overhead, compared to what asm.js&WebAsm does (or avoids to do),
for the kind of uses where asm.js&WebAsm are desired.

For the "plain" JavaScript, there are the run-time decisions.

> Modern CPUs use _some_ runtime information to make code run faster. Examples
> include branch predictors and the recognition of stride lengths to move data
> into the cache before the instructions being executed need it.

Sure. But that run-time information is internal to the CPU. And the CPU will
use it for the native binary code that is the final result of asm.js or
WebAsm, just like any other. But that native binary code is "static," it's
explicitly not "small traced chunks" the way "plain" JavaScript is handled.

> I do not rule out that WebAssembly developers, similarly, will find hat
> there are ways to use runtime information that speed up WebAssembly code.

Think about that: it they would find something like that, exactly the same
technique could be used to speed any native code, including Linux kernel and
anything native you imagine.

If you manage to develop software method that actually improves the execution
speed of the native code in run-time, you'd be famous and (if you know how to
market it) rich.

~~~
barrkel
> I do not rule out that WebAssembly developers, similarly, will find hat
> there are ways to use runtime information that speed up WebAssembly code.

 _Think about that: it they would find something like that, exactly the same
technique could be used to speed any native code, including Linux kernel and
anything native you imagine._

That's exactly what profile-guided optimization does. It's not a new
invention, it's working technology. And it's far from inconceivable that PGO
could be applied to the intermediate code that web assembly effectively is.

Specific example: a common tradeoff made in compilation is between space and
speed, and there are some cases - like padding to align a jump target - that
can win big speed improvements in inner loops, but are pessimal when used
liberally (because code size inflates and doesn't fit in cache). Realigning
jump targets is something that can be done to compiled code, in particular
compiled code before it has been linked, when all the relocations and fixups
are still available. Having information about hot code can make a big
difference here.

(BTW: optimizing linkers are surprisingly involved here, particularly for
targets that have a bunch of addressing modes, like x86. Some ways of writing
in fixups can result in smaller code (e.g. 1 byte offsets rather than 2 byte
offsets), but this effect cascades: making code smaller can make what used to
be a 2 byte offset possible to fit in 1 byte. Don't underestimate the amount
of optimization that your linker does with native code (if you have a smart
linker; my experience is from the Delphi compiler source).)

~~~
acqq
> it's far from inconceivable that PGO could be applied to the intermediate
> code that web assembly effectively is.

A developer could do some kind of PGO before he produces the final binary, I
can imagine that. But then it's still just a static binary.

And I personally can't imagine PGO being done in the user's browser and not
being slower than the alternative of not doing it, just like I've never heard
of some OS which does PGO on the native binaries when user runs them. Maybe
you know of something like that? The PGO I know is always a slow process, done
only before shipping the binary to the user, it's a kind of "post-processing"
step of compiling, not of the normal execution at the user's computer.

~~~
brianwawok
Java does PGO on every server running Java in the world.

Even some swing apps benefit once you get it started up..

That said, I'm not sure the full JVM is coming to browsers anytime soon.

~~~
acqq
The target model of the asm.js (and therefore WebAsm) intentionally doesn't
assume the "VM" features that Java VM has. It's much, much lower level. No
classes. Even no strings.

Java VM receives the classes, methods, strings, has GC and all that, but it
has to JIT to reach that lower level to be efficient and has to do a kind of
establishing what's actually used, similarly to what tracing JIT engines for
classic JavaScript do.

I believe that kind of run-time measurements and then code generation and
optimization is what some Java people call PGO, and what asm.js at the moment
intentionally (by design) avoids.

In short, Java's PGO on the user side is not what PGO for static languages
like C is (by the developer). And asm.js is even lower than C. It's really
closer to... asm.

Exactly because asm.js avoided these decisions was Firefox with asm.js support
faster than Chrome at the time the later treated all js code the same.

------
lacampbell
I really hope web assembly takes off and becomes a thing wide implemented in
all the major browsers. The web is such a fantastic application platform
(despite its frequent misuse...), and removing the javascript performance tax
will be huge.

~~~
Taek
JavaScript is not just a performance tax, it's also a language that is poorly
suited to a great number of tasks which we would like to apply web browsers to
today.

Not that it is all around terrible, but definitely much preferred if we can
choose the best language for the job instead of being strictly stuck with
JavaScript.

------
johncolanduoni
Is WebAssembly's binary format finalized? I wasn't able to find anything about
it, but about two weeks ago binaryen pushed a new release[1] whose notes said
"update wasm version to 0x01, in prep for release, and since browsers are
ready to accept it".

From what I had heard the plan was not to do that until the final standard was
settled on, but I wasn't able to find any corresponding announcement.

[1]:
[https://github.com/WebAssembly/binaryen/releases/tag/version...](https://github.com/WebAssembly/binaryen/releases/tag/version_28)

~~~
callahad
Yes. Here's the announcement: [https://lists.w3.org/Archives/Public/public-
webassembly/2017...](https://lists.w3.org/Archives/Public/public-
webassembly/2017Feb/0002.html)

------
daurnimator
What's the point if you can't interact with the DOM? Almost all examples of
webassembly just render to a canvas.

Does this mean instead of a normal "native app" I'm going to start getting C
applications compiled with wasm and distributed in electron? What does this
possibly gain the end user?

~~~
callahad
You're unnecessarily constraining your thinking to the present-day Web. WASM
fundamentally expands what's feasible in that domain.

For instance, access to the DOM doesn't really matter for game engines like
Unity or Unreal, or for lower level libraries like OpenCV, libsass, or
libarchive which you might want to use in your web application.

No one is arguing that WebAssembly will completely replace JavaScript,
especially not right out of the gate, but it _will_ be used to optimize hot
code paths within JS apps, as well as allowing robust, efficient, native
libraries to be used directly on the Web. This is more about the pie getting
larger than it is about WebAssembly hypothetically crowding out JavaScript.

~~~
daurnimator
> For instance, access to the DOM doesn't really matter for game engines like
> Unity or Unreal

My point was who _wants_ these to be in the browser? I mean they're cool as
demos, but I don't see the use. Is it just people using web browsers as the
content delivery platform instead of e.g. Steam?

~~~
pdkl95
> who wants these to be in the browser

Anybody that resents the user having ultimate control over the _User Agent_. A
game in e.g. the Unity engine isn't important. Instead, there are a _lot_ of
people that would love to replace their (easily adblockable) web page with a
small opaque binary that contains freetype, custom layout/UI library, and
maybe "drm"-like obfuscation. You don't need the DOM if you intent to render
everything yourself.

At best, we will see a new wave of "flash intro"[1] style "custom user
experience" replacing perfectly usable HTML pages. At worst, this could be the
catalyst that replaces what remains of the open web with a locked down "cable
tv"-like mess.

[1] [http://www.zombo.com/](http://www.zombo.com/)

~~~
lomnakkus
That's an interesting idea, but I'm not sure if it's got any legs for "mostly-
content" sites given the inherent unsearchability of that approach.

------
ClassyJacket
>At least 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.

I support anything that improves performance and efficiency. But the best of
both worlds is always great. I'm wondering if it would be possible to
implement reference counting (and maybe automatic reference counting) similar
to Objective-C, and if so, would that simply be a matter of the particular
language and WebAssembly transpiler you're using supporting it? And are there
disadvantages to reference counting that make it a bad idea? I enjoyed using
it doing earlier iPhone programming.

~~~
q3r3qr3q
> And are there disadvantages to reference counting that make it a bad idea?

I thought it had a performance cost.

~~~
ktRolster
Not much of one. The amount of time it takes to allocate the memory and free
it is the dominant factor.

~~~
comex
Maybe in the non-atomic case. Atomic refcounts force synchronization between
CPUs when different threads access the same data, even if they only read it;
that can have a quite significant cost.

~~~
repsilat
They also tend to prohibit some smart gc optimisations like moving your shit
while you're not looking, and the cache behaviour can be bad because either,

\- the data isn't stored next to the count so you get two pointer indirection
per access, or

\- the data _is_ stored next to the count, and the object gets cached-in when
it gets collected.

Piggybacking on the thread because I haven't had much concrete experience with
smart pointers: how does the "circular chain" problem seem to manifest? Is it

\- "goes wrong quickly," usually picked up and fixed without too much trouble,

\- "like any old memory leak" \-- maybe a problem if processes run a long
time, hard to track down, or

\- devs are usually smart enough to see them coming, knowing to keep the "has
a pointer to" relation a partial order (either by type or some other natural
hierarchy.)

?

------
etimberg
I recall seeing a test compile of some C++ code to WebAssembly instead of JS
and on Chrome it was an order of magnitude slower than the JS version. Has the
performance increased lately?

------
hoschicz
Javascript is an awfully designed language (it's getting better, but the
basics are awful, no ints, crazy comparsions...) I hope that it will die soon
and enable everybody to write web apps in a language of their choosing.

This may even end the craze around JS frontend tooling.

------
msoad
I can totally see Qt a and .NET apps running on top WebAssembly. Imagine MS
Word is running in your browser without them having to rewrite it in JS!

~~~
dmarcos
WebAssembly won't give you unlimited power. You will still have the browser
sandboxing and security / privacy policies in place. Accessing to the local
file system is for instance constrained in the browser for good reasons.
WebAssembly apps will be able to do what Web APIs let any page do.

~~~
mstade
Is this universally true – i.e. baked in to the wasm spec – or is it just true
in a browser environment? Consider things like NW.js[1] or Electron[2] – might
we see cross platform apps being developed where all or parts of it are
written in <insert language here> and compiled to wasm, then packaged up with
a runtime and delivered as a "native" application for desktop, mobile, or
whatever?

[1]: [https://nwjs.io](https://nwjs.io)

[2]: [https://electron.atom.io](https://electron.atom.io)

~~~
noam87
What would be the benefit of that? Might as well just compile to native and
distribute that without all the overhead, no?

~~~
mstade
I probably should have specified but I was referring to GUI applications
specifically. For things without a GUI, or that require deeper system
integration than you get with these runtimes you're absolutely right – there's
little point. But for a very large class of GUI applications it makes a lot of
sense, working with technologies that not only have stood the test of time and
are good enough for plenty of use cases, but also mean you can with very
little effort package your application for multiple operating systems. Some of
these applications will need stronger performance than can be provided by the
JS engine, so hence the question re: wasm.

Does that make more sense?

------
austinjp
"the team working on React could replace their reconciler code (aka the
virtual DOM) with a WebAssembly version."

Is anyone working on such a thing?

------
astrodust
It's both amusing and absurd that what was practically intended as Java's
little helper, JavaScript, has grown up to be this thing that might actually
replace Java entirely.

How long until there's a really good JVM written in JavaScript of some form
and embedded Java apps end up running in JavaScript for performance _and_
security reasons?

It'll be even more ridiculous and hilarious if the "j" in "jruby" ends up
meaning "JavaScript".

~~~
batmansmk
Java and Javascript are related like Car and Carpet are similar. There was no
historical connection between Java and JavaScript beyond renting the brand
"Java" from Sun to make the language more credible.

~~~
zeveb
Well, it's possible that if it hadn't been for Java JavaScript might have had
a decent, parens-based syntax.

I still wonder what might have been if Eich had been allowed to write the
Scheme system he had been hired to do. While I'm not a fan of Scheme by any
means, it is approximately 281,757,423,024,353 better than JavaScript.

And Scheme's a great little language for implementing _other_ languages.
Imagine, we could have had transpiling years ahead of time. We might be using
S-expressions instead of JSON. Heck, we might even have moved to an
S-expression syntax for HTML & CSS by now.

Imagine, one syntax for everything (thanks to
[https://www.w3schools.com/js/tryit.asp?filename=tryjs_intro_...](https://www.w3schools.com/js/tryit.asp?filename=tryjs_intro_inner_html)
&
[https://www.w3schools.com/css/css_howto.asp](https://www.w3schools.com/css/css_howto.asp)
for the examples):

    
    
        (html (head (title "Example")
                (style (body (background-color linen))
                       (h1 (color maroon)
                           (margin-left (px 40)))))
              (body
               (h1 "What can JavaScript do?")
               (p (@ (id "demo")) "JavaScript can " (em "change") " HTML content.")
               (button (@ (type "button")
                          (onclick (set! (inner-html (get-element-by-id document "demo"))
                                         "Hello JavaScript!")))
                       "Click me!")))
    

The world could have been so much better.

~~~
nessus42
I'm a _HUGE_ fan of Scheme. And of Lisp, in general. But having seen in the
"real world" how so many people are so adverse to Lisp's beautiful syntax, I'm
pretty confident that JavaScript would never have caught on if it looked like
Lisp rather than like C.

~~~
zeveb
They wouldn't have had a choice, though, just as folks don't have a choice
with JavaScript.

I imagine that folks would have cottoned on to the advantage pretty quickly.
And those that didn't … I guess they could have always become telephone
cleaners or something:-)

~~~
brlewis
Pure Scheme would not be sufficient. You need at least DOM-handling libraries.
And if those libraries were poorly designed, then people wouldn't cotton onto
the advantage quickly. Look at DSSSL.

~~~
fiddlerwoaroof
Because of macros lisps are more resistant to bad APIs than other languages,
in my experience.

~~~
brlewis
That is a very good point.

------
kristianp
When compiled from C/C++, does WASM do bounds checking of pointers and arrays?
What kind of memory safety does it offer?

~~~
azernik
WASM offers a virtual machine to the user, in which there are global variable
slots, a stack for local variables, and one or more "linear memories" (chunks
of RAM for heap allocations). The first two are completely bounds-checked -
you tell the virtual machine to operate on a certain offset in a global/local
variable ID, and you are safe from your access affecting anything outside of
that variable.

The linear memories, on the other hand, are up to you - you can execute
operations on address within a linear memory, and it's up to you if you messed
up and overwrote or read out data that you shouldn't have. What you _do_ get
is a) protection against heap overflows affecting values outside the heap, and
b) protection against execution of heap data. In the future, they're also
planning to support multiple linear memory segments, which would allow you to
isolate memory used for potentially-buggy dynamically-allocated buffer code
from memory used by less-fragile or more-sensitive code. WebAssembly.org's
descriptions indicate that linear memories would be used both for C/C++ heap
allocations and for any local/global variables accessed with operators (like
the & reference operator) that make it hard to make these distinctions
statically.

More information on the security properties of the system:
[http://webassembly.org/docs/security/](http://webassembly.org/docs/security/)

General information on linear memory semantics:
[http://webassembly.org/docs/semantics/#linear-
memory](http://webassembly.org/docs/semantics/#linear-memory)

------
pmontra
> At least 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.

Ouch, back to the 80s, early 90s. I think I'll stick with JavaScript at least
until WebAssembly gets garbage collection. I might be wrong but I don't see
many people writing SPAs in C++ for the extra speed (let's say, the JS layer
acting like an X Server for the DOM, driven by a C++/WebAssembly application).
Games, yes.

Furthermore JS has view source. WebAssembly has a text format [1] but it's
really assembly. Hopefully there will be source maps [2].

[1] [http://webassembly.org/docs/text-
format/](http://webassembly.org/docs/text-format/)

[2]
[http://webassembly.org/docs/tooling/](http://webassembly.org/docs/tooling/)

~~~
deburo
The lack of GC is a benefit here. Remember, WASM as an MVP is meant to bring
C/C++ codebases on the web.

There is plenty to be excited about here. This will enable faster [media apps,
games, etc]([http://webassembly.org/docs/use-
cases/](http://webassembly.org/docs/use-cases/)) on the web. Wasm is knocking
at the door and I can't wait to see what it's bringing with it.

Edit: HN really should support a few more formatting options.

~~~
Salgat
It's not a benefit, it's simply a temporary compromise to get it out faster.

------
calahad
What makes a compiled executable faster than interpreted code seems kind of
self evident.

~~~
Qwertious
I see what you mean, but it's actually possible for JITed code to be _faster_
than compiled code, as JIT can make run-time optimisations that aren't visible
at compile-time.

~~~
raarts
True fact but not really useful if this only applies to 0.01% of the cases.

------
tannhaeuser
I realize this is about discussing technical merit, but I'd like to share a
less naive view of what WebAss does to the web (eg. DRM, making ad-blockers
impossible, etc.) over in the [other thread]
([https://news.ycombinator.com/item?id=13755370](https://news.ycombinator.com/item?id=13755370)).

Right now, the discussion evolves around finding fecalia-/coprophilia-inspired
names for the WebAss ecosystem. Can't wait until America Awakens to contribute
:)

