WebAssembly: Where does it fit?

Paras Bhattrai
Jan 13 · 3 min read

WebAssembly is being pushed to be adopted on scale with all the four major browsers now supporting it. Since the web toolchain is already growing with more new things coming out, it makes sense to question if this is a relevant thing to spend time upon or just another to be skipped. Diving into web assembly, following is a brief in lay man terms.

What is it?

WebAssembly (Wasm) is being described as ‘binary instruction format for a stack based virtual machine’. In short, it means running your compiled C, Rust (and eventually others) on a virtual machine. This could be on your web browser, on the client side. ‘Client side’ being the keyword and hot topic for some debate. Your existing code from a compiled language now can be used on front-end.

Enabling you to not to be limited to only web technologies for your web based needs.

Can it replace JS on front-end with C?

I know some of my friends are already thinking about re writing JS components using compiled language but that is not what Wasm is for. It is meant to fill in the performance/library support gap that exists between native libraries of some languages like C and JS. Now we all know how vast JS libraries are, but for some use cases, we have better alternatives in existing C codebases. This is where WebAssembly comes into picture and allows to use existing code base on web. Famous example of this being Autocad on web. The entire desktop like Autocad running into web browser without re-writing the software in web technologies.

So for now, JS exists in co-relation with Wasm. Giving developer the choice to choose.

Is there any performance gain by design?

When I think of C or Go, I think in terms of threads. The good news is Wasm team is on the move to make this happen, bringing this to web by some clever logic to be used with service workers.

By design, the highlight differences between JS and Wasm lies in how V8 evaluation works. For JS, V8 uses Ignition interpreter which passes on to turbofan optimiser for efficient code generation. Meaning optimiser might always not be sure about exact optimisation to make because of the interpreter nature, hence a provision of de-optimisation in some cases. This on the Wasm side, has the advantage of compilation. Wasm code is used with V8’s liftoff which compiles and turbofan is brought in after, again generating optimised code but only once this time. The peak performance although is almost the same. So pro JS developer would mostly be generating optimised code.

Performance chart at: webassembly-performance-graph

Another proposal to improve performance is supporting SIMD (Single Instruction Multiple Data). This means using more of client’s hardware for some (heavy?) computation. SIMD simply means vectoring multiple similar instructions (e.g., add, subtract) into a single set to be performed at once using the capability of your (client’s) CPU.

Being able to use existing code non-web code bases on web is something some of us were waiting for long to happen. After when JS made it’s debut on the back-end, a front-end language, it is interesting to see back-end languages in front-end arena, let it only be the beginning. Wasm looks promising considering its wide adoption.

Read : ebay-engineering-article

Writing stories with experiences, scripts with Golang. Loves having deep conversations with humans.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade