DEV Community


Why the heck is everyone talking about WebAssembly?

captainsafia profile image Safia Abdalla ・6 min read

So, I'm gonna be honest with you folks. I do a terrible job of staying up to date on the latest tech. I see things come up on Twitter, I see people talk about it, I add it to my list of things tto learn, and then I never get around to it. It's a vicious cycle. But, it's a new year, so it's the perfect time to break vicious cycles.

Earlier today, I saw a tweet about WebAssembly. I've heard a lot of chatter about WebAssembly over the past couple of years. I've skimmed through the WebAssembly website and even attended a talk on WebAssembly at a conference once. That being said, I've never really taken the time to dive into the technology and really understand what all the enthusiasm was about. Until today. So, why the heck is everyone talking about WebAssembly?


Answering "What?" is usually a good place to start when trying to figure out anything new. The WebAssembly homepage provides this description:

WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications.

This description was definitely not written for people who wanted to learn about WebAssembly in a hurry. I did some snooping around to see if I could find an explainer article that was a little bit more approach. I recall that Lin Clark produced some pretty good content on WebAssmebly so I decided to see if her introductory article would be a little bit more helpful.

I found that her intro was pretty useful. It confirmed that my assumption on what WebAssmebly was was true. WebAssembly is a way to take code in any programming language and run it within a web browser. OK. That's a much more approachable definition and I can immediately see the value of a technology like that. Now, how does it work?


While the "What?" is an interesting question to answer, the "How?" is even more interesting. Anyone who knows me (or has read my previous blog posts) knows that I like to get very nitty gritty when exploring how things work. I figured that for this, I'd start by writing my own program, compiling it down to WebAssembly, and then running it in the browser.

I found that WebAssembly's introductry documentation was a lot more approachable than some of the text on their landing page. I followed the directions under the "Downloading the Toolchain" section. They instructed me to clone the Emscripten SDK and install it on my local machine.

$ git clone
$ cd emsdk
$ ./emsdk install latest
$ ./emsdk activate latest
$ source ./
Enter fullscreen mode Exit fullscreen mode

Much to my surprise, absolutely nothing terrible happened as I ran these steps. That's right. Nothing went wrong when getting set up for something new! What a pleasant surprise.

The next step was to write a "Hello, World!" program in C and compile it to WebAssembly. Once again, the steps under the "Compile and run a simple program" section of the Developer Guide.

So, what essential happened. I wrote a program in C and compiled that program using the Emscripten toolchain. This Emscripten compiler generated a Wasm source file, a JavaScript file, and an HTML file. The HTML page loads the JavaScript file which in turns loads the Wasm source file onto the page. Since I'm using a recent version of Chrome browser, the compiled Webassembly in the Wasm source file is run by the browser.

The WebAssembly program is represented as a plain JavaScript object, aptly called Module in the codebase. This Module object is generated in the javaScript file generated by the Emscripten compiler and stores information about the memory used within a WebAssembly program, the Wasm binary associated with the program, code to manage the runtime status of a program, and more. Essentially, this module encompasses the data and code of a WebAssembly program and can be sent to wherever you need a WebAssembly program to run (like my browser). You can find more information about WebAssembly modules in this design doc.


Now, why WebAssembly? One of the most popular reasons that came up when researching this question was WebAssembly's speed.

Although performance is an important factor for any technology, I don't believe it's the most important factor. I've seen far too many developers sacrafice other important factors (like developer experience and maintainability) at the altar of performance when it wasn't necessary.

To clarify: I'm not dismissing the benefits of WebAssembly's speed in certain contexts. I'm just looking for more pros.

What else does WebAssembly offer? Well, the other obvious big perk is that it expands the types of programs (and by extension programmers) who can deliver their applications through the Web. I can't understate the value of this. It's an interesting premise. I'm curious to see how this will change how people develop on the Web and what impact WebAssembly

The reasons above are compelling for WebAssembly as a technology in general, but I'm curious to know if I might be able to use it directly in the contexts I'm working in. I spend most of my time these days doing full-stack web development with React in the front-end and Node in the backend. I found one rather compelling and interesting use case for someone like me.

From the "How?" section above, you'll recall that WebAssembly runs compiled code within the browser. Because this code is compiled, it has undergone a certain amount of obfuscation.

Despite these, there are still ways to get around this obfuscation. When I was researching this, I came across this paper that discussed ways that compiled WebAssembly modules could be deciphered. When there's a will, there's a way.

Why not?

No technology is perfect. After exploring some of the reasons for WebAssembly, I decided to see if there was any reasons to avoid WebAssembly. What are the shortcomings of WebAssembly?

