Use this before you start

History

It is interesting to be developer these days. Necessity to know programming language is like necessity to know English was let’s say some 40-50 years ago in India. For developers who have been in the circuit for some time clocking laps with advancements in their track of programming; these times are brutal and they are struggling to keep up with this pace, let alone we talk about developers who just entered the circuit.
WebAssembly is one such concept ratified as standard in December of 2019 which has raised hopes of many developers with what they could accomplish with this standard. Then there is another faction of developers / technology enthusiast who are struggling to wrap the concept inside their head.
The incentive to endure this journey is not the use case (no reason to doubt is there a use case at all for such technology) but the necessity to adopt and stay relevant. If you had followed the pace of adoption many libraries and SDK’s have already embraced support for WebAssembly decorated with release trains of browsers as well.
In this dispatch we intend to attempt a format of writing where we introduce you to the avenues which you could treadto use this technology and then dive where we find interest in the coming weeks. Doesn’t this sound much of breadth first style of learning!
This technology has its own track of vivid history. Its enabling components have existed for some time in this space. ASM.JS is a piece of JavaScript code which anyone who have built gaming library will know. It still stands to be a viable alternative on browsers which do not support WebAssembly.
Oh! wait we didn’t engage in the ceremony of introducing WebAssembly. The attempt made in this article was to introduce them using their predecessors but I am reminded that let us not assume that everyone would have cognizance of predecessors or for that reason fiddled with ASM.JS. So here we go –

WebAssembly is an open standard which defines the binary code format supported by multiple browsers.

If this doesn’t sound overwhelming you can get overwhelmed by the definition in the introduction of this technology webpage – https://webassembly.github.io/spec/core/intro/introduction.html.
Returning back to the thread on predecessor of this technology other than ASM.JS there is Google Native Client abbreviated as NaCl (chemical formula for table salt) which supports running binary code from within the browser without dependency on the OS. Such, a capability was off-course sandboxed and also built to eventually role out as ChromeOS.
By now you might have caught the wind on developing and working with WebAssembly might require low level programming which many of us have drifted away long ago. Endure further with strong heart. Weak hearted developers who faint on the appearance of hex code might have problems in working with WebAssembly.
This technology is definitely is not another framework like Angular, Vue, Reactive of something of that category. So, don’t start with that expectation.
Parallels with other such proprietary ventures
Another thing that few of us lads would have got wind of is; wasn’t Microsoft ActiveX, Adobe Flash, Microsoft Silverlight, Java Applets something similar? And have they not succeeded in the past. Weren’t they marketed with similar promises –

Run binary code from browser

Now, that we have JavaScript omnipresent are we fancying with writing low level code using JavaScript? Well the train of thoughts have to stop right there –
1. Yes, we are fancying writing low level code using javascript, but we also can leverage code already written in C, C++, CLANG, C#, F#, Rust code and make it run in browser.
2. In the past these ambitions venture was from a particular vendor and the technology was proprietary with limited support across browsers. Often requiring hacks to make it work across browsers and their versions. That is not true for this technology. It is by working group of many vendors under W3C umbrella and are supported by major browser vendors
3. This technology is for web but is not limited to web. It is expected to not only run in browsers but can be run without any change in non-browser environment as well
Avenues to tread
Before we get running east to west covering the breadth of this technology let us understand one thing very clear; which might be a repetition but in different words though –

WebAssembly is not a language it is not a framework. It is a standard which can be used as target for compiling code written in plethora of programming languages.

Primary goal of this technology is to offer the performance not thought off in web scenarios without introducing complexity of learning a new language. So, this means; you can re-compile your code written in C / C++ / Rust / Typescript / ASM.JS to run as WebAssembly module.
To put this further in perspective consider the current state of affairs in browser application. You can visualize a browser to contain following important components –

Virtual Machine for some might cause unease and they might prefer call it script engine. Feel easy and call it so. No harm. The notion focused here is about having a machine which translates a programming language to instructions which can be executed by the browser.
Today, it is limited to JavaScript. WebAssembly intends to change that and add itself to the list of supported formats for instructions in the Virtual Machine in the above illustration.
Other aspects of browser i.e. WebAPI, the related low-level aspects which are facaded by the WebAPI will remain the same. Thus, making WebAssembly interact with the environment where it is operating.
For those panicky on security; WebAssembly is a standard and the implementor of the runtime and hook which makes WebAssembly interact with environment has the onus to secure the interactions. Sounds, flaky. No problems, for surface browsers, security aspect in WebAssembly is that way. When we finish covering the breadth we will pick this up again (may in a dispatch focused on security itself).
That brings to ambiguity which we intend to rest now and here itself. Does it mean WebAssembly is a pseudo language? Yes, it is a low-level language which if you are interested you can write as well directly using an editor. However, that is something which is you might want to do if you have a solid grasp of the standard. For now, as we start exploring the breadth there are tools that helps us accomplish this goal. Thus, the statement we started with stating WebAssembly is not a language or a framework it is rather a standard [instruction set] which is a target for compiling code written in many languages. Emphasis is the term “instruction set”.
We have enough background and the time is ripe for us developer to explore the directions in which we can explore further.

The avenue to the left is what WebAssembly trumpets to the developer. Take your C / C++ code and use a toolchain like Emscripten to make it a WebAssembly module.Emscripten is merely a popular example. You can very well use or develop your own toolchain if you have appetite for such an endeavour. To get inspired you can browse on WasmFiddle (https://wasdk.github.io/WasmFiddle/) or WasmExplorer (https://mbebenita.github.io/WasmExplorer/).
The central avenue is the costliest of all the avenues in terms of effort you need to endeavour. If you wonder how can one write instructions directly at WebAssembly level, imagine the role of Emscripten in the left avenue, it does the job for you given an C / C++ code. In this avenue instead of Emscripten doing it for you; you need to hand stitch the instruction set. WebAssembly standard not only defines the binary file format it as well defines the text file format which is composed of instruction written in the instruction set of WebAssembly. Strong hearted explorers can browse the standard directly here https://webassembly.github.io/spec/core/text/index.html
The avenue to the right is creative and demands you pick up the language constructs in the manner defined in AssemblyScript (https://docs.assemblyscript.org/). We like the way they introduce themselves “Let’s attempt the unthinkable, shall we?”. The unthinkable is of compiling a high level loosely typed language to something which is closer to the hardware and is very strict in terms of available instructions. The discipline with which this is achieved is AssemblyScript is a subset of Typescript (typed version of javascript; which enables to bring in some discipline in code) and a toolchain Binaryen . This is equivalent to Emscripten and offers the ability to parse JavaScript (transpiled from Typescript) to WebAssembly module.
If you have come this far through this article you should get inspired and sustain the momentum to pick up and build the next wow using this technology –
• WebGL polygons drawn to flyby over mountainous terrain
• WebGL used to build a 2D bouncing ball game
Click around and interact the basic WebAssembly module and check the limitations of these demos in the index page – https://yutakaaoki.github.io/
Here is another inspiration which will inject a developer into the trajectory unthought off till now – Machine Learning model running in browser! Yes, it is becoming possible and ASM.JS was making it happen with many limitations but WebAssembly becoming standard and toolchains supporting WebAssembly expanding exponentially; this is becoming reality. Take that to the next step – fog computing