My feeble attempt at a non-too-technical, mostly FUD- and hyperbole-free FAQ about WebAssembly.
Is WebAssembly CPU machine code?
No, WebAssembly is an intermediate format more akin to .NET or Java bytecode than machine code. If you don’t like the .NET or Java association, just think of it as an instruction set of a ‘fantasy CPU’.
Is WebAssembly assembly code?
No, ‘assembly code’ usually means the text representation of a specific CPU instruction set. WebAssembly in its typical form is neither a text representation nor is it CPU-specific (the WASM spec does define a text representation though, which is basically WebAssembly-assembly).
Is WebAssembly “Java Applets/ActiveX/Plugins 2.0”?
ActiveX and browser plugins were native machine code DLLs where the security was built on trusting a 3rd-party and wishful thinking. With WebAssembly the trust rests solely on the browser maker and his ability to secure the browser sandbox.
Is WebAssembly a security risk?
Can I access sockets, files, native API X… from WebAssembly?
Can I load and call into a DLL from WebAssembly?
No, DLLs are native machine code and thus off-limits.
Slightly related: WebAssembly supports dynamic linking between WASM modules, this allows to reuse shared code modules (the idea is to reduce download size by moving shared code into a separate module which can be cached locally).
Can I start a program or process from WebAssembly?
Nope, same reason as DLLs, it would be unsafe.
Can WebAssembly be used to circumvent adblockers?
…but what about ‘Show Source’?!
As a frontend developer, do I need to learn C/C++ now?
Can WebAssembly manipulate the DOM?
Isn’t WebAssembly useless for garbage collected languages?
YES AND THANK THE GODS FOR THAT! Erm, actually no, scratch that :)
It is true that WebAssembly doesn’t have garbage collection support, but this doesn’t mean that a WebAssembly module cannot implement its own garbage collector. Look at Unity3D’s IL2CPP, Kotlin Native, or clang’s Automatic Reference Counting for examples of garbage-collected languages that don’t need a garbage-collected VM to work. There is some info about potential GC support in a future WebAssembly version here.
But WebAssembly programs are too big!
This is not the fault of WebAssembly itself, which is a very compact byte code format, but usually is a problem of the code base that’s been compiled to WebAssembly.
There are several reasons why WebAssembly modules can become bloated:
- Language runtimes: Most languages need some sort of runtime library to be useful. In C this includes functions like printf, strcmp, fopen, … in C++ the std library classes can be considered the runtime even though most std library code is in inline methods. Higher level languages like C# have a much ‘richer’ runtime, this is good for programmer productivity, but terrible for code size.
- Huge ‘Modulith’ Projects: Large C++ projects like AAA game engines or big UI frameworks are easily multi-million-line code bases, and also often heavily use OOP features like dynamic dispatch (virtual methods). Such code bases make it very hard for the compiler’s dead code elimination to do its thing.
- 3rd-party-dependencies: Many libraries and (for instance) game development middleware haven’t been designed with binary size in mind, and adding such dependencies carelessly can quickly grow out of control.
In the ‘native world’ executable sizes of several dozen megabytes are not uncommon these days, but on the web this is simply not acceptable. The TL;DR is to use a more ‘embedded-programming’ philosophy when writing code for WebAssembly (also here’s one of my older blog posts about the topic: 10 simple diet tricks for asm.js).
WebAssembly programs can be small, but it takes effort. Hopefully now that ‘executable size’ is important again, we will also see more developers focus on this. Maybe somebody comes up with a smallest-possible C runtime (I’m sure there’s still room for improvements if seldom-used features are removed).
If WebAssembly is running in the JS engine, how can it be fast?
That’s about all the FAQ-worthy questions I can think of for now. Until next time :)