This was a surprisingly difficult question to answer. I suspect that because WebAssembly is a fairly new technology, it hasn't achieved the criticial mass necessary to spot any bumps or kinks in the technology. Or maybe WebAssembly is flawless and perfect and has absolutely no flaws?

I will say, it would've been a little easier to find reasons not to use WebAssembly before major browsers adopted the technology by default. The fact that Firefox, Chrome, Edge, and Safari all support WebAssembly. All that being said, here's a couple of the things that I've noticed while researching Web assembly.

From the "How" section above, you might recall that the C source code that I wrote was eventually converted to a Wasm binary that was loaded onto the webpage and executed by my browser. There's a whole new asset (the Wasm binary) that needs to be sent down the network to my browser. As with anything that is sent down via the Internet to user's browsers, care needs to be taken to minimize the size of the binary so that it doesn't slow down page load times. This isn't a downside of WebAssembly, per se, just something to watch out for. It's not like this problem doesn't exist with non-Wasm assets on the web. And from my research, it seems like quite a few people have written articles on how to minimize the size of these binaries so shrug, this might not actually be that big a deal.

Another cumbersome issue that I came across when researching WebAssembly is the interpolarity between WebAssembly and JavaScript. For example, how do you invoke a function written in JavaScript from your WebAssembly program (in whatever language it is written in)? I found a Medium article that discussed a work around one developer used and a proposal for allowing the WebAssembly modules that I described in the "How?" section above to be imported like ES6 mdoules.

So yeah, I guess, for the most part the "Why not" for WebAssembly is that it's a fairly new technology and not all the details have been figured out. But from what I read, the champions of the community seemed pretty proactive about responding to issues and creating design proposals for problems so there's that.


Alright! That was a pretty fun exploration. I'm glad that I'm a little bit more confidently informed on what WebAssmebly is. I don't imagine myself using it any time soon, but I think that's because I'm not working in a situation (building 3D games, etc) that would benefit from using WebAssmebly.

Are you currently using WebAssembly? Do you have concrete plans to use it in a feature/product you'll be shipping soon? Did I misunderstand anything about WebAssembly in this blog post?

Discussion (36)

Editor guide
theothertimduncan profile image

I think WebAssembly will have more value for developers who aren't using Javascript for the back-end. Like, um, me. As a C# developer, being able to re-use C# code client side will have a significant impact on how I work. I can't wait until Blazor is mature enough to be used.

captainsafia profile image
Safia Abdalla Author

I see. Do you know which parts of your codebase you'd compile to WebAssembly assuming all the tooling and such is mature?

theothertimduncan profile image

I'm a member of the strongly-typed church. I prefer to catch errors at build time instead of runtime. And one of the things I like about C# and Visual Studio (not VS Code, actual VS) is being able to easily rename properties or methods and have that change automatically done through the entire codebase. It's also nice to be able to quickly and easily see what code is referring to what and where.

This breaks down at the Javascript/C# barrier. As one example, when I'm dealing with json responses to ajax requests, I usually create a class in C# for containing the data which then gets serialized into json. I then have to very wary of changing that class because it could then break the javascript that consumes it. And identifying what may be using that json in the javascript code can be a challenge.

Typescript would help with this but brings some of it's own challenges. WebAssembly would remove the C#/Javascript barrier and let me use C# on both sides. To more specifically answer your question, at a minimum, some of the Javascript code that I would convert to C# would be the code that handles the json responses from the server since I could then have that code use the exact same class used by the server.

Thread Thread
rhymes profile image

Hi Tim, you might want to look into a validator for your JSON. I've never used any of them but you can find some here

WebAssembly, at least for now, it's not going to help much in that, unless you write the entire app in C# with WebAssembly. The thing is that JS and WASM need to continuosly serialize and deserialize data coming from one to the other back and forth. So, if you write the JSON parser/validator in C# it would mean that each time you have to go from JavaScript (used to issue the HTTP call) to C# (to parse and validate the data) to JS (to use such data). That part of WebAssembly is still quite slow.

There a few proposals around to help with that but I think WebAssembly will truly excel for CPU heavy computations or when a lot of concurrency is involved (because they are adding threads to it).

Thread Thread
theothertimduncan profile image

I would use HttpClient in Blazor. But I agree that the interop between Javascript and C# could become an issue.

lisaveras profile image
LV 🏳️‍🌈

Thanks for this post. This is the most straightforward article I've read about Web Assembly.

I think people haven't really started playing with because it involves the browser but it's supposed to be used for tasks that are typically run in the back end. We haven't yet broken through that mentality of having things happen where we expect them to.

rhymes profile image

Nailed it, it requires a (big) shift in mentality.

Some are still trying to understand how to use web workers effectively or edge computing.

