This blog post describes my first experiences with WebAssembly. I have always tried to avoid front-end development in general, and JavaScript in particular, especially for anything complex, and increasingly as the library churn has increased and relevant toolchains have demonstrated their significant risks. Recently, I investigated TypeScript, which has some advantages, but is just a wrapper that still depends on JavaScript. So, I was excited about WebAssembly as a replacement for JavaScript but have found that my expectations were largely invalid.
As with .NET, multiple language can compile to the .wasm binary code format, which is logically like bytecode compiled from Java in that it converts quickly and easily to machine-specific instruction sets. Any platform – JavaScript in a browser, NodeJS, a C/C++, rust, .NET, or any other executable process on any operating system – can host the WebAssembly virtual machine and invoke WebAssembly modules.
WebAssembly does not appear to be intended for:
- Interacting with the page DOM, including event handlers. Continue to implement DOM interactions with JavaScript, passing data to WebAssembly modules when appropriate.
WebAssembly appears to be appropriate for:
- Complex, high-performance code, especially interacting directly with memory.
- Making existing (tested, high-performance) libraries written in C, C++, rust, and .NET available to JavaScript, whether from the client or the server.
- Implementing client-side code in languages other than JavaScript.
- Anything significantly complex, for which JavaScript may not be the best form of expression.
- Writing code that can run in almost any environment.
WebAssembly is not exactly a language, although there is a textual representation of its bytecode. You compile things written in other languages to WebAssembly. In a browser, WebAssembly is like the glue between JavaScript and these other things – a way of passing values from JavaScript to code written in other languages running in the browser and passing values back from that existing code to that JavaScript. Outside of a browser, WebAssembly is like an abstraction of machine code that any process can invoke, compiled from one of various languages and including some interfaces for exchanging data.
One of challenges with WebAssembly is that not all features are available in all environments. For example, a process may access file systems, but JavaScript in a browser cannot, and even the console is different in JavaScript. Implementations for browsers provide workarounds for some of these limitations, such as something that uses browser local storage to emulate files.
That’s about as far as I have gotten so far.
Deliverystack.net 