After reading this article -, I have to share some opinion about WASM. First of all, it is good that WebAssembly is becoming a defined standard. And we have already seen impressive results. Most recently, a demo of Doom3 was compiled to WASM. The result was, that it can run in every browser that has WASM support.

When you read about Web Assembly, you can read about all the high performance languages you now can run in the browser. Never the less, I have to show you now four limitations, that you should consider before migrating to your favorite ‘high performance language’.

First is that WASM is basically nothing more then a binary representation of ASM.js. ASMjs was previously, the go to target when compiling native languages for the browser. It is a subset of JavaScript instructions, that can execute much faster then regular JS. most notably probably, that there are no closures and faster access to uInt8arrays in ASMjs. The new advantage of WASM is, that the binary downloads are smaller and the execution time is more constant. Note: the execution is not faster, but it will be the same on every platform and browser.

Second: You still have the limitation on the JS VM. You only have a single threat. Your favorite language might support multi threats. On the browser you are still limited to a single treat. asynchronous processing with golang will not run concurrently on multiple CPU. At this point, I have a wish. Please enable Web Assembly to work with the new shared memory buffers. This could enable compilers to produce code, that is creating multiple WebWorker, they all could access the shared memory.

Third: Data input output. Within WASM you have limited access to the API’s in the browser. To play games, WebGL has been made available. The same reduced functionality available in JS. For graphic programming I personally look forward to the WebGPU. Coding native with our typical statical languages, you can use many API’s, you can’t in the browser. In browser there is no file system. You can not read files with random access. Also the Networking. It has to stay secure. it will stay within the Virtual Machine in the Browser. Network requests still need to be executed in JS. This will also cause an extra step when transferring data between JavaScript and the WASM program. processing lots of data, I think it will be more effective to directly process it in JS. You WebAssembly program probably is fastest, when it can do more computations with less data.

Fourth: Access the DOM. To build web applications you have to manipulate the DOM. the DOM is not available directly in WASM. Some API wrapper will be needed. You could try to draw you app entirely on a canvas. As of today, I do not believe you can gain performance advantages, that are worth the extra effort.

So, here you have it, do you still want to use WebAssembly? The plain Advantages of other languages still apply. Static typing, fast-ish memory access compiler optimizations and all the plugins and features of your favorite IDE.