By adding WebAssembly (which is getting multi threading) to the mix we'll be able to efficiently run web apps using the CPU of the client instead of running jobs on the server and then delivering the result to the client.

sayanarijit profile image
Arijit Basu • Edited

I'm not against web assembly or anything, but I think the whole idea of client-server architecture was to push processing to the server side and keep the clients as thin as possible. Web assembly lets us use our personal preferred language on the front-end and that's a great thing. But I'd prefer if it somehow restricts the processing to a minimum. I don't want my browser to crash when I open a web page on a budget mobile or laptop.

The last thing I want is websites demanding something like "WARNING: this site requires _ CPU cores and _ gb RAM to work properly in your browser."

Thread Thread
jnday profile image

IMO, it's to balance resources not simply use them in one area. You're essentially looking at Parkinson's Law moving the processing burden back and forth as technology improves in different areas.

Nice article btw!

jtenner profile image

There are technologies now that allow develoeprs to write TypeScript and compile it to Web Assembly. The technology is called AssemblyScript.

I have written an article about it here.

Also, I'm really glad to see Web Assembly catching so much interest! It's going to make a lot of waves in the Web Development community for years to come.

ben profile image
Ben Halpern

I don't foresee myself using WebAssembly so much as using things that make use of WebAssembly. I've been tracking WebAssembly for a while as reason to keep leaning in on the browser as a platform.

Support for WebAssembly is surprisingly far along:

captainsafia profile image
Safia Abdalla Author

Yeah. This was one of the things that impressed me too. Multiple browser engines hopping in to support the technology this early in seems like a really good sign.

ben profile image
Ben Halpern

One interesting case I've read into a bit, but I'll admit I've stayed pretty surface level with is Dropbox developing client-side compression which would be fairly infeasible with JavaScript:

It pushes client-side computing way further than ever possible before in the browser.

Thread Thread
ryan profile image
Ryan • Edited

Client-side compression is a great use case, I didn't even think about that.

If a user wants to take a photo on their phone and post it to a website, they'll upload it in the default maximum resolution and then the server will have to compress it. With wasm the resizing could be done in browser and save bandwidth/data plus server resources.

scapal profile image
Pascal Fautré

One of the big downside of the current node/npm ecosystem is maintainability.
Don't touch at a frontend SPA project for 6 months and I dare you to be able to make it build again.
Even if you have a package lock file, it will just not build nor run anymore.

Same thing about upgrading, there is no elegant way to upgrade the dependencies without breaking everything.

The lack of a really standard library like you could find in Golang gave place to thousands of "< 100 lines of code" libraries of very heterogeneous quality.

Even a quite small frontend project ends up with a thousand dependencies with almost the same amount of different authors and with NPM telling you some of them have critical security.

added 1067 packages from 800 contributors and audited 7442 packages in 204.795s
found 74 vulnerabilities (6 low, 55 moderate, 13 high)

