- Games
   - Emulator cores
   - Crypto
   - Compression
   - Software graphics
   - Audio processing
   - Computer vision
   - Physics engines
   - Other heavy math/matrix/constraint solvers
   - In-memory databases

    - DRM

When it's possible to ignore the DOM by uploading your own renderer (e.g. custom freetype/etc compiled to webasm), it's possible to prevent adblocking based on HTML/CSS selectors.

Yes, well-designed sites will use WebAssembly in other more reasonable ways. Entirely separate from that are the websites that try to disable the right-click context menu to "protect" images, and the businesses that are watching there revenue disappear with the rise in adblocking. Some businesses will - often foolishly - use all available means to "protect their content", so that's how they will use WebAssembly.

Presumably you'll be authoring a "NoAss" add-on, following along in the "NoScript" tradition.

More fecalia-themed names:

AssAssassin

SafeAss

MyAss

OpenAss

SafeMyAss

OpenMyAss

$ file /usr/bin/ruby

/usr/bin/ruby ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=4b353b68b7d8b46a570883c82efe48db9d77ef22, stripped

Looks like somebody managed it ;)

Snark aside, the trick for running managed languages on the WASM virtual architecture is the same as running them anywhere else: compile the runtime to the target, then ship the runtime with your program. That's what Go does, and why its hello world binary is 1.6 MB.

For a working example, PyPy.js (https://pypyjs.org) successfully ports Python to asm.js. It costs about 5MB in overhead, so it's not a practical alternative to JavaScript, but at this point it's mainly an optimization problem. If a language can statically analyze what libraries and runtime facilities a given program requires, then it can strip out everything else, leaving behind a reasonably sized binary for delivery over the Web.

That said, I agree that more people will want to work in higher level languages, though I kinda suspect "most" are going to still prefer Javascript for the forseeable future - so I sorta see JS compiling to WASM as inevitable.

A clue lies in the fact that all the major browser vendors (Google, Microsoft, Mozilla, Apple) are implementing WebAssembly. What is the strategic reason for this?

The speculation is that it all has to do with the rise of native mobile apps, which posed a threat to the web-entrenched interests. Google, I'm guessing, would prefer that you to stay in the web browser, using Google Search to to find all your applications, running them Google Chrome, and remaining a captive audience for Google's advertising clients. (instead of are searching for apps in the App Store and running them natively).

One important reason that native apps initially took off was that games, and other interactive content, could not be efficiently implemented for mobile web browsers. WebAssembly (in combination with WebGL) pretty much solves this problem. People have already ported a number of C++.OpenGL games to the web using emscripten.

> I, and everyone else I know, has little to no interest writing C/C++/Rust in the browser

I understand that most 3D game development is done in C++. I'm guessing that you don't know a lot of 3D game developers?

Besides games, many professional applications are developed in C++, for a variety of reasons. Examples could include scientific, engineering, graphics and audio processing software.

> Most of the people I know want to write Java/Python/Ruby/Elixir/Scala/C#/Clojure in the browser

Python is an interpreted language and CPython is implemented in C. You can cross-compile to WebAssembly today and start running Python scripts in the browser. Performance critical paths in Python scripts, like NumPy operations, which are offloaded to compiled C functions, would be offloaded to compiled WASM functions.

As for garbage collected languages, like Java and C#, future versions of WebAssembly will provide low-level GC primitives, which should theoretically allow those languages to run in the web browser as well. Having said that, you would incur the overhead of having to run the JVM/CLR virtual machine inside the browser engines's own JavaScript/WebAssembly virtual machine.

> 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.

I suspect there is a lot of interest from C/C++/Rust developers already, and will continue to grow as WASM matures. Something like 10 million professional developers know and use C++ regularly, so this is a not insignificant usergroup on its own.

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

Kind of like how it does on a regular compiler

Nevertheless, here are a few of the main reasons you might want to work in a language that can easily target WASM:

1. Wholesale porting of desktop applications and game engines to the Web. This is the guise under which we developed asm.js, and it resonated well enough that Epic and Unity added support for asm.js to their engines.

2. Re-using existing, well-tested libraries that are written in C/C++. Why settle for zip.js if I can use libarchive directly? What about libraries that don't necessarily have high-quality JavaScript equivalents, like OpenCV, Box2D, or libsass?

3. Shipping high-performance codecs for multimedia formats like FLIF, BPG, and AV1 that aren't natively supported by browsers. Mozilla is actively using this strategy to develope the AV1 codec: https://hacks.mozilla.org/2017/02/webassembly-will-ease-coll...

4. Optimizing hot paths in JavaScript codebases, in the same way that Python or Ruby programmers will often re-implement individual functions or modules in C to overcome bottlenecks. For an example of this, consider the Flask microframework in Python, which depends on the Jinja2 templating library, which depends on Markupsafe for escaping HTML. Buried inside markupsafe is a 200 line file, "_speedups.c", that speeds things up. So even if end-developers aren't writing C/C++/Rust, they can still benefit from libraries that incorporate WASM.

5. Saving battery life. The fewer cycles it takes to finish a computation, the longer the CPU can spend sleeping. WASM provides significantly greater control over exactly what executes, and you can opt to burn CPU cycles on optimization once, during compilation, to get more a more efficient .wasm artifact for everyone. Since WASM is statically typed, the compiler also has many more optimizations available to it; no more worrying about monomorphism or type inference as with a JS VM's JIT compiler.