Golang or C++ project I wrote 3 years ago still compile and run as intended.
If I can write a web app in Go, using something like Vugu (, I won't hesitate for a second.

stevetwitte profile image
Stephen Taylor Witte

Great article! I have been keeping up on the general development of Web Assembly ever since it was asm.js and it's really cool to think that soon you could write your software once and have it run on every platform that has a browser. Also if you interested this talk from 2014 is great...

bgadrian profile image
Adrian B.G.

Actually pretty no one is talking about WebAssembly, compared to Blockchain or IoT is still an obscure technology.

Like PWA they need a wide adoption first, and to solve a business need.


ben profile image
Ben Halpern

It's possible that there is a decent amount of "talk" in terms of podcasts, conference talks, etc. But Google trends probably is more reflective of what problems people are solving on a day-to-day basis. I doubt Webassembly is ever going to be the actual concern of that many developers, even if it gains popularity. But idk.

I think blockchain is a huge outlier in its capacity to gain mainstream traction. Even when Webassembly is well-established, I doubt the news will report on it.

steelwolf180 profile image
Max Ong Zong Bao

I like Web Assembly due to it allows ppl to use different languages for Web development and the only company that I know of that has fully adopted it is Figma.

Which I'm one of the developer in my company that uses that design tool in a web browser on Linux machine.

prestongarno profile image
Preston • Edited

There is support for direct C++ to JavaScript function calls using something called "embind" (feature of the emsdk). At work we use I to wrap our C++ API in a js-friendly API. So fast & easy compared to how it used to work where you could only communicate with JSON.stringify or synchronizing state with SharedArrayBuffer.

I think embind might be experimental. At work we have not used it with production code but I can't wait until we do.

leob profile image

So the use case (for now, maybe there's more) is (1) speed, (2) wrote your client side apps in languages other than Javascript? This is a technology that I might be following "from the sidelines" but not spend time on to actively pursue until there are compelling use cases.

syrusakbary profile image
Syrus Akbary

Completely agree with the article.

I'm working with my team at Wasmer to move WebAssembly server-side because of all the nice properties it have to run any kind of software in an universal way (mainly because of it's sandbox design and it's almost native speeds!)

dfockler profile image
Dan Fockler

It's kind of that idea of a universal binary. If your computer can run a browser, it can run a WASM binary file. The coolest part is that it can be distributed just by visiting a website. I think getting webapps even closer to performance parity with native apps is still the goal. Allowing any language to compile to WASM is kind of a nice side-effect of having it running in a browser-based virtual machine.

krishnapg profile image
Gopalakrishna Palem • Edited

Except for Game engines, WebAssembly is pretty much pointless, given the peer W3C standards.

  1. For any high-performance computation, you already have a WebSocket standard that can be used for offloading the computation to high-end servers.
  2. For Visuals, Sound and GPU you have WebGL, WebAudio and WebGPU standards (the last one is upcoming).
  3. For Edge computing, you have WebWorkers (if the device has browser) or other (more better) options in the form of Embedded languages (ERLANG, C etc.)

And then, even for game programming, no AAA-rated game targets WebAssembly. So, unless you are an indie who is using some OSS like Unity for game development, WebAssembly is pretty much useless in business environments.

Not to mention the architectural anti-patterns of mixing the business layer with the presentation layer, which goes back to the same problems of WCF and Java on Web.

To summarize, its pretty much hard to find a genuine real-world business use-case for WebAssembly. It is better to stick to other W3C standards.

jonathansimonney profile image

Precisely my question : it can be used only with language where you have a way of creating a C binary, am I right ?

(Because the article spoke of "any language", but then spoke of creating a C binary.)

stevespringett profile image
Steve Springett

I haven’t followed WASM closely over the past year but to my knowledge, none of the threats I’ve identified have been addressed as of yet. identifies some security concerns to be aware of. There may be more. Like I said, I’ve stayed away and haven’t kept to to date.

codemaster74 profile image
Alexis Rios • Edited

Companies tried to kill Javascript years ago, with plug-ins, applets, activeX, but they affected battery life on mobile devices and raised security concerns, so the industry moved back and revived JavaScript.

JavaScript recently has become a big mess with so many frameworks and incompatibility so, it looks like WebAssembly is the new thing, supported by all major modern browsers, to write code not using JavaScript. Currently you have to write code in TypeScript or something else that gets transpiled to plain old JavaScript, so it would be great to write in any other language of choice and deploy your app to the cloud.

Microsoft for example provides the open source Blazor, that also looks promising, using C# or any other .NET Core language.

Will see if it gets adopted by the industry. Will be great to have native compiled code running on the browser and move away once and for all from JavaScript

pkrasam profile image

Thanks for this post @captainsafia . As a systems engineer, the options provided by WASM becomes very useful as we move into a world where humans begin to interact &/or augment with machines more often. Plus in cases where a machine interacts w/ other machine(s), we need something more native to how they are build and operated. You might find this website also useful:

dmitriz profile image
Dmitri Zaitsev • Edited

Much to my surprise, absolutely nothing terrible happened as I ran these steps. That's right. Nothing went wrong when getting set up for something new! What a pleasant surprise.

With what a terrible state of software we must be living...

seefer007 profile image
Darren Evans • Edited

My view of WebAssembly is that it's a much-needed compilation target in the browser that allows you to write client-side applications in languages other than JavaScript. It's basically democratizing the front-end language space, resulting in more choice for everyone in what language you want to use for web applications. This is a good thing. Different languages have different strengths and WebAssembly allows you to make use of 'the right tool for the right job' philosophy.

You mention that there's a whole new asset, the Wasm binary, that needs to be sent to the browser. Is this also not the case with JavaScript? The JS script source has to be sent to the browser yes? Isn't the only difference in the source code format, namely text vs binary? Or do I have this wrong? I'm a relative newcomer to web development so I may well be mistaken :)

rhymes profile image

The JS script source has to be sent to the browser yes? Isn't the only difference in the source code format, namely text vs binary?

Not just that. WASM is binary and already compiled to there's no parsing nor interpretation nor compilation steps to be had.

sebastiandg7 profile image
Sebastián Duque G

Thanks for the article. Any information about using WebAssembly with the actual web frameworks?

jonathansimonney profile image

Ok. Thank you very much for the answer.

jessekphillips profile image
Jesse Phillips

One person has been working on eliminating the Javascript to